ISO/TR 23249:2022

Blockchain and distributed ledger technologies – Overview of existing DLT systems for identity management

This document provides an overview of existing DLT systems for identity management, i.e. the mechanisms by which one or more entities can create, receive, modify, use and revoke a set of identity attributes. This document covers the following topics: — Managing identity for individuals, organizations, things (IoT & objects), functions and processes and other entities including within and across DLT systems. — Description of the actors and their interactions and common interfaces. — Architectures. — Existing relevant standards and frameworks.

Titre manque

General Information

• Status: Published
• Publication Date: 17-May-2022
• ICS: 35.030 - IT Security
• ICS: 35.240.40 - IT applications in banking
• ICS: 35.240.99 - IT applications in other fields
• Technical Committee: ISO/TC 307 - Blockchain and distributed ledger technologies
• Drafting Committee: ISO/TC 307/JWG 4 - Joint ISO/TC 307 - ISO/IEC JTC 1/SC 27 WG: Security, privacy and identity for Blockchain and DLT
• Current Stage: 6060 - International Standard published
• Start Date: 18-May-2022
• Due Date: 03-Jul-2022
• Completion Date: 18-May-2022

Overview

ISO/TR 23249:2022 - Blockchain and distributed ledger technologies: Overview of existing DLT systems for identity management provides a descriptive, non‑normative survey of how distributed ledger technologies (DLT) are used to create, manage, present and revoke identity attributes. It summarizes architectures, actor roles, common interfaces and existing identity systems and frameworks (e.g., uPort, DIF, Alastria ID, ESSIF, Sovrin / Hyperledger stacks, KTDI, LACChain, Masterchain). Target audiences include academics, solution architects, developers, regulators and standards bodies.

Keywords: ISO/TR 23249:2022, blockchain identity management, DLT systems for identity, decentralized identity, self‑sovereign identity (SSI), DID, verifiable credentials (VC).

Key topics and technical considerations

ISO/TR 23249:2022 focuses on descriptive analysis and design considerations rather than prescriptive requirements. Major technical topics include:

• Authority models: top‑down (centralized issuance) vs bottom‑up (user‑controlled identifiers).
• Identifier origination schemes: bring‑your‑own‑address, credential registries, global or anchor registries and hybrid approaches.
• Custody and delegation: key custody models, custodians, social/key recovery, delegated interactions and custodial services.
• Credential architectures: issuance, storage, presentation, selective disclosure and revocation mechanisms.
• Privacy and cryptography: use of zero‑knowledge proofs (ZKP), pairwise/pseudonymous identifiers and selective disclosure patterns.
• Actors and interfaces: roles (issuers, subjects, verifiers, custodians), data stores, and common APIs (e.g., CHAPI, DID/VC related interfaces).
• Architectural patterns: on‑chain vs off‑chain data, anchoring strategies, bundling/anchors, decentralized key management and storage (e.g., IPFS references).
• Taxonomies and frameworks: coverage of NIST taxonomic approaches, Trust Over IP, and mapping to existing DLT identity systems.

Practical applications

ISO/TR 23249:2022 helps stakeholders understand how to apply DLT to identity use cases such as:

• User authentication and access control for web services and enterprise systems.
• Self‑Sovereign Identity (SSI) deployments enabling user‑centric control of identifiers and verifiable credentials.
• Cross‑border digital identity and travel credentials (e.g., Known Traveller Digital Identity concepts).
• KYC / AML processes where verifiable credentials streamline onboarding while protecting privacy.
• IoT and device identity management for secure, verifiable device attributes.
• Interoperability planning across multiple DLT networks and governance models.

Who should use this document

• Solution architects and developers designing DLT identity systems
• Policy makers, regulators and auditors assessing identity approaches
• Standards organizations and consortia seeking alignment
• Researchers and educators comparing existing DLT identity implementations

Related standards and frameworks

The report references and maps to existing standards and initiatives such as ISO 22739 (vocabulary), W3C Decentralized Identifiers (DID) and Verifiable Credentials (VC) concepts, NIST taxonomies, Trust Over IP (ToIP), and regional frameworks like ESSIF and EBSI.

For implementers, ISO/TR 23249:2022 is a practical reference to evaluate architectures, privacy trade‑offs and interoperability pathways for blockchain‑based identity management.

Standards Content (Sample)

TECHNICAL ISO/TR
REPORT 23249
First edition
2022-05
Blockchain and distributed ledger
technologies – Overview of existing
DLT systems for identity management
Reference number
© ISO 2022
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 1
5 Existing taxonomies and conceptual architectures . 3
5.1 General . 3
5.2 NIST Taxonomic approach for blockchain IDMS . 3
5.2.1 General . 3
5.2.2 Authority model . 3
5.2.3 Custody and delegation . 4
5.2.4 Identifier origination schemes . 5
5.2.5 Credential architectures . 6
5.3 Functional role of DLT in identity systems. 7
5.4 Trust Over IP Foundation . 7
6 Existing DLT systems for identity management . 7
6.1 General . 7
6.2 uPort . 7
6.3 Decentralized Identity Foundation (DIF) . 9
6.4 Alastria ID . 10
6.5 European Self Sovereign Identity Framework (ESSIF) .13
TM
6.6 Sovrin Network, Hyperledger Indy, Hyperledger Aries and Hyperledger Ursa .15
TM
6.7 WEF Known Traveller Digital Identity (KTDI ) . 20
6.8 WeIdentity . 24
6.9 Masterchain. 25
6.9.1 General . 25
6.9.2 Actors in the system . 27
6.10 LACChain . 27
6.11 Decentralised digital architecture based on blind signatures .29
6.11.1 General .29
6.11.2 Actors in the system .30
6.11.3 Functions in the system .30
6.11.4 Flow of messages in the system . 31
7 Existing relevant standards and frameworks.32
Bibliography .37
iii
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to
the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see
www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 307, Blockchain and distributed ledger
technologies, in collaboration with Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 27, Information security, cybersecurity and privacy protection.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
iv
Introduction
The target audience of this document includes but is not limited to academics, solution architects,
customers, users, developers, regulators, auditors and standards development organizations.
v
TECHNICAL REPORT ISO/TR 23249:2022(E)
Blockchain and distributed ledger technologies – Overview
of existing DLT systems for identity management
1 Scope
This document provides an overview of existing DLT systems for identity management, i.e. the
mechanisms by which one or more entities can create, receive, modify, use and revoke a set of identity
attributes.
This document covers the following topics:
— Managing identity for individuals, organizations, things (IoT & objects), functions and processes
and other entities including within and across DLT systems.
— Description of the actors and their interactions and common interfaces.
— Architectures.
— Existing relevant standards and frameworks.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 22739, Blockchain and distributed ledger technologies — Vocabulary
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 22739 apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
4 Abbreviated terms
AML Anti-Money Laundering
BCOS Be Credible, Open & Secure
BSP Biometric Service Providers
CCG Credentials Community Group
CHAPI Credential Handler API
CMS Confidential Messaging Service
DID Decentralized Identifier
DIF Decentralized Identity Foundation
DKMS Decentralized Key Management System
DLT Distributed Ledger Technology
EBSI European Blockchain Services Infrastructure
eIDAS EU Regulation on electronic Identification, Authentication and trust Services
ERC Ethereum Request for Comments
ESSIF European Self Sovereign Identity Framework
FISCO Financial Blockchain Shenzhen Consortium
GDPR EU General Data Protection Regulation
HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure
ID identity
IDMS Id Management System
INATBA International Association for Trusted Blockchain Applications
IPFS InterPlanetary file system
JSON JavaScript object notation
JSON-LD JSON Linked Data
JWT JSON Web Token
TM
KTDI Known Traveller Digital Identity
KYC Know Your Customer
NIS Network and Information Systems
PKI public key infrastructure
SDK software development kit
SIOP Self-issued OpenID Provider
SSI Self-Sovereign Identity
RFC Request for Comments
ToIP Trust over IP
TOOP The Once Only Principle
URI Uniform Resource Identifier
VC Verifiable Credentials
W3C World Wide Web Consortium
WebKMS Cryptographic Key Management Systems for the Web
ZCAP-LD Authorization Capabilities for Linked Data
ZKP Zero Knowledge Proof
5 Existing taxonomies and conceptual architectures
5.1 General
This clause contains existing taxonomies and conceptual architectures, in the form of a list of examples,
which is not intended to be exhaustive.
5.2 NIST Taxonomic approach for blockchain IDMS
5.2.1 General
Reference [4] provides an example of a taxonomic approach to understand emerging blockchain
identity management systems as a National Institute of Standards and Technology (NIST) publication. It
highlights the different features and characteristics that are possible, also exploring the opportunities,
challenges and risks associated.
5.2.2 Authority model
There are two main approaches for the authority model, which is the way the system is controlled:
— Top-down: A system owner acts as a central authority that has control over identifier origination
and/or credential issuance. This power could be delegated to create a hierarchical structure.
— Bottom-up: There is no single entity acting as a central authority that has control over identifier
origination and/or credential issuance. Participants create and manage their own identifiers and
credentials without the need of any permission, although they need to follow the (technical) rules
of the identity systems.
There are different schemes for identifier origination. An identifier is originated starting from the
generation of a blockchain address directly by the user who controls the custody of the associated
private keys, usually with the generation of a public/private key pair and then deriving a blockchain
address from the public key using a cryptographic hash function and some protocol-specific
transformations. There are also additional identifier origination schemes that do not start with the
generation of a blockchain address but rather reference the address after generation.
Different methods could be used to originate identifiers, as shown in Figure 1 (reproduced with
permission from NIST): schemes that involve no initial registration or self-registration are on the left
of the figure. The rightmost box labelled with “By a central authority” represents a top-down authority
model. The schemes in-between are other possible alternatives.
In the top-down approach, credentials and/or identifiers are issued by a central authority (a corporate
office, a central government), while in the bottom-up they are issued by any user to another user, or
directly issued by a user to themselves.
Figure 1 — Identifier origination schemes
5.2.3 Custody and delegation
Figure 2 (reproduced with permission from NIST) shows different interactions between entities and an
identity management system; these interactions are either direct or delegated through custodian (in
this context, a datastore is an off-chain personal storage linked with a given identity).
Figure 2 — Interactions between relevant actors
Users who lose their private keys can recover them if a specific key recovery mechanism has been put in
place, such as a user-designated Custodian, a list of user-appointed trustees (social recovery), time delay
mechanisms and/or a central authority (when suited). Custodians could offer their services through a
competitive market. Some types of credentials can be transferrable from one user to another, as when
they represent ownerships relations. All these interactions could be delegated through Custodians.
From one or more credentials it is possible to derive a presentation that allows Subjects to share
verifiable information directly with a relying party and authenticate themselves. This presentation
disclosure could be selective when it includes just a minimal amount of information, on a need-to-know
basis, thanks to advanced cryptographic techniques such as zero-knowledge proof (in this context,
presentation means information derived from one or more credentials that a subject discloses to a
verifier to communicate some quality about a subject).
Users can be able to maintain a set of special purpose identifiers not linked with their primary identifier,
e.g. by using pairwise pseudonymous identifiers with a dedicated identifier for each relationship with
a third-party. A pairwise pseudonymous identifier is an opaque unguessable subscriber identifier
generated by a Credential Service Provider (CSP) for use by a specific individual Relying Party (RP).
This identifier is only known to and only used by one CSP-RP pair. See https:// csrc .nist .gov/ glossary/
term/ Pairwise _Pseudonymous _Identifier
5.2.4 Identifier origination schemes
The identifier origination schemes introduced before could be implemented in different ways, including:
— Credential Registry Acting as Identifier: the credentials for each participant in the system are stored
in a smart contract deployed on the system. This is typical of bottom-up approaches. Standards such
as ERC-725, Proxy Account, alleviate the burden on the blockchain from the need to deploy a smart
contract for each new identity in the system, and ERC-725 Key Manager, allows subjects to delegate
certain capabilities to custodians.
— Global Identifiers Registry: a single monolithic (set of) smart contract(s) that acts as a global
registry for storing and managing all identifiers. The smart contract(s) logic defines the different
governance models. The registry can contain all the logic and data to resolve identifiers to their
metadata or hashes to the actual data stored elsewhere.
— Anchors Registry: A single monolithic smart contract that acts as a global registry. The registry
contains hashes of identifier management operations that are grouped together into bundles or
anchors. The bundling is executed by a second level layer protocol, with the help of some decentralized
storage.
— Bring-Your-Own Blockchain Address: there is no need to register an identifier before using it, and
any blockchain address is a valid identifier. The main difference from the approaches based on
smart contracts is that identifiers are not initially registered and stored on-chain, so they are non-
discoverable.
— Unspent Transaction Output Model: this is the identifier scheme used in Bitcoin and other
cryptocurrencies, where identifiers are created by submitting transactions to the blockchain, as
recipients of the unspent output from a transaction.
5.2.5 Credential architectures
Credentials could be stored on-chain or off-chain. On-chain credentials could be implemented such that
only the hashes of the credentials are stored on the blockchain, for comparison purposes. Different
credential architectures are possible including:
— Per-Identifier Credentials Registry: Credentials are managed as entries in a per-identifier smart
contract that acts as a container. The subjects could have unilateral control over their credentials,
adding or removing them from the contract as preferred. This architecture creates a significant
load on the blockchain. ERC-735, Claim Holder, reduces the burden on the blockchain.
— Global Credentials Registry: In this case, there is a single smart contract. The identifier that has
deployed the system owns this smart contract, and could delegate, transfer, or limit the authority
over it with respect to other identifiers: this architecture supports credentials revocation. Examples
of this architecture are ERC-780, Ethereum Claims Registry and ERC-1056.
— Non-Fungible Token Repository: in this approach a Credential is a Non-Fungible Token (NFT), a
token that is unique and possibly transferable. NFT Repositories are useful for managing digital
ownership. Example of this architecture are ERC-721, Non-fungible Token Standard.
— User-Mintable, Predefined, Non-Fungible Token: in this architecture a credential takes the form of
an entitlement to let a user create (“mint”) a predefined and pre-assigned NFT according to specific
conditions.
— Off-chain Object: in this architecture, a credential is an off-chain object, that manages the direct
communication between parties.
Architectures for identifiers as in 5.2.4 could be combined with different architecture credentials,
with possible examples:
— Global Identifiers Registry and Per-Identifier Credentials Registry: SmartID project from
Deloitte.
— Global Registry for Identifiers and for Credentials: Smart contract-based PKI (SCPKI), BlockPKI.
— Off-chain Objects with Global Credentials Registry: uPort, Hyperledger Indy.
— Non-fungible Tokens with Global Credentials Registry: ERC-1616, Attribute Registry.
5.3 Functional role of DLT in identity systems
Different initiatives propose different roles for the DLT in identity management. Most popular roles
include:
— Associating identifiers with public keys (“Decentralized PKI”): within this role, a DLT is primarily
used for establishing an association between an identifier and a public key.
— Attestation of credentials: similar to digital signature or timestamping on credential as found in
traditional systems.
— Support for credentials revocation: the DLT is used to support the revocation of credentials.
— Definition of common credential templates: a common template for credentials is stored in the DLT,
to promote interoperability.
— Trust Anchors: DLT can be used to define some initial trust anchors.
5.4 Trust Over IP Foundation
The Trust over IP (ToIP) Foundation (https:// trustoverip .org/ ), homed at The Linux Foundation, aims
to simplify and standardize how trust is established online so that everyone can feel safe, secure, and
private in all of our digital interactions—whether between individuals, businesses, governments, or
any “thing” on the Internet of Things.
Its mission is to define a complete architecture for Internet-scale digital trust that combines
cryptographic trust at the machine layer with human trust at the business, legal, and social layers,
specifying how standards and components can be combined to fulfil the requirements of all four layers
of the stack, for both governance and technology.
6 Existing DLT systems for identity management
6.1 General
This clause contains a list of examples that includes (but it is not limited to) several relevant existing
systems.
6.2 uPort
1) [7]
uPort , provides a platform for self-sovereign digital identity management (Self-Sovereign Identity
is an emerging concept associated with the way identity is managed in the digital world. According
to the Self-Sovereign Identity approach, users are expected to be able to create and control their own
identity, without relying on any centralized authority, see https:// ec .europa .eu/ futurium/ en/ system/
files/ ged/ eidas _supported _ssi _may _2019 _0 .pdf). The provided platform includes:
— The uPort Serto App, to re-forge user trust by putting users back in control of their personal data
and identity. With the uPort app they can locally store their credentials and decide when and with
whom they want to share.
— The uPort SDK, to integrate uPort’s trusted data and identity management platform solution in
a mobile app, letting customers securely store their private data with confidence and peace of
mind. They can control their most important attributes and how and when they share them with
companies, institutions, and peers.
— The uPort Libraries.
1) uPort is an example of a suitable product available commercially. This information is given for the convenience
of users of this document and does not constitute an endorsement by ISO of this product.
uPort is described as a self-sovereign digital identity platform – anchored on the Ethereum blockchain.
The uPort technology primarily consists of smart contracts, developer libraries, and a mobile app. uPort
identities are fully owned and controlled by the creator – independent of centralized third-parties for
creation, control or validation.
The company offers a collection of tools and protocols for building decentralized user-centric
applications, built on open standards and open source libraries. It is based in the use of Ethereum
addresses as identifiers and the use of a specific contract for registering and managing DIDs, according
to the ERC-1056 Lightweight Identity Ethereum Improvement Proposal (EIP), and JSON Web Tokens for
protocol requests and responses, according to IETF RFC 7519 (https:// tools .ietf .org/ html/ rfc7519).
As explained in the uPort specifications, a uPort identity is just someone or something that can sign
data or transactions and receiving signed data about itself.
An identity has:
— An Identifier in the form of a DID.
— A signing key.
— A public key stored on the uPort Registry.
[8]
uPort provides an Ethr-DID library conforming to ERC-1056 intended to use Ethereum addresses as
fully self-managed DIDs. It allows a user to easily create and manage keys for these identities and lets
the user sign standards compliant JSON Web Tokens (JWT) that can be consumed using the DID-JWT
library. This library encapsulates the functionality of Ethr-DID-Resolver and Ethr-DID-Registry, and
supports the following capabilities:
— Create and manage keys for DID identities.
— Sign JWTs.
— Authorize third parties to sign on a DID's behalf.
— Enable discovery of service endpoints (e.g. decentralized identity management services).
The Ethr-DID-Registry is a smart contract that facilitates public key resolution for off-chain (and on-
chain) authentication. It also facilitates key rotation, delegate assignment and revocation to allow
3rd party signers on a key's behalf, as well as setting and revoking off-chain attribute data. These
interactions and events are used in aggregate to form a DID's DID document using the Ethr-Did-Resolver.
The Ethr-DID-Registry supports the following operations:
— Looking up identity ownership.
— Changing identity ownership.
— Looking up a delegate.
— Adding a delegate. Delegates are needed to allow Web3 providers to sign a change identity owner
operation or to sign JWTs (a Web3 provider is the way the Web3.js framework talks to the blockchain,
see https:// web3 .py .readthedocs .io/ en/ stable/ providers .html)
— Revoking a delegate.
— Enumerating delegates off-chain.
— Setting off-chain attributes.
— Revoking off-chain attributes.
— Reading off-chain attributes.
— Enumerating linked identity events.
— Assembling a DID document.
An identity can:
— Sign JWTs to authenticate themselves to a third party, and disclose private information about
themselves.
— Receive requests for disclosure about themselves.
— Receive and store signed third party verifications about themselves.
— Sign Ethereum transactions.
[9]
Currently, uPort supports the following application flows :
— Send Verification Claim Flow, to allow a user to request a Verified Claim to an issuer, and an issuer
to create and deliver Verified Claims to a user. A Verifiable Claim is always signed by the issuer, and
includes the DID of the issuer, the DID of the subject, the time of issuance and a set of one or more
claims.
Different claims about the same entity will have the same subject DID, essentially corresponding to
her Ethereum address, allowing linkability [from an attacker’s perspective, the linkability of two
or more items of interest (IOIs), e.g., subjects, messages, actions, . means that within the system
(comprising these and possibly other items), the attacker can sufficiently distinguish whether
these IOIs are related or not, see https:// tools .ietf .org/ id/ draft -hansen -privacy -terminology -00
.html]. Conversely, unlinkability is the inability for the attacker to sufficiently distinguish whether
these IOIs are related or not.
— Selective Disclosure Flow, to allow a relying party to request a user for claims. This flow is formed
by a Selective Disclosure Request and a Selective Disclosure Response. The Selective Disclosure
Request can specify requirements for claims (based on the OpenID-Connect specification adapted
to support Verifiable Claims) requested from a user. The response is always signed and it normally
includes an array of Verified Claims JWTs or IPFS hash of JSON encoded equivalent.
— Ethereum Transaction Request Flow, to allow a client application request a user to sign an Ethereum
transaction.
— Private Chain Provisioning Flow, with experimental support for supporting Ethereum accounts on
private chains.
6.3 Decentralized Identity Foundation (DIF)
DIF (https:// identity .foundation/ ) is an engineering-driven organization focused on developing the
foundational elements necessary to establish an open ecosystem for decentralized identity and ensure
interoperability between all participants.
DIF focuses in developing specifications and emerging standards for protocols, components, and data
formats that implementers can execute against, and seeks to align industry participants to advance
their common interests.
Currently DIF has the following working groups:
— Identifiers and discovery.
— Storage and compute.
— Authentication.
— Claims and credentials.
— DID Communication.
— Sidetree development & operating group.
— Secure data storage.
— Interoperability.
DIF produces the following specifications related to this document:
— Universal Resolver: specification and implementation of a driver-based framework that enables
resolution of DIDs.
— Universal Registrar: specification and implementation of a driver-based framework that enables
creation/updates/deactivation of DIDs.
— Well-known DID configuration: specifications, documents, and implementations for discovering
DIDs from well-known HTTP(S) URIs.
— Identity Hubs: encrypted personal datastore for identity interactions and decentralized apps.
— DID Authentication Profile for SIOP: Defines how to use OpenID Connect (OIDC) together with the
strong decentralization, privacy and security guarantees of DID for everyone who wants to have a
generic way to integrate SSI wallets into their web applications.
— DIDComm JS Lib: A shared effort with the Hyperledger Aries project to create a standardized means
of authenticated general message passing between DID controllers.
— Credential Manifest: The DID Credential Manifest is a format that aims to normalize the process of
credential acquisition, wherein the issuer is able to describe the requirements that the subject or
participant in the credential generation process needs to meet for the issuer to generate the desired
credential.
— VC JSON Schemas: The VC JSON Schema specification aims to provide a standardized mechanism to
use JSON Schemas as the data backing for Verifiable Credentials. Though the repository lives in the
W3C-CCG, this working group contains key contributors and has a vested interest in contributing to
the development of the specification.
— Sidetree protocol: specifications, documents, and implementations for the chain/ledger-agnostic
DID scaling protocol.
6.4 Alastria ID
Alastria ID is the digital identity project of the Identity Commission of Alastria (https:// alastria .io/ ),
whose ecosystem in shown in Figure 3. Their proposal for digital identity in blockchain aims to provide
an infrastructure and development framework, to carry out sovereign digital identity projects, with
full legal validity in the euro zone, following these premises:
— Follow the guidelines of the e-Identity workshop report, of the EU Blockchain Observatory and
Forum (https:// www .eublockchainforum .eu/ sites/ default/ files/ reports/ workshop _5 _report _ - _e
-identity .pdf).
— Compliance with eIDAS Regulation.
— Make the digital identity in blockchain and the GDPR two complementary tools, following
the recommendations described in EU Blockchain Observatory and Forum (https:// www
.eublockchainforum .eu/ sites/ default/ files/ report _identity _v0 .9 .4 .pdf) and the study from European
Parliamentary Research Service (https:// www .europarl .europa .eu/ RegData/ etudes/ STUD/ 2019/
634445/ EPRS _STU %282019 %29634445 _EN .pdf).
[10]
A digital identity allows the user/subject to authenticate and present (certified) personal information
in order to get a service, those actions require the creation and set-up of a digital identity and the
gathering of certified personal information (credentials) from trusted sources.
Figure 3 — Alastria ecosystem
For pseudonymous single usage, i.e. presenting some information in order to get a service where the
service provider does not need to record anything and is not going to provide services in a recurrent
way an Alastria ID is enough. Consider for example a user presenting a credential entitling to obtain a
digital asset (photo, song, etc.) or access to a given place (building, conference centre).
When authentication is required or when recurrent service is going to be provided or when the service
provider needs to record the presentation gathered, the Alastria ID could be recorded in order to make
easier to provide the service or record interactions with the user.
For credential issuance linked to an Alastria ID, the Alastria ID also needs to be recorded by the entity.
Then, to use Alastria ID in front of a given entity (service provider or credential issuer) the user Alastria
ID is likely to be recorded by the entity. When there is another identifier used by the entity to identify
internally the same user (Legacy Id), the Alastria ID and the Legacy Id are intended to be linked
together. The general flow of operations is shown in Figure 4.
There are different situations that are possible for the relationship between a subject and a given entity
(service provider or credential issuer), depending on whether the user has an Alastria ID, a Legacy Id
for that entity and whether the Alastria ID is recorded (and linked to the Legacy Id) by the entity.
Figure 4 — General view of Alastria ID flows and registry
Alastria ID considers the following operations:
— Alastria ID creation. Subjects are identified by DIDs anchored in an Ethereum network, as in the
uPort/DIF initiatives.
— Onboarding with Alastria ID.
— Alastria ID registration & legacy Id linking.
— Alastria ID authentication.
— Alastria ID credentials: credential issuance, credential revocation, credential query status.
— Alastria ID presentations: present presentation, withdraw presentation, presentation query status.
Credential issuance and presentation operations are registered in the DLT as evidence. Each credential
operation generates a specific hash, that stored in a tuple associated with the corresponding role. To
avoid correlation, the issuer generated credential hash and the user generated credential hash are
different. Similarly, the user generated presentation hash and the relying party generated presentation
hash are also different. See Figure 5 for a pictorial representation.
Figure 5 — Unlinkability of transactions
6.5 European Self Sovereign Identity Framework (ESSIF)
The European Blockchain Services Infrastructure (EBSI, see https:// ec .europa .eu/ cefdigital/ wiki/
display/ CEFDIGITAL/ EBSI) is a joint initiative from the European Commission and the European
Blockchain Partnership (EBP, see https:// ec .europa .eu/ digital -single -market/ en/ news/ european
-countries -join -blockchain -partnership) to deliver EU-wide cross-border public services using
blockchain technology. The EBSI is materialized as a network of distributed nodes across Europe (the
blockchain), leveraging an increasing number of applications focused on specific use cases. In 2020,
EBSI became a CEF Building Block, providing reusable software, specifications, and services to support
adoption by EU institutions and European public administrations.
EBSI Platform is a peer to peer network of interconnected nodes. The European Commission operates
a minimum number of EBSI nodes at European level and the Member States operate EBSI nodes at a
national level. All the nodes are able to create and broadcast transactions that will update the ledger.
The architecture of each node is composed of two main functional areas (see Figure 6, reproduced with
permission from EBSI):
— A set of four layers comprising components which together provide the EBSI infrastructure,
which contain capabilities common to all use cases. These layers include generic capabilities and
connectivity to Blockchain networks.
— A set of two layers comprising use case-specific components enabling support for hosting of business
applications.
Figure 6 — EBSI layered approach
ESSIF is one of the use cases of EBSI, aiming to implement a generic self-sovereign identity (SSI)
capability, allowing users to create and control their own identity across borders without relying on
centralized authorities.
ESSIF has defined a data model considering:
— Identities and DIDs anchored in a DLT, allowing for multiple DIDs, aligned with W3C DID specifications.
— Verifiable IDs, a specific type of credential tailored for identification purposes under the current
eIDAS Regulation.
— Verifiable Attestations, covering other credential types, when needed inheriting attributes from
parent Verifiable IDs.
— Links with the eIDAS Levels of Assurance, and with the legal value of presentations.
ESSIF’s key flows include:
— DID registration.
— Obtaining verifiable IDs.
— Obtaining verifiable attestations.
— Linking verifiable IDs with OpenID Connect.
— Submitting verifiable attestations.
Some of the specific components analysed include the eIDAS Bridge, to seal verifiable credentials, and
the Trusted Issuers’ Ledger. Figure 7 (reproduced with permission from EBSI) shows the different user
stories for the different actors in the system.
Figure 7 — ESSIF User stories per actor
TM
6.6 Sovrin Network, Hyperledger Indy, Hyperledger Aries and Hyperledger Ursa
TM2)
The Sovrin Network (https:// sovrin .org/ ) is described as a public service utility enabling
self-sovereign identity on the Internet. The Sovrin Network is decentralized, meaning individuals
can collect, hold, and choose which identity credentials –such as a driver’s license or employment
credential– without relying on individual siloed databases that manage the access to those credentials.
TM
Sovrin is an open source project that offers the tools and libraries to create private and secure data
TM
management solutions that then run on the identity network of Sovrin .
TM
The following is the set of actors who play a role in the Sovrin Network (see Figure 8 and Figure 9):
— Holder/Prover: acquires, stores and presents identity claims to an inspector, and submits a registry
identifier to the identifier registry.
— Issuer: issues identity claims to a holder and verifies identifier ownership through the identifier
registry.
— Inspector/Verifier: requests claims from holders and verifies identifier ownership through the
identifier registry.
— Identifier registry: in charge of maintaining the digital identifiers (DID’s) registered.
2) Sovrin is the trademark of a product supplied by the Sovrin Foundation. This information is given for the
convenience of users of this document and does not constitute an endorsement by ISO of this product.
Figure 8 — General roles (similar to W3C Verifiable Credentials Data Model)
NOTE Reproduced with permission from ssimetup.org.
Figure 9 — Roles and main flows instantiation
TM
Sovrin is a consortium blockchain where everybody can use the platform, without prior permission.
TM
However, Sovrin is permissioned ledger with a known set of validator nodes, called stewards, which
achieve consensus on the ledger.
TM
Sovrin uses DKMS, a new approach to cryptographic key management intended for use with
[11]
blockchain and distributed ledger technologies (DLTs) where there are no centralized authorities .
DKMS inverts a core assumption of conventional PKI (public key infrastructure) architecture, namely
that public key certificates will be issued by centralized or federated certificate authorities (CAs). With
DKMS, the initial "root of trust" for all participants is any distributed ledger that supports a new form
of root identity record called a DID.
A DID is a globally unique identifier that is generated cryptographically and self-registered with the
identity owner’s choice of a DID-compatible distributed ledger, so no central registration authority
is required. Each DID points to a DID document—a JSON or JSON-LD object containing the associated
public verification key(s) and addresses of services such as off-ledger agent(s) supporting secure peer-
to-peer interactions with the identity owner.
DIDs are a new type of identifier designed for cryptographically verifiable digital identity that are
“independent” or “self-sovereign”, i.e., fully under the control of the identity holder and not dependent
on any centralized registry, identity provider, or certificate authority.
TM
A DID added directly to the Sovrin public ledger is called a public DID, whereas a pairwise
pseudonymous DID shared and stored privately “off-ledger” between the agents for two identity holders
TM
is called a private DID. The ability for Sovrin infrastructure to support both is fundamental to both
its Privacy by Design architecture as well as its ability to scale.
Since no third party is involved in the initial registration of a DID and DID document, it begins as
"trustless". From this starting point, trust between DID-identified peers can be built up through the
exchange of verifiable credentials—credentials about identity attributes that include cryptographic
proof of authenticity of authorship.
TM
Sovrin identity holders can also choose to h
...