Use Cases and Requirements for Decentralized Identifiers

W3C Working Group Note

This version:
Latest published version:
Latest editor's draft:
Previous version:
Joe Andrieu (Invited Expert)
Phil Archer (GS1)
Kim Hamilton-Duffy
Ryan Grant
Adrian Gropper
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. cryptographically 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 Group Note.

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

Publication as a Working Group Note 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.

This document is governed by the 15 September 2020 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 identifier. Even if we restrict ourselves 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. cryptographically verifiable: it should be possible to prove control of the identifier cryptographically;
  4. resolvable: it should be possible to discover metadata about the identifier.

Further desired features and their benefits are provided in a later section.

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

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

Controllers create and control DIDs, while Requesting 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 Requesting 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 Requesting 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, Requesting 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 uses a snapshot of the terminology section of the DID Core specification, as published in the 8 November 2020 Working Draft. Any subsequent change to that terminology section is not reflected here. In the case of discrepancy, the terms provided in DID Core document are authoritative.

Authentication is a process (typically some type of protocol) by which an entity can prove it has a specific attribute or controls a specific secret using one or more verification methods. With DIDs, a common example would be proving control of the private key associated with a public key published in a DID document.
decentralized identifier (DID)
A globally unique persistent identifier that does not require a centralized registration authority because it is generated and/or registered cryptographically. The generic format of a DID is defined in the DID Core specification [DID-CORE]. A specific DID scheme is defined in a DID method specification. Many—but not all—DID methods make use of distributed ledger technology (DLT) or some other form of decentralized network.
DID controller
An entity that has the capability to make changes to a DID document. A DID may have more than one DID controller. The DID controller(s) can be denoted by the optional controller property at the top level of the DID document. Note that one DID controller may be the DID subject.
DID delegate
An entity to whom a DID controller has granted permission to use a verification method associated with a DID via a DID document. For example, a parent who controls a child's DID document might permit the child to use their personal device in order to authenticate. In this case, the child is the DID delegate. The child's personal device would contain the private cryptographic material enabling the child to authenticate using the DID. However the child may not be permitted to add other personal devices without the parent's permission.
DID document
A set of data describing the DID subject, including mechanisms, such as public keys and pseudonymous biometrics, that the DID subject or a DID delegate can use to authenticate itself and prove its association with the DID. A DID document may also contain other attributes or claims describing the DID subject. A DID document may have one or more different representations as defined in the W3C DID Specification Registries [DID-SPEC-REGISTRIES].
DID fragment
The portion of a DID URL that follows the first hash sign character (#). DID fragment syntax is identical to URI fragment syntax.
DID method
A definition of how a specific DID scheme must be implemented to work with a specific verifiable data registry. A DID method is defined by a DID method specification, which must specify the precise operations by which DIDs are created, 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 and ends with either a question mark (?) character or a fragment hash sign (#) character (or the end of the DID URL). DID path syntax is identical to URI path syntax.
DID query
The portion of a DID URL that follows and includes the first question mark character (?). DID query syntax is identical to URI query syntax.
DID resolution
The function that takes as its input a DID and a set of input metadata and returns a DID document in a conforming representation plus additional metadata. This function relies on the "Read" operation of the applicable DID method.
DID scheme
The formal syntax of a decentralized identifier. The generic DID scheme begins with the prefix did: as defined in DID Core specification [DID-CORE]. Each DID method specification must define a specific DID scheme that works with that specific DID method. In a specific DID method scheme, the DID method name must follow the first colon and terminate with the second colon, e.g., did:example:
DID subject
The entity identified by a DID and described by a DID document. A DID has exactly one DID subject. Anything can be a DID subject: person, group, organization, physical thing, digital thing, logical thing, etc.
A DID plus any additional syntactic component that conforms to the definition of the DID URL Syntax [DID-CORE]. This includes an optional DID path (with its leading / character), optional DID query (with its leading ? character), and optional DID fragment (with its leading # character).
DID URL dereferencing
The function that takes as its input a DID URL, a DID document, plus a set of dereferencing options, and returns a resource. This resource may be a DID document plus additional metadata, or it may be a secondary resource contained within the DID document, or it may be a resource entirely external to the DID document. If the function begins with a DID URL, it uses the DID resolution function to fetch a DID document indicated by the DID contained within the DID URL. The dereferencing function then can perform additional processing on the DID document to return the dereferenced resource indicated by the DID URL.
DID URL dereferencer
A software and/or hardware system that performs the DID URL dereferencing function for a given DID URL or DID document.
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.
proof purpose
A property of a DID document that communicates the purpose for which the DID controller included a specific type of proof. It acts as a safeguard to prevent the proof from being misused for a purpose other than the one it was intended for.
As defined by [RFC3986]: "...the term 'resource' is used in a general sense for whatever might be identified by a URI." Similarly, any resource may serve as a DID subject identified by a DID.
As defined for HTTP by [RFC7231]: "information that is intended to reflect a past, current, or desired state of a given resource, in a format that can be readily communicated via the protocol, and that consists of a set of representation metadata and a potentially unbounded stream of representation data." A DID document is a representation of information describing a DID subject.
Means of communicating or interacting with the DID subject or associated entities via one or more service endpoints. Examples include discovery services, agent services, social networking services, file storage services, and verifiable credential repository services.
service endpoint
A network address (such as an HTTP URL) at which services operate on behalf of a DID subject.
Uniform Resource Identifier (URI)
The standard identifier format for all resources on the World Wide Web as defined by [RFC3986]. A DID is a type of URI scheme.
verifiable credential
A standard data model and representation format for cryptographically-verifiable digital credentials as defined by[VC-DATA-MODEL].
verifiable data registry
A system that facilitates the creation, verification, updating, and/or deactivation of decentralized identifiers and DID documents. A verifiable data registry may also be used for other cryptographically-verifiable data structures such as verifiable credentials. For more information, see [VC-DATA-MODEL].
verification method

A set of parameters that can be used together with a process or protocol to independently verify a proof. For example, a public key can be used as a verification method with respect to a digital signature; in such usage, it verifies that the signer possessed the associated private key.

"Verification" and "proof" in this definition are intended to apply broadly. For example, a public key might be used during Diffie-Hellman key exchange to negotiate a shared symmetric key for encryption. This guarantees the integrity of the key agreement process. It is thus another type of verification method, even though descriptions of the process might not use the words "verification" or "proof."

Universally Unique Identifier (UUID)
A type of globally unique identifier defined by [RFC4122]. UUIDs are similar to DIDs in that they do not require a centralized registration authority. UUIDs differ from DIDs in that they are not resolvable or cryptographically-verifiable.

When we refer to methods and registries, we mean DID methods and verifiable data 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

We present use cases in two formats: short use cases in this section; and extended use cases, providing more detail, in § 6. Focal Use Cases. The diagram below provides a visual guide to different domains where Decentralized Identity is seen as important to people and links to the use cases within each domain.

Figure 1 Each use case is assigned to one of six broad domains

2.1 Online shopper

Merry has been seeking a special edition, collectible card ever since her best friend, Eli, opined about losing the one his Dad had given him as a reward for getting straight "A"s at school. She found it on an online marketplace, for sale by DeepVintage in another country, over 2000 miles away. Although the marketplace promises refunds, Merry is also worried that Eli's heart would be broken if she accidentally got him a fake.

Fortunately, DeepVintage makes use of globally-recognized identifiers for everything in its marketplace so that Merry can be sure she's searching the right collectible. Furthermore, DeepVintage is able to provide identity documentation in the form of signed statements of title transfer from each of the owners, all the way back to the original, which includes a statement of authenticity from the original manufacturer. Each of the signed statements can be independently verified because they were signed using public DIDs for the buyer and seller. The collected signatures comprise a complete chain of custody along with some interesting anecdotes about each sale. Merry was able to verify the provenance of the card and delighted Eli with a surprise gift of a perfect replacement for his lost memento.

Requirements: Authentication/proof of control, Decentralized/self issued, Inter-jurisdictional, Can't be administratively denied, No call home, Survives issuing organization mortality, Survives deployment end-of-life, Survives relationship with service provider, Human-centered interoperability

Contributed by GS1 and Legendary Requirements

2.2 Vehicle assemblies

When Bertha bought her new car, it came with its own DID, not just as an alternative VIN, but with unique DIDs for every replaceable component in the vehicle and a secure data storage for keeping track of vehicle use and maintenance. Even before she purchased it, she was able to verify that, as advertised, every part in the car is 100% made with carbon-neutral processes as certified by various independent agencies.

As the controller of the car's DID, she had automatic control over all of its components' DIDs. During maintenance, she would choose mechanics that automatically provided digital records of their work, stored at her direction in the car's data store. When a part needed to be replaced, she'd make sure the new component's DID is recorded and the old one retired. Similarly, her car automatically tracked fuel purchases and saved telemetry reports to storage, where it was kept securely under her control.

She found an insurance company that was able to automatically offer her a discount after passing a certification of good maintenance and good driving. When she later put her car up for sale, she was able to prove her track record of maintenance. Upon sale, she transferred control over the car's DID and its secure storage, giving the new owner a working, and contiguous record of the vehicle.

Requirements: Authentication/proof of control, Decentralized/self issued, Inter-jurisdictional, Can't be administratively denied, No call home, Survives issuing organization mortality, Survives deployment end-of-life, Survives relationship with service provider, Human-centered interoperability

Contributed by Spherity

2.3 Confidential Customer Engagement

Maria runs a small shopping & delivery service for several dozen shoppers. She uses a DID provided by each shopper to provide secure access to her records of purchases, which include receipts and product names for everything she's ever bought them through her service. As she shops, she scans the products as she puts them in her basket, automatically uploading her shopping progress to her secure storage. Her customers can follow along, viewing her progress and even communicating securely to answer questions about product options.

Each customer's data is encrypted just for them, and only accessible using the DID they gave to Maria. Customers are able to see the actual products purchased, with ready access to product details like nutrition facts, ingredients, and certifications. All of this information is stored in the cloud, yet encrypted at the source so that not even the cloud storage provider can see what Maria is buying for her customers and each customer only has access to information related to their own shopping list. When she changes cloud providers, Maria is able to easily and simply migrate all of the data, encrypted and without exposing any data, while the system just continues to work with the new data store.

Requirements: Authentication/proof of control, Associated cryptographic material, Streamlined key rotation, No vendor lock in, Privacy preserving Cryptographic authentication and communication,

Contributed by Digital Bazaar, Transmute & Legendary Requirements

2.4 Accessing Master Data of Entities

Decentralized identifiers allow one to discover the location of an authoritative public master data record of an entity. This mechanism can be used for organizations as well as things. The authoritative master data record could be retrieved from a designated service endpoint listed in the DID document. The record may be self-certifying, i.e. verifiable with a key listed in the DID document or third party attested represented as a verifiable presentation.

The third party attesting master data of an organization might be a chamber of commerce, while the third party attesting the master data of a thing might be its manufacturer. The decentralized nature of the identifier is important in particular for the device as the DID can act as an entry to that master data even if the manufacturer goes out of business or stops the service.

Requirements: Decentralized/self issued, Guaranteed unique identifier, Authentication/proof of control, Service endpoint discovery, Associated cryptographic material

Contributed by Robert Bosch GmbH

2.5 Transferable Skills Credentials

Dixon's employer uses DIDs and VCs to track workplace successes and recognition. Every employee has a DID registered with the company that is accessible via the company registry. When Dixon completes a training program — like CPR or Export Compliance — or receives an accolade like employee of the month, the company mints a new Verifiable Credential for him. These are not only used by HR in their evaluations for raises and bonuses, they are all made available to Dixon in a form he can use outside the firm. He maintains a career portfolio on his own server which he uses to keep track of his career.

When a devastating Earthquake nearly destroyed half of his small town, Dixon was able to present a selection of his workplace credentials to the office of the Incident Commander, establishing his expertise in disaster response. He used the proof material associated with the DID to prove that he was the recipient of those credentials. He was immediately put to work helping people recover from the disaster.

Over the years, following corporate policy, he updates his cryptographic material for his workplace DID. After these updates, all of the credentials could still be verified as having been issued to Dixon.

Requirements: Authentication/proof of control, Guaranteed unique identifier, Associated cryptographic material, Streamlined key rotation, Cryptographic future proof

Contributed by David Chadwick, University of Kent, Legendary Requirements

2.6 Cross-platform User-driven Sharing

Franklyn is frustrated by the seemingly endless surveillance that tracks his activity online. He is a single father of two girls whose privacy is absolutely vital to him. He does what he can to minimize the ways in which he might accidentally put his kids at risk, avoiding sharing details of his life, his shopping, or the inadvertent geo-located digital photo. He has minimized his digital footprint and opted out of everything but the most secure and privacy respecting sites.

However, when he can verify that a website is meeting his own standards for privacy and is willing to accept a fiduciary obligation to protect his information, he appreciates the personalized services that can be created by sharing select nuggets of information while remaining as anonymous as possible.

For each service, he creates a new unique DID and authorizes the company to use it to track him, as long as they have agreed to his specific terms of service, which covers inappropriate use of his data, whether internally or in redistributing it to other companies. With this unique identifier, the services are able to build up a history of interactions with Franklyn, without recourse to his legal identity, IP address, any credit or income data, nothing. Just the DID. By authenticating, using the DID, the service has an exceptionally strong assurance that the current session user is Franklyn. Should the store data become compromised in a data breach, all the attackers will get is a history of shopping and shopping lists associated with an arbitrary DID controlled by an unknown party.

As he becomes comfortable with a given service, he gradually shares more details, such as his pending shopping requirements. This virtual shopping list is broken into categories and different parts are shared with different retailers depending on their specialty. The stores are able to notify Franklyn of any special offers, which he is free to ignore or take advantage of.

Thanks to a promotional banner at a particular retailer's website, Franklyn learned he could get an extra discount on clothing because he is a military veteran. He gives that retailer a digital credential attesting to his status and links it to the DID they already have, securing the military discount for the rest of his relationship with them.

Both Franklyn and the merchant realize that, over time, the merchant will have an increasingly accurate profile of Franklyn's interests and this might prompt him to begin using a new DID, unlinked to the previous one. Recognizing this as a negative in some of their customers' opinions, the merchant explicitly offers Franklyn the option of revoking his current DID. Doing so would mean that access to, and use of, the information associated with the DID would be restricted to legal record-keeping mandates clearly described in the merchant's privacy policy.

Even without this explicit option, as Franklyn is the controller of the DID, he can cancel access to his data storage or simply revoke the DID entirely at any time.

Requirements: Decentralized/self issued, Privacy preserving, Preempt/limit trackable data trails, Human-centered interoperability

Suggested by Airgrid

2.7 Pseudonymous Work

Before becoming a full time journalist, Sahar worked many odd jobs and uncredited gigs in the publishing and movie industries: she was a ghostwriter, a scriptfixer, various kinds of editor, a translator, and more. Some of these gigs still pay her residuals years later in the form of tiny micropayments. When these now-classic works are reprinted or syndicated, the payments are automatically sent using information associated with Sahar's DID without anyone involved thinking much about who exactly the contract refers to as “anonymous ghostwriter X” or “translator of appendix C”. Using a DID as her identifier, rather than her name, allows Sahar to retain psuedonymity but provide a means for others to pay the right person.

Requirements: Privacy preserving, Minimized rents, Survives relationship with service provider, Human-centered interoperability

Contributed by Juan Caballero

2.8 Pseudonymity within a supply chain

Modern supply chains are highly complex, typically involving multiple companies taking ownership and/or custody of shipments from the point of origin through to the final destination, be that a retailer or end consumer. Furthermore, since most mass-produced products are made to stock rather than bespoke for a specific customer, the manufacturer typically does not know which final retailer or retail store will receive each specific product instance; the individual path through the supply chain network is not predefined by the manufacturer but instead emerges over time as a set of intermediate distributors and wholesalers distribute product in response to orders from their customers. Data concerning that supply chain can be commercially sensitive. For example, a transport company may not wish their customer to know that they sub contracted part of the journey to another partner. It can be a security risk too. The locations of warehouses and distribution centers where large stocks of particular items are held can be a target for the insertion of counterfeit goods into legitimate supplies.

A downstream party such as a retailer, pharmacy or end consumer may have a legitimate reason or in some cases a legal requirement to know that each product is genuine and can be traced back to the genuine manufacturer through an unbroken chain of custody, without any gaps or inconsistencies in the traceability data.

A downstream party may also want to check whether the product ID and serial number were actually issued by the manufacturer. However, the manufacturer may not want to provide such information about valid serial numbers to its competitors or counterfeiters, so there may be a need to control access to such services.

For these reasons and more, identifiers for business partners, locations and transactions often need to be obfuscated, and the data exchanged between partners is typically restricted both in terms of its content and in terms of access to it. This is especially true when a manufacturer does not want its competitors to know the actual source of the ingredients or components in its products. Different parties will be interested in different things too. For example, a retailer may be interested in knowing where a particular shipment is and when it is expected to arrive; a consumer of a food product is more likely to be concerned about the original source of the item and the total number of food miles in the product.

Decentralized Identifiers could be generated by sending and receiving parties at each stage in the chain. This would preserve psuedonymity yet prove control of the identified shipment at each stage and, via the DID Document, provide access to data (subject to authorization) pertaining to each transaction without enabling correlation across multiple shipments or other sensitive information.

Requirements: Authentication/proof of control, Decentralized/self issued, Service endpoint discovery, Privacy preserving Preempt/limit trackable data trails, Survives relationship with service provider

Contributed by GS1

2.9 Digital Permanent Resident Card

Sam is a long term immigrant to the United States who just received notice of Permanent Resident status from the United States Citizenship and Immigration Services (USCIS). Along with his notice is directions for downloading and using a digital version of his physical card, including a one-time activation code. After getting a digital wallet, he visits the USCIS website, signs in, and uses his activation code to get a digital credential. His wallet provides a DID to the website and demonstrates control over the DID to prove to USCIS that the identifier is under Sam's control. USCIS issues a newly minted digital credential with the subject identifier set to the provided DID.

Now, Sam can use that digital credential anywhere by demonstrating the same proof of control to provide a specific level of identity assurance, anchored in the cryptography of the proof-of-control ceremony. Verifiers of that credential can cryptographically verify both the authenticity and origin of the credential itself — it can be proven that it was issued by USCIS and unchanged since then — AND it can verify that the presenter of the credential still controls the identifier.

Requirements: Authentication/proof of control, No call home, Associated cryptographic material, Minimized rents, Legally-enabled identity, Human-centered interoperability

Suggested by DHS SVIP

2.10 Importing retro toys

Jodie is operations manager at ImportersRUs, a boutique importer specializing in small run retro products manufactured in Asia. Last year she got her big break when she licensed the right to make "Retro" Lima Bean Babies, a huge collector phenomenon in the 1990s. As long as her products have a distinct, visible tag with "R" on one side and "Retro" on the other, she can manufacture anything from the Lima Bean Babies catalog.

To handle fulfilment, Jodie works in small batches with a large number of different products and frequently changes manufacturers to stay on top of shifting materials, transportation, and tariff costs.

Jodie registers a DID with US Customs and Border Protection (US CBP) for ImportersRUs (demonstrating proof-of-control as she does) and secures a digital license from Tie Enterprises (owners of the Lima Bean Babies trademark and designs) issued to her DID and signed using a DID that Tie Enterprises has also registered with US CBP. For her manufacturers, Jodie cryptographically delegates the digital license to individual manufacturers using the DID (which is both the subject of the license and known to US CBP). Those manufacturers are responsible for getting the product to the port of Los Angeles. They, in turn, cryptographically delegate their licenses to logistics firms to actually move the product from their facility to Los Angeles, while maintaining cryptographic verifiability of both the original license, and the chain of delegations.

When her products reach the United States, US CBP can automatically review the digital manifest filed for entry and each of the delegations to verify that this given batch of products is, in fact, officially licensed Lima Bean Baby products.

This digitally verifiable provenance of her license streamlines access through US Customs, regardless of her supply chain, without reducing the effectiveness of US CBP at fighting the illegal import of pirated product.

Requirements: Authentication/proof of control, Associated cryptographic material, Delegation of control, Inter-jurisdictional, Human-centered interoperability

Suggested by DHS SVIP

2.11 Public authority identity credentials (eIDAS)

Eva is a young woman and citizen of Belgium. Like many individuals of her generation, what matters to her is not only her connection to her own nation state, but also her identity as European, as well as the beliefs in cross-border values and mobility. Eva is interested in pursuing a Bachelor's Degree at a university in Spain.

In order to facilitate the administrative processes involving authorities and organizations in multiple countries, she wishes to manage her digital identity in a way that is independent of a central authority. She installs a wallet and creates a DID within the European Self-Sovereign Identity Framework (ESSIF), which is being implemented with support from the European Commission, as part of the European Blockchain Service Infrastructure (EBSI). Eva then requests a digital credential from the Federal Government of Belgium containing claims about her legal identity (name, date of birth, etc.). This credential is compliant with the E.U.'s Electronic IDentification, Authentication and Trust Services regulation (eIDAS), which standardizes attributes and trust services in all E.U. member states.

With her ESSIF identity, Eva can apply to the Spanish university. The university in turn issues further digital credentials to Eva's wallet, such as a student record number, or — after successful completion of the program — a digital diploma. In her future life, Eva can continue to enrich and use her ESSIF identity in many ways, for example when applying for a job at a company in Finland, for registering her own business in Romania, for opening a bank account, or for applying for E.U. grants. Since her ESSIF identity includes credentials from eIDAS-compliant public authorities, it is suitable for use cases requiring the highest levels of assurance, while still providing the benefits of a decentralized identity architecture.

Requirements: Authentication/proof of control, Guaranteed unique identifier, No call home, Associated cryptographic material, Minimized rents, No vendor lock in, Cryptographic future proof, Cryptographic authentication and communication, Legally-enabled identity, Human-centered interoperability

Suggested by Eric Wagner, Markus Sabadello

2.12 Correlation-controlled Services

Cary is frustrated by the seemingly ubiquitous systems of privatized surveillance that monitor her actions in an attempt to improve their convenience. She was one the first adopters of anti-cookie features and anti-adware software and avoids "Sign-in with (some platform)". Unfortunately, this also means that she doesn't get the benefits offered by many of today's online services including the ability to cut the airport security line or shop by using her face at the neighborhood market. She just isn't willing to sacrifice her privacy by using OAuth or OpenID Connect for a convenient login: every sign-in with those technologies is visible to the "identity provider". Further, behind the scenes, every service is legally able to correlate the identifier she uses for authentication with each other, collecting information that Cary may not have divulged if asked directly. She finds it manipulative at best, and at times, outright coercive. With Decentralized Identifiers, Cary creates a pair-wise unique DID for every service provider she interacts with, and her wallet and/or agent not only manages which DID is used for which service, it also manages — if she approves it directly or though policy — automatic authentication and authorization with those services she trusts. She now has cryptographically unique identifiers that are correlatable only by those services she chooses to use them — and a single-sign-on experience with her semi-autonomous client-side self-sovereign or fiduciary delegate — without introducing a third party who knows every site she visits.

Requirements: Authentication/proof of control, Decentralized/self issued, No call home, Privacy preserving, No vendor lock in, Preempt/limit trackable data trails, Survives relationship with service provider, Human-centered interoperability

Contributed by Adrian Gropper

3. Requirements

The short use cases in the previous section, and the focal use cases towards the end of the document, point to a set of requirements that Decentralized Identifiers must fulfil. The use cases and their requirements are tabulated below, followed by a definition of each requirement.

Use case12345678910111213141516171819202122
Online shopperXXXXXXXXX
Vehicle assembliesXXXXXXXXX
Confidential Customer EngagementXXXXXX
Accessing Master Data of EntitiesXXXXX
Transferable Skills CredentialsXXXXX
Cross-platform User-driven SharingXXXX
Pseudonymous WorkXXXX
Pseudonymity within a supply chainXXXXXX
Digital Permanent Resident CardXXXXXX
Importing retro toysXXXXX
Public authority identity credentials (eIDAS)XXXXXXXXXX
Correlation-controlled ServicesXXXXXXXX
Enterprise IdentifiersXXXXXXXXXXXXXXXXX
Life-long Credentials (education)XXXXXXXXXXXXXXXXXXX
Prescriptions (healthcare)XXXXXXXXX
Digital Executor (law)XXXXXXXXXXXXXXXXXX
Alice Rents a Car (credentials)XXXXXX
Portable Secure CommunicationXXXXXXXXXXXXXXX
Use case12345678910111213141516171819202122
1. Authentication/proof of control
It is possible to prove that the entity claiming control over the identifier is indeed its controller
2. Decentralized/self issued
These identifiers are created and managed by the controller of the identifier, who may also be its subject. 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.
3. Guaranteed unique identifier
Identifiers are globally unique with no possibility of duplication, however unlikely that may be.
4. No call 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.
5. Associated cryptographic material
The identifier is tightly coupled with cryptographic material that can be used to prove control over that identifier.
6. Streamlined key rotation
When authentication materials need to be updated, these identifiers can update without direct intervention with requesting parties and with minimal individual interaction.
7. Service endpoint discovery
These identifiers allow requesting parties to look up available service endpoints for interacting with the subject of the identifier.
8. Privacy preserving
Use of the identifier does not, of itself, reveal any information about the subject
9. Delegation of control
The controller of the identifier is able to delegate that control to a third party.
10. 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.
11. 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.
12. 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".
13. 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.
14. Preempt/limit trackable data trails
As cookies and other session/state-tracking mechanisms were gradually turned into scaffolding for unwanted or collusive tracking in the evolution of the web stack, so too might any new data exchange or communication systems unwittingly facilitate unwanted tracking based on new data trails. Resistance to these kinds of surveillance exploits need to be designed into new systems.
15. Cryptographic future proof
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.
16. Survives issuing organization 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.
17. Survives deployment end-of-life
These identifiers are usable even after the systems deployed by requesting parties move past their useful lifetime. They are robust against technology fads and can seamlessly work with both legacy and next-generation systems.
18. 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.
19. 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.
20. 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.
21. Legally-enabled identity
These identifiers can be used as a basis for credentials and transactions that can be recognized as legally valid under one or more jurisdictions.
22. Human-centered interoperability
Decentralized identifiers need to be easy to use by people with no technical expertise or specialist knowledge.

4. Features and Benefits

In collecting and evaluating potential use cases and requirements it is possible to identify the key features of DIDs that provide benefits in the areas of anti-censorship, anti-exploitation, ease of use, privacy, and sustainability. The requirements and their associated benefits can be seen in the following grid.

RequirementAnti-censorAnti-exploitationEase of usePrivacySustainability
Authentication/proof of controlXX
Decentralized/self issuedXXXX
Guaranteed unique identifierXX
No call homeXXXX
Associated cryptographic materialXXX
Streamlined key rotationXXXX
Service endpoint discoveryX
Privacy preservingXXX
Delegation of controlX
Can't be administratively deniedX
Minimized rentsX
No vendor lock inXX
Preempt/limit trackable data trailsXXX
Cryptographic future proofXX
Survives issuing organization mortalityX
Survives deployment end-of-lifeXX
Survives relationship with service providerXX
Cryptographic authentication and communicationXX
Registry agnosticXXX
Legally-enabled identityXXX
Human-centered interoperabilityXX

5. DID Actions

Here are the actions envisioned in earlier work by Credentials Community Group as being necessarily supported by DIDs. Actions have been grouped by Create, Use, Read, Update, and Delete.

5.1 Create

Diagram shows Subject and Controller as separate entities (represented as outlines of people) then an arrow labelled with the word Create pointing to a box representing the DID. A second arrow, labelled Register DID, points to a box representing the registry.
Figure 2 The basic flow for creating and registering a DID

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 actions, it should be possible to create the DID without interaction with any particular authority.

5.2 Use

Complex diagram. Controller presents DID to requesting party (RP). RP resolves DID to get public proof material published by controller, signed by controller's private proof material. Requesting party sends challenge string to controller who signs with same private material and returns, thus proving control of DID and verifying the signature.
Figure 3 Possible flow showing how an authentication interaction could use DIDs for autonomous authentication

5.2.1 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.

5.2.2 Authenticate

Requesting 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.

5.2.3 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".

5.2.4 Verify Signature

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

5.3 Read

Complex diagram. Requesting party resolves DID at a DID registry. A DID document is returned. The DID is then dereferenced to get a service endpoint. There is no identity provider involved. The process can be audited by querying the registry.
Figure 4 The 'DID Document' should be understood to be information suitable for establishing secure interactions on behalf of the subject, such as public key material and service endpoints.

5.3.1 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.

5.3.2 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 Requesting 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.

5.3.3 Audit

Some methods may provide an explicit audit trail of all 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 Requesting 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.

5.4 Update

Diagram shows controller on the left with an arraow labeled 'Modify' leading to three boxes labeled 'Service endpoints', 'Forward/Migrate' and 'Recovery material'. A separate arrow labeled 'Rotate or revoke' points to 'Public proof material.'
Figure 5 Controllers have many options to ensure the continued usefulness of a DID

5.4.1 Rotate

Controllers may rotate (that is, update) 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.

5.4.2 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 DID Controllers to make these changes without necessarily changing the primary proof mechanism for control of the DID itself.

5.4.3 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.

5.4.4 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 Requesting Parties.

5.5 Delete

Diagram shows an arrow from the controller to the registry, labeled 'Deactivate DID'. On the roght hand side, the Requesting patry is connected to the Registry by an arrow labeled 'Resolve DID'. The return arrow, colored red, is labeled 'Inactive.'
Figure 6 DIDs can be deactivated

5.5.1 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 and therefore the 'inactive' message(s) will vary.

6. Focal Use Cases

6.1 Enterprise Identifiers

6.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 (a.k.a. DUNS Number, e.g. 150483782), Global Location Number (e.g. 9501101020016), 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. Business to business and business to customer transactions might be conducted with more efficiency and with greater assurance of the validity of the transaction if a mechanism to self-issue cryptographic identifiers were created.

6.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 with proof of provenance from supply chain partners whose identities are themselves known to a high degree of certainty. Digitally signed documentation is collected at each stage of the manufacturing, packaging, and shipping process. This documentation is then submitted to Customs upon the product's 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.

6.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.

6.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.

Requirements: Authentication/proof of control, Decentralized/self issued, Guaranteed unique identifier, No call home, Associated cryptographic material, Streamlined key rotation, Service endpoint discovery, Delegation of control, Inter-jurisdictional, Can't be administratively denied, No vendor lock in, Cryptographic future proof, Survives issuing organization mortality, Survives deployment end-of-life, Survives relationship with service provider, Cryptographic authentication and communication, Registry agnostic

6.2 Life-long Credentials (education)

Contributed by Kim Hamilton-Duffy

6.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 identifier. 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.

6.2.2 Description

When Sally earned her master’s degree at the University of Oxford, she received a digital diploma that contained a decentralized identifier she provided. This digital diploma is signed using a decentralized identifier which has been published and verified by the University of Oxford. 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 the stated university without having to contact the university directly.

6.2.3 Challenges

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

6.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.

Requirements: Authentication/proof of control, Decentralized/self issued, Guaranteed unique identifier, No call home, Associated cryptographic material, Streamlined key rotation, Service endpoint discovery, Inter-jurisdictional, Can't be administratively denied, Minimized rents, No vendor lock in, Preempt/limit trackable data trails, Cryptographic future proof, Survives issuing organization mortality, Survives deployment end-of-life, Survives relationship with service provider, Cryptographic authentication and communication, Registry agnostic, Human-centered interoperability

6.3 Prescriptions (healthcare)

6.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.

6.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.

6.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.

6.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.

Requirements: Authentication/proof of control, Decentralized/self issued, Guaranteed unique identifier, Associated cryptographic material, Service endpoint discovery, Privacy preserving, Preempt/limit trackable data trails, Cryptographic authentication and communication, Human-centered interoperability

6.4 Digital Executor (law)

6.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.

6.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.

6.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).

6.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.

Requirements: Authentication/proof of control, Decentralized/self issued, Guaranteed unique identifier, Associated cryptographic material, Streamlined key rotation, Service endpoint discovery, Privacy preserving, Delegation of control, Inter-jurisdictional, Can't be administratively denied, Minimized rents, No vendor lock in, Cryptographic future proof, Survives deployment end-of-life, Survives relationship with service provider, Cryptographic authentication and communication, Legally-enabled identity, Human-centered interoperability

6.5 Alice Rents a Car (credentials)

Contributed by Adrian Gropper

6.5.1 Background

It’s 2021 and SSI is the golden child. Alice looks forward to never having to use a password or fill out a form again. Alice’s service providers are looking to adopt zero-trust architecture with Y2K zeal. Neither of them really know what SSI or zero-trust means, but they want it.

6.5.2 Description

Alice has just provisioned an “agent” as recommended by an organization she trusts and supported by her browser vendor. It’s costing her $5/month and is somehow linked to the facial recognition that also unlocks her smartphone. Her agent occasionally sends a text message asking a question with a yes or no answer but otherwise mostly leaves her alone. Her agent bears a “Magic Button” logo that she thinks is a bit like “credit cards welcome here” in the old days.

Alice is going to France. She uses a non-tracking search engine to discover a list of car rental companies anonymously to avoid price discrimination and targeted ads. Some of the rental companies display the "Magic Button" logo, some don’t. She knows that the ones that do will respect her agent. She picks a company for the rental even though she has never done business with them before, knowing that with "Magic Button" her user experience will be an automated breeze.

Among dozens of others, Alice already has "Magic Button" service providers for her US driver’s license, her US insurance, and her bank. The DMV, insurer, and bank all authenticate Alice using a secure pseudonym linked to her smartphone. Each of the three has a different DID for Alice, but each of the three knows that they can use that DID in court to hold Alice accountable. Alice just knows that her smartphone allowed her to sign her driver’s license application, her insurance application, and her bank customer registration form using facial recognition because "Magic Button" works.

Alice clicks on the “Rent Now” button and:

  • Exposes a DID through her agent in order to set up a secure communication channel.
  • The car rental company tells Alice’s agent that they will need license, insurance, and bank info for the purpose of renting a car in France.
  • Alice’s agent has a policy that saying that any company as large as her chosen car rental company can get whatever they explicitly ask for. Smaller companies, or large ones on a blacklist may need Alice to give explicit permission — which the agent will ask for using a text message.
  • Alice’s agent offers three signed bearer tokens authorizing release of her personal information from three specific service providers. These tokens are encrypted so that the rental company doesn’t know what’s in them. Alice’s service providers use pre-registered information linked to their DID for Alice to decrypt the tokens and verify they were signed by Alice’s agent.
  • Note, that in this example, Alice does not care that her three service providers know she is becoming a rental customer. If Alice did care, she might go through the trouble of having one or another of the services issue a Verified Credential to her so she can present it wherever she wants. Alice’s agent has policies that force the more privacy preserving, Holder-mediated flow when dealing with some less trusted vendors.
  • The rental company gathers the information from Alice’s service providers, checks it against their internal rental policies, and issues Alice’s agent a signed capability linked to a QR code. The agent emails the capability to Alice.

The whole sequence from click in the search results to Alice getting a QR code in the email took 8 seconds. A week later:

  • Alice goes to the rental garage at Charles de Gaulle airport, and picks a car with the keys already in it and the price posted on the parking space. She drives to the automated exit gate.
  • At the gate, Alice opens her email, shows the QR code she received through her agent and gets a message on her phone asking her to scan her face. The gate agent combines the license info of the car, the QR code and the challenge signed by Alice with her face and opens the gate.

6.5.3 Challenges

The challenge in this case is to combine technical standards and protocols into a human-meaningful interoperability claim that crosses between one's general-purpose agent and a multitude of domain-specific service offerings.

6.5.4 Distinction

This use case is based on a profiling exercise by a group to be determined and the voluntary adoption of the badge by some agents and some service providers. The badge need not be associated with a costly certification process which means that both audited and un-audited versions of the claim can co-exist. False and misleading assertions are already enforced by both the marketplace and by truth in labeling laws.

Requirements: Streamlined key rotation, Service endpoint discovery, Inter-jurisdictional, No vendor lock in, Survives relationship with service provider, Human-centered interoperability

6.6 Portable Secure Communication

Contributed by Nader Helmy, Daniel Hardman, Ted Thibodeau Jr

6.6.1 Background

Designing systems that securely support the scale of global communication on the Web has traditionally come with a distinct set of tradeoffs that often negatively impact end-users. Current PKI systems tightly control who gets to manage and control the cryptographic keys associated with the set of digital certificates that serve as the backbone of the internet. This constraint means that modern cryptography is largely unusable for the average user, forcing them to borrow or "rent" identifiers such as email addresses, usernames, and website domains, through systems like DNS, X.509, and social networks. By not directly controlling their own identifiers, people who want to use secure communication are not only unable to utilize cryptographic security in many of their everyday interactions, they are also limited to choosing between traditional secure messaging services to safely communicate with friends and family in a limited, chat-style context.

In a traditional secure messaging approach, the security is a property of the platform; if a user changes platforms, either temporarily or permanently, they get their security a different way, tied to a different login and different terms of service. DIDs take security out of the hands of the context owner, i.e., an application or service provider, and put it in the hands of the DID controller, who can choose the contexts in which they want to communicate and when. This makes security decentralized and portable, instead of having the security of an interaction tied to the protocol, transport, or application used to facilitate it. This feature allows people to easily switch communication contexts without losing any security guarantees, and provides a resilient backbone for all internet communications. Moving away from traditional identifiers, such as phone numbers and email addresses, can help to break down the siloed ecosystems that prevent data portability and make it difficult to more broadly incorporate secure communication technology in applications and services. Current approaches to secure communication often have drawbacks such as the following:

  • reliance on commonly used identifiers which are not directly under user control
  • use of a central intermediary or centralized components to facilitate interactions
  • requirement that one or more parties have a highly available web server
  • siloed and non-interoperable security architectures tied to a single domain

DIDs help to solve this issue by enabling a style of communication which is truly peer-to-peer and message-based. Message-based systems decouple the relationship between producers of messages and consumers of messages, creating an abstraction that puts the two on equal footing and allows for many different kinds of devices with differing requirements to interface in a flexible and technology-neutral way. DIDs allow people to simultaneously use the same identifier for both traditional communications and newer transactions that require a higher level of cryptographic security, as well as allowing them to switch contexts without losing any security guarantees. These decentralized identifiers are not rented or borrowed from centralized providers but are instead directly under user control.

6.6.2 Description

Samira is a humanitarian aid worker in Khartoum who wants to create connections with new people she meets. She has a smartphone but doesn’t always have Internet access in the remote areas that she visits in her line of work. Since she can’t always use the Internet, most of her preferred methods of communication are not always available. When she’s offline and meets a new person she wishes to communicate with, she establishes a direct secure connection between her device and theirs by having them scan a QR code to pass on her DID and start sharing peer-to-peer messages secured by the keys on her device. When online, Samira’s DID can be resolved to its DID document that contains her public key material. In this way, she can maintain these secure connections whether she has access to the Internet or not. Whenever Samira is working on a new campaign or wants to raise awareness about issues affecting her local region, she is able to securely communicate with all relevant parties, regardless of the device, platform, or network infrastructure they are using.

At one point, Samira sees a friend of hers, Ahmed, who’s part of a local organization campaigning against unfair labor practices in local agriculture. Samira wants to support the efforts of this group and get involved, but she worries that publicly allying with the farm workers will negatively affect her ability to act as a neutral party in labor negotiations. By creating a unique DID for herself in the group at very little cost, she can engage in online multi-party secure communication with all of the members of Ahmed’s organization. Messages are secured via mutual authentication between Samira and each of the other members. Using these connections, and using either direct peer to peer connections or online services that both Samira and Ahmed trust not to have any ‘backdoors’, they are able to have private and confidential communications with the other members at any time, without fear of censorship. Members of the organization are able to have confidence that they’re talking to Samira, and she can verify who she is communicating with. Samira can use the same identifier and connection with the group to share credentials that prove she’s a humanitarian worker and attest to her history.

Eventually, Samira loses her phone. To make sure no one impersonates her, she revokes the keys on all of the DIDs she is using for communication. Rather than losing access to all of her existing connections, Samira is able to update her online service endpoints and routing capabilities to make sure she continues to receive messages securely on the devices she still owns. When she gets a new phone, she can add new keys to her DID Document to continue exchanging secure messages online with her connections without interruption. Keys shared through direct, offline connections need to be updated individually by Samira to ensure continued communication. Should Samira want to change the DIDs she’s using (for instance, because she’s changing DID method providers), she can send a message to her connections notifying them that she’s deprecating her old DID and providing her new DID with authentic digital signatures. Again, for entirely offline connections, this must be done one by one but it means that Samira is able to manage all of her secure communications across her devices, platforms, and applications in a consistent way, thanks to the security features provided by DIDs.

6.6.3 Challenges

Samira's use of a DID-based communication system comes with a number of user experience challenges. These include the management of her different communication contexts and switching between them, as well as the automation of connection management with things like key rotation, updating service endpoints, and routing via Agents. Users should not be exposed to the details of such coordination, but should be able to interact with, modify, and audit the process as needed. It’s likely that users will be interacting with secure messaging protocols via a number of different interfaces & devices and for a variety of different purposes, though the logic and experience should be coherent and consistent across different platforms.

6.6.4 Distinction

Many DID use cases describe the need for authenticated communication and cryptographic security. This use case focuses on today's reliance on phone numbers or email addresses as primary identifiers for messaging services, and illustrates how DIDs can be the backbone of a resilient message-based architecture for the internet which is asynchronous, not mediated by third parties, and empowering of everyday use of cryptographic identifiers for both basic messaging and higher-level communications.

Requirements: Associated cryptographic material, Streamlined key rotation, Service endpoint discovery, Privacy preserving, Delegation of control, Authentication/proof of control, Decentralized/self issued, Guaranteed unique identifier, Inter-jurisdictional, No vendor lock in, Preempt/limit trackable data trails, Cryptographic future proof, Survives relationship with service provider, Cryptographic authentication and communication, Human-centered interoperability

A. References

A.1 Informative references

Decentralized Identifiers (DIDs) v1.0. Drummond Reed; Manu Sporny; Markus Sabadello; Dave Longley; Christopher Allen. W3C. 9 March 2021. W3C Working Draft. URL:
DID Specification Registries. Orie Steele; Manu Sporny. W3C. 11 March 2021. W3C Note. 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:
Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. 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: