Decentralized Identifiers

Importance of identifiers in a digital world

It is increasingly important to identify persons, concepts, things…
- any reasoning, control, associations, etc., of resources rely on this ability
The digital economy relies on proper identification to combine information from different sources
- it is vital that identifiers are unique

Globally unique identifiers are all around us

They are becoming ubiquitous:
- persons
- companies, institutions,…
- books, magazines,…
- retail items
- genes, proteins, viruses,…
- stars, galaxies,…
- vehicles, airplanes,…
- intelligent home devices, Internet/Web of Things,…

Identifiers on the Web

The fundamentals of the Web Architecture are defined on three axes:

Identification: “URIs are used to identify resources.”

Interaction: “Web agents communicate using standardized protocols[…]. By entering a URI [user agents] perform a retrieval action for the resource identified by the URI.”

Formats: “Most protocols […] contain a payload of representation data and metadata, to transfer the representation between agents.”

A typical experience

Consider these two scholarly references:

Tomislav Strinić, Damir Buković, Ljubomir Pavelić, Josip Fajdić, Ivan Herman, Ivica Stipić, Ivan Palada & Ivana Hirš, “Anthropological and clinical characteristics in adolescent women with dysmenorrhea”. Collegium antropologicum, 27(2), (2003).

Ivan Herman, Markus Gylling, “Bridging the Web and Digital Publishing”, The Journal of Electronic Publishing, (2015).

Only one of the two publications is mine…
The name is not enough; you need a unique personal identification to avoid problems with, in this case, homonyms
This has become even more important in a networked, digital world

Of course, I do have identifiers

ivan@w3.org
ivan@ivan-herman.net
https://www.w3.org/People/Ivan/
https://www.ivan-herman.net/
0000-0003-0782-2704 (ORCID)
89df9321-bf5c-4237-aabc-1f8f202ab5c6 (UUID)

Identifiers are usually context dependent

Personal identifiers
- ivan@ivan-herman.net
- https://www.ivan-herman.net/
Professional identifiers
- ivan@w3.org
- https://www.w3.org/People/Ivan/
- 0000-0003-0782-2704
Undecided (depends on its usage)
- 89df9321-bf5c-4237-aabc-1f8f202ab5c6

There is a need for many identifiers!

One person may have to have many different identifiers, depending on the person’s various facets in life
- there should be a very easy way to create as many unique identifiers as needed!
Are the aforementioned identifiers really the right ones?
- note that most of them are created for another purpose (email, personal information site) and are “just” used as identifiers…

Problems with current identifiers

Ease of creation
- https://www.ivan-herman.net depends on buying a host name
- ivan@w3.org is not meant to be an identifier, and an email address is not “cheap”
Decentralized
- https://www.ivan-herman.net depends on a single point of failure; what happens if the hosting site disappears?
- 0000-0003-0782-2704 depends on the ORCID database. What happens if it is discontinued, hacked, etc?

Problems with current identifiers

Persistent
- When I leave the W3C then ivan@w3.org disappears…
- If I do not pay for the ivan-herman.net domain any more, the URL disappears…
Resolvable
- How can I get more information on what 0000-0003-0782-2704 identifies?
(Cryptographically) Verifiable
- What about https://www.ivan-herman.com? How can one prove that this domain is not referring to me?
- What happens if I stop paying for the domain and somebody else buys it?

Identifiers may fulfill several requirements

HTTPS URIS are:
- resolvable
- verifiable by a human and through HTTPS and certificates
- but: centralized, not persistent, complex to create
ORCID numbers are:
- persistent (while ORCID is around, that is), easy to create
- verifiable by a human but not cryptographically
- but: centralized, only resolvable by turning them into a special URL
UUID-s are
- persistent, decentralized, easy to create
- but: not resolvable, not verifiable

High level view: DIDs and DID Documents

“Global, distributed, key-value database”

Also known as ”Verifiable Data Registry”
There may be several of those!
- in the DID world, the term method is used for the different approaches and/or implementations
Different methods can have very different characteristics
- May be based on distributed ledgers (generic or specialized)
- DID documents stored may be on specialized sites (e.g., github)
- May be ephemeral DIDs with lighter requirements (e.g., on an intelligent device)
The choice depends on the relative importance of the various requirements for a specific usage

DID Documents

Contain reference to the “controllers”, i.e., entities that may make changes on the DID Document
Include cryptographic information related to the DID subject
- RSA, secp25519 elliptical curve keys, bitcoin elliptic curve keys, etc.
- can be expressed using JWK, or with a DID specific terms
- can be used for
  - authentication;
  - assertions (e.g., of credentials);
  - key agreement (e.g., to establish secure communication);
  - capability invocation (e.g., authorization to access an API);
  - capability delegation (e.g., delegate an API access to another authority);
  - …

DID Documents (cont.)

May contain other types of data related to the subject
- reference to alternative identities (“alsoKnownAs”)
- various service references (e.g., access to a service providing credentials)
- etc.
May or may not physically “exist” somewhere in the database
- some methods generate them on-the-fly

DIDs and DID Documents are closely coupled

DIDs have the right characteristics through the DID Document
- DID documents are the “representation data and metadata” of a DID in the Web architecture
A DID Document is tightly bound to the DID it “describes”
DID+DID Document may be also used as a decentralized cryptographic keychain for various cryptography applications

Serialization of DID Documents

DID Documents are defined via an abstract data model
Can be serialized as:
- JSON
- JSON-LD
- CBOR
- other serializations may come to the fore

There are simple ones

Securing unique, secure, etc., identities for persons, animals, objects, abstract concepts…
- unique and unambiguous literature references
- consistent semantic statements on “resources”
- identify objects in an internet of “things”
- etc.
DID usage is often bound to Verifiable Credentials
- e.g., life-long credential proving a University Degree, identified with a DID

Find information on purchased goods

shopping cart with various goods (cloths, books, shoes, camera); the camera has a DID and there is a four step process connecting that DID with a mobile: (1) get hold of the DID, (2) resolve the DID document (3) Verify the DID (4) follow a service refernece to get information

Find information on purchased goods

It is very important that:
- the identification is unique and persistent
- the information has not been tampered with
The same mechanism can be used for constituent parts of goods but the information can remain fully decentralized

Pool of relationships

Four humans connected to a Distributed Ledger of DID documents for all participants. Two figures are annotated as 'A' and 'B'; arrows connect these two with four steps (1) 'A' sems hos DID to 'B', (2) 'B' retrieves the DID document (connected to the ledger) for 'B', (3) 'B' encrypts her data using the keys of 'A', (4) 'B' sends the encrypted data to 'B'

Pool of relationships

No need for a complex and centralized key management system
- there may be different ledgers for the various participants
Both “A” and “B” may remain anonymous

Reminder: URIs, URNs, URLs, …

Ellipse labeled as 'URI' with three contained ellipses: (a) labeled as 'URL, locate through schemes' with examples https://..., ftp://..., data://...; (b) labeled as 'URN name through namespaces', with examples urn:isbn:..., urn:uuid:..., and urn:iso:... (c) labeles as 'INFO information assets through namespaces, with examples info:dewey:... and info:oclnum:...

DID is a new type of URI

The center of the figures is the string 'did:xyz:abcde1234567'. The string is surrounded by three annotations: (a) (pointing at 'did') 'Fixed string 'this is a DID'' (b) (pointing at 'xyx') 'Method name, eg, 'sov', 'bctr', 'key'', and (c) (pointing at 'abcde1234567') 'Method specific identifier'.

DID is a new type of URI

Ellipse labeled as 'URI' with four contained ellipses: (a) labeled as 'URL, locate through schemes' with examples https://..., ftp://..., data://...; (b) labeled as 'URN name through namespaces', with examples urn:isbn:..., urn:uuid:..., and urn:iso:... (c) labeled as 'INFO information assets through namespaces, with examples info:dewey:... and info:oclnum:...; (d) labeled as 'DID identify through methods with example did:sov:..., did:bcbtr:... and did:key:...'. The ellipse labeled as DID is in the centre of the containing one.

Why is it important that it is a URI?

DID are within the IETF/W3C world
- tools, libraries may be used to manage them
- existing specifications automatically apply to DIDs:
  - "<a href='did:btcr:xyv2-xzpq-q9wa-p7t'>abcd</a>" is valid HTML
  - "<did:btcr:xyv2-xzpq-q9wa-p7t> a rdf:Class." is a valid RDF Turtle statement
DIDs are part of the Web

Examples for ledger based DIDs

did:btcr:xyv2-xzpq-q9wa-p7t
- built “on top” of the Bitcoin blockchain
- the method specific identifier is generated from the bitcoin transaction position reference
did:sov:mnjkl98uipsndg2hdjdjuf7
- based on a dedicated distributed ledger (Sovrin)
- the method specific identifier generated from either a simple UUID or the subject’s public keys

Ledger based DIDs

There are other methods based on generic (e.g., Ethereum), or dedicated (e.g., Veres One) ledgers
They are generally meant to be general solutions for identity, usable by various applications

Non-ledger based DIDs

General solutions for identity storage but based on other technologies:
- github method, based on the user’s Github presence, with DID documents stored in a dedicated (per-user) repository
- methods looking into the usage of IPFS
- etc.

Examples for special purpose methods

did:key:z6Mki7KaCeTufKQ6…NEv28PhP1PHF35btNN
- can be used for single, ephemeral interactions (e.g., IoT)
- the method specific identifier is an encoded public cryptographic key
- the DID documents aren’t stored; they are generated on demand
did:git:625557b5a9cdf3…a2a716da897e2f9657
- solves the git commit contributor problems without relying on a centralized GPG keychain
- the method specific identifier is generated from the “Git Commit ID”, as well as the contributors’ public keys
- DIDs identify a git repository as well as the contributors of the repository

Examples for special purpose methods

did:peer:1zQmZMygzYqNwU6Uhmewx…LSwwgf2aiKZuwa
- interaction among a fixed number of “peers”, e.g., business relationships
- the method specific identifier is generated from the DID document
  - the document stores the user’s public key(s)
- all participants have access to the DID documents
- information in the DID documents are used to exchange encrypted messages among peers

Methods in general

Lots of experimentation is happening, exploring different methods
- there is also a need to develop proper user interfaces, applications, etc, to store DIDs in personal wallets, for example
We can expect to see a convergence of methods to only a few in the coming years

Abstract model of a DID document

Uniquely related to the DID subject, i.e., the entity identified by the DID
- the document must contain the DID itself
Includes a separate DID for the controller
- identifies an entity that “in charge” of the DID document
Expresses public cryptographic keys and other verification methods
May be extended to include application or method specific information

DID Document syntaxes

The specification defines JSON, JSON-LD, and CBOR syntaxes
The information can be converted from one syntax to the other in a lossless way
- this means that, for example, only a subset of CBOR is used

Typical DID document structure

{
    "id":"did:example:abcedefgh", 
    "controller":"did:example:xyzwvy", 
    "verificationMethod":[{ ... }], 
    "authentication":[{ ... }], 
    "assertionMethod":[{ ... }], 
    "service":[{ ... }] 
}

Digression: DID URLs

DIDs identify the DID subject
DID URLs identify a resource to be located (typically part of a DID document)
- are based on a DID
- they act as locators, although the exact details of dereferencing may depend on the methods

Remember?

DID URLs

The center of the figures is the string 'did:xyz:abcde1234567/path?query=qrst#fragment'. The string is surrounded by two annotations: (a) (pointing at part of the string until '/') 'DID' (b) (pointing at the rest) ''Path', 'query', and 'fragment' (just like a URI) with a method specific interpretation'.

Verification methods

List of various public keys
Their usage is not specified: can be used for DID verification but also for any other application

{
    "verificationMethod":[{
        "id":"did:example:12345#keys-1",
        "type":"JsonWebKey2020",
        "publicKeyJwk": {
            "kty": "OKP",
            "crv": "Ed25519",
            "x": "VCpo2LMLhn6iWku8MKvSLg2ZAoC-nlOyPVQaO3FxVeQ"
        }
    },{
        "id":"did:example:12345#keys-2",
        "type":"Ed25519VerificationKey2018",
        "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
    }]
}

Authentication

Keys that can be used for the authentication of the controller:
- can refer to a key listed separately in publicKey (via a DID URL)
- can include a full key that can be used for authentication only

{
    "authentication":[
    "did:example:12345#keys-1",
    {
        "id":"did:example:12345#keys-3",
        "type":"X25519KeyAgreementKey2019",
        "publicKeyBase58": "9hFgmPVfmBZwRvFEyniQDBkz9LmV7gDEqytWyGZLmDXE"
    }]
}

Service endpoints

Discovering any service endpoints the subject wants to advertise

{
    "service":[{
        "type":"IdentityHub",
        "verificationMethod":"did:example:12345#keys-2",
        "serviceEndpoint":"https://example.org/identityservice"
    },{
        "type":"MessagingService",
        "serviceEndpoint":"https://example.org/photos/34567"
    }]
}

Documents to read

Use cases and requirements: https://www.w3.org/TR/did-use-cases/
Core spec: https://www.w3.org/TR/did-core/
DID Specification Registries: https://www.w3.org/TR/did-spec-registries/
These slides: https://iherman.github.io/did-talks/talks/generic/

Some more documents to come

Rubric: Documenting what criteria to look for when choosing a specific method
Implementation guide

Today’s Status

Draft specification was developed in a W3C CG
Working Group started in September 2019
Plan is to be technically ready (i.e., Candidate Recommendation) in January 2021
Recommendation should be available by by the end of 2021

Decentralized Identifiers (DIDs)

Presentation held at XXX, on 2020-xx-yy

Ivan Herman, ivan@w3.org

Decentralized Identifiers
(DIDs)