By Maaike van Leuken (TNO)
Last revision: 06-03-2023
Standard: a neat document written by a standardisation body in which a technology is defined.
Specification: a neat document in which a technology is defined. The difference with a standard is that the document was not written by a recognised standardisation body.
Standardisation body: W3C, DIF, OIDF, Aries, ...
Technology: a technical protocol, concept, architecture, ... that can be used to achieve a certain goal.
Proof format: the cryptographic algorithm used to make a proof in the creation of the presentation. Examples of proof formats are JWS, Ed25519, ECDSA, RSA, ... .
Credential format: the format along which the claims are structured, such as JSON, JSON-LD, ABC, ... .
The term ID token is used as defined in the OIDC Terminology.
The term VP token is used as defined in the OIDC4VP standard.
The terms credential, claim, presentation, verifiable credential and verifiable presentation are used as defined in the W3C VC Data Model Glossary.
The terms credential application and credential response are used as defined in the DIF Credential Manifest Glossary.
The terms self-sovereign identity, issuer, holder, verifier, subject, party, delegation, mandate ... are defined in the eSSIF-Lab Glossary.
The terms self-certifying identifier and self-authenticated identifier are used as defined in tbd.
The terms identifier, link secret, presentation definition and presentation submission are defined in the DIF Presentation Exchange Terminology.
The terms mdoc, mDL, mDL reader and mDL holder are used as defined in ISO/IEC 18013-5:2021 (mDL).
There is a large amount of standardisation developed and in development within the context of Self-Sovereign Identities (SSI). The standards and specifications vary from legacy technologies to new and upcoming technologies, from specifications on cryptographic signature schemes to usability and inclusivity concepts such as guardianship. Whenever looking into a standard or specification, it can be hard to place it in the bigger picture:
We have made a graphical overview of the situation trying to answer these questions, which can be found here. Here you see the basic model. To answer the questions above, we want to give the relation between various technologies. This becomes fuzzy quickly. To keep it uncluttered, we have made buttons on the bottom that can be used to toggle specific views.
The overview graphically answers the questions above more or less. This document will describe the structure of the graphical overview and give a description for each technology mentioned in the graphical display.
This document is made in such a manner that it is accessible to all parties working with or wanting to work with SSI. We will explain each technology in the overview on a high level. Links to the specification are given for further (more technical) reading.
This document has been developed for the Dutch Blockchain Coalition (DBC) and has been discussed with multiple technical experts.
Both this document and the graphical overview are living documents. The amount of specifications is ever-growing and updates of specifications are brought out periodically. We will try our best to keep our resources up-to-date. We also welcome any input from technical experts on the standards and their context. If you have any suggestions or questions, please contact us.
The Trust over IP (ToIP) model consists of two stacks: the technology stack and the governance stack. We will here restrict ourselves to the technology stack, since we aim to give context for technologies. The stack consists of the following four layers:
While looking through various specifications / standards, it seemed to make sense to arrange them according to the ToIP technology stack, as they seem to fit into these layers. We have made some small alterations to the layers in the ToIP technology stack, such that the scope is broadened (wider than just DID-based methods) and renamed the layers such that the fit our purpose better. The result is displayed below.
For each of these layers, we dedicate a chapter below and explain what the scope of the layer is, what technologies belong to the layer. For each of the technologies we will
Trust anchors form the basis of the entire stack. Without a strong foundation to anchor your trust to, you cannot have trust in the information communicated on the higher layers, i.e. the credentials exchanged in layer 4. Technologies in layer 1 include identifiers, decentralised public key infrastructure and registries.
An identifier is used to identify a party in a certain context. This identifier can be authenticated by another party. Strong identifiers must be self-certifying, i.e. there should be a strong binding between the key and the corresponding identifier.
Decentralised identifiers (DIDs) allow for the authentication of decentralised digital identities of a DID subject. A DID is a URI that associates the DID subject with a DID document, which describes the DID subject and how they can authenticate themselves using cryptographic keys. By resolving the DID Document, a sender can find the endpoint where to reach the receiver and the public key that the receiver will use in the communication with the sender. DID documents are generated using a specific DID method. It depends on the DID method whether the DID is a self-certifying identifier.
A DID can be a global unique identifier, but parties can also have multiple (peer)DIDs to separate domains/personas.
X.509 certificates are very widely used to define the binding between a party's (partial) identity and a public key. This certificate can be signed by a certificate authority, such as is done for protocols like TLS in HTTPS. X.509 certificates can also be self-signed. Since you can put attributes in the certificate, X.509 certificates can also be used as credential format.
A link secret is a non-correlatable secret only known to the holder. During credential issuance, the link secret is sent as a blind attribute to the issuer. The issuer thus doesn't know the value of the link secret. The issuer can then sign all claims, including the blinded link secret. The holder can prove ownership over the credentials to a verifier without disclosing a persistent identifier.
Not a standard, but a cryptographic technique.
Based on Pedersen commitments, see link secrets.
Raw public keys can be used as an identifier.
As the name suggests, this is the decentralised version of the classic, centralised public key infrastructure. The decentralisation ensures that no single party can compromise the integrity and security of the system as a whole. In decentralised PKI, there is no need to have a trusted third party.
KERI is a novel technology for Decentralised Key Management Infrastructure (DKMI). It has been brought under in an informational standard.
The primary operation for key management is key rotation, that can be performed using key event receipt logs (KERL).
The trust is rooted in self-certifying identifiers.
A registry is used to store information that could be checked by anyone. To provide more protection against malicious modifications and a single-point of failure, this registry should be implemented in a decentralised fashion. Decentralised Ledger Technologies (DLTs), such as a blockchain, can be used for this. Note that SSI solution do not necessarily require the usage of DLTs. IRMA for example is a ledger-less SSI solution.
A blockchain is a distributed database, without a single point of failure or a single central authority that you must trust, leading to a higher level of privacy and security.
The European Blockchain Services Infrastructure (EBSI) is a European consortium that created a blockchain for the public sector.
In the mDL standard, the notion of Verified Issuer Certificate Authority List (VICAL) is introduced. This list can be used as a trust anchor for verifiers.
Status List 2021
To exchange data, first a trusted (mutually) authenticated channel has to be set up. Peer-to-peer connections have to be established between agents of the communicating parties.
A peer-to-peer protocol establishes a secure and private communication between .
By resolving the DID Document, a sender can find the endpoint where to reach the receiver and the public key that the receiver will use in the communication with the sender.
Various message types are defined:
Now that a connection tunnel has been set up, credentials can be exchanged. This layer is about the trust triangle (or diamond).
This section describes protocols related to the issuance of credentials. We describe to standards to do so. Additionally, we also discuss the credential manifest.
This standard formalizes the protocol to issue credentials by specifying the following four messages in the protocol:
The proof type can be JWT, JSON-LID or ZKP.
This standard describes an API for credential issuance via OIDC (and OAuth2.0), by defining what the credential offer and credential offer response should look like.
The proof type must be JWT.
In order for the issuer to send the soon-to-be holder a credential, the issuer needs to know some information about the subject. This specification a data format named the credential manifest, describing the inputs a subject must provide to an issuer in which format, in order for the issuer to determine whether to issue the credential to the subject. The subject, i.e. the user agent, discovers the credential manifest and can then form a credential application, containing the information on the subject that the issuer needs. The issuer can then determine whether this application is accepted or declined and sends a credential response. The formats for the credential application and credential response are also specified in this standard.
We assume that the credential manifest is claim format and transport envelope agnostic, just like the formats in presentation exchange. However, this has not been clearly specified in this standard, but there are some hints.
The credential manifest is the issuance equivalent to the presentation definition specified in presentation exchange.
This standard formalizes the protocol for presentation exchange by specifying the following three messages in the protocol:
OIDC for Verifiable Presentations is, as the name suggests, an extension to OIDC allowing the exchange of verifiable presentations (in a VP token) in addition to an ID token. The standard defines the protocol for this, by defining what the request and response must look like.
In order for the holder to send the verifier a presentation, the holder needs to know (1) the verifier's proof requirements and (2) how to formulate the proof according to the requirements. This specification defines two data formats:
These formats are claim format and transport envelope agnostic, as long as the claim format can be serialized as JSON.
The presentation definition is the verification equivalent of the credential manifest.
Overview: Link to RWOT Credential Comparison Matrix + Paper.
In the next sections we will describe the credential formats that are standardised. Note that these still have a lot of degrees of freedom in there, as choices can be made in the used signature algorithm, revocation mechanism, identifiers...
The data model defines the terms claim, credential and presentation that form the basis for the verifiable credentials. Verifiable credentials and verifiable presentations are defined by giving a format on how to specify them.
The standard for Verifiable Credentials leaves some room for choices in claim format (JSON vs JSON-LD) and proof format (JWT vs linked data proofs).
The standard specifies the implementation of a driving license in association with a mobile device, through specifying amongst others:
The credential format used for the mDL is the MDOC.
It's very useful to be able to delegate and mandate rights and duties towards a third party to for example an employee.
The ACDC protocol aims to provide granular provenanced proof-of-authorship of the data contained via a chain of linked ACDCs. It allows for delegation of credentials by setting up a verifiable chain-of-custody.
Variant of VC
claim formats: JSON, CBOR, MGPK, CESR