Use Cases and Requirements for Decentralized Identifiers

Use Cases and Requirements for Decentralized Identifiers
Use Cases and Requirements for Decentralized Identifiers
W3C Working Group Note
17 March 2021
This version:
Latest published version:
Latest editor's draft:
Previous version:
Editors:
Joe Andrieu
(Invited Expert)
Phil Archer
GS1
Authors:
Kim Hamilton-Duffy
Ryan Grant
Adrian Gropper
Participate:
GitHub w3c/did-use-cases
File a bug
Commit history
Pull requests
2021
W3C
MIT
ERCIM
Keio
Beihang
).
W3C
liability
trademark
and
permissive document license
rules
apply.
Abstract
This document sets out use cases and requirements for a new type of identifier that has 4 essential characteristics:
decentralized
: there should be no central issuing
agency;
persistent
: the identifier should be inherently
persistent, not requiring the continued operation of an underling organization;
cryptographically verifiable
: it should be possible
to prove control of the identifier cryptographically;
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
public-did-wg@w3.org
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.
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.
Example
IANA
https
//example.com/page.html
↑ ↑
Registrar Licensee
DOI
s 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,
ISBN
s 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 (
UUID
s) [
RFC4122
fulfill this role, however, there is no way to
prove
control of
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;
cryptographically 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
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
DID
s 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
DID
s,
while Requesting Parties rely on
DID
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
DID
s and, in turn, Requesting
Parties use to apply
DID
s.
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
DID
s 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.
authenticate
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
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
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.
DID
URL
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)
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.
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
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
services
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
DID
s 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
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
DID
s and
VC
s 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.
Requirements
Use case
10
11
12
13
14
15
16
17
18
19
20
21
22
Online shopper
Vehicle assemblies
Confidential Customer Engagement
Accessing Master Data of Entities
Transferable Skills Credentials
Cross-platform User-driven Sharing
Pseudonymous Work
Pseudonymity within a supply chain
Digital Permanent Resident Card
Importing retro toys
Public authority identity credentials (
eIDAS
Correlation-controlled Services
Enterprise Identifiers
Life-long Credentials (education)
Prescriptions (healthcare)
Digital Executor (law)
Alice Rents a Car (credentials)
Portable Secure Communication
Use case
10
11
12
13
14
15
16
17
18
19
20
21
22
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. joe@example.com, 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.
Feature
Requirement
Anti-censor
Anti-exploitation
Ease of use
Sustainability
Authentication/proof of control
Decentralized/self issued
Guaranteed unique identifier
No call home
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
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
Legally-enabled identity
Human-centered interoperability
5.
DID
Actions
Here are the actions envisioned in earlier work by
Credentials Community Group
as being necessarily supported by
DID
s. Actions have been grouped by Create, Use,
Read, Update, and Delete.
5.1
Create
Figure
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
Figure
Possible flow showing how an authentication interaction could use DIDs for autonomous authentication
5.2.1
Present
DIDs are
URI
s, 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
Controller
s 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
Figure
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
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
Figure
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
Figure
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).
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.
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.
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
[DID-CORE]
Decentralized Identifiers (DIDs) v1.0
. Drummond Reed; Manu Sporny; Markus Sabadello; Dave Longley; Christopher Allen. W3C. 9 March 2021. W3C Working Draft. URL:
[DID-SPEC-REGISTRIES]
DID Specification Registries
. Orie Steele; Manu Sporny. W3C. 11 March 2021. W3C Note. URL:
[QR]
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:
[RFC3986]
Uniform Resource Identifier (URI): Generic Syntax
. T. Berners-Lee; R. Fielding; L. Masinter. IETF. January 2005. Internet Standard. URL:
[RFC4122]
A Universally Unique IDentifier (UUID) URN Namespace
. P. Leach; M. Mealling; R. Salz. IETF. July 2005. Proposed Standard. URL:
[RFC7231]
Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL:
[VC-DATA-MODEL]
Verifiable Credentials Data Model 1.0
. Manu Sporny; Grant Noble; Dave Longley; Daniel Burnett; Brent Zundel. W3C. 19 November 2019. W3C Recommendation. URL:
Permalink
Referenced in:
1.2 Concepts of Decentralized Identity
(2)
(3)
Permalink
Referenced in:
1.2 Concepts of Decentralized Identity
(2)
(3)
(4)
(5)
(6)
(7)
(8)
(9)
(10)
(11)
(12)
(13)
(14)
(15)
Permalink
Referenced in:
1.2 Concepts of Decentralized Identity
(2)
(3)
(4)
(5)
(6)
5.2.2 Authenticate
5.2.3 Sign
5.4.2 Modify Service Endpoint
(2)
5.4.3 Forward / Migrate
(2)
5.4.4 Recover
Permalink
Referenced in:
1.2 Concepts of Decentralized Identity
(2)
Permalink
Referenced in:
1.2 Concepts of Decentralized Identity
(2)
(3)
(4)
(5)
(6)
(7)
(8)
(9)
(10)
(11)
(12)
(13)
(14)
(15)
(16)
(17)
(18)
5.2.3 Sign
5.3.1 Resolve
5.3.2 Dereference
Permalink
Referenced in:
1.2 Concepts of Decentralized Identity
Permalink
Referenced in:
1.2 Concepts of Decentralized Identity
(2)
(3)
(4)
(5)
Permalink
Referenced in:
1.2 Concepts of Decentralized Identity
Permalink
Referenced in:
1.2 Concepts of Decentralized Identity
Permalink
Referenced in:
1.2 Concepts of Decentralized Identity
Permalink
Referenced in:
1.2 Concepts of Decentralized Identity
(2)
Permalink
Referenced in:
1.2 Concepts of Decentralized Identity
(2)
(3)
(4)
(5)
(6)
(7)
(8)
(9)
Permalink
Referenced in:
1.2 Concepts of Decentralized Identity
(2)
(3)
(4)
(5)
(6)
(7)
(8)
5.3.2 Dereference
Permalink
Referenced in:
1.2 Concepts of Decentralized Identity
Permalink
Referenced in:
Not referenced in this document.
Permalink
Referenced in:
1.2 Concepts of Decentralized Identity
(2)
Permalink
Referenced in:
Not referenced in this document.
Permalink
Referenced in:
1.2 Concepts of Decentralized Identity
Permalink
Referenced in:
1.2 Concepts of Decentralized Identity
(2)
Permalink
Referenced in:
1.2 Concepts of Decentralized Identity
Permalink
Referenced in:
1.2 Concepts of Decentralized Identity
Permalink
Referenced in:
5.2.1 Present
Permalink
Referenced in:
1.2 Concepts of Decentralized Identity
Permalink
Referenced in:
1.2 Concepts of Decentralized Identity
(2)
Permalink
Referenced in:
1.2 Concepts of Decentralized Identity
(2)
Permalink
Referenced in:
1. Introduction