RFC011 Verifiable Credential
Last updated
Last updated
This RFC describes the generic requirements for Verifiable Credentials (VC) within the Nuts specification. It also lists all required chapters for a specific VC RFC. This RFC uses the Verifiable Credential Data Model specification.
This document describes a Nuts standards protocol.
This document is released under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.
It's to be expected that multiple parties can assert certain claims with information about a subject. These claims have to be structured in such a way that they are verifiable and searchable. Examples of such claims are a company name, or its chamber of commerce number. Users can search on the name of an organization to find out which services are supported. This will directly influence the interaction the user can have with the system of that organization. Making sure this information is correct and that it can be trusted is therefore extremely important.
holder: The party that receives a VC from an issuer.
issuer: The party that issues a VC.
proof: Proof asserting that a VC is valid using cryptography.
VC: Verifiable Credential according to the Verifiable Credential Data Model.
VP: Verifiable Presentation according to the Verifiable Credential Data Model.
To support a variety of claims, Nuts uses the Verificable Credential (VC) format as described by W3C Verifiable Credential specification. Every Nuts specific VC and proof type must follow the W3C specification. If the W3C specification offers optional fields then the specification of that credential must specify if and how they should be used. All VCs MUST use DIDs as specified in RFC004 to reference the issuer.
Verifiable Credentials are usually represented in JSON-LD format. Every JSON-LD document requires one or more context definitions. Every Nuts VC type and proof type SHOULD be specified in the Nuts JSON-LD context. Nodes MUST support this context and the W3C Verifiable Credential context. A node MAY support additional contexts.
To ensure the authenticity and integrity of the VC, a VC document MUST contain an embedded proof in a proof section as described in section 2.2.1 of Verifiable Credential Data Integrity Specification. The following proof types must be supported by a Nuts node implementation:
This signature suite is specified by https://w3c-ccg.github.io/lds-jws2020. It uses a detached JWS for presenting the signature in the jws part of the proof. RFC7797 describes how a detached JWS works. The hashing algorithm MUST be of type ES256.
The proof MUST have a verificationMethod which contains an assertMethod ID from a resolvable Nuts DID Document of a public key of the JSONWebKey2020 type.
All VCs MUST have a content-type equal to application/vc+json when published on the network. VCs MAY NOT specify more than one additional type next to VerifiableCredential.
VCs are not updatable, an update can be performed by revoking the current and issuing a new VC.
VC identifiers MUST be constructed as DID#id where id is unique for the given issuer.
A VC MUST have an active issuer at the time of usage. Usage includes using the VC to generate a VP or sending it along in an OAuth flow. If the issuer is deactivated at the time of usage, the VC MUST be regarded as invalid.
If a VC issuer is a Nuts DID Subject and the VC is published via a transaction according to RFC004 and RFC005 then the transaction MUST refer to the correct transaction as specified by RFC004. This ensures the correct ordering of transactions.
Below is an example of a credential. Issuer and Subject are the same in the example. This specification neither requires nor prevents this.
All the following chapters MUST be present in the specification of a VC.
It MUST specify the contents of the credentialSubject JSON field. It MUST specify which parts of the credentialSubject are mandatory or optional, and the format.
A VC specification MUST specify how a VC is issued and if there are any requirements on the issuer. It MUST specify any requirements for the holder. It MUST specify if VCs or other credentials are required in order to obtain the VC. It MUST specify the content-type type selector.
It MUST specify which proof types are acceptable or if there's a limitation to certain proof types. This also means that specifications SHOULD to be updated when new proof types are available.
It MUST list the requirements for when a VC is to be trusted. It could, for example, require every node to trust a certain issuer by default.
It MUST specify how a VC can be revoked by the issuer, or it MUST specify an expiration duration. It MAY refer to the default revocation mechanism stated below.
VCs that are issued by a Nuts DID can be revoked by publishing the following transaction on the network:
Such a revocation transaction has the following requirements:
the issuer MUST match the DID as the issuer field of the VC.
the subject MUST match the id field of the VC.
a reason MAY be filled with a revocation reason.
the date MUST provide the date in RFC3339 format. From this moment in time the VC is revoked.
the proof MUST be a JsonWebSignature2020 proof.
The transaction MUST be published on the Nuts network. The content-type is application/vc+json;type=revocation
The signature is calculated as stated in §3.1.1.
It MUST specify where the VC SHOULD be used: as requirement for other VCs, in the OAuth flow according to RFC003 or any other use case. If a VC can be used in a Verifiable Presentation (VP), it MUST specify if additional VCs are to be expected in the VP. It SHOULD describe the use case well enough so any implementation can take appropriate measures for optimizing querying/checking, such as indexing certain fields.
It MUST specify if a VC SHOULD be published via some means. It MUST specify if it contains personal information as identified by the GDPR or local legislation. It MUST specify who MAY receive and/or store the VC.
It MUST specify if other services than the Nuts network are required for the VC to be issued and/or obtained. If so, it MUST specify the protocol.
Nuts foundation
W.M. Slakhorst
Request for Comments: 011
Nedap
February 2021
