Registration as DataService in did doc

[arnoweiss]

In Tractus-X, there's a mechanism that auto-registers a connector at its own did service. It's subdivided into implementation-agnostic SPI [1], registration logic [2] and an implementation for SAP DIV [3]. Perhaps the former two could be extensions relevant for the upstream Connector project.

If adoption isn't desired, maybe it would be a good feature to reimplement upstream.

[1] https://github.com/eclipse-tractusx/tractusx-edc/tree/main/spi/did-document-service-spi
[2] https://github.com/eclipse-tractusx/tractusx-edc/tree/main/edc-extensions/did-document/did-document-service-self-registration
[3] https://github.com/eclipse-tractusx/tractusx-edc/tree/main/edc-extensions/did-document/did-document-service-dim

[arnoweiss]

Additon: There's a feature request downstream now to implement this feature for the IdentityHub Identity API [1].
cc @paullatzelsperger - would love to get your take here.

[1] eclipse-tractusx/tractusx-edc#2678

[paullatzelsperger]

First, when creating participant contexts (~users) in IdentityHub, there is a way to provide a list of service endpoints directly on creation. As a common pattern, a ProtocolEndpoint and a CredentialService endpoint are provided, but additional ones could be provided as well. IdentityHub has an API to CRUD service endpoints later.

The much larger issue though is that in my opinion the connector should never directly communicate with IdentityHub (or DIV or any other wallet) using their respective management APIs for several reasons:

• tight coupling: this would require the connector to have knowledge of the absolute URL of the wallet component, plus, the connector would need to have authentication privileges for the API.
• genericity: the specific APIs for every wallet component (DIV, IH, ...) would need to be implemented in the connector. This does not scale well and will cause problems when users bring their own wallet.
• separation of concerns: to me, it's not the connector's job to perform deployment tasks and registering an endpoint could be regarded as such.
• clusterability: this will almost certainly cause consistency problems in clustered/replicated runtimes.

Instead, deployment tasks like that, registering endpoints, creating participant contexts etc. should be performed by an orchestration tool, such as Terraform, Ansible, a shell script, etc.

I strongly advise against implementing this directly in the connector.

[arnoweiss]

Thanks for the feedback. I don't share all fundamental concerns mentioned - your point on separation of concerns though is valid, especially for multi-tenant systems.