Integrate DID/SSI

[MoritzKeppler]

Sovereign identities can foster a sovereign data exchange. Beside the DAPS proposed by IDS today we'd like to prepare the EDC for integration of decentralized identifier / self-sovereign identity solutions.

[jimmarino]

From this branch:

https://github.com/eclipse-dataspaceconnector/DataSpaceConnector/tree/gaiax-hackathon/registration-service

[paullatzelsperger]

@jimmarino lets hold on here a bit, i'm currently cleaning that one up considerably. i'll post the relevant PR here when that's done.

[jimmarino]

@beardyinc OK cool. Should we close this out since there is already a PR for this work?

[paullatzelsperger]

we can either close it or link it to #58. However, lets check whether this issues is fully solved by PR #58 or not

[schanzen]

Hey (DAPS operator here). I would just like to point two issues that are also related to the changes in #58:

1. A self-signed JWT is NOT a verifiable credential as stated in the code. If you want to make use of VCs in JWTs, you probably want to put a Verifiable Presentation (VP) derived from a VC into the JWT. See also https://www.w3.org/TR/vc-data-model/#json-web-token. Which brings us to:
2. You will not replace the DAPS with a self-signed DAT. Why should connectors trust the contents? You will still need a DAPS which issues VCs (see also https://www.w3.org/TR/vc-data-model/#json-web-token) which a connector can then use to generate a self-signed JWT containing the VP.

my 2 cents.

EDIT: Maybe also reconsider going hard on the DIDs: https://lists.w3.org/Archives/Public/public-new-work/2021Sep/0000.html

[jimmarino]

Hi,

Thanks for the feedback. To be clear, our approach with federated identity is to use a self-signed token with verifiable presentations and the ability to obtain additional verifiable credentials for a client via an Identity Hub.

In a DID-based system, it is possible to introduce multiple trust anchors, which allow providers to verify JWT claims and verifiable credentials obtained from an Identity Hub.

One of the reasons we are investigating federated identities is because some of our use cases stipulate that no central authority be required to anchor identities in a dataspace. Also, we want to remove single points of failure, which many OAuth2-based implementations are susceptible to.

Of course, users can choose which identity model suits their needs with the EDC. There is an OAiuth2 implementation that can be cleanly swapped with the distributed identity implementation (or implementations if people want to support multiple ways of achieving federated identity).

For more details on the approach to federated identity we are pursuing, see the following specs. We're happy to answer questions as they arise.

https://identity.foundation/identity-hub/spec/ https://identity.foundation/sidetree/spec/ https://w3c-ccg.github.io/did-method-web/ https://www.w3.org/TR/did-core/

[schanzen]

Hi,

Thanks for the feedback. To be clear, our approach with federated identity is to use a self-signed token with verifiable presentations and the ability to obtain additional verifiable credentials for a client via an Identity Hub.

I was commenting on the code, which does not implement what you imply.

In a DID-based system, it is possible to introduce multiple trust anchors, which allow providers to verify JWT claims and verifiable credentials obtained from an Identity Hub.

You can always introduce multiple trust anchors even now. The trust is essentially established at the discretion of the callee (the endpoint verifying the DAT). Whichever trust sources you have configured there are trusted. Nothing is keeping you from trusting multiple different DAPS instances. Trust does not come form the ether of a ledger or the DID spec. It comes from specific configurations on the endpoint.

One of the reasons we are investigating federated identities is because some of our use cases stipulate that no central authority be required to anchor identities in a dataspace. Also, we want to remove single points of failure, which many OAuth2-based implementations are susceptible to.

But you will not solve this issue. I think there is a misunderstanding here on what the DAPS is for. It is not relevant which standards you use or architecture you build it on. If you have a single point of trust you have single point of failure. It does not matter which format of token you choose. Verifiable Credentials also expire. So it does not matter if you use OAuth or any other mechanism to retrieve them.

Of course, users can choose which identity model suits their needs with the EDC. There is an OAiuth2 implementation that can be cleanly swapped with the distributed identity implementation (or implementations if people want to support multiple ways of achieving federated identity).

You are conflating protocol standards with trust management. SSI does not change the trust model. It simply moves responsibility of handling credentials to the credential holder and limits interaction with IdPs. Also, formats like VCs offer flexibility wrt PABCs for selective disclosure.

Note I am not arguing against the use of VCs and SSI. I am simply pointing out that by doing so you will not achieve the goal which is claimed in the OP of this issue. You will still have issuers which are essentially DAPS instances. Whether you call them DAPS instances or not is irrelevant. Those issuers will have to be configured as trust anchors somehow on the endpoints.

For more details on the approach to federated identity we are pursuing, see the following specs. We're happy to answer questions as they arise.

https://identity.foundation/identity-hub/spec/ https://identity.foundation/sidetree/spec/ https://w3c-ccg.github.io/did-method-web/ https://www.w3.org/TR/did-core/

As you can see from the link I posted, the DID efforts seem to be going nowhere for now. Committing on anything beyond VCs and possibly SIOP seems like a gamble.

BR

[jimmarino]

Hi, Thanks for the feedback. To be clear, our approach with federated identity is to use a self-signed token with verifiable presentations and the ability to obtain additional verifiable credentials for a client via an Identity Hub.

I was commenting on the code, which does not implement what you imply.

Could you point out where that is the case? There are still parts of the code that need to be completed and filled out (it is still experimental), but I don't see how the existing code inhibits our goals.

In a DID-based system, it is possible to introduce multiple trust anchors, which allow providers to verify JWT claims and verifiable credentials obtained from an Identity Hub.

You can always introduce multiple trust anchors even now. The trust is essentially established at the discretion of the callee (the endpoint verifying the DAT). Whichever trust sources you have configured there are trusted. Nothing is keeping you from trusting multiple different DAPS instances. Trust does not come form the ether of a ledger or the DID spec. It comes from specific configurations on the endpoint.

I think we should be careful here. I didn't say that it is impossible to introduce multiple trust anchors with existing security infrastructure. I said it is possible to do so with DID-based systems (and arguably in a more flexible way, but that is a separate discussion).

One of the reasons we are investigating federated identities is because some of our use cases stipulate that no central authority be required to anchor identities in a dataspace. Also, we want to remove single points of failure, which many OAuth2-based implementations are susceptible to.

But you will not solve this issue. I think there is a misunderstanding here on what the DAPS is for. It is not relevant which standards you use or architecture you build it on. If you have a single point of trust you have single point of failure. It does not matter which format of token you choose. Verifiable Credentials also expire. So it does not matter if you use OAuth or any other mechanism to retrieve them.

I am not sure I follow why we will not solve the issue.

We should be careful about terms here as well. Some of our use cases require that a central authority must not be needed to anchor identities. This means participants must be in control of their identities. This can be achieved by anchoring a DID in a DLT or using another mechanism such as web DIDs, in combination with an Identity Hub. My understanding is that no matter how many "DAPS" systems there are, there is always the possibility that the participant's (central) identity provider can "pull the plug" and invalidate its identity. Having multiple (central) identity providers does not solve that problem.

My other point was that many (not all) OAuth2 implementations are susceptible to being single-points of failure. Again, it doesn't matter how many identity providers you have in a system. If one of the providers goes down, a significant portion of the dataspace will be rendered inoperable. Achieving reliability in this model is difficult since it requires features such as geographic replication and fault-tolerance that few infrastructures support.

In our approach, these risks are mitigated by the ubiquity of DLT technologies or having each participant host their own DID document via web DIDs.

Of course, users can choose which identity model suits their needs with the EDC. There is an OAiuth2 implementation that can be cleanly swapped with the distributed identity implementation (or implementations if people want to support multiple ways of achieving federated identity).

You are conflating protocol standards with trust management. SSI does not change the trust model. It simply moves the responsibility of handling credentials to the credential holder and limits interaction with IdPs. Also, formats like VCs offer flexibility wrt PABCs for selective disclosure.

I don't understand how my previous statement conflates protocol standards and trust management. I was saying that the EDC architecture allows for choice. Users can choose an OAuth2 model, DAPs, federated identity, or another approach that fits their use case if they elect to implement the appropriate extensibility points.

FWIW, Identity Hubs are designed to support selective disclosure.

Note I am not arguing against the use of VCs and SSI. I am simply pointing out that by doing so you will not achieve the goal which is claimed in the OP of this issue. You will still have issuers which are essentially DAPS instances. Whether you call them DAPS instances or not is irrelevant. Those issuers will have to be configured as trust anchors somehow on the endpoints.

I don't think anyone associated with this PR is claiming we are attempting to remove trust anchors. We're actually trying to do the opposite: enable a flexible and robust way for participants to choose which trust anchors they want to use.

In my mind DAPS is basically an implementation. I don't think we should use the term interchangeably with "identity provider" or "trust anchor". In any event, the key thing we would like to achieve with EDC is choice. A one-size-fits-all approach to identity is not going to work for our users given their different use cases and requirements. IMO, we need to adopt an open architecture to accommodate this reality.

For more details on the approach to federated identity we are pursuing, see the following specs. We're happy to answer questions as they arise. https://identity.foundation/identity-hub/spec/ https://identity.foundation/sidetree/spec/ https://w3c-ccg.github.io/did-method-web/ https://www.w3.org/TR/did-core/

As you can see from the link I posted, the DID efforts seem to be going nowhere for now. Committing on anything beyond VCs and possibly SIOP seems like a gamble.

BR

I and others have a different view on this. The good thing is that the EDC architecture is flexible enough for people to choose which extensions and identity implementations best fit their needs.

[schanzen]

Hi, Thanks for the feedback. To be clear, our approach with federated identity is to use a self-signed token with verifiable presentations and the ability to obtain additional verifiable credentials for a client via an Identity Hub.

I was commenting on the code, which does not implement what you imply.

Could you point out where that is the case? There are still parts of the code that need to be completed and filled out (it is still experimental), but I don't see how the existing code inhibits our goals.

I did not find any JWTs which implement any standard asserted third party claim. It is quite a bit PR, sorry if I might noth ave looked at everything. So if there is something I missed, I would be happy to look at that.

In a DID-based system, it is possible to introduce multiple trust anchors, which allow providers to verify JWT claims and verifiable credentials obtained from an Identity Hub.

You can always introduce multiple trust anchors even now. The trust is essentially established at the discretion of the callee (the endpoint verifying the DAT). Whichever trust sources you have configured there are trusted. Nothing is keeping you from trusting multiple different DAPS instances. Trust does not come form the ether of a ledger or the DID spec. It comes from specific configurations on the endpoint.

I think we should be careful here. I didn't say that it is impossible to introduce multiple trust anchors with existing security infrastructure. I said it is possible to do so with DID-based systems (and arguably in a more flexible way, but that is a separate discussion).

One of the reasons we are investigating federated identities is because some of our use cases stipulate that no central authority be required to anchor identities in a dataspace. Also, we want to remove single points of failure, which many OAuth2-based implementations are susceptible to.

OAuth2 does not impose anything on user identities. It is an authorization protocol. In fact, the OpenID Connect profile for federation/discovery would contradict this statement.

But you will not solve this issue. I think there is a misunderstanding here on what the DAPS is for. It is not relevant which standards you use or architecture you build it on. If you have a single point of trust you have single point of failure. It does not matter which format of token you choose. Verifiable Credentials also expire. So it does not matter if you use OAuth or any other mechanism to retrieve them.

I am not sure I follow why we will not solve the issue.

We should be careful about terms here as well. Some of our use cases require that a central authority must not be needed to anchor identities. This means participants must be in control of their identities. This can be achieved by anchoring a DID in a DLT or using another mechanism such as web DIDs, in combination with an Identity Hub. My understanding is that no matter how many "DAPS" systems there are, there is always the possibility that the participant's (central) identity provider can "pull the plug" and invalidate its identity. Having multiple (central) identity providers does not solve that problem.

My other point was that many (not all) OAuth2 implementations are susceptible to being single-points of failure. Again, it doesn't matter how many identity providers you have in a system. If one of the providers goes down, a significant portion of the dataspace will be rendered inoperable. Achieving reliability in this model is difficult since it requires features such as geographic replication and fault-tolerance that few infrastructures support.

In our approach, these risks are mitigated by the ubiquity of DLT technologies or having each participant host their own DID document via web DIDs.

Of course, users can choose which identity model suits their needs with the EDC. There is an OAiuth2 implementation that can be cleanly swapped with the distributed identity implementation (or implementations if people want to support multiple ways of achieving federated identity).

You are conflating protocol standards with trust management. SSI does not change the trust model. It simply moves the responsibility of handling credentials to the credential holder and limits interaction with IdPs. Also, formats like VCs offer flexibility wrt PABCs for selective disclosure.

I don't understand how my previous statement conflates protocol standards and trust management. I was saying that the EDC architecture allows for choice. Users can choose an OAuth2 model, DAPs, federated identity, or another approach that fits their use case if they elect to implement the appropriate extensibility points.

Because the form factor of the implementation of an attestation (JWT, VC) is independent from the identities.

FWIW, Identity Hubs are designed to support selective disclosure.

Note I am not arguing against the use of VCs and SSI. I am simply pointing out that by doing so you will not achieve the goal which is claimed in the OP of this issue. You will still have issuers which are essentially DAPS instances. Whether you call them DAPS instances or not is irrelevant. Those issuers will have to be configured as trust anchors somehow on the endpoints.

I don't think anyone associated with this PR is claiming we are attempting to remove trust anchors. We're actually trying to do the opposite: enable a flexible and robust way for participants to choose which trust anchors they want to use.

In my mind DAPS is basically an implementation. I don't think we should use the term interchangeably with "identity provider" or "trust anchor". In any event, the key thing we would like to achieve with EDC is choice. A one-size-fits-all approach to identity is not going to work for our users given their different use cases and requirements. IMO, we need to adopt an open architecture to accommodate this reality.

This is the misunderstanding in conjunction with what you wrote above. A DAPS does not handle identities. After all, the "AP" stands for "attribute provisioning". It issues credentials to identities. It acts as an issuer (as in VC isser or JWT issuer) of claims. Identities are what the callers already need to have prior to obtaining DATs. Usually provisioned by a CA (which is already a distributed mechanism for identities). In order to retrieve a DAT, which is issued by the DAPS, connectors need to authenticate with their identity. The DAPS does not care where the identity comes from per se. But it depends on the DAPS operator if it has anything to say about those identities, of course. But that will always be the case independent of the technology and this is exactly my point: DATs are essentially things a third party says about the identity. For example because it did some kind of audit or certification. It may even be the manufacturer. This is important, as this third party is the only one able to make those claims. Self-attesting the claims in the DAT does not make sense as they cannot be meaningfully verified. Yes, the DAT may be self-signed, but then it would still require the claims of a DAPS. Either using, for example, OIDC aggregated/distributed claims or verifiable credentials/presentations. If the claims are not verifiable in a self-contained attestation, then it must be done out of band but that is another story. Now the crux is that in the OP it said that the EDC is used besides the DAPS. I am pointing out that unless you do not care about claims you will always need one or more DAPS depending on your trust model/use case.

For more details on the approach to federated identity we are pursuing, see the following specs. We're happy to answer questions as they arise. https://identity.foundation/identity-hub/spec/ https://identity.foundation/sidetree/spec/ https://w3c-ccg.github.io/did-method-web/ https://www.w3.org/TR/did-core/

As you can see from the link I posted, the DID efforts seem to be going nowhere for now. Committing on anything beyond VCs and possibly SIOP seems like a gamble. BR

I and others have a different view on this. The good thing is that the EDC architecture is flexible enough for people to choose which extensions and identity implementations best fit their needs.

Sure, I was just pointing out the development in case you may have missed it as it is relevant.

[jimmarino]

Could you point out where that is the case? There are still parts of the code that need to be completed and filled out (it is still experimental), but I don't see how the existing code inhibits our goals.

I did not find any JWTs which implement any standard asserted third party claim. It is quite a bit PR, sorry if I might noth ave looked at everything. So if there is something I missed, I would be happy to look at that.

That's not the point of this PR. There is an extensibility layer where this will be handled. To discuss further, please open a discussion topic as this thread is becoming unmanageable and starting to veer off into other topics not related to the PR itself.

One of the reasons we are investigating federated identities is because some of our use cases stipulate that no central authority be required to anchor identities in a dataspace. Also, we want to remove single points of failure, which many OAuth2-based implementations are susceptible to.

OAuth2 does not impose anything on user identities. It is an authorization protocol. In fact, the OpenID Connect profile for federation/discovery would contradict this statement.

I didn't say OAuth2 imposes something on user identities. I just said we are looking at a federated identity system because: (1) we do not want to require centralized authorities for anchoring identities; and (2) we don't want a single point of failure that many (but not all) OAuth2 implementations introduce (which is distinct from point 1). Those are two separate reasons.

I don't understand how my previous statement conflates protocol standards and trust management. I was saying that the EDC architecture allows for choice. Users can choose an OAuth2 model, DAPs, federated identity, or another approach that fits their use case if they elect to implement the appropriate extensibility points.

Because the form factor of the implementation of an attestation (JWT, VC) is independent from the identities.

We're just talking past each other. I didn't say or imply this.

FWIW, Identity Hubs are designed to support selective disclosure.

Note I am not arguing against the use of VCs and SSI. I am simply pointing out that by doing so you will not achieve the goal which is claimed in the OP of this issue. You will still have issuers which are essentially DAPS instances. Whether you call them DAPS instances or not is irrelevant. Those issuers will have to be configured as trust anchors somehow on the endpoints.

I think you are misunderstanding the goal of this PR and our work on federated identity in general. I don't want to distract from the technical discussion here so if you would like to continue, please open a discussion thread stating what you believe our goals to be and why you think we will not achieve them. We can then respond to those in turn.

This is the misunderstanding in conjunction with what you wrote above. A DAPS does not handle identities. After all, the "AP" stands for "attribute provisioning". It issues credentials to identities. It acts as an issuer (as in [VC isser]

The DAPS does not care where the identity comes from per se. But it depends on the DAPS operator if it has anything to say about those identities, of course. But that will always be the case independent of the technology and this is exactly my point: DATs are essentially things a third party says about the identity. For example because it did some kind of audit or certification. It may even be the manufacturer. This is important, as this third party is the only one able to make those claims. Self-attesting the claims in the DAT does not make sense as they cannot be meaningfully verified. Yes, the DAT may be self-signed, but then it would still require the claims of a DAPS. Either using, for example, OIDC aggregated/distributed claims or verifiable credentials/presentations. If the claims are not verifiable in a self-contained attestation, then it must be done out of band but that is another story. Now the crux is that in the OP it said that the EDC is used besides the DAPS. I am pointing out that unless you do not care about claims you will always need one or more DAPS depending on your trust model/use case.

Please have a look at the Identity Hub specification. You are misinterpreting what this PR is and how the code works. We are not trying to remove third-party attestation. In fact, we are trying to do the exact opposite - offer a flexible framework in the EDC to handle this that aligns with the requirements of many users.

One of the main points of this PR is to enable the use of self-sovereign identities as described in this PR and the documentation accompanying the code. Currently, DAPS does not map well to that world. Many use cases may not care about that and maybe DAPS will handle self-sovereign identities in the future. At the same time, there is strong interest in this project to explore alternatives based on distributed identity standards work currently being undertaken by the W3C and DIF. Fortunately, the EDC extensibility architecture allows for both centralized and federated models, and users can choose which works best for them.

I and others have a different view on this. The good thing is that the EDC architecture is flexible enough for people to choose which extensions and identity implementations best fit their needs.

Sure, I was just pointing out the development in case you may have missed it as it is relevant.

OK. We're aware of these developments as some of the people helping with this PR sit on the standards boards and technical committees involved in distributed identity.

[jimmarino]

Closing as this work has been integrated.