Connector Identification URL

[trueg]

(On behalf of Daimler)

Overview

We think it is important to state that connectors in the IDS should be uniquely identified by their resolvable URL. This not only allows connectors to serve a description of themselves (preferably as an RDF document, for example json-ld), but also goes a long way towards a non-centralized system (as compared to some random UUID given by a central institution).
Furthermore IDs would be human as well as machine-readable at the same time, an advantage that should not be neglected.

Going one step further the self-description of the connector could contain the public key for the certificate of the connector, thus, allowing authentication in a similar way to Web-ID (https://www.w3.org/wiki/WebID).
As such, a connector would require the certificate's private key in order to prove that it controls the URL in question, and, thus, is in fact the connector it claims to be.

While using a mechanism similar to WebID would be preferable from our point of view, the important part is the resolvable URL which provides the connector's self-description and acts as a unique identifier.

Implementation Impact

• Connector certificates need to contain the identifying URL.
• The DAPS needs to include the (verified) connector URL in the authentication token for the connector to use.
• The broker should only list connectors with verified identity URLs.

[HeinrichPet]

Tasks:

• Evaluate with reference to the DAPS/DAT/Identity in general (@gbrost , @jlangkau)
• Evaluate with reference to the self description/Connector (@sebbader, @clange, @tmberthold , @juliapampus )
• Evaluate with reference to the Broker (@sebbader)

[tmberthold]

Sounds like a verified variant of the ids:referringConnector in the token: The RDF connector entity as referred to by the DAT, with its URI included as the value. The value MUST be its accessible URI
https://github.com/International-Data-Spaces-Association/InformationModel/blob/018abfe8a1e96ac842cccc99d4ae1dddfdc838cc/model/security/Token.ttl#L111

[gbrost]

We are starting a concept document here, trying to address this as well as other certification/id topics:
https://github.com/International-Data-Spaces-Association/IDS-ThinkTank/blob/main/connector-identity/concept.md

@trueg The mentioned UUIDs are the ones provided by the Connector to identify data assets, right? Or where do we have UUIDs generated by a central instance?