A Survey on Decentralized Identifier Methods for Self Sovereign Identity

Abstract

We survey diferent approaches to Decentralized Identifiers (DIDs) for managing Self-Sovereign Identity (SSI). This kind of identification is used to give full control of identity to end-users by means of a distributed ledger, without the use of a centralized authority that manages the identity of users. We first describe SSI and then DIDs, by summarizing their characteristics. We list the diferent format implementations of these digital identities by reporting the type of verifiable data registry on which they are based on. We also report the document status od DIDs, the link to their description, and date of creation and update, with the purpose of understanding how much these projects are popular. Finally, we show which and how many of these DIDs are based on public or non-public ledgers.

Keywords

• eol>Decentralized identifiers
• Self-Sovereign identity
• Identity management

1. Introduction

IdM and authentication, is the process of approving or rejecting a subject’s request for access to an object (i.e., someone or something that wants to utilize a resource) (i.e., resources that a subject wants to use like network, data, application, service, etc.). Access control, in other terms, is a security method that limits who or what can perform a given activity (such as use, read, write, execute, or view) on a particular resource in a computing environment. Most often, this step is finished following successful authentication.

A new class of identifiers called a Decentralized Identifier (DID) allows for the creation of a verified, decentralized digital identity. A DID can be any topic that the DID’s controller chooses (e.g., a person, group, object, data model, abstract entity, etc.).3 DIDs have been created to be independent of centralized registries, identity providers, and certificate authorities, in contrast to conventional, federated identities. DIDs are URIs that associate a DID subject with a DID document allowing trustable interactions associated with that subject. Each DID document may contain cryptographic information, verification techniques, or other services that ofer a variety of ways for a DID controller to demonstrate control over the DID. Services allow for secure communication involving DID subjects. If the DID subject is an information resource, such as a data model, then a DID might ofer the capability to return the DID subject itself.

In this paper, we present the many formats in which these digital identities have been implemented together with information on their status as documents, links to their descriptions, and dates of creation and updates. Lastly, we demonstrate which DIDs are based on public or non-public ledgers and how many there are of each. Anyone can join the network of a public blockchain infrastructure without needing to ask for permission; additionally, all network users have access to the shared ledger and can participate in consensus by validating transactions (some examples are the blockchains of Bitcoin and Ethereum). Private networks are only accessible by invitation, which indicates that a centralized authority manages who is permitted access to the network. Additionally, this central entity has the power to assign participants roles, such as granting them the possibility to perform transactions and mining privileges. The existing transactions on the chain can be edited, deleted, or overridden by the same entity (some examples are the Morpheus Network4 and Corda5). Finally, a permissioned blockchain (also consortium blockchain) needs the operator’s consent in order to join and carry out certain operations. They have an extra layer of access control as a security mechanism, limiting specific on-chain actions to identifiable participants only. While permissioned blockchains allow any node to operate once the operator grants permission, private blockchains only permit known nodes to operate (some examples are Ripple and IBM Food Trust6). For non-public blockchains, we consider all the proposals that do not meet the features of public blockchains, hence private and permissioned. Some of the proposals are ledger-agnostic: they are given without specifying the ledger, while some other proposals are based on a registry which is not a blockchain.

The paper has the following structure: after this introduction motivating the use of DIDs (Section 1), we present Self-Sovereign Identity in Section 2 and then Section 3 elaborates on DIDs by presenting their structure and features. Section 4 summarizes the diferent DID methods, while Section 5 overviews the related work. Finally, we wrap up the paper with final conclusions and future work. 3W3C recommendation on Decentralized Identifiers (DIDs) v1.0: #dfn-decentralized-identifiers. 4Morpheus Network: https://morpheus.network/. 5Corda: https://www.r3.com/corda-platform/. 6IBM Food Trust: https://www.ibm.com/products/supply-chain-intelligence-suite/food-trust. https://www.w3.org/TR/did-core/

2. Self-Sovereign Identity

The term “identity” is in general considered as a collection of attributes associated with a specific person or entity, given a particular context. A non-human identity may be related to a piece of software or hardware, for example. An identity includes at least one identifier (or more) and may also indeed include further attributes associated with that person or entity. For example, human identities may include attributes such as name, age, address, phone number, and job title. On the other hand, non-human identities collect attributes such as an owner, IP address, and perhaps a model or version number. This set of attributes can be used for authentication and authorization, but also to provide information about the related identity to applications.

A Digital Identity [ 1 ] is a means for people to prove electronically that they are who they say they are. The history of online identities started with centralized identities, then federated, and finally user-centric identities nowadays. Unfortunately, giving centralized authorities the power to govern a person’s digital identity has many of the same drawbacks as giving state authorities control over people’s physical identities: users are tied to a single authority who can confirm a false identity, or even deny their own. Power is inherently transferred from the users to centralized entities through centralization. One of the ifrst federated systems was Microsoft’s Passport (year 1999). It envisioned federated identification, which would enable users to use a single identity across several websites. Nonetheless, it made the federation virtually as centralized as conventional government by placing Microsoft at its heart. Sun Microsystem established the Liberty Alliance in response (year 2001). They opposed the concept of centralized power and established a “genuine” federation instead. The outcome, however, was an oligarchy because the power of centralized authority was shared among diferent organizations (e.g., Intel, Oracle, British Telecom).

Self Sovereign Identity (SSI) is a sovereign, enduring, and portable identity for any person, organization, or body, that allows its owner to access all relevant digital services by utilizing credentials linked to the identity in a privacy-preserving manner [ 2 ]. Unlike previous identity management systems where the service provider was at the center of the model, SSI is user-centric. In this system, the claim issuer releases the identity by attesting some attributes of the user, in order for him to be authenticated by a relying party. The latter can request claims provided by claim issuers, there must be a relationship of trust between the relying party and the claim issuer. So the SSI ecosystem is composed of three main roles Issuer, Holder and Verifier : Issuer: creates and issues credentials to a holder; Holder: receives credentials from an issuer, retains it and when it is required, it shares them with a verifier; Verifier: receives and verifies credentials presented by a holder. This workflow, which is further detailed in the following of this section, is represented in Figure 1.

The basis of the SSI architecture is the distributed ledger of a blockchain. The blockchain acts as a replacement for the registration authority in classic identity management systems (i.e., IAM) and works as an identifier registry . A verifiable data registry (VDR),7 in the context of decentralized identity, is a place where DIDs can be anchored to. Everyone who reads the blockchain can verify the identifier stored in it by posing a challenge to the user or a delegate. Public-private key pairs are the most common authentication method used in SSI solutions, in fact, they are called Decentralized Public Key Infrastructures. However, some of the proposals are not based on a blockchain (as we will see in Figure 2). The pairing of identification and authentication is maintained. The identifier as well as the verifiable claims are directly managed by the user. The actual identity claim is stored in user-controlled storage, typically of-chain for privacy considerations.

The SSI architecture relies on mapping an identifier to a specific authentication method that is recorded on a registry [ 3 ]. Identifiers can be grouped into three diferent categories: • First, identifiers based on random number generation rely on probabilities to avoid collisions. • Then, centralized identifiers utilize a registration authority in order to assign identifiers and prevent collisions. • Finally, blockchain technology can help merge the best aspects of both previous approaches, and authentication is typically done with the use of a public/private key pair, where the public key is stored as the value of the identifier on the blockchain [ 3 ].

The underlying architecture of the SSI is the blockchain for the registration authority in classic identity management systems. In fact, it is also called identifier registry .

In defining the key characteristics of SSI, ten principles underlying this model were defined: these principles have been grouped into three sections in [ 4 ], as shown in Table 1. Security can be summed up as the protection of personal user data and the limiting of data exposure to the minimum required to fulfill a function. A persistent identity was named as a security requirement, but this should not contradict a “right to be forgotten” as stated by Allen [ 5 ]. The Controllability category as both control and consent should extend to the removal of the identity, not only the creation and access. The Portability of the Identity is essential so that the user can use their identity wherever they want and be independent of any particular identity provider.

The ten principles consist in Existence: A user must have an independent existence, this means that an SSI identity can never be “decoupled” from its physical entity and therefore cannot exist exclusively in the digital world. Control: a user must control his own identity. Note that this does not preclude other entities, such as users, companies, or institutions, from making assertions about the user and defining certain characteristics or properties. Access: the user must have access to his own data. Transparency: Systems and algorithms must be transparent. Persistence: Identities must be long-lived. At the same time, the user should be able to have an identity if they wish and claims should be modified or removed, this is referred to as the “right to be forgotten”. Portability: Identity information and services must be portable, i.e. not linked to a digital entity, for example, a social network, nor to a specific jurisdiction, such as a State. Interoperability: Identities should be as widely usable as possible, they have to be used globally and are not limited to certain businesses or industries. Consent: Users must agree to the use of their identity. Minimization: Disclosure of claims must be minimized. Protection: User rights can be protected and they have priority over the network needs to support the SSI model.

There are three technical elements at the basis of an SSI system: • Decentralized Identifiers (DIDs) : an alphanumeric string that uniquely identifies an entity.

For example, some identifiers for an individual may be the name and surname or the tax code, or codes that allow this individual to be recognized unambiguously. Similarly, in an SSI model, DIDs are alphanumeric codes based on a double cryptographic key system, stored on the blockchain, which allows an entity to be uniquely identified online. 7Verifiable data registry: https://www.w3.org/TR/did-core/#dfn-verifiable-data-registry.

• Verifiable Claims (VCs) : any type of attribute associated to an entity. Some equivalents of a VC in the real world are a driving license or a university degree. However, in the SSI model, the VCs are digital, immutable, and independently verifiable in each interaction where that specific attribute is required. • DID Documents: a set of data describing the DID subject, including mechanisms, such as cryptographic public keys, that the DID subject or a DID delegate can use to authenticate itself and prove its association with the DID [ 6 ].

In this paper, we focus on the first component, i.e., DIDs, which will be detailed in the following sections.

3. Decentralized Identifier (DID)

A Decentralized Identifier (DID) is a new type of globally unique identifier. DIDs are the core component of a new layer of decentralized digital identity and public key infrastructure (PKI) for the Internet. W3C decentralized identifiers [ 6 ], can be seen as a high-level naming scheme, such as Uniform Resource Name (URN ). DIDs are composed of: i) a scheme, ii) a method, and iii) a method specific identifier , which are separated by colons: for example, “id:example:12345”. The scheme is the DID keyword, the method part describes the DID method used to store the identity data, and the method-specific identifier is diferent for each method, and it describes the way to generate the identifier.

DIDs are a new type of identifier that enables verifiable, decentralized digital identity [ 6 ]. DIDs design was studied to be separated from centralized registries, identity providers, and certificate authorities. Moreover, the DID design makes it possible for the controller of a DID to prove control over it without the permission of any other party. DIDs are, in the end, Universal Resource Identifiers (URI s) that associate a DID subject with a DID document allowing trustable interactions associated with that specific subject [ 6 ]. In this context, a DID document records cryptographic material, verification methods, and services that enable a DID controller to prove control over the DID while services make it possible to have trusted interactions associated with the DID subject.

The Decentralized Identity Foundation (DIF ) developed a resolver for these paths [ 7 ]; a specific driver is developed and maintained for each individual method. It uses the method type to decide which driver to use and uses the method specific identifier to resolve the DID document stored on the specified blockchain. The DID document is the key part of the decentralized identity [ 3 ]. In it, the authentication method is defined to bind the specified identifier to an identity that is in control of a secret key or other data used in the authentication.

DIDs are only the base layer of decentralized identity infrastructure. The higher layer is Verifiable credentials, the technical term for a digitally signed electronic credential [ 8 ]. DIDs can be used to identify various entities in the Verifiable Credentials ecosystem such as issuers, holders, subjects, and verifiers. DIDs can be used as identifiers for people, devices, and organizations [ 8 ].

3.1. DID Document

The DID infrastructure can be thought of as a global key-value database in which the database is all the DID-compatible blockchains, distributed ledgers, or decentralized networks where the key is a DID and the value is a DID document. A DID document is a valid JSON-LD (JSON for Linking Data)8 object that uses the DID context defined in the DID specification [ 8 ]. Developers can use any other representation method, such as XML or YAML, that is capable of expressing the data model.9 The DID document includes six optional components: 1. DID, so that the DID document is fully self-describing. 2. Set of cryptographic material, such as public keys, that can be used for authentication or interaction with the DID subject. 3. Set of cryptographic protocols for interacting with the DID subject, such as authentication and capability delegation. 4. Set of service endpoints that describe where and how to interact with the DID subject. 5. Timestamps for auditing. 6. JSON-LD signature if needed to verify the integrity of the DID document. 11

Listing 1: An example of DID Document. {"@context": [ "https://www.w3.org/ns/did/v1", "https://w3id.org/security/suites/ed25519-2020/v1 "], "id": "did:example:123", "authentication": [{ "id": "did:example:123#z6MkecaLyHuYWkayBDLw5ihndj3T1m6zKTGqau3A51G7RBf3", "type": "Ed25519VerificationKey2020", // external (property value) "controller": "did:example:123", "publicKeyMultibase": "zAKJP3f7BD6W4iWEQ9jwndVTCBq8ua2Utt8EEjJ6Vxsf"}], "capabilityInvocation": [{ "id": "did:example:123#z6MkhdmzFu659ZJ4XKj31vtEDmjvsi5yDZG5L7Caz63oP39k", "type": "Ed25519VerificationKey2020", // external (property value) "controller": "did:example:123", "publicKeyMultibase": "z4BWwfeqdp1obQptLLMvPNgBw48p7og1ie6Hf9p5nTpNN"}], "capabilityDelegation": [{ "id": "did:example:123#z6Mkw94ByR26zMSkNdCUi6FNRsWnc2DFEeDXyBGJ5KTzSWyi", "type": "Ed25519VerificationKey2020", // external (property value) "controller": "did:example:123", "publicKeyMultibase": "zHgo9PAmfeoxHG8Mn2XHXamxnnSwPpkyBHAMNF3VyXJCL"}], "assertionMethod": [{ "id": "did:example:123#z6MkiukuAuQAE8ozxvmahnQGzApvtW7KT5XXKfojjwbdEomY", "type": "Ed25519VerificationKey2020", // external (property value) "controller": "did:example:123", "publicKeyMultibase": "z5TVraf9itbKXrRvt2DSS95Gw4vqU3CHAdetoufdcKazA"}] }

The DID document uses JSON-LD format and is composed of various components, here is a list of them: • The context on the JSON-LD format can be seen as “the context of the conversation” when people communicate with one another on a specific subject. Context is used to map terms, a short word 8JSON-LD: https://json-ld.org. 9DID representation formats: https://www.w3.org/TR/did-core/#representations.

that may be expanded to IRIs (Internationalized Resource Identifiers). An IRI is built on top of a URI and is defined as a sequence of characters, not as a sequence of octets. The DID Document must have exactly one top-level context statement. The key for this property is @context and the value for this key is the URL for the generic DID context https://w3id.org/did/v1. • id represents the actual identifier. • The publicKey lists all the public keys whose corresponding private keys are controlled by the entity identified by the DID. The value of the publicKey property is an array of public keys. It includes also id and type properties and the value property can be PublicKeyPem, PublicKeyHex, PublicKeyBase58, EthereumAddress, or similar, depending on the format and encoding of the public key. • The DID Authentication is the mechanism by which an entity can cryptographically prove that they are associated with a DID. The value of the authentication property is an array of the proof mechanisms, each one includes the type property and embeds or references a public key. • The DID Service Endpoint includes a serviceEndpoint property that is a JSON array of service endpoints. serviceEndpoint describes the network address at which a service operates on behalf of an entity. DID Service Endpoints include discovery services, social networks, file storage services, and verifiable claim repository services. • The last component of a DID Document is the Proof. Proof contains a created property which represent a creation timestamp and an updated property that represent the update timpestamp.

Both of the timestamps are valid XML DateTime values normalized to UTC 00:00.

4. The DID Method Specification and a Survey

DIDs and DID Documents can be adapted to any modern blockchain, distributed ledger, or other decentralized networks capable of resolving a unique key into a unique value. Defining how a DID and DID document are created, resolved, and managed on a specific blockchain or “target system” is the role of a DID method specification. DID method specifications define the following operations for a particular target system: 1. Create. Some DID methods may generate a DID directly from a cryptographic key pair. 2. Read. Some DID methods use blockchains that can store DID Documents directly on the blockchain. Others may instruct DID resolvers to construct them dynamically based on attributes of a blockchain record. Others may store a pointer on the blockchain to a DID document stored in one or more parts on other decentralized storage networks such IPFS [ 9 ]. 3. Update. The update operation is the most critical from a security standpoint because control of a DID document represents control of the public keys or proofs necessary to authenticate an entity. Since verification of DID document update permissions can only be enforced by the target blockchain, the DID method specification must define precisely how authentication and authorization are performed for any update operation. 4. Delete. DID entries on a blockchain are by definition immutable, so they can never be “deleted” in the conventional database sense. However, they can be revoked in the cryptographic sense. A DID method specification must define how this termination is performed.

4.1. A List of DID Methods

In Table 2 we report all the 168 DID methods that follow the W3C standard [ 10 ], which have been collected up to May 2023. We enrich this list by providing the network/DLT on which the proposal is used. Some of these proposals use two diferent registries, as the grn DID, for example. For each registry we report the fundamental characteristics: if the registry is a Public ledger (Pb) Private ledger (Pr), Permissioned ledger (Pd), Permissionless ledger (Pl), Non-Ledger (Nl), and finally Ledger-agnostic (La). highlights the fact that Ethereum is the most frequent public blockchain used for DIDs. the last update was in 2022, while Table 4 does the same for all the DID proposals on public blockchains; the proposals updated in 2022 are highlighted in bold. Table 3 and Table 4 provide a Web link to the documentation of the related method: if the DID method is tagged with “app” it means that an implementation is also available, while with “draft” only the draft of a potential DID specification is given. We can see that, despite a large number of proposals, only a few of them has been updated in public ledgers, Ethereum is definitely the first choice with one DID method out of two adopting this choice (around 51%). to find. The acronyms in the third column can be read by using the following legend: Public ledger (Pb) Private ledger (Pr), Permissioned ledger (Pd), Permissionless ledger (Pl), Non-Ledger (Nl), Ledger-agnostic (La). This table is updated to May 2023.

5. Related Work

In this section, we present and describe some of the works in the related literature that survey blockchainbased approaches to SSI and applications concerning SSI and blockchain-based systems.

In [ 11 ] the authors provide an overview of IAM solutions based on their basic components, including identity management, authentication, and access control; related to the identity concept, they discuss self-sovereign identity. A taxonomy based on their features is then proposed to categorize these proposals. Finally, the existing methods are compared by using the proposed taxonomy.

The work in [ 3 ] provides an overview of the Self-Sovereign Identity (SSI) concept, focusing on four diferent components that are considered essential to the architecture. Self-Sovereign Identity is enabled by the new development of blockchain technology. The authors give a simple overview of blockchain-based SSI, introducing an architecture overview as well as relevant actors in such a system. Then they discuss identifiers in such systems by presenting some related approaches in SSI. Most central to the concept of an SSI is the verifiable claims that are presented to relying parties.

[ 12 ] provides a review of existing blockchain-based identity management papers and patents published between May 2017 and January 2020, which allow the user to take over control of his/her own identity. The work in [ 13 ] examines the properties that a self-sovereign identity should have and explores the impact of SSI on the laws of identity. It also describes the essential life cycles of an identity management system and inter-relates how the notion of SSI can be applied in these life cycles.

Method did:bnb did:btcr did:dual did:ens did:eosio did:erc725 did:etho did:gatc did:ion did:ipid did:jolo did:monid did:pistis did:ethr

Ethereum Bitcoin Ethereum Ethereum Eosio Ethereum Ethereum

Smart Ethereum and others Bitcoin IPFS Ethereum Ethereum

Ethereum did:pkh did:polygon

Ethereum

Polygon, Ethereum did:scheme

IPFS did:selfkey did:signor

Ethereum

Ethereum e altro did:sol did:stack did:tangle did:tls did:trx did:tyron did:tz did:unisot did:vaultie did:vivid

Solana Bitcoin IOTA Tangle Ethereum Tron Zilliqa Tezos Bitcoin SV Ethereum Zilliqa, Neo

State draft https://github.com/ontology-tech/ DID-method-specs/blob/master/did-bnb/ DID-Method-bnb.md draft https://github.com/dcdpr/btcr-DID-method draft https://github.com/Smart-ID-Card/Dual-DID/ blob/main/docs/dual-did-method.md draft https://github.com/veramolabs/did-ens-spec app https://www.gimly.io/eosio-identity discontinued draft https://github.com/ontology-tech/ DID-method-specs/blob/master/did-etho/ DID-Method-etho.md draft https://github.com/decentralized-identity/ ethr-did-resolver/blob/master/doc/did-method-spec. md draft https://github.com/gataca-io/gataca-did-method

Moreover, the paper illustrates several possible information flows involving a self-sovereign identity leveraging blockchain technology covering diferent aspects of an identity management system.

The paper in [ 14 ] presents a blockchain-based digital identity solution. Without depending upon a single trusted third party; the proposed framework achieves passport-level legally valid identity. This solution for making identities Self-Sovereign builds on a generic provable claim model for which attestations of truth from third parties need to be collected. Four diferent implementations are shown to ofer sub-second performance for claim creation and claim verification. In [ 15 ] the authors present the Sora identity system, which is a mobile app that takes advantage of blockchain technology to create a secure protocol for storing encrypted personal information, as well as sharing verifiable claims about personal information.

The work in [ 16 ] provides a criteria-driven survey of the solutions and technologies for identitymanaging blockchain-based systems and architectures in the context of verified claims and self-sovereign identities. the authors consider an extensive set of requirements covering ecosystem aspects, end-user functionality, mobility and overhead aspects, compliance/liability, EU regulations, standardization, and integration.

In [ 17 ] the state-of-the-art in Blockchain (BC)-based self-sovereignty and patient data records in healthcare is reviewed, by also proposing to provide an analysis of the design trade-ofs. The motivation is to investigate the potential of blockchain technology for use in patient data and identity management. As a distributed decentralized technology, blockchains can be very beneficial, giving patients control over their own data and self-sovereign identity. The work in [18] first validates nine properties of self-sovereignty proposed by credible sources, then it proposes five new ones, and finally, it reasons about and validates these properties by proposing an architecture to enforce them. In [19] the authors implement a PoC of a decentralized OpenID Connect Provider by matching it with SSI, in order to give users the freedom to choose from a large pool of identity providers instead of just a select few corporations.

6. Conclusion

With the rapid growth of digital ecosystems, individuals are increasingly sharing large amounts of personal data through low-security digital interactions, sacrificing their privacy and security. Digital ID is a way of proving who we are and generating opportunities to carry out interactions in a simple and safe way in the digital world. Eficiency, cost reduction, fraud prevention, and less bureaucracy are some of the benefits of using a secure digital identity.

Blockchains (public from our point of view) can support the transparent use of DID for real-world applications. However, using this approach to IdM is still challenging: Many IdM features, including identity recovery, lookup services, backup of cryptographic keys, etc., may be jeopardized by the complete removal of the central authority. As a result of their familiarity with the various warnings, it has been demonstrated in practice that user agreement frequently results in the disclosure of the maximum information. Moreover, in order to provide pseudonymity while retaining the necessary levels of secrecy, integrity, authenticity, non-repudiation, and robustness, a user-controlled identity requires a transparent flow of data.

In this paper, we have collected and reviewed 107 diferent approaches to represent a DID, all following W3C standards and reference documents [ 6, 8, 10 ]. The goal is to understand where possible real-world applications based on SSI are directed to, and the general adoption of this approach.

Acknowledgments

S. Bistarelli and F. Santini are members of INdAM GNCS and Consorzio CINI. This work has been partially supported by: GNCS-INdAM, CUP E55F22000270001; Project FICO, Ricerca di Base 2021, University of Perugia; Project BLOCKCHAIN4FOODCHAIN, Ricerca di Base 2020, University of Perugia; Project GIUSTIZIA AGILE, CUP J89J22000900005. [18] K. C. Toth, A. Anderson-Priddy, Self-sovereign digital identity: A paradigm shift for identity, IEEE

Security & Privacy 17 (2019) 17–27. doi:10.1109/MSEC.2018.2888782. [19] Z. A. Lux, D. Thatmann, S. Zickau, F. Beierle, Distributed-ledger-based authentication with decentralized identifiers and verifiable credentials, in: 2020 2nd Conference on Blockchain Research & Applications for Innovative Networks and Services (BRAINS), 2020, pp. 71–78. doi:10. 1109/BRAINS49436.2020.9223292.

References

[1] P. A. Grassi , J. L. Fenton , M. E. Garcia , Digital identity guidelines [including updates as of 12- 01- 2017], 2017 . doi:https://doi.org/10.6028/NIST.SP. 800 -63-3.

[2] N. Naik , P. Jenkins, uport open-source identity management system: An assessment of selfsovereign identity and user-centric data platform built on blockchain , in: 2020 IEEE International Symposium on Systems Engineering (ISSE) , IEEE, 2020 , pp. 1 - 7 .

[3] A. Mühle , A. Grüner , T. Gayvoronskaya , C. Meinel , A survey on essential components of a self-sovereign identity , Comput. Sci. Rev . 30 ( 2018 ) 80 - 86 .

[4] A. Tobin , D. Reed , The inevitable rise of self-sovereign identity , The Sovrin Foundation 29 ( 2016 ) 18 .

[5] C. Allen , The path to self-sovereign identity , 2016 . URL: https://www.lifewithalacrity.com/ 2016 / 04/the-path -to-self-soverereign-identity .html.

[6] W3C , Decentralized identifiers (dids) v1.0, 2021 . URL: https://www.w3.org/TR/did-core/.

[7] D. I. F. (DIF), Universal resolver , 2022 . URL: https://dev.uniresolver.io/.

[8] W3C, A primer for decentralized identifiers , 2021 . URL: https://w3c-ccg.github.io/did-primer/.

[9] TranSendX, did:ipid method specification, 2018 . URL: https://did-ipid.github.io/ipid-did-method/.

[10] W3C , List of did methods, 2023 . URL: https://www.w3.org/TR/did-spec-registries/#did-methods.

[11] F. Ghafari , K. Gilani , E. Bertin , N. Crespi , Identity and access management using distributed ledger technology: A survey , International Journal of Network Management 32 ( 2021 ). doi: 10 . 1002/nem.2180.

[12] Y. Liu , D. He , M. S. Obaidat , N. Kumar , M. K. Khan , K.-K. Raymond Choo , Blockchain-based identity management systems: A review , Journal of Network and Computer Applications 166 ( 2020 ) 102731 . doi:https://doi.org/10.1016/j.jnca. 2020 . 102731 .

[13] M. S. Ferdous , F. Chowdhury , M. O. Alassafi , In search of self-sovereign identity leveraging blockchain technology , IEEE Access 7 ( 2019 ) 103059 - 103079 . doi: 10 .1109/ACCESS. 2019 . 2931173 .

[14] Q. Stokkink , J. Pouwelse , Deployment of a blockchain-based self-sovereign identity , in: 2018 IEEE International Conference on Internet of Things (iThings) and IEEE Green Computing and Communications (GreenCom) and IEEE Cyber, Physical and Social Computing (CPSCom) and IEEE Smart Data (SmartData ), 2018 , pp. 1336 - 1342 . doi: 10 .1109/Cybermatics\_ 2018 . 2018 . 00230 .

[15] M. Takemiya , B. Vanieiev , Sora identity: Secure, digital identity on the blockchain , in: 2018 IEEE 42nd Annual Computer Software and Applications Conference (COMPSAC) , volume 02 , 2018 , pp. 582 - 587 . doi: 10 .1109/COMPSAC. 2018 . 10299 .

[16] M. Kuperberg , Blockchain-based identity management: A survey from the enterprise and ecosystem perspective , IEEE Transactions on Engineering Management 67 ( 2020 ) 1008 - 1027 . doi: 10 .1109/TEM. 2019 . 2926471 .

[17] B. Houtan , A. S. Hafid , D. Makrakis , A survey on blockchain-based self-sovereign patient identity in healthcare , IEEE Access 8 ( 2020 ) 90478 - 90494 . doi: 10 .1109/ACCESS. 2020 . 2994090 .