On federated identity management (on federated data spaces)

[panosprotopapas]

Hello,

I'm posting this here as I don't really know where it fits best, and I'd like to inquire on whether this is something that is already supported by Sovity-edc, if it is planned for the future, and also share some ideas around this.

I've been testing a PoC deployment where I have 2 separate Sovity-DAPS (Keycloak) deployments each having a single connector registered as a client with them and deployed in production mode. I'm assuming a different data space authority is administering each Keycloak deployment. Hence having the two connectors negotiate and exchange data between them would imply the existence of a federated data space connecting the two otherwise separate data spaces.

I was able to achieve this by having the Keycloak /certs endpoint serve 4 public keys instead of 2, that is, the 2 public keys of both Keycloak deployments. Each connector is contacting their local Keycloak for a token, which is signed by their local Keycloak's private key, but when sent to the other connector the token is recognised since the other connector has received the corresponding public key from the /certs endpoint when being initialised.

From a security point of view, this only required each data space authority (Keycloak) getting hold of the public keys of the other Keycloak and then serving them as trusted public keys to their local connectors. Of course, this give rise indirectly to a huge risk, that 2 connectors could have the same participant-id, since the 2 Keycloak deployments don't check each other for id uniqueness (not sure if this can be achieved/enforced within Keycloak(s)).

Based on this, I was thinking that perhaps a more granular treatment of the tokens produced by different DAPS would make sense. Instead of only being interested in the client_id part of the token for identification, the iss providing the Keycloak realm's URI could be used as well to produce a 2-tier ID that also includes a DAPS-id (assuming measures to prevent spoofing of the iss field are in place).

In my view, this naturally gives rise to new data sharing policies like "share this with everyone on DAPS-xyz" or "share this with connector-1 from DAPS-abc".

Would this be something that you are considering for the near future?

Thanks a lot!

[tmberthold]

Based on this, I was thinking that perhaps a more granular treatment of the tokens produced by different DAPS would make sense. Instead of only being interested in the client_id part of the token for identification, the iss providing the Keycloak realm's URI could be used as well to produce a 2-tier ID that also includes a DAPS-id (assuming measures to prevent spoofing of the iss field are in place).

In my view, this naturally gives rise to new data sharing policies like "share this with everyone on DAPS-xyz" or "share this with connector-1 from DAPS-abc".

Would this be something that you are considering for the near future?

Hello and thank you for the concept (I'll just call it that). I will pass this on internally and see what the others think about this.

[tmberthold]

@panosprotopapas Thank you again for your suggestion and for taking the time to share your concept with us. After discussing this internally, we've decided that this is not something we are planning on our roadmap.

We though truly appreciate your input, as it helps us better understand the needs and interests.
Please feel free to share any other ideas or suggestions in the future - we're always open to feedback.

[panosprotopapas]

Thank you for the consideration and the quick reply (as always). I'll be sure to share any new suggestion in the future.