[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:
- What does the technology described in the standard achieve?
- What is the context of this technology and its standard?
- Is this standard compatible with standard ?
- Are standards and 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.
- General shows the general interactions between technologies, that is, without choosing a specific technology.
- DIDComm shows the DIDComm-based technologies.
- OIDC shows the OIDC-based technologies.
- DDIP shows the Dutch Decentralised Interoperability Profile.
- AIP shows the Aries Interop Profile.
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:
- 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.
- 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.
- Trust task protocols. This is the trust triangle comes into play and the credentials are exchanged.
- 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
- the most recent version
- when the most recent version was published
- 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
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
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.
Link Secret
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
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
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
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
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
OpenID Connect
Used in many systems. Less or no migration needed compared to moving to a DIDComm-based system
Self-Issued OpenID Provider
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
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
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
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
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
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
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:
- 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.
- 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
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
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
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
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
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
Chained Credential
Guardianship
Credential Handler API
EASSI
Accessibility
To Research
- Sovrin governance & trust framework
- Decentralised file system?
- Timestamping
- Presentation definition and submission
- Gordian envelopes