search

nuts-foundation / nuts-node

The reference implementation of the Nuts specification. A decentralized identity network based on the w3c ssi concepts with practical functionality for the healthcare domain.
https://nuts-foundation.gitbook.io
GNU General Public License v3.0
22 stars 14 forks source link

Support multiple DIDs per subject #3187

Open stevenvegt opened 3 weeks ago

stevenvegt commented 3 weeks ago

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.

reinkrul commented 3 weeks ago

This is more an issue for https://github.com/nuts-foundation/nuts-specification?

woutslakhorst commented 2 weeks ago

This is more an issue for https://github.com/nuts-foundation/nuts-specification?

true, but we operate more on the backlog here than there.

woutslakhorst commented 2 weeks ago

todo list in #3191