ETSI GS PDL 023 V1.1.1 (2024-04)

PDL service enablers for Decentralized Identification and Trust Management

DGS/PDL-0023_DID_Framework

General Information

• Status: Not Published
• Technical Committee: PDL - Permissioned Distributed Ledger
• Current Stage: 12 - Citation in the OJ (auto-insert)
• Due Date: 23-Apr-2024
• Completion Date: 16-Apr-2024

Standards Content (Sample)

GROUP SPECIFICATION
PDL service enablers for Decentralized Identification and
Trust Management
Disclaimer
The present document has been produced and approved by the Permissioned Distributed Ledger (PDL) ETSI Industry
Specification Group (ISG) and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.

2 ETSI GS PDL 023 V1.1.1 (2024-04)

Reference
DGS/PDL-0023_DID_Framework
Keywords
decentralized identifier, PDL
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from:
https://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure Program:
https://www.etsi.org/standards/coordinated-vulnerability-disclosure
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
and/or governmental
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2024.
All rights reserved.
ETSI
3 ETSI GS PDL 023 V1.1.1 (2024-04)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definition of terms, symbols and abbreviations . 7
3.1 Terms . 7
3.2 Symbols . 8
3.3 Abbreviations . 8
4 Introduction (informative) . 9
5 ETSI-ISG-PDL Decentralized Identification and Trust management Framework . 9
5.1 Definition of terminologies . 9
5.2 Reference Framework Overview . 9
5.2.1 Introduction. 9
5.2.2 PDL services for decentralized identification and trust management . 11
5.2.2.1 Ledger Role-based registration management service . 11
5.2.2.2 DID Operational participants Registry service. 11
5.2.2.3 DID Resolver service . 11
5.2.2.4 DID Document Registry service . 11
5.2.2.5 VC Data Registry service . 11
5.2.2.6 DID Verification management service . 12
5.3 PDL Framework Operations and Services . 12
5.3.1 Registration Management . 12
5.3.1.1 Introduction . 12
5.3.1.2 Role-based registration . 12
5.3.1.3 De-registration . 15
5.3.2 Data Management . 16
5.3.2.1 Introduction . 16
5.3.2.2 DID and DID Documents management . 16
5.3.2.2.1 Procedure . 16
5.3.2.2.2 DTMF Operations . 17
5.3.2.3 Co-ordinated DID Document publishing to PDL . 20
5.3.2.4 Verifiable Credentials management . 22
5.3.2.4.1 Procedure . 22
5.3.2.4.2 DTMF Operations . 23
5.3.3 Decentralized Identifier Verification Management . 25
5.3.3.1 Introduction . 25
5.3.3.2 DID verification process . 25
5.4 ETSI-ISG-PDL Platform Services . 27
5.4.1 Introduction. 27
5.4.2 Ledger Role-based Registration management Services . 27
5.4.2.1 Ledger Role-based Registration management Service - Participant's registration process . 27
5.4.2.2 Ledger Role-based Registration management Service - Participant's de-registration process . 28
5.4.2.3 Ledger Role-based Registration management Service - DID and DID Document Storage process . 28
5.4.2.4 Ledger Role-based Registration management Service - VC(s) Storage process . 30
5.4.3 DID Operational participants Registry service . 30
5.4.3.1 DID Operational participants Registry service - Participant's de-registration process . 30
5.4.3.2 DID Operational participants Registry service - Authorization verification process (during DID,
DID Document or VC Storage management) . 30
5.4.3.3 DID Operational participants Registry service - Authorization verification process (during DID
Verification) . 31
5.4.4 DID Document Registry service . 31
ETSI
4 ETSI GS PDL 023 V1.1.1 (2024-04)
5.4.4.1 DID Document Registry service - DID and DID Document Storage process . 31
5.4.4.2 DID Document Registry service - DID Verification process . 31
5.4.5 DID Resolver service . 32
5.4.5.1 DID Resolver service - DID registry . 32
5.4.5.2 DID Resolver service - DID Verification process . 32
5.4.6 VC Data Registry service . 32
5.4.6.1 VC Data Registry service - VC Data Storage process . 32
5.4.6.2 VC Data Registry service - DID Verification process . 32
5.4.7 DID Verification Management service . 32
5.5 Summary . 33
Annex A (informative): Change History . 34
History . 35

ETSI
5 ETSI GS PDL 023 V1.1.1 (2024-04)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are publicly available for ETSI members and non-members, and can be
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI Web server (https://ipr.etsi.org/).
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its

Members. 3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and of the 3GPP
Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of the ®
oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
Foreword
This Group Specification (GS) has been produced by ETSI Industry Specification Group (ISG) Permissioned
Distributed Ledger (PDL).
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.

ETSI
6 ETSI GS PDL 023 V1.1.1 (2024-04)
1 Scope
The present document defines Permissioned Distributed Ledger (PDL) Platform services to enable a decentralized
identification and trust management framework. The present document also describes the characteristics and behaviour
of this framework, along with the services that it offers and ideal solutions that can be built using it.
The objective of the present document includes:
• To define PDL platform services to handle registration management of different type of entities/participants to
operate over the PDL platform to accomplish their specific tasks and purpose to realize the overall
decentralized identification and trust management process.
• To define PDL platform services to handle decentralized identifier(s), related documents, and verifiable
credentials.
• To define PDL platform services to verify the decentralized identifier and related information to enable a
specific service provision (e.g. public, and private services).
In scope:
• Definition of Functionalities, Interface Reference points, and Procedures.
The approach taken in the present document is to focus on defining what needs to happen, not how it is implemented.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
[1] ETSI GS PDL 012 (V1.1.1): "Permissioned Distributed Ledger (PDL); Reference Architecture".
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] W3C Recommendation 19 July 2022: "Decentralized Identifiers (DIDs) v1.0 - Core architecture,
data model, and representations".
[i.2] ETSI GR PDL 019 (V1.1.1): "PDL Services for Decentralized Identity and Trust Management".
[i.3] EIDAS: "Supported Self-Sovereign Identity", May 2019.
ETSI
7 ETSI GS PDL 023 V1.1.1 (2024-04)
[i.4] ENISA: "Digital Identity, Leveraging the Self-Sovereign Identity (SSI) Concept to Build Trust",
January 2022.
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
applications at end-device: application (e.g. a client application or wallet) used by the DID holder or Controller to
generate, manage, store, or use private and public key pairs for related security (e.g. confidentiality and/or integrity
protection)
NOTE: The sensitive information (such as cryptographic materials) may need to be protected by the "secure
element" within the device or wallet. In such as case, the use of the cryptographic key(s) is restricted to
the DID holder or controller respectively.
Decentralized IDentifier (DID): digital identifier managed through decentralized platform where the subject
(e.g. end-user/device/any entity) possess the full control over its generation and associated data exposure, independent
from any centralized registry, identity provider, or certificate authority
NOTE: DIDs can be URLs/URIs that relate a DID subject which enables trustable interactions with that subject.
DID can refer to any subject (e.g. a person, organization, thing, data model, abstract entity, etc.) as
determined by the controller of the DID. A DID is considered as a form of pseudonym as used in eIDAS
and it is not directly linked to a formal identifier of the natural or legal person.
DID controller: controller of a DID is the entity (person, organization, or autonomous software) that has the capability
as defined by a DID method and indicated in the DID document to make any changes to a DID document
NOTE: A DID holder can be the DID controller in some cases (or) a DID controller can be a different entity as
authorized by the DID holder. DID controller holds the proof of possession or control of the holder's
private key and will be responsible for issuance of a unique and anonymous DID to the holder.
DID document: DIDs resolve to the DID Documents, i.e. a set of simple documents that contains information
associated to a DID (e.g. to verify the DID) and describes how to use a specific DID
NOTE: Each DID Document may contain at least three information such as proof purposes, verification methods
(such as cryptographic public keys), and service endpoints (can also indicate services relevant to
interactions with the DID holder). Proof purposes are combined with verification methods to enable
mechanisms for proving various aspects related to DID holder's identification, authentication, and
authorization.
DID holder: subject which is referred by the DID is called as the DID holder
NOTE: A DID holder in some cases can generate the DID and, in such cases, the DID holder is also referred as a
DID controller.
DID resolver function: DIDs can be resolvable to their corresponding DID documents, where a DID Resolver function
supports storage of DIDs and returns necessary data to access DID documents
DID verification: allows authentication of the subject identified by the DID
NOTE: The DID holder presents the data derived from one or more VCs, issued by one or more VC issuers, with
a specific verifier (i.e. a service provider) to request and receive specific service of interest to the DID
holder. A verifiable presentation is a tamper resistant/evident presentation encoded (with cryptographic
methods) in such a way that authorship of the data can be trusted after a process of cryptographic
verification. The DID holder authentication is facilitated with protocol exchanges between the DID
holder, DID verifier and the trust management framework to verify the DID and validate the VCs (as part
of authentication) to check if that can be sufficient to provide a requested service (i.e. resource access) for
the DID holder.
ETSI
8 ETSI GS PDL 023 V1.1.1 (2024-04)
DID verifier: it is a role that any third-party service provider or application server would perform to identify and
authenticate the DID holder using the trust management framework
distributed ledgers: record of data stored by consensus with cryptographic audit trail maintained and validated by
nodes in a decentralized platform based on governance
NOTE: Distributed ledger can be of two types such as permissioned distributed ledger and permission less
distributed ledger. As the Permissioned Distributed Ledger (PDL) is further used in the present document,
PDL service is further clarified below.
off-chain storage: privacy sensitive data associated to the DID can be stored and managed in isolation using off-chain
methods or using any local/external authorized storage space as required
PDL services: it can facilitate the storage of DID related data such as DID documents, VC, etc.
NOTE: The ledgers which store the DID related data should be considered as a form of secure area (e.g. secure
element or trusted platform). For example., the storage of DID can be supported through use of an agent
service (such as PDL platform service if a distributed ledger is implemented for the storage) to remotely
access the data from the end device and controlled through multiple authentication and authorization
factors.
Verifiable Credentials (VC): are tamper-evident credentials that has authorship which can be cryptographically
verified, and it includes one or more claims asserted by the VC issuer for the DID holder (i.e. subject)
NOTE: In practice, DIDs are used in combination with VCs to enable trusted digital interactions, where the
required information about the subject is shared with third parties, by proving to those third parties that
the DID subject has ownership of certain attestations or attributes. This proof is based on the
cryptographic link between the VC, the DID subject the VC is about, and the issuer of the VC, which can
be the DID subject itself (self-asserted claims), or another trusted entity.
VC Issuer: is an entity (e.g. a trusted entity or a trust service provider) that performs claims assertation about one or
more subjects, creates a VC from the claims, and transmits the VC to the holder
NOTE: Trust on the VC is established either by trusting the issuer's DID (e.g. by out-of-band mechanisms,
bilateral relationship, trusted lists etc,) or by any other means. The third party (e.g. service provider) can
then use the presented cryptographically protected proof (i.e. the VC) to verify the ownership and
trustworthiness of the claims about the subject.
VC Storage: to enable usage of VCs, the system that implements VC storage performs mediation service for the
creation and verification of the identifiers, keys, and other relevant data, such as VC schemas, revocation of VC data,
issuer public keys, and so on, e.g. some configurations may require correlation of identifiers for subjects
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
DDRS DID Document Registry Service
DID Decentralized IDentifier
DLT Distributed Ledger Technology
DPRS DID operational Participants Registry service
DRS DID Resolver Service
DTMF Decentralized identification and Trust Management Framework
DVMS DID Verification Management Service
eIDAS electronic IDentification, Authentication, and trust Services
ID IDentifier
L-RMS Ledger Role-based registration Management Service
L-RMS-ID Ledger Role-based registration Management Service IDentifier
NWK-ID NetWorK IDentifier
ETSI
9 ETSI GS PDL 023 V1.1.1 (2024-04)
PDL Permissioned Distributed Ledger
RMS Registration Management Service
SLA Service Level Agreement
SSI Self-Sovereign Identity
URI Uniform Resource Identifier
URL Uniform Resource Locator
VC Verifiable Credentials
VDRS Verifiable credentials Data Registry Service
W3C World Wide Web Consortium
4 Introduction (informative)
With the evolution of technologies, businesses, and advanced services, a more seamless, user friendly, user controlled,
and privacy preserved identity management system is most essential for the quick roll-out and success of any business
and services. Meanwhile, the trust in the identity of the subject or object (i.e. a natural or legal person, entity, etc.) has
become the cornerstone of all digital services and activities. Here comes the decentralized identification, where a
decentralized identifier is considered as the most suitable candidate which can link various essential and limited set of
attributes (specific to the end-user(s) or device) as required for any specific service that can be shared with the service
provider(s) or verifier(s) in order to enable authentication of the end-user/device to offer a specific set of service(s). The
present document defines various PDL platform services such as role-based registration management, DID operation
participants registry service, DID registry service, DID Resolver service, DID document registry service, Verifiable
credentials data registry service, and DID verification management service, to enable the overall decentralized
identification and trust management process. All forms of decentralized identification methodologies can utilize the
PDL platform services defined in the present document to handle related data and trust management over the PDL
platform. Specific implementation details (e.g. Implementation of identity using a specific method) are out of scope of
the present document.
5 ETSI-ISG-PDL Decentralized Identification and Trust
management Framework
5.1 Definition of terminologies
A decentralized identification and trust management process enables authentication of the end-user(s)/device(s) (i.e. to
set up the initial trust between the end-user/device being the service consumer and the service provider). The key
enablers to realize a fully functional decentralized identification and trust management involves various operational
aspects such as DID generation (i.e. by a DID holder or DID controller), VC issuance (by a VC Issuer), DID storage
and management, VC storage and management, Verification of the DID (by a DID verifier) for identification and
authentication as listed and described in detail below.
5.2 Reference Framework Overview
5.2.1 Introduction
The present document uses a functional block architecture to define various services required to enable a decentralized
identification and trust management framework. A decentralized platform has the capability to facilitate a globally
unique digital identifier (i.e. DID with no possibility of duplication) related data management and control of associated
cryptographic verification data, service information, etc. as needed for decentralized identification and authentication of
a DID holder (i.e. user/device) to setup trusted interactions between the DID holder and a service provider for any
related digital service provisions. The procedural aspects of PDL based decentralized identification and trust
management ranges from different participants registration along with access control over the decentralized
identification system, related data storage and management operations (e.g. throughout the data lifecycle), the
decentralized identifier verification, and selective data exposure to service provider(s) for end-user/device
authentication respectively.
ETSI
10 ETSI GS PDL 023 V1.1.1 (2024-04)
A Decentralized Identification and Trust management framework can utilize the PDL services described in the PDL
reference architecture (ETSI GS PDL 012 [1]) for the governance related aspects and the decentralized identification
management and operation specific PDL services as shown in Figure 5.2.1-1. The core PDL service functionalities
(i.e. capabilities, behaviour, and relationships) which forms the building block of decentralized identification and trust
management process includes the following as shown in Figure 5.2.1-1 and it is described in detail in clause 5.2.2:
• Ledger Role-based registration management service;
• DID Operational participants Registry service;
• DID Resolver service;
• DID Document Registry service;
• VC Data Registry service; and
• DID Verification management service.
[R1] An ETSI-ISG-PDL compliant PDL platform SHALL include Mandatory Services required by the applications
using a decentralized Identification and trust management framework.
[O1] An ETSI-ISG-PDL compliant PDL platform MAY include one or more of Optional Services required by the
applications using such platform.
[R2] An ETSI-ISG-PDL compliant PDL platform SHALL include registry service(s) to manage the registered
participant specific data such as DID, DID documents and VC Data.
[O2] An ETSI-ISG-PDL compliant PDL platform MAY use a unified registry service for storing DID, Documents
and VC data specific to the DID Holder.
[O3] An ETSI-ISG-PDL compliant PDL platform MAY use dedicated registry service for storing different data
types such as DID with DID Documents and VC data specific to the DID Holder.
DID Controller
End User/ Presentation for authentication Verifier
Device (Service
(DID Holder) Provider)
PDL Platform Service(s)
Governance
Role based Registration
DID Operation participants Registry
Verifiable
Claim Issuer
DID Document Registry
DID Resolver VC Data Registry
Off-Chain Storage
DID Verification management
External Entities
PDL/DLT System
Figure 5.2.1-1: PDL based Decentralized Identification and Trust management framework
ETSI
11 ETSI GS PDL 023 V1.1.1 (2024-04)
5.2.2 PDL services for decentralized identification and trust management
5.2.2.1 Ledger Role-based registration management service
The Ledger role-based Registration Management Service (L-RMS) considers the following different roles for the
participants who are the integral users of the decentralized identification and trust management framework. It provides
registration service (along with authorization for fine grained access control) specific to the corresponding roles of the
participants and their allowed operations in the PDL platform. The role-based registration management service offers
registration and de-registration (e.g. revocation of registration) related services for different participants:
• Identity Holder (i.e. a DID Holder);
• Identity Controller (i.e. a DID Controller);
• VC Issuer; and
• DID Verifier.
[O2] An ETSI-ISG-PDL compliant PDL platform MAY include Decentralized Identification and Trust management
framework related functionalities.
If the PDL platform supports Decentralized identification and Trust Management Framework (DTMF) related
functionalities and operations, then further requirement(s) described in this clause are applicable.
[R2] An ETSI-ISG-PDL compliant PDL platform SHALL include Ledger Role-based registration management
service to manage the registration and operation of different participants (entities) utilizing such a framework.
5.2.2.2 DID Operational participants Registry service
The DID operational Participants Registry Service (DPRS) records and keeps track of the registered and de-registered
participants from the PDL platform based DTMF by considering the instructions from the L-RMS.
[R3] An ETSI-ISG-PDL compliant PDL platform SHALL include a registry service to record the registration and
operational details of different participants (entities) utilizing such a framework.
5.2.2.3 DID Resolver service
The DID Resolver Service (DRS) stores the DIDs in a DID registry, keeps track of the DID(s) and its associated DID
document location information (e.g. address) to enable DID document fetching and verification by the authorized
services and entities (i.e. DID Verifiers e.g. service providers).
5.2.2.4 DID Document Registry service
The DID Document Registry Service (DDRS) allows to store and manage the DID documents associated to the DID to
facilitate DID verification. Whereas each DID Document can contain at least three things: proof purposes, service
specific information for which the DID document can be used, verification methods, and service endpoints. Proof
purposes are combined with verification methods to provide mechanisms for proving things.
EXAMPLE: A DID Document can specify that a particular verification method, such as a cryptographic public
key or pseudonymous biometric protocol, can be used to verify a proof that was created for the
purpose of authentication.
Service endpoints enable trusted interactions with the DID holder as well as authorized verifier. The DID Document
Registry service offers Create (i.e. to store), Update, Revoke DID documents (i.e. deletion) related service operations.
5.2.2.5 VC Data Registry service
The VC Data Registry Service (VDRS) allows to store and manage the VCs associated to the DID to facilitate
VC based DID verification and validation related to a service request. The VC Data Registry service offers Create,
Update, and Revoke VCs related service operations.
ETSI
12 ETSI GS PDL 023 V1.1.1 (2024-04)
5.2.2.6 DID Verification management service
The DID Verification Management Service (DVMS) can be a composite service (ETSI GS PDL 012 [1]) that uses DID
resolver service, DID document registry service, DID operation(al) participant registry service and VC Data Registry
service to fetch necessary data related to verification of DID (i.e. authentication of the subject identified by the DID),
and performs exposure of selective data to the verifier to enable authentication of the subject and authorization
verification of subject to respective service(s).
5.3 PDL Framework Operations and Services
5.3.1 Registration Management
5.3.1.1 Introduction
Registration Management procedure describes how any participant mentioned in clause 5.2.2.1 can register to the
DTMF shown in Figure 5.2.1-1 to perform any of decentralized identification and trust management related operations
using the PDL based DTMF. Further the registration management procedure also describes how a participant can be
de-registered from the DTMF based on various conditions.
5.3.1.2 Role-based registration
The detailed registration management procedure for different participants (taking different roles) is described in this
clause as shown in Figure 5.3.1.2-1. The role-based registration procedure primarily involves two services such as
Ledger Role-based registration management service and DID Operational participants Registry service described in
clause 5.2.2. An entity (i.e. related to DID holder device, VC issuer and the DID Verifier) which requires to participate
in the Decentralized identification and trust management process can use the registration procedure described in this
clause to initially register to the DTMF to allow any further operations over the DTMF.
Registry
End Device
PDL platform/Ledger PDL Node-1 PDL Node-X Registry
Registry Service
Client/Application
Registration Management
(DID operation
(e.g., DID-Controller/VC Issuer/DID Verifier
participants)
Service (L-RMS)
1. Registration Request
(Identity,
DID service, Required access role
2. Authentication message exchanges
3. Process the request
4. Creates DID operation
participant registry transaction
5. Registry Transaction Notification
6. Propagate the registry
transaction
7. Receive the registry
transaction
8. Forward the registry Transaction
9. Record the registry
transaction
Figure 5.3.1.2-1: Role-based registration Procedure
ETSI
13 ETSI GS PDL 023 V1.1.1 (2024-04)
If the DID holder wants to register to the DTMF, it performs the following steps:
1) The DID holder sends a registration request to the PDL platform's Ledger role-based Registration Management
Service (L-RMS), which includes a source identity, service type information set as 'DID service' (i.e. to
indicate that the registration is related to the DID related entity which need to act as the DID holder in the
DTMF), required access role (indicates that DID holder access role is requested) and the actual DID (i.e. DID
refers to decentralized identity/digital identity/Self-Sovereign Identity (SSI) [i.1], [i.2], [i.3] and [i.4]. It is
generated either by the subject or by the subject controller in a privacy protected form to uniquely identify an
entity e.g. DID Controller in case of internet of things).
NOTE 1: The entity may have registered to the PDL platform as a general user (e.g. using ETSI GS PDL 012 [1])
of the PDL platform, in which case the entity may have a source identity). In certain case of
implementation if the entity has a client application or wallet installed to use the PDL platform, the access
to the PDL platform can be authenticated using the identity and credentials (e.g. public-private key)
associated to the client applications or the wallet.
[Conditional - applicable for DID Controller] In case, if a DID controller is involved in the registration procedure
instead of DID holder, then in step 1 the DID controller sends to the L-RMS, a registration request with the required
access role set as, 'DID Controller', Source Identity of the DID controller along with the other information described for
step 1 above.
[Conditional - applicable for DID holder/Controller who also want to take the role of VC Issuer] In case, if a DID
holder/controller is involved in the registration procedure, then in step 1 it sends to the L-RMS, a registration request
with more than one required access role set as, 'DID holder/Controller as applicable', 'VC Issuer', along with the other
information described for step 1 above.
[Conditional - applicable for VC Issuer] In case, if a VC Issuer is involved in the registration procedure, then in step 1
the VC Issuer sends to the L-RMS, a registration request where the required access role is set as, 'VC Issuer', and
Source Identity of the VC Issuer is also included with the other information as described for step 1 above.
[Conditional - applicable for DID Verifier] In case, if a DID Verifier is involved in the registration procedure, then in
step 1 the DID Verifier sends to the L-RMS a registration request where the required access role is set as, 'DID
Verifier', and Source Identity of the DID Verifier is also included with the other information as described for step 1
above.
2) The L-RMS can initiate and perform mutual authentication (e.g. based on local policy) with the DID holder
based on a preconfigured credentials (e.g. public-private key pair or any secret key associated to the client
application or wallet).
3) On a successful mutual authentication, the L-RMS process the registration request.
4) The L-RMS determines to register the DID holder and it sets a registration ID for the DID holder. Further it
creates a Registry transaction notification message which includes the L-RMS ID, target Registry service
information (i.e. such as registry service name, and ID (e.g. address) related to the DID Operation(al)
participant registry), Source Identity, Service type information (DID service), Registration ID, DID,
Authorized access role (set as DID holder), Authorization code, and Lifetime (for the validity of the
registration). Further the message can be transformed into a transaction (i.e. DID Operation(al) participant
registry transaction) to add the new participant related registration information to the DID Operation(al)
participant registry.
[Conditional - applicable for DID Controller] In case, if a DID controller is involved in the registration procedure
instead of DID holder, then in step 4, the L-RMS determines to register the DID controller and it sets a registration ID
for the DID controller. Further it creates Registry transaction notification message which includes the L-RMS ID, target
Registry service information (i.e. such as registry service name, and ID (e.g. address) related to the DID Operation(al)
participant registry), Source Identity, Service type information (DID service), Registration ID, DID, Authorized access
role (set as DID controller), Authorization code, and Lifetime (for the validity of the registration). Further the message
can be transformed into a transaction (i.e. DID Operation(al) participant registry transaction) to add the new participant
to the DID Operation(al) participant registry).
ETSI
14 ETSI GS PDL 023 V1.1.1 (2024-04)
[Conditional - applicable for VC Issuer] In case, if a VC Issuer is involved in the registration procedure, then in step 4,
the L-RMS determines to register the VC Issuer and it sets a registration ID for the VC Issuer. Further it creates
Registry transaction notification message which includes the L-RMS ID, target Registry service information (i.e. such
as registry service name, and ID (e.g. address) related to the DID Operation(al) participant registry), Source Identity of
the VC Issuer, Service type information (DID service), Registration ID, DID, Authorized access role (set as VC Issuer),
Authorization code, and Lifetime (for the validity of the registration). Further the message can be transformed int
...