Decentralized identifiers

Nuts uses W3C Decentralized Identifiers as a base for tracking identities. From the W3C website:

Decentralized identifiers (DIDs) are a new type of identifier that enables verifiable, decentralized digital identity. A DID identifies any subject (e.g., a person, organization, thing, data model, abstract entity, etc.) that the controller of the DID decides that it identifies. In contrast to typical, federated identifiers, DIDs have been designed so that they may be decoupled from centralized registries, identity providers, and certificate authorities. Specifically, while other parties might be used to help enable the discovery of information related to a DID, the design enables the controller of a DID to prove control over it without requiring permission from any other party. DIDs are URIs that associate a DID subject with a DID document allowing trustable interactions associated with that subject.

Within Nuts, DIDs identify different parties. All DID methods require their own specification. The Nuts specification for the nuts DID method can be found on https://nuts-specification.readthedocs.io. Nuts DIDs are designed so they represent public/private key pairs. Any party can generate and claim a key pair. Only when information is added to the key pair, the key pair becomes important.

DIDs can gather claims through Verifiable Credentials. This allows a DID to actually represent something known in real life. For example: adding an organization name credential connects the key pair to the name of the organization. It connects the digital world to the real world.

Nuts DID Documents

DIDs are backed by a DID Document. It defines the public keys, who can alter the document and any services related to the DID. Nuts DID documents are automatically propagated through the network when they are created. When DID documents are created, the DID always represents the public key fingerprint of the associated key. A DID document is always created with a new key. Signing keys are are added to the authentication, assertionMethod, capabilityInvocation and capabilityDelegation sections. Encryption keys are added to the keyAgreement section.

Services

The services section is used to list service endpoints. Although still available, the preferred way is to register services via Discovery.

did:x509

In did:x509 a certificate is converted to a DID Document (that includes its entire certificate chain) so it can be used in the Verifiable Credentials ecosystem. This DID Method provides a temporary bridge between the ‘old’ world of CAs/Certificates and the ‘new’ Verifiable Credential world. With other DID Methods, certificates are only used to create a secure channel for communication and optionally for client authentication. In did:x509 the certificates are also used in the cryptographic proofs to obtain access-tokens. This means the certificate chain now provides the root of trust and has stricter requirements than connection certificates.

Trust in specific certificate CAs is configured per use-case in a Discovery and Access policies definition file. CRLs from the trusted chains (per those definition files) are consulted when evaluating did:x509 Verifiable Credentials; see Certificate revocation (CRL) handling for how a failure to download a CRL is handled — for did:x509 this always hard-fails.