1. Introduction
The need for globally unique identifier schemes has been addressed many
times. Globally unique ID schemes typically rely on a central authority
controlling a 'root' space that is then delegated to local organizations
who in turn delegate to further organizations who eventually add the final
string to complete the identifer. Even if we restrict ourseleves to online
identifiers, there are many examples of this.
- IANA controls the root namespace of the Internet's Domain Name System;
registrars operate the top level domains and then license specific domain
names to their clients, and it's these clients who create the actual
identifiers for online resources (URLs). The example below shows who
controls what in a typical URL.
IANA
↓
https:
↑ ↑
Registrar Licensee
- DOIs have the form
10.{registrant}/{suffix} where 'registrant' is defined by the
DOI organization and the suffix by the registrant.
- Global Trade Item Numbers (GTINs) seen on many of the world's barcodes
are managed in a similar way, as are Legal Entity Identifiers,
ISBNs and more.
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:
- decentralized: there should be no central issuing
agency;
- persistent: the identifier should be inherently
persistent, not requiring the continued operation of an underling organization;
- crytopgraphically verifiable: it should be possible
to prove control of the identifier cryptographically;
- 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
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.
Note: Shared terminology
This section is automatically synchronised with the terminology section in
the DID Core specification.
This section defines the terms used in this specification and throughout
decentralized identifier infrastructure. A link to these terms is
included whenever they appear in this specification.
- authentication
-
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.
- binding
-
A concrete mechanism used by a caller to invoke a DID resolver or a
DID URL dereferencer. This could be a local command line tool, a
software library, or a network call such as an HTTPS request.
- 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.
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.
- decentralized identity management
-
identity
management that is based on the use of decentralized identifiers.
Decentralized identity management extends authority for identifier generation,
registration, and assignment beyond traditional roots of trust such as
X.500 directory services,
the Domain Name System,
and most national ID systems.
- decentralized public key infrastructure (DPKI)
-
Public key infrastructure
that does not rely on traditional certificate authorities because it uses decentralized identifiers and
DID documents) to discover and verify public key descriptions.
- 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 for authentication purposes. 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 #core-representations or 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. See #methods.
- 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. See
#path.
- 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. See #query.
- 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. The inputs and outputs of this function are
defined in #resolution.
- DID resolver
-
A DID resolver is a software and/or hardware component that performs the
DID resolution function by taking a DID as input and producing a
conforming DID document as output.
- DID scheme
-
The formal syntax of a decentralized identifier. The generic DID scheme
begins with the prefix
did: as defined in the
section of the DID Core specification.
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.
- DID URL
-
A DID plus any additional syntactic component that conforms to the
definition in #did-url-syntax. This includes an optional DID
path, optional DID query (and its leading
? character),
and optional DID fragment (and 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 use 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. The inputs and outputs of this function are
defined in #did-url-dereferencing.
- 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.
- public key description
-
A data object contained inside a DID document that contains all the
metadata necessary to use a public key or verification key.
- resource
-
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.
- representation
-
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. The #core-representations
section of the DID Core specification
defines several representation formats for a DID document.
- service
-
A 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 a service operates 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 the W3C [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].
- verifiable timestamp
-
A verifiable timestamp enables a third-party to verify that a data object
existed at a specific moment in time and that it has not been modified or
corrupted since that moment in time. If the data integrity could reasonably
have modified or corrupted since that moment in time, the timestamp is not
verifiable.
- 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."
- verification relationship
-
An expression of the relationship between the DID subject and a
verification method. An example of a verification relationship is
#authentication.
- 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.
The term DID registry is under discussion within the Working Group.
A particular point to bear in mind is that not all DID methods require DIDs to be registered to be functional.
When we refer to methods and registries, we mean DID methods and DID registries. A working assumption for the use cases is that all
DIDs resolve to DID Documents. DID
Documents contain the cryptographic material to perform the functions related to
that particular DID, including
associated proof methods and any service endpoints, that is, services that can
make use of the DID.
2. Use Cases
2.1 Online shopper
Traditionally, a shopper frequents a trusted retailer and can physically hold the products they wish to purchase.
The product and the information about it is trusted because it is put there by the brand, and the shopper trusts that
the retailer has received the product through trusted supply chain partners. Today, there is a multitude of
channels and platforms for selling and buying products. The internet has changed consumer purchasing behavior
as more and more commerce is conducted digitally. This introduces new challenges for brands, retailers and consumers,
as the relationship is not as direct as the traditional mode of shopping.
Online shopping, especially through 3rd party marketplaces, creates a proliferation of digital records about that product
across platforms. Unlike a physical product, a consumer cannot be assured that the record (and the information
presented about that product) came from the brand or other authoritative source. Product identification and information
and the source of the product itself is less reliable, and introduces trust issues with representations of products
bought and sold online. Additionally, unique identification is critical to business processes, but also to online
purchasing. Very often two different products share the same identifier across the supply chain, and so what a
consumer purchases and what ultimately is received may be different.
Mechanisms are required for the following to provide trust in the digital representation of a product across platforms:
- validation of the legitimacy of an online listing — in particular on third party marketplaces;
- assurance of identification uniqueness and key identifying data element accuracy.
Contributed by GS1
2.2 Vehicle assemblies
Manufactured goods are usually the output of multiple processes carried out by multiple actors. Think of a vehicle
(be it a ship, a train, a car or a plane) with
components and assemblies of components from multiple suppliers that are then added to the emerging vehicle as it makes its
way along the production line. During the lifetime of that vehicle, components will be replaced and serviced, and this work
can be carried out by any number of different agents.
A mechanism that allows each agent to make independent assertions about their work – the components created or replaced,
the tests carried out, which part was married up to which other part and so on – would allow the complete manufacturing and
service history of the vehicle to be computed.
The independent aspect is important. A decentralized identifier created and applied to each component or assembly can be
cryptographically verified without the need to call home to a supply company that may or may not continue to exist. Moreover, there
is no requirement for the overall vehicle manufacturer to maintain an aggregated database concerning a vehicle that, in a
traditional system, is not only a single point of failure but that is immediately out of date as soon as the vehicle goes in
for its first service. A decentralized system allows each component of the vehicle to have its own history, its own credentials
and its own lifecycle, independent of other components and the vehicle – or vehicles – of which it is a part over time. At the end of its life,
the identifier may continue to be useful as a reference point for recycling and safe disposal information, even if the original
manufacturer is no longer in business.
The vehicle itself has its own identifier too. This would allow that particular vehicle to be a reference for the components
and any licensing, insurance, servicing etc. Again, the decentralized nature of DIDs promises subsequent owners control
over the identifier without dependency on any central agency allowing the maintenance record(s) to transition smoothly throughout
the entire lifecycle of the vehicle.
Contributed by Spherity
2.3 Encrypted Data Vault
Data stored in the cloud is typically visible to the cloud platform operator, even when flagged as being ‘only accessible to
you.’ For data to be stored in the cloud – in other words, on someone else’s computer – and for it to be only accessible to the data
owner, it must be encrypted. A Decentralized Identifier that leads to information with which a user can prove control of the
identifier without resort to a centralized authority could enable substitutable encrypted cloud storage. That is, the data owner
would be able to change cloud storage provider, take their encrypted data with them, and still offer fine-grained access control
to specific parties or their delegates. Associating cryptographic information with the DID would allow the data owner to change
their keys and still be able to control access without having to decrypt and re-encrypt it.
Contributed by Digital Bazaar & Transmute
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.
Contributed by Robert Bosch GmbH
2.5 Identifiers in an ecosystem of verifiable credentials (VCs)
Remembering the 4 essential characteristics of a decentralized identifier, there are situations
where DIDs offer tangible benefits over existing identifier schemes. For example:
- Verifiable credential issuers publishing the list of subject attributes that they are authoritative for (their
authoritative nature can be proven).
- In similar vein, VC issuers may publish authoritative schemas for the types of credential that they issue.
- Terms of use or other policy constraints that might apply to issued VCs.
- A published list of the public keys used to sign credentials becomes useful in a chain of trust if that list can itself
be verified.
- The controller of a decentralized identifier can rotate (update) their cryptographic keys, either to overcome their existing keys
being compromised or the development of superior technology. This does not affect the validity or proveability of any
verifiable credentials associated with that identifier.
Contributed by David Chadwick, University of Kent
2.7 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 anonimity but provide a means for others to pay the right person.
Contributed by Juan Caballero
2.8 Anonymity 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 anonymity 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.
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 Customs 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.
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 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.
Suggested by DHS SVIP
