[DRAFT] SSI Standardisation Overview

By Maaike van Leuken (TNO)
Last revision: 06-04-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).


Abbreviations

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:

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.

The two stacks in the ToIP model.

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.

The four layers from the ToIP stack used to structure the overview of the standards.

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

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
Most recent version:
v1.0
Published on:
19-07-2022
Link:
Decentralised Identifiers (DIDs)
Competitive to:
X.509, link secret, raw public key
Compatible with:
DID Exchange Protocol, DIDComm,
Compatible with
Issue Credential Protocol,
Compatible with
Presentation Exchange,
Compatible with
Present Proof Protocol


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:
ITU
Most recent version:
10/19
Published on:
14-10-2019
Link:
X.509
Competitive to:
DID, link secret, raw public key
Compatible with:
OIDC


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:
-
Most recent version:
-
Published on:
-
Link:
-
Competitive to:
DID, X.509, raw public key
Compatible with:
AnonCred, DIDComm


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.

Recovery

https://sovrin.org/wp-content/uploads/2019/03/What-if-someone-steals-my-phone-110319.pdf

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:
Web of Trust
Most recent version:
N.A.
Published on:
16-07-2022
Link:
KERI
Competitive to:
PKI
Compatible with:
DID


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:
Most recent version:
-
Published on:
-
Link:
-
Competitive to:
Other DLTs
Compatible with:
DID


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:
-
Most recent version:
-
Published on:
-
Link:
-
Competitive to:
Other DLTs
Compatible with:
Trusted Issuer


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

Registry Applications
Identifier
Schema
Revocation
Delegation
Trusted Issuer

Link Oskar

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.

Trusted Verifier

Link Oskar

Trusted App

Revocation Method

Revocation List

Status List 2021

Cryptographic Accumulator

https://link.springer.com/content/pdf/10.1007/978-3-642-00468-1_27.pdf

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

OCA Definition

(?)


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:
DIF
Most recent version:
v2.0
Published on:
-
Link:
DIDComm Messaging
Competitive to:
OIDC
Compatible with:
DID, DID exchange protocol,
Compatible with:
issue credential protocol,
Compatible with:
present proof protocol,


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:

DID Exchange Protocol
Standardisation body:
Aries RFC
Most recent version:
1.0
Published on:
15-04-2021
Link:
DID Exchange Protocol 1.0
Competitive to:
-
Compatible with:
DIDComm


OpenID Connect
Standardisation body:
OpenID Foundation
Most recent version:
1.0
Published on:
08-11-2014
Link:
OpenID Connect Core 1.0
Competitive to:
DIDComm
Compatible with:
SIOP, OIDC4CI, OIDC4VP, presentation exchange


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


Agent

Wallet
Wallet Rendering
DKMS

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:
DIF
Most recent version:
3.0
Published on:
27-10-2021
Link:
Issue Credential Protocol 3.0
Competitive to:
OIDC4CI
Compatible with:
DID, link secret, DIDComm
Compatible with:
DIDComm, DID exchange protocol, present proof protocol


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.

OpenID Connect for Verifiable Credential Issuance
Standardisation body:
OpenID Foundation
Most recent version:
1.0
Published on:
30-12-2022
Link:
OpenID for Verifiable Credential Issuance
Competitive to:
issue credential protocol
Compatible with:
OIDC, SIOP, mDL, VC


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:
DIF
Most recent version:
0.0.1
Published on:
-
Link:
Credential Manifest
Competitive to:
-
Compatible with:
JSON-based credentials, OIDC4CI, issue credential protocol,
Compatible with:
CHAPI


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:
DIF
Most recent version:
3.0
Published on:
22-06-2021
Link:
Present Proof Protocol 3.0
Competitive to:
OIDC4VP
Compatible with:
DIDComm, issue credential protocol, presentation exchange


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

OpenID Connect for Verifiable Presentations
Standardisation body:
OpenID Foundation
Most recent version:
1.0
Published on:
17-12-2021
Link:
OpenID Connect for Verifiable Presentations
Competitive to:
present proof protocol
Compatible with:
OIDC4CI, SIOP, presentation exchange, VP


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:
DIF
Most recent version:
2.0.0
Published on:
-
Link:
Presentation Exchange 2.0.0
Competitive to:
-
Compatible with:
JSON-based credentials, OIDC4VP, present proof protocol,
Compatible with:
CHAPI


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.

Device Binding Attachments
Standardisation body:
Aries RFC
Most recent version:
-
Published on:
07-04-2022
Link:
Aries RFC 0728: Device Binding Attachments
Competitive to:
SECDSA
Compatible with:
present proof protocol, AnonCred


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:
W3C
Most recent version:
v1.1
Published on:
03-03-2022
Link:
Verifiable Credentials Data Model v1.1
Competitive to:
other credential formats
Compatible with:
OIDC4CI, OIDC4VP, issue credential protocol,
Compatible with:
present proof protocol


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:
ISO
Most recent version:
1
Published on:
xx-09-2021
Link:
ISO/IEC 18013-5:2021
Competitive to:
other credential formats
Compatible with:
OIDC4CI, OIDC4VP, VICAL


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.

AnonCred
Standardisation body:
-
Most recent version:
-
Published on:
-
Link:
-
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:
ToIP Foundation
Most recent version:
-
Published on:
25-04-2022
Link:
Authentic Chained Data Containers (ACDC)
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:
-
Most recent version:
-
Published on:
-
Link:
-
Competitive to:
-
Compatible with:
-


Chained Credential
Standardisation body:
-
Most recent version:
-
Published on:
-
Link:
-
Competitive to:
-
Compatible with:
-


Guardianship

Standardisation body:
-
Most recent version:
-
Published on:
-
Link:
-
Competitive to:
-
Compatible with:
-


Credential Handler API

Standardisation body:
W3C
Most recent version:
1.0
Published on:
23-06-2021
Link:
Credential Handler API 1.0
Competitive to:
-
Compatible with:
-


EASSI

Standardisation body:
-
Most recent version:
-
Published on:
-
Link:
-
Competitive to:
-
Compatible with:
A variety of wallets


Accessibility

To Research