[DRAFT] SSI Standardisation Overview

By Maaike van Leuken (TNO)
Last revision: 06-03-2023

Glossary

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.

Revocation mechanism

Credential profile

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).

DID

DPKI

SSI

OIDC

DDIP

AIP

Introduction

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:

• What does the technology described in the standard achieve?
• What is the context of this technology and its standard?
• Is this standard $x$ compatible with standard $y$?
• Are standards $x$ and $y$ competitors?

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.

Audience

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.

Context and Continuation

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.

Description of the Model

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:

1. Public utilities. This forms the basis for the other layers through defining trust anchors such that the technologies in this layer create a trusted basis.
2. Peer-to-peer communication. This layer defines the (private) digital wallets and agents, such that credentials can be stored and exchanged, via peer-to-peer protocols.
3. Trust task protocols. This is the trust triangle comes into play and the credentials are exchanged.
4. Application ecosystems. This layer defined market applications built on top of the other 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

• list some general information about the standard:
• the standardisation body
• a link to the standard
• the technologies it is competitive to
• the technologies it is compatible with
• give a short description of what the technology does

Layer 1: Trust Anchors

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.

Identifier

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 Identifier
Standardisation body:
W3C
v1.0
Published on:
19-07-2022
Decentralised Identifiers (DIDs)
Competitive to:
Compatible with:
Compatible with
Compatible with
Compatible with

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
Standardisation body:
10/19
Published on:
14-10-2019
Competitive to:
Compatible with:

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.

Standardisation body:
-
Published on:
-
Competitive to:
Compatible with:

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 Key

Raw public keys can be used as an identifier.

Decentralised Public Key Infrastructure

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.

Key Event Receipt Infrastructure
Standardisation body:
N.A.
Published on:
16-07-2022
Competitive to:
PKI
Compatible with:

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.

Registry

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.

Distributed Ledger Technology

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.

Hyperledger
Standardisation body:
-
Published on:
-
Competitive to:
Compatible with:

Hyperledger is a collection of projects related to DLTs and creates open-source DLT. Hyperledger falls under guardianship of the Linux Foundation.
European Blockchain Services Infrastructure
Standardisation body:
-
Published on:
-
Competitive to:
Compatible with:

The European Blockchain Services Infrastructure (EBSI) is a European consortium that created a blockchain for the public sector.

Registry Applications
Trusted Issuer

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.

Revocation Method

Status List 2021

Cryptographic Accumulator

https://github.com/hyperledger/anoncreds-spec/blob/main/spec/ursaAnonCreds.pdf

https://github.com/hyperledger/indy-sdk/blob/main/docs/concepts/revocation/cred-revocation.md

(?)

Layer 2: Peer-to-Peer Connection

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.

Peer-to-Peer Protocol

A peer-to-peer protocol establishes a secure and private communication between .

DIDComm
Standardisation body:
v2.0
Published on:
-
Competitive to:
Compatible with:
Compatible with:
Compatible with:

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:

• DIDComm plaintext messages
• DIDComm signed messages
• DIDComm encrypted messages
DID Exchange Protocol
Standardisation body:
1.0
Published on:
15-04-2021
Competitive to:
Compatible with:

OpenID Connect
Standardisation body:
1.0
Published on:
08-11-2014
Competitive to:
Compatible with:

Used in many systems. Less or no migration needed compared to moving to a DIDComm-based system
Self-Issued OpenID Provider
Standardisation body:
v2
Published on:
18-12-2021
Competitive to:
Compatible with:

Layer 3: Credential Exchange Protocols

Now that a connection tunnel has been set up, credentials can be exchanged. This layer is about the trust triangle (or diamond).

Issuance Protocol

This section describes protocols related to the issuance of credentials. We describe to standards to do so. Additionally, we also discuss the credential manifest.

Issue Credential Protocol
Standardisation body:
3.0
Published on:
27-10-2021
Competitive to:
Compatible with:
Compatible with:

This standard formalizes the protocol to issue credentials by specifying the following four messages in the protocol:

• Holder → issuer: what credential the holder would like to receive from the issuer.
• Issuer → holder: offer the credential and possibly its notify the price.
• Holder → issuer: request the credential.
• Issuer → holder: issue the credential.

The proof type can be JWT, JSON-LID or ZKP.

OpenID Connect for Verifiable Credential Issuance
Standardisation body:
1.0
Published on:
30-12-2022
Competitive to:
Compatible with:

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.

Credential Manifest
Standardisation body:
0.0.1
Published on:
-
Competitive to:
Compatible with:
JSON-based credentials, OIDC4CI, issue credential protocol,
Compatible with:

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.

Verification Protocol

Present Proof Protocol
Standardisation body:
3.0
Published on:
22-06-2021
Competitive to:
Compatible with:

This standard formalizes the protocol for presentation exchange by specifying the following three messages in the protocol:

• Prover → verifier: propose what the presentation would look like.
• Verifier → prover: request a presentation.
• Prover → verifier: provide the presentation.
OpenID Connect for Verifiable Presentations
Standardisation body:
1.0
Published on:
17-12-2021
Competitive to:
Compatible with:

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.

Presentation Exchange
Standardisation body:
2.0.0
Published on:
-
Competitive to:
Compatible with:
JSON-based credentials, OIDC4VP, present proof protocol,
Compatible with:

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:

1. A presentation definition format for the verifier's proof requirements. A presentation definition defines which proof formats are allowed, and optionally a set of selection rules or a purpose.
2. A presentation submission format for the holder to formulate proofs. It shows how the presented inputs are in accordance with the requirements specified in the presentation definition.

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.

Credential

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...

Verifiable Credential
Standardisation body:
v1.1
Published on:
03-03-2022
Competitive to:
Compatible with:
Compatible with:

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).

Mobile Document
Standardisation body:
1
Published on:
xx-09-2021
Competitive to:
Compatible with:

The standard specifies the implementation of a driving license in association with a mobile device, through specifying amongst others:

• the interface between the mDL and the mDL reader
• the interface between the mDL reader and the issuing authority infrastructure
• how to tie the mDL to the mDL holder (where the holder must be equal to the data subject), through the use of a portrait image of the mDL holder.

The credential format used for the mDL is the MDOC.

AnonCred
Standardisation body:
-
Published on:
-
Competitive to:
Compatible with:

Layer 4: Application Ecosystems

TBD

Delegation and Mandate

It's very useful to be able to delegate and mandate rights and duties towards a third party to for example an employee.

Authentic Chained Data Containers
Standardisation body:
-
Published on:
25-04-2022
Competitive to:
Compatible with:

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
KERI
JSON
claim formats: JSON, CBOR, MGPK, CESR

ZCap
Standardisation body:
-
Published on:
-
Competitive to:
Compatible with:

Chained Credential
Standardisation body:
-
Published on:
-
Competitive to:
Compatible with:

Guardianship

Standardisation body:
-
Published on:
-
Competitive to:
Compatible with:

Credential Handler API

Standardisation body:
1.0
Published on:
23-06-2021
Competitive to:
Compatible with:

EASSI

Standardisation body:
-
Published on:
-
Competitive to:
Compatible with:
A variety of wallets

To Research

• Sovrin governance & trust framework
• Decentralised file system?
• Timestamping
• Presentation definition and submission
• Gordian envelopes