You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since the decentralized identity world is still very much in flux, new DID-methods are introduced every x months. In Nuts v6 we move away from the did:nuts method in favor of did:web, however, due to the nature of did:web this method is less secure and alternatives are already in the making [1][2]. We therefor want to have the option to follow the latest insights and introduce other did-methods with different properties without the need for vendors to migrate all their DIDs over to a new method.
Proposal
Currently a vendor registers one DID for each subject (customer, system, user etc). This strong correlation between DID and subject makes it less flexible to support multiple did-methods.
We therefor propose a higher level concept Subject to represent an entity which can have multiple identities (e.g. DIDs).
The vendor does no longer interacts with the node APIs using a DID, but with a subject-id. This id is vendor specific and only used local, linked to at least one DID. During an interaction with other systems, the nuts-node will choose the appropriate did-method.
Governance
Which DID method to use when?
Using the TrustOverIP framework the trust trickles down the layers:
The Use Case (Layer 4) trust a Credential Governance (Layer 3). The Credential Governance chooses and trusts a (set of) appropriate DID-methods (Layer 1).
Linking DIDs
In order for other parties to know that several DIDs belong to the same Subject, the AlsKnownAs property of the DID-Document MUST be used. Bidirectional linking should be used: both DID Documents link to each other.
Creating presentations
A holder must be able to configure the preferred DID-method to sign a VP.
Validating Presentations
A Verifiable Presentation MUST be able to contain Credentials with different subject-DIDs for the same subject. The verifier must verify, by resolving the corresponding DID-documents and comparing the values of the AlsoKnownAs set, that the VCs are issued to the same Subject as the signer of the Verifiable Presentation.
Discovery Service
The discovery service currently assumes a subject has only one id. In order to support presentations issued to different subject-ids, the following roles must make changes:
Use-Case owner
The presentation definition must contain prefixes for the accepted did-methods for the subjects. Introducing new did-methods must be coordinated by use-case participants so that every one supports new methods.
Discovery Service Client
The client must understand the subject can have multiple ids and verify the AlsoKnownAs properties. Unknown methods should be ignored
Discovery Service Participant
The participants must sign the VP using the correct did-method so that every participant of the use-case can resolve the DID document and validate the VP.
The text was updated successfully, but these errors were encountered:
Context
Since the decentralized identity world is still very much in flux, new DID-methods are introduced every x months. In Nuts v6 we move away from the did:nuts method in favor of did:web, however, due to the nature of
did:web
this method is less secure and alternatives are already in the making [1][2]. We therefor want to have the option to follow the latest insights and introduce other did-methods with different properties without the need for vendors to migrate all their DIDs over to a new method.Proposal
Currently a vendor registers one DID for each subject (customer, system, user etc). This strong correlation between DID and subject makes it less flexible to support multiple did-methods.
We therefor propose a higher level concept Subject to represent an entity which can have multiple identities (e.g. DIDs).
The vendor does no longer interacts with the node APIs using a DID, but with a subject-id. This id is vendor specific and only used local, linked to at least one DID. During an interaction with other systems, the nuts-node will choose the appropriate did-method.
Governance
Which DID method to use when?
Using the TrustOverIP framework the trust trickles down the layers:
The Use Case (Layer 4) trust a Credential Governance (Layer 3). The Credential Governance chooses and trusts a (set of) appropriate DID-methods (Layer 1).
Linking DIDs
In order for other parties to know that several DIDs belong to the same Subject, the AlsKnownAs property of the DID-Document MUST be used. Bidirectional linking should be used: both DID Documents link to each other.
Creating presentations
A holder must be able to configure the preferred DID-method to sign a VP.
Validating Presentations
A Verifiable Presentation MUST be able to contain Credentials with different subject-DIDs for the same subject. The verifier must verify, by resolving the corresponding DID-documents and comparing the values of the
AlsoKnownAs
set, that the VCs are issued to the same Subject as the signer of the Verifiable Presentation.Discovery Service
The discovery service currently assumes a subject has only one id. In order to support presentations issued to different subject-ids, the following roles must make changes:
Use-Case owner
The presentation definition must contain prefixes for the accepted did-methods for the subjects. Introducing new did-methods must be coordinated by use-case participants so that every one supports new methods.
Discovery Service Client
The client must understand the subject can have multiple ids and verify the AlsoKnownAs properties. Unknown methods should be ignored
Discovery Service Participant
The participants must sign the VP using the correct did-method so that every participant of the use-case can resolve the DID document and validate the VP.
The text was updated successfully, but these errors were encountered: