Use Cases and Requirements for Decentralized Identifiers

W3C Working Draft

This version:
Latest published version:
Latest editor's draft:
Previous version:
Joe Andrieu (Invited Expert)
Phil Archer (GS1)
GitHub w3c/did-use-cases
File a bug
Commit history
Pull requests


This document sets out use cases and requirements for a new type of identifier that has 4 essential characteristics:

  1. decentralized: there should be no central issuing agency;
  2. persistent: the identifier should be inherently persistent, not requiring the continued operation of an underling organization;
  3. crytopgraphically verifiable: it should be possible to prove control of the identifier cryptographically;
  4. resolvable: it should be possible to discover metadata about the identifier.

Although existing identifiers may display some of these characteristics, none currently displays all four.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at

This document was published by the Decentralized Identifier Working Group as a Working Draft.

GitHub Issues are preferred for discussion of this specification. Alternatively, you can send comments to our mailing list. Please send them to (archives).

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the W3C Patent Policy. The group does not expect this document to become a W3C Recommendation. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 1 March 2019 W3C Process Document.

1. Introduction

The need for globally unique identifier schemes has been addressed many times. Globally unique ID schemes typically rely on a central authority controlling a 'root' space that is then delegated to local organizations who in turn delegate to further organizations who eventually add the final string to complete the identifer. Even if we restrict ourseleves to online identifiers, there are many examples of this.

In all these cases, ultimately, there is a central authority on which the identifier system depends. Those central authorities go to significant efforts to make their identifiers persistent and resolvable, however, should they cease to exist, the long term integrity of the identifier is at least questionable to a greater or lesser extent. For as long as those organizations exist (and they are generally well established with no immediate threat to their survival), the way to assess whether a particular identifier is in some way 'valid' is to query the issuing authority.

These factors point to a need in some circumstances for a globally unique identifier that is 'self sovereign', that is, one that does not depend on any issuing authority. Universally unique identifiers (UUIDs) [RFC4122] fulfill this role, however, there is no way to prove control of a UUID.

This document sets out use cases and requirements for a new kind of identifier that meets all these basic requirements:

  1. decentralized: there should be no central issuing agency;
  2. persistent: the identifier should be inherently persistent, not requiring the continued operation of an underling organization;
  3. crytopgraphically verifiable: it should be possible to prove control of the identifier cryptographically;
  4. resolvable: it should be possible to discover metadata about the identifier.

1.1 Existing Work

The use cases and requirements set out below have not been created a priori. Substantial work has been done within W3C and elsewhere leading, in particular, to Decentralized Identifiers (DIDs) Data Model and Syntaxes published as a Community Group Report by the Credentials Community Group in August 2019. That work provides a framework — a set of concepts — that have proved to be useful when discussing DIDs and the problems they can solve (see below). Those concepts are used within this document to set out the detail of the problem that the Decentralized Identifier Working Group is chartered to solve. It is the nature of the standardization process that these terms may be modified within the standard itself and therefore, their use here should not be seen as authoritative.

1.2 Concepts of Decentralized Identity

Issue 39: Relying Party terminology could confuse things

Terminology in this opening prose is being discussed, in particular the term 'relying party'

A decentralized system will enable several key actions by three distinct entities: the Controller, the Relying Party, and the Subject.

Controllers create and control DIDs, while Relying Parties rely on DIDs as an identifier for interactions related to the DID Subject.

The Subject is the entity referred to by the DID, which can be anything: a person, an organization, a device, a location, even a concept. Typically, the Subject is also the Controller, but in cases of guardianship, agents (human or software), and inanimate Subjects, this is not possible. As such, the Subject has no functional role. When the Subject is, in fact, the DID Controller, we consider the action to be taken by the Controller on their own behalf as the Subject. When the Subject is not the DID Controller, the Controller is said to be taking action on behalf of the Subject, such as when an employee manages a DID on behalf of their employer or a parent uses a DID on behalf of their child.

The DID Controller and Relying Party may be individuals or interactive systems, but for simplicity in this document, we refer to both as if they were individual persons performing these actions.

Only a DID Controller can perform the actions that control a DID, however, anyone can act as a Relying Party for any DID they know, including the DID Controller, should they wish to inspect or verify their own DID.

This use case document defines these actions in terms of the eventual systems we anticipate using the resultant specification.

Perhaps the most salient point about Decentralized Identifiers is that there are no "Identity Providers". Instead, this role is subsumed in the decentralized systems that Controllers use to manage DIDs and, in turn, Relying Parties use to apply DIDs. These decentralized systems, which we refer to as DID registries, are designed to operate independently from any particular service provider and hence, free from any given platform authority. It is anticipated that DIDs will be registered using distributed ledger technology (DLT).

In practice, the definition and operation of all current decentralized systems retain some elements of centralized control. Depending on the criteria one uses to evaluate such systems — from who controls the most widely used code base to who controls the specification — where a system resides on the spectrum of centralized and decentralized varies. However, the design of any decentralized identity system is separate from the academic debate about how decentralized it may be in practice.

The use cases presented below make use of a number of high level concepts as follows.

Note: Shared terminology

This section is automatically synchronised with the terminology section in the DID Core specification.

This document attempts to communicate the concepts outlined in the decentralized identifier space by using specialized terms to discuss specific concepts. This terminology is included below and linked to throughout the document to aid the reader:

decentralized identifier (DID)
A globally unique identifier that does not require a centralized registration authority because it is registered with distributed ledger technology (DLT) or other form of decentralized network. The generic format of a DID is defined in this specification. A specific DID scheme is defined in a DID method specification.
DID controller
The entity, or a group of entities, in control of a DID or DID document. Note that the DID controller might include the DID subject.
DID document
A set of data describing the DID subject, including mechanisms, such as public keys and pseudonymous biometrics, that the DID subject can use to authenticate itself and prove their association with the DID. A DID document might also contain other attributes or claims describing the subject. These documents are graph-based data structures that are typically expressed using [JSON-LD], but can be expressed using other compatible graph-based data formats.
DID fragment
The portion of a DID URL that follows the first hash sign character (#). DID fragment syntax is identical to the URI fragment syntax.
DID method
A definition of how a specific DID scheme can be implemented on a specific distributed ledger or network, including the precise methods by which DIDs are resolved and deactivated and DID documents are written and updated.
DID path
The portion of a DID URL that begins with and includes the first forward slash character (/). DID path syntax is identical to the URI path syntax.
DID query
The portion of a DID URL that follows the first question mark character (?). DID query syntax is identical to the URI query syntax.
DID registry
A role a system performs to mediate the creation, verification, updating, and deactivation of decentralized identifiers. A DID registry is a type of verifiable data registry. For more information, see [VC-DATA-MODEL].
DID scheme
The formal syntax of a decentralized identifier. The generic DID scheme is defined in this specification. Separate DID method specifications define a specific DID scheme that works with that specific DID method.
DID subject
The entity the DID document is about. That is, the entity identified by the DID and described by the DID document.
A DID plus an optional DID path, optional ? character followed by a DID query, and optional # character followed by a DID fragment.
distributed ledger (DLT)
A distributed database in which the various nodes use a consensus protocol to maintain a shared ledger in which each transaction is cryptographically signed and chained to the previous transaction.
Uniform Resource Identifier (URI)
An identifier, as defined by [RFC3986].
Universally Unique Identifier (UUID)
An identifier, as defined by [RFC4122].
Issue 14: What does it mean for a DID to be "recorded in a registry"? FPWD

The term DID registry is under discussion within the Working Group. A particular point to bear in mind is that not all DID methods require DIDs to be registered to be functional.

When we refer to methods and registries, we mean DID methods and DID registries. A working assumption for the use cases is that all DIDs resolve to DID Documents. DID Documents contain the cryptographic material to perform the functions related to that particular DID, including associated proof methods and any service endpoints, that is, services that can make use of the DID.

2. Use Cases

2.1 Online shopper

Traditionally, a shopper frequents a trusted retailer and can physically hold the products they wish to purchase. The product and the information about it is trusted because it is put there by the brand, and the shopper trusts that the retailer has received the product through trusted supply chain partners. Today, there is a multitude of channels and platforms for selling and buying products. The internet has changed consumer purchasing behavior as more and more commerce is conducted digitally. This introduces new challenges for brands, retailers and consumers, as the relationship is not as direct as the traditional mode of shopping.

Online shopping, especially through 3rd party marketplaces, creates a proliferation of digital records about that product across platforms. Unlike a physical product, a consumer cannot be assured that the record (and the information presented about that product) came from the brand or other authoritative source. Product identification and information and the source of the product itself is less reliable, and introduces trust issues with representations of products bought and sold online. Additionally, unique identification is critical to business processes, but also to online purchasing. Very often two different products share the same identifier across the supply chain, and so what a consumer purchases and what ultimately is received may be different.

Mechanisms are required for the following to provide trust in the digital representation of a product across platforms:

  1. validation of the legitimacy of an online listing — in particular on third party marketplaces;
  2. assurance of identification uniqueness and key identifying data element accuracy.
Editor's note

More short use cases to be added

3. DID Actions

Here are the thirteen (13) actions envisioned in earlier work by Credentials Community Group as being necessarily supported by DIDs. In the diagram, actions have been grouped by Create, Read, Update, and Delete (CRUD) as well as Use.

Actions supported by DIDs, grouped by type, and related to the entity which carries out the action

3.1 Create

Issue 14: What does it mean for a DID to be "recorded in a registry"? FPWD

This section refers to recording in a registry. I've changed it to say 'may be' but this can only be finalized when Issue-14 is resolved.

Controllers create DIDs, uniquely binding cryptographic proofs with the identifier, typically using public-private key-pairs. These DIDs may be recorded in a registry in such a manner as to be able to resolve to a DID Document. The DID Document may be dynamically and deterministically generated through resolution or it may be explicitly constructed as a stand-alone resource and either stored or referenced in the registry. In this scenario, the process will need access to any registry, ideally a decentralized system, and like the rest of the DID CRUD actions, it shold be possible to create the DID without interaction with any particular authority.

3.2 Present

DIDs are URIs, which is to say a string of characters. As such, they may be presented in the same manner as URIs by simply transmitting or presenting that string of characters. There is no requirement, however, that DIDs be human readable. Thus they may contain long, complex numbers represented in various formats. For ease of use, implementations may rely on data carriers such as QR codes [QR] for ease of capture using a camera-enabled device such as a smart phone.

3.3 Authenticate

Relying Parties may wish to prove that the individual presenting a DID is in fact its DID Controller or specified as a Controller for a particular service endpoint. This authentication process should use the cryptographic material in the DID Document to test if the claimed Controller can, in fact, prove control, typically through some sort of challenge-response. DID Documents and methods may allow for separate proofs for different service endpoints, distinct from update and delete actions. This separation would support transactional proofs that are expected to be used frequently, while controlling proofs are expected to be used rarely.

3.4 Sign

Using cryptographic material associated with that found in a DID Document, DID Controllers may sign digital assets or documents. This signature can later be verified to demonstrate the authenticity of the asset. In this way, it should be possible to refer to the asset as "signed by the DID".

3.5 Resolve

The first step in using a DID for anything other than presentation is to resolve the DID to a specific DID Document, to reveal the cryptographic material and service endpoints associated with that DID. How this occurs should be method-specific and is out of scope for the DID Working Group.

3.6 Dereference

Dereferencing a DID uses the material in its DID Document to return a resource. The expectation is that, by default, dereferencing a DID without a reference to a service endpoint will return the DID Document itself. When a DID is combined with a service parameter (forming a DID URL), dereferencing will return the resource pointed to from the named service endpoint, which was discovered by resolving the DID to its DID Document and looking up the endpoint by name. In this way, a Relying Party may dynamically discover and interact with the current service endpoints for a given DID. Services can therefore be given persistent identifiers that do not change even when the underlying service endpoints change.

3.7 Verify Signature

Given a digital asset signed by a DID, a Relying Party may use the cryptographic material in the DID Document to verify the signature.

3.8 Rotate

Controllers may rotate the cryptographic material for a DID by updating the DID Document as recorded in its registry. Different methods should be able to handle this differently, but the result would be an update to the core cryptographic proof required to prove control of the DID and the DID Document.

3.9 Modify Service Endpoint

DID Controllers should be able to change service endpoints associated with a DID, including the proof mechanism for authenticating as the Subject for any given endpoint. The process for doing this is method specific, but is designed to allow Controllers to make these changes without necessarily changing the primary proof mechanism for control of the DID itself.

3.10 Forward / Migrate

To support interoperability, some methods may provide a way for DID Controllers to record in their registry (by updating the DID Document), that the DID should be redirected to another DID, which now has full authority to represent the originating DID. This mechanism would allow DID Controllers to migrate a DID from one method or registry to another.

3.11 Recover

Some methods may provide a means for recovering control of a DID if its existing private cryptographic material is lost. These means will vary by method but can include social recovery, multi-signature, Shamir sharing, or pre-rotated keys. In general, recovery triggers a rotation to a new proof, allowing the DID Controller of that new proof to recover control of the DID without interacting with any Relying Parties.

3.12 Audit

Some methods may provide an explicit audit trail of all CRUD actions on that DID, including a timestamp for when the actions took place. For distributed ledger-based registries, this audit trail is fundamental to the way the ledgers record transactions. This would allow relying parties to see, for example, how recently a DID was rotated or its service endpoints updated, which may inform certain analytics regarding the reliability of the DID's cryptographic material.

3.13 Deactivate

Instead of deleting a DID, Controllers should be able to deactivate a DID such that downstream processes like authentication and dereferencing are no longer functional. Most decentralized systems cannot guarantee actual deletion of a record. Indeed, distributed ledgers are often touted as "immutable". Methods should define deactivation processes to achieve the same effect as deletion. The mechanisms for deactivation will vary based on the method.

4. Feature/Benefit Grid

In collecting and evaluating potential use cases, we have identified fifteen (15) key features supported by the DID specification, which provide benefits in the areas of anti-censorship, anti-exploitation, ease of use, privacy, and sustainability.

The features and their associated benefits can be seen in the following grid. A brief definition of each feature follows.

Feature Anti-censor Anti-exploitation Ease of Use Privacy Sustainability
1. Inter-jurisdictional X       X
2. Can't be administratively denied X        
3. Minimized rents   X     X
4. No vendor lock in   X     X
5. Self-issued, self-managed X X   X  
6. Streamlined rotation     X    
7. No phone home       X  
8. No surveillance capitalism   X   X X
9. Cryptographic future proof         X
10. Survives issuing organization mortality     X   X
11. Survives deployment end-of-life         X
12. Survives relationship with service provider     X   X
13. Cryptographic authentication and communication X X   X  
14. Service Discovery     X   X
15. Registry agnostic X X   X X

5. Required Features

1. Inter-jurisdictional
Inter-jurisdictional identifiers do not depend on the legal jurisdiction in which they are issued. They are valid for uses anywhere without loss of fidelity or reliability. No jurisdiction is directly able to prevent their use. (Anti-censorship and Sustainable).
2. Can't be administratively denied
These identifiers can't be denied or taken away by administrative function. This prevents shifting politics and bad actors from interfering. (Anti-censorship).
3. Minimized rents
These identifiers don't incur ongoing expenses if unused nor on a per transaction basis. Fees based on updates—which incurs network and computational costs to verify—are considered "minimal". (Anti-exploitation and Sustainable).
4. No vendor lock in
These identifiers are not dependent on any given vendor. Vendor-specific identifiers restrict usage to that which is acceptable to the vendor and may allow vendors to extract disproportionate rents for usage. (Anti-exploitation, Privacy, and Sustainable).
5. Self-issued, self-managed
These identifiers are created and managed by the subject of the identifier. They are not assigned, given, sold, or rented to the individual using them. The party relying on the identifier for identification, authentication, and authorization, does not need to manage the creation, update, and recovery of these identifiers. (Anti-censorship, Ease of use, and Privacy)
6. Streamlined rotation
When authentication materials need to be updated, these identifiers can update without direct intervention with relying parties and with minimal individual interaction. (Ease of use)
7. No phone home
When using these identifiers, there is no need to contact the issuer of the identifier to verify it. Verification and authentication can occur without further communication with the issuer. (Privacy)
8. No surveillance capitalism
These identifiers limit the effectiveness of surveillance capitalism by minimizing cross-service correlatability. Individuals may use these identifiers at multiple service providers without their activity being tracked for collusion or third party embedded surveillance techniques like cookies. (Anti-exploitation and Privacy).
9. Cryptographic future proofing
These identifiers are capable of being updated as technology evolves. Current cryptography techniques are known to be susceptible to quantum computational attacks. Future-proofed identifiers provide a means to continue using the same identifier with updated, advanced authentication and authorization technologies. (Sustainable)
10. Survives organizational mortality
These identifiers survive the demise of the organization that issued them. They usefulness of these identifiers survive organizations going out of business, being purchased (and potentially losing domain names or root credentials), and even the internal decay of an organization that no longer has the ability to verify the authenticity of records they once issued.
11. Survives deployment end-of-life
These identifiers are usable even after the systems deployed by relying parties move past their useful lifetime. They are robust against technology fads and can seamlessly work with both legacy and next-generation systems.
12. Survives relationship with service provider
These identifiers are not dependent on the tenure of the relationship with a service provider. This contrasts with identifiers like service-centric emails, e.g.,, which when used as identifiers in other systems can cause problems when individuals no longer use the service provider.
13. Cryptographic authentication and communication
These identifiers enable cryptographic techniques to authenticate individuals and to secure communications with the subject of the identifier, typically using public-private key pairs.
14. Service discovery
These identifiers allow relying parties to look up available service endpoints for interacting with the subject of the identifier. (Ease of use and Sustainable)
15. Registry agnostic
These identifiers are free to reside on any registry implementing a compatible interface. They are not beholden to any particular technology or vendor.

6. Feature Coverage

Not all use cases illustrate each feature, and not all DID methods support all features. However, we are gathering use cases to make sure all key features are clearly described. The following chart shows which features are explicitly illustrated in the Focal Use Cases.

Feature Corporate Educational
Prescriptions Digital
Sign On
1. Inter-jurisdictional X X   X  
2. Can't be administratively denied X   X X X
3. Minimized rents     X    
4. No vendor lock in X X X X  
5. Self-issued, self-managed X X X X  
6. Streamlined rotation   X   X  
7. No phone home   X X    
8. No surveillance capitalism     X    
9. Cryptographic future proof X X     X
10. Survives issuing organization mortality   X      
11. Survives deployment end-of-life   X      
12. Survives relationship with service provider X X      
13. Cryptographic authentication and communication X X X X X
14. Service Discovery          
15. Registry agnostic          

7. Focal Use Cases

7.1 Decentralized Corporate Identifiers (enterprise)

7.1.1 Background

There are many types of identifiers that corporations use today including tax identification numbers (e.g. 238-42-3893), Legal Entity Identifiers (e.g. 5493000IBP32UQZ0KL24), Data Universal Numbering System identifiers (aka. DUNS Number) (e.g. 150483782), and many more that communicate the unique identity of an organization. None of these numbers enable an organization to self-issue an identifier or to use the number to cryptographically authenticate or digitally sign agreements. A great number of business to business and business to customer transactions could be executed more quickly and with greater assurance of the validity of the transaction if a mechanism to self-issue cryptographic identifiers were created.

7.1.2 Description

A North American government would like to ensure that the supply chain that feeds electronic products into the country is secure. As a result, a new method of submitting digital documentation to Customs is enabled that requires that all documentation is provided as machine-readable digitally signed data. Digitally signed documentation is collected at each stage of the manufacturing, packaging, and shipping process. This documentation is then submitted to Customs upon the products entry into the country where all digital signatures are verified on the documentation. Some aspects of the signed documentation, such as firmware hashes and checksums, are then used by Customs and downstream customers to verify that the products have not been tampered with after leaving the manufacturing facility.

Decentralized Identifiers should ensure 1) low management overhead for the government, 2) self-management of identifiers and cryptographic key material, and 3) a competitive marketplace.

7.1.3 Challenges

The requirement of downstream customers to use the same documentation and digital signature mechanisms that were provided to Customs is potentially problematic in this scenario. Governments often create ad-hoc solutions for their import solutions, which make securing the global supply chain difficult as each government has their own method of securing the supply chain and identifying corporations that downstream customers need to integrate with. If you are a global company, that means integrating with many supply chain systems (each with different capabilities). As such, any securing of the supply chain with downstream customers must then depend on the country-specific corporate identification and PKI solution, which leads to ad-hoc solutions that drive up the cost of doing business across borders.

A supply chain identifier solution that is simple, self-administered, built on global standards, is flexible in the cryptographic mechanisms used to authenticate, and can be used by governments and downstream customers with little to no modification to the regional government or corporate systems does not exist today.

7.1.4 Distinctions

Many Decentralized Identifier use cases focus on Self-Sovereign Identity and individuals. This use case focuses on organizations and their departments as entities that would also benefit from Decentralized Identifiers.

7.2 Life-long, recipient-managed Credentials (education)

7.2.1 Background

Educational Verifiable Credentials [VC-DATA-MODEL] offer benefits over traditional educational credentials in that the recipient is able to store and share their credentials, and a third party may independently verify the credential (including authenticating the identity of the recipient), without necessarily consulting the issuer, and without dependence on centuries old treaty-based bureaucratic process for the international verification of credentials. This provides the promise of recipient-owned long-lived credentials that the recipient may use in any country, even if the issuing institution goes out of business.

However, traditional public-private key pair-based identifiers present challenges for rotating keys, especially if the identifier in a credential is simply the public key (with the private key used for authentication).

  1. With the public key embedded in the digitally signed credential, it is literally impossible to update the signing key; a recipient must contact the issuer and request re-issuing with a new identifer. If the issuer is not reachable, or is unwilling or unable to issue a new credential, the recipient cannot update the cryptographic material.
  2. If the credential relies on a centralized key registry or authority for managing rotation, then that registry becomes the centralized point of failure. This may or may not be an improvement, especially for longer held credentials.
  3. If the credential's cryptographic technology becomes outdated, there is no way to update the credential to use a more robust technology; a recipient must contact the issuer for reissuance.

The key rotation is particularly problematic for credentials expected to last a lifetime. It should be anticipated that a given individual will change their key management strategy and systems several times over the course of their life, e.g. relying on a cloud wallet, a mobile wallet, or a dedicated hardware wallet, as their needs change.

By issuing an educational credential to a recipient's DID, the recipient has the ability to prove ownership of a credential even if the cryptographic material used for authenticating changes over time.

7.2.2 Description

When Sally earned her master’s degree at Oxford, she received a digital diploma that contained a decentralized identifier she provided. Over time, she updates the cryptographic material associated with that DID to use her latest hardware wallet, with biometric protections and a quantum resistant algorithm. A decade after graduation, she applies for a job in Japan, for which she provides her digital diploma by uploading it to the prospective employee’s website. To verify she is the actual recipient of that degree, she uses the decentralized identifier to authenticate, using her current hardware wallet (with rotated keys). In addition to the fact that her name matches the name on the diploma, the cryptographic authentication provides a robust verification of her claim, allowing the employer to rely on Sally’s assertion that she earned a master’s degree from Oxford.

7.2.3 Challenges

Rotating keys without invalidating Sally's educational credentials and providing acceptable proof of education internationally.

7.2.4 Distinction

Oxford had no need to provide services for resetting or updating Sally’s username or password; they had no role in managing Sally’s changes to her authentication credentials. The potential employer did not need to contact Oxford to verify Sally’s claim of a master’s degree; they were able to verify the credential and authenticate Sally’s identity with information retrieved over the Internet.

7.3 Prescriptions (healthcare)

7.3.1 Background

Alicia wants help with her urinary tract infection (UTI) and is a bit touchy about her privacy. In the old days, she would have to make an appointment in-person and get a paper prescription to take to a pharmacy. She wants to save money and have peace of mind.

7.3.2 Description

Alicia is in a state that allows an online service to diagnose and prescribe medication. She uses the identity wallet on her smartphone to register with the online medical practice. She tells the online practice her name is Althea (a pseudonym) with password-less authentication and a verified driver's license credential to prove that she's a resident of the state. The remote physician, Barkley, is licensed by the state Board of Medicine and credentialed by the online service. He's securely signed in using the identity wallet on his smartphone. Barkley issues Alicia a digital prescription in the form of a verifiable credential and allows Alicia to download it however she pleases. Alicia is a librarian and trusts her local public library to erase their logs as allowed by law. She uses one of their computers to sign-in and do all of this. She snaps a picture of the QR code that is the prescription to take to the pharmacy. Connor, the licensed pharmacist, scans the prescription QR code and fills the prescription. Alicia pays cash.

7.3.3 Challenges

The challenge of this particular use-case is that only Barkley and Connor are verified identities and accountable for their interaction with Alicia. Alicia can be anonymous or pairwise-pseudonymous with both Barkley and Connor and everything just works. Alicia, Barkley, and Connor all keep separate and legally authentic copies of the records of their interaction in case of dispute.

7.3.4 Distinction

The Prescription use-case is a common and high-value example of privacy engineering as we shift to convenient and cost-effective online commerce among licensed and unlicensed individuals as peers. Barkley and Connor benefit by reducing or even eliminating the influence of their respective institutions or employers and therefore make more money. They pass some savings to Alicia who also gets increased peace of mind.

7.4 Digital Executor (law)

7.4.1 Background

Today, when people die, there are no standard technologies for heirs, executors, or probate courts to properly take control of an individual's online accounts and digital assets. With a DID linked to accounts and assets, a DID owner could define a trigger for a third party to assume control over the DID Document. Ideally, this trigger would specify (a) an oracle (how to know the death/incapacity occurred), (b) a means for the new owner to assert control, and (c) appropriate checks and accountability.

7.4.2 Description

Kathy uses DIDs to manage her authentications to various services. As part of her estate planning, she generates a unique credential that she gives to her attorney, Gloria, with provisions specified in her will, which initially lists Mike as the digital executor. With appropriate obfuscation, that credential is specified in multiple DID documents as a probate authority, with the authorization to change the master key in case of death, which shall be recorded publicly, on chain, as a notarized invocation of the probate authority. As it happens, Kathy had a falling out with Mike and notified Gloria just two weeks before her death that her friend Miyake should now be her digital executor. Upon Kathy's death, Gloria uses the probate credential to publicly record the assertion of probate and to replace the DID's master key with a new key, controlled by Miyake, who lives in Japan (Kathy, Gloria, and Mike live in the United States). Now, any system using Kathy's DIDs for authentication can programmatically recognized Miyake's authority and specifically know that Kathy's credentials were modified under a assertion of probate.

7.4.3 Challenges

The late date change in digital executorship from Mike to Miyake could be problematic if Kathy had directly listed Mike's credential in the DID Document. Because she instead chose to rely on her attorney, Kathy has a more flexible way to direct her wishes, while still leveraging the collective control over her authenticated logins to various services. In addition, Miyake's geographic location could make it hard for them to travel to the United States and may make it difficult to provide proof of identity traditionally used by U.S. courts. Also, because Gloria invokes the probate mechanism, Miyake need only provide a suitable credential at that time; he did not need to create and maintain a credential over a long period of time (as would be the case if Gloria weren't involved).

7.4.4 Distinction

Multiple DIDs with a common, blinded authority for probate assumption of control. The legal selection of the new owner is mediated through a trusted fiduciary (an attorney of record). Cross-border transfer of ownership.

7.5 Single Sign On (security)

7.5.1 Background

Passwords are notoriously misused ("123456"), stolen from the supposedly-secure database on the server-side, easy to forget when sufficiently secure, and never the last word in authentication for forgotten password situations. Proving control of a DID can replace storage and retrieval of a shared secret.

7.5.2 Description

Editor's note

This section in particular needs review to ensure it carries information relevant to the WG's work.

Use a DID as a single-sign-on to a Web site, for example between a Web page and a Web browser with a mobile identity app. When desirable, the relationship can add a shared secret for 2FA.

Detailed aspects of this use case are out of scope for the Decentralized Identifier Working Group but they have been explored elsewhere [DID-Auth].

7.5.3 Challenges

Transfer sign-on capability from control of a password to control of the DID.

7.5.4 Distinction

This use case describes the most common authentication action for people on the Internet.

A. References

A.1 Informative references

Introduction to DID Auth. Markus Sabadello; Kyle Den Hartog; Christian Lundkvist; Cedric Franz; Alberto Elias; Andrew Hughes; John Jordan; Dmitri Zagidulin. URL:
Decentralized Identifier Resolution (DID Resolution). Markus Sabadello; Dmitri Zagidulin. W3C Community Group Report. URL:
JSON-LD 1.0. Manu Sporny; Gregg Kellogg; Markus Lanthaler. W3C. 16 January 2014. W3C Recommendation. URL:
Information technology — Automatic identification and data capture techniques — QR Code bar code symbology specification. ISO/IEC JTC 1/SC 31 Automatic identification and data capture techniques. February 2015. ISO/IEC standard. URL:
Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter. IETF. January 2005. Internet Standard. URL:
A Universally Unique IDentifier (UUID) URN Namespace. P. Leach; M. Mealling; R. Salz. IETF. July 2005. Proposed Standard. URL:
JavaScript Object Notation (JSON) Pointer. P. Bryan, Ed.; K. Zyp; M. Nottingham, Ed.. IETF. April 2013. Proposed Standard. URL:
Verifiable Credentials Data Model 1.0. Manu Sporny; Grant Noble; Dave Longley; Daniel Burnett; Brent Zundel. W3C. 19 November 2019. W3C Recommendation. URL: