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.

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.

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.

Concepts of Decentralized Identity

Terminology in this opening prose is being discussed, in particular the term 'relying party' which has been changed to 'requesting party' in this version of the doc.

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.

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

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.

Use Cases

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 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: , , , , , , , ,

Contributed by GS1 and Legendary Requirements

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: , , , , , , , ,

Contributed by Spherity

Encrypted Data Vault

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 USDA 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: , , , ,

Contributed by Digital Bazaar, Transmute & Legendary Requirements

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: , , , ,

Contributed by Robert Bosch GmbH

Identifiers in an ecosystem of verifiable credentials (VCs)

Dixon's employer uses DIDs and VCs to track workplace successes and recognition. Every employee has a DID registered with the company and accessible via the company registry. When he 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. 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: , , , ,

Contributed by David Chadwick, University of Kent, Legendary Requirements

Sharing opted-in information across platforms

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 her 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 her and her 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 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: , , ,

Suggested by Airgrid

Collecting payments for work conducted anonymously

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: , , ,

Contributed by Juan Caballero

Psuedonymity 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: , , , ,

Contributed by GS1

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: , , , , ,

Suggested by DHS SVIP

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 had a distinct, visible tag with "R" on one side and "Retro" on the other, she could 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, CBP can automatically review the digital manifest filed for entry and each of the delegations to verify that this given batch of products are, 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 CBP at fighting the illegal import of pirated product.

Requirements: , , , ,

Suggested by DHS SVIP

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: , , , , , , , , ,

Suggested by Eric Wagner, Markus Sabadello

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.

Features and Benefits

In collecting and evaluating potential use cases and requirements it is posisble 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.

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.

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

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.
Possible flow showing how an authentication interaction could use DIDs for autonomous authentication

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.

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.

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

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.

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

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.

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.

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.

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.'
Controllers have many options to ensure the continued usefulness of a DID

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.

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.

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.

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.

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.'
DIDs can be deactivated

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.

Features and Benefits

In collecting and evaluating potential use cases, we have identified fifteen (15) key features of DIDs that 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. Preempt/limit trackable data trails   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
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 requesting 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. Preempt/limit trackable data trails
As “cookie” 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.
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 requesting 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., joe@example.com, 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 requesting 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.

Feature Coverage

Not all use cases illustrate each feature, and not all DID methods support all features. The following chart shows which features are explicitly illustrated in the Focal Use Cases.

Feature Corporate Educational
credentials
Prescriptions Digital
Executor
Single
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. Preempt/limit trackable data trails     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

Focal Use Cases

Decentralized Corporate Identifiers (enterprise)

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.

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.

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.

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: , , , , , , , , , , , , , , , ,

Life-long, recipient-managed Credentials (education)

Contributed by Kim Hamilton-Duffy

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.

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.

Challenges

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

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: , , , , , , , , , , , , , , , , , ,

Prescriptions (healthcare)

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.

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.

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.

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: , , , , , , , ,

Digital Executor (law)

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.

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.

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

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: , , , , , , , , , , , , , , , , ,

Single Sign On (security)

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.

Description

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 two-factor authentication (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]].

Challenges

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

Distinction

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

Requirements: , , , , , ,

Alice Rents a Car (credentials)

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.

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

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.

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: , , , , ,