Decentralized Identifiers (DIDs)
A DID is a self-sovereign identity - a lifetime, portable, and verifiable digital identity, that does not depend on any centralized authority.
URIs, URLs, and URNs

- URLs - locate resources
- URIs - identify people, concepts, things, etc.
- URNs - persistent names that do not change, no matter their location

A DID is functionally a URN, that in many cases can be resolved to one or more URLs.
Why is it important for DIDs to be URIs?
Supported natively within the IETF/W3C ecosystems
- tools, libraries support already available
- existing specifications already apply to DIDs:
- <a href="did:example:123">John</a> is valid HTML
Problems with current identifiers
- andrei.sambra@qredo.com
- https://deiu.me
- https://github.com/deiu
- @andreisambra
- @deiu:matrix.org
- +33 6 85 42 ...
Are they easy to create?
> the ones under my "control" typically involve buying a domain name
Are they decentralized?
> architecturally but also from a governance standpoint
Are they portable/persistent?
> what if I leave Qredo, can I still use that email address?
Are they (cryptographically) verifiable?
Core properties of DIDs
Ease of creation.
> should be "cheap" to create lots of DIDs
A persistent identifier.
> once created, it is permanently assigned to the subject
A resolvable identifier.
> can be looked up to discover metadata
A cryptographically-verifiable identifier.
> owner can prove control using cryptography
A decentralized identifier.
> no centralized registration authority is involved
DIDs, DID documents, DID subjects

DID is an identifier assigned by a DID controller to refer to a DID subject and resolve to a DID document that describes the DID subject. The DID document is an artifact of DID resolution and not a separate resource distinct from the DID subject.
DIDs, DID documents, DID subjects

DID documents
- Contain one or more public keys that can be used to authenticated the DID subject during an interaction.
- One or more services associated with the DID subject that can be used for different types of interactions.
- Additional metadata, such as timestamps, digital signatures, or cryptographic proofs, or metadata related to delegation or authorization.
- Serialized to JSON, JSON-LD, CBOR, and others to come soon.
Example of a DID document (JSON-LD)
{
"@context": [
"https://www.w3.org/ns/did/v1",
"https://w3id.org/security/suites/ed25519-2020/v1"
],
"id": "did:example:12345",
"controller: "did:example:12345",
"authentication": [{
"id": "did:example:12345#z6MkecaLyHuYWkayBDLw5ihndj3T1m6zKTGqau3A51G7RBf3",
"type": "Ed25519VerificationKey2020",
"controller": "did:example:123",
"publicKeyMultibase": "zAKJP3f7BD6W4iWEQ9jwndVTCBq8ua2Utt8EEjJ6Vxsf"
}],
"service": [{
"id": "did:example:12345#vcs",
"type": "VerifiableCredentialService",
"serviceEndpoint": "https://example.com/vcs"
}]
}
DID methods

The DID methods support the same basic functionally (creation, update, etc.), but they differ in how that functionality is implemented.

Over 100 methods already proposed!
Ledger based methods
- did:btcr:xyv2-xzpq-q9wa-p7t
- built "on top" of the Bitcoin blockchain
- the method specific identifier is generated from the blockchain tr position
- did:eth:0xF3beAC30C498D9E26865F34fCAa57dBB935b0D74
- built "on top" of the Ethereum blockchain
- the method specific identifier is generated from the corresponding Ethereum address
- did:sov:mnjka2gh493qbgyqlkjs1op
- based on a dedicated ledger (Sovrin)
- the method specific identifier is generated from either an UUID or a public key
Non-ledger based methods
- did:web:example.com
- built "on top" of the Web
- the method specific identifier is generated from Web URIs
- did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH
- does not require a DID document (generated on the fly)
- the method specific identifier is generated from an encoded public key
- did:peer:1z6MkpTHR8VNsBxYAA...jSwuBV8xRoAnwWsdvktH
- based on (private) relationships between peers
- the method specific identifier is generated from the identifiers of the parties involved (i.e. A <> B)
DID verification
"verificationMethod": [
{
"id": "did:example:123#key-0",
"type": "JsonWebKey2020",
"controller": "did:example:123",
"publicKeyJwk": {
"kty": "OKP",
"crv": "Ed25519",
"x": "VCpo2LMLhn6iWku8MKvSLg2ZAoC-nlOyPVQaO3FxVeQ"
}
},
{
"id": "did:example:123#key-1",
"type": "Ed25519VerificationKey2018",
"controller": "did:example:123",
"publicKeyBase58": "3M5RCDjPTWPkKSN3sxUmmMqHbmRPegYP1tjcKyrDbt9J"
}
]
Can list various public keys, without having to specify their usage (authentication, etc.).
DID verification is an enabled for Verifiable Credentials.
DIDs & Verifiable Credentials

* graphics from Mattr
Verifiable Credential
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://w3id.org/citizenship/v1"
],
"type": [
"VerifiableCredential"
],
"credentialSubject": {
"id": "did:example:123",
"type": [
"Person"
],
"birthDate": "1988-02-17",
"photo": "data:image/png;base64,iVBORw0KGgoAAA....."
},
"issuer": "did:example:456",
"issuanceDate": "2020-04-22T10:37:22Z",
"identifier": "83627465",
"name": "Proof of legal age",
"description": "Government of Example Country",
"proof": {
"type": "Ed25519Signature2018",
"created": "2020-04-22T10:37:22Z",
"proofPurpose": "assertionMethod",
"verificationMethod": "did:example:456#key-1",
"jws": "eyJjcml0IjpbImI2NCJdLCJiNjQiOmZhbHNlLCJhbGciOiJFZERTQSJ9..BhWew0x-txcroGjgdtK-yBCqoetg9DD9SgV4245TmXJi-PmqFzux6Cwaph0r-mbqzlE17yLebjfqbRT275U1AA"
}
}
Verifiable Credential

Verifiable Credential - privacy through ZKPs
- Privacy-preserving VCs with the help of BBS+ LD-Proofs.
- BBS+ LD-Proofs reduce dependency on a ledger by discarding the credential definition. The only call to a ledger is to retrieve the issuer’s DID document.
- Benefits of BBS+ LD-Proofs:
- selective disclosure (n of m properties)
- non-linkability of VC signatures and credential holders
- BBS+ Signatures spec currently in progress at W3C.
Almost “production-level,” as the library has yet to do a v1.0 release. Currently developed by Hyperledger (Ursa) and MATTR.
BBS+ LD-Proof Example (initial VC)
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://w3id.org/citizenship/v1",
"https://w3id.org/security/bbs/v1"
],
"id": "https://issuer.oidp.uscis.gov/credentials/83627465",
"type": ["VerifiableCredential", "PermanentResidentCard"],
"issuer": "did:example:489398593",
"identifier": "83627465",
"name": "Permanent Resident Card",
"description": "Government of Example Permanent Resident Card.",
"issuanceDate": "2019-12-03T12:19:52Z",
"expirationDate": "2029-12-03T12:19:52Z",
"credentialSubject": {
"id": "did:example:b34ca6cd37bbf23",
"type": ["PermanentResident", "Person"],
"givenName": "JOHN",
"familyName": "SMITH",
"gender": "Male",
"image": "data:image/png;base64,iVBORw0KGgokJggg==",
"residentSince": "2015-01-01",
"commuterClassification": "C1",
"birthCountry": "Bahamas",
"birthDate": "1958-07-17"
},
"proof": {
"type": "BbsBlsSignature2020",
"created": "2020-04-26T04:21:07Z",
"verificationMethod": "did:example:489398593#test",
"proofPurpose": "assertionMethod",
"proofValue": "jx2VhjyZqUT91e2Oh...xmu5YwqOxPMRsWH3H+2wSA=="
}
}
BBS+ LD-Proof Example (reveal document)
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://w3id.org/citizenship/v1",
"https://w3id.org/security/bbs/v1"
],
"type": ["VerifiableCredential", "PermanentResidentCard"],
"credentialSubject": {
"type": ["PermanentResident", "Person"],
"@explicit": true,
"givenName": {},
"familyName": {},
"gender": {}
}
}
Whereby a zero knowledge proof disclosing only givenName, familyName and gender can be derived from the initial VC using the following as the reveal document (using a JSON-LD frame).
BBS+ LD-Proof Example (ZKP)
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://w3id.org/citizenship/v1",
"https://w3id.org/security/bbs/v1"
],
"id": "https://issuer.oidp.uscis.gov/credentials/83627465",
"type": ["PermanentResidentCard", "VerifiableCredential"],
"description": "Government of Example Permanent Resident Card.",
"identifier": "83627465",
"name": "Permanent Resident Card",
"credentialSubject": {
"id": "did:example:b34ca6cd37bbf23",
"type": ["Person", "PermanentResident"],
"givenName": "JOHN",
"familyName": "SMITH",
"gender": "Male"
},
"expirationDate": "2029-12-03T12:19:52Z",
"issuanceDate": "2019-12-03T12:19:52Z",
"issuer": "did:example:489398593",
"proof": {
"type": "BbsBlsSignatureProof2020",
"created": "2020-05-25T23:07:10Z",
"verificationMethod": "did:example:489398593#test",
"proofPurpose": "assertionMethod",
"proofValue": "ABgA/4N3qygQRJlX3gmQOlJRGbO1KTXKQUmaN02xl+FiNZUDmGfa5OoKtg0RJ4wxxA08t3Vut61G/pq4yN0byg...msTtQPYJS084355GRBur5jnzPNJ2W6Gu3ZqqQeRrVyw1gzdhVDNOE8KUm9OQ3AvCuxo8PHNrqzNvc6VA==",
"nonce": "37pdwue1a8FWLqgwCd0QJ0IJTFhp609KtxeCTWZGnfAVE+sOBDffYez+TY/bmVy+6z4="
}
}
Things to consider
- Adoption rate (the specification is in the final steps of becoming a W3C Recommendation -- i.e. a W3C standard)
- Interoperability (i.e. the "decentralized" angle)
- The DID spec does not cover protocols, only the data model. What happens when DID document data needs to be updated (for a blockchain implementation)?
- Google, Apple, and Mozilla* lodged formal objections to W3C approval of the DID 1.0 specification:
- Lack of proven interoperability
- Encourages divergence rather than convergence
- Centralized methods allowed
- Proof-of-work methods are harmful for sustainability
*92% of Mozilla’s 2019 income came from its 2017 Google ad deal.
Are DIDs a good fit for us?
Links
DID data model spec:
https://www.w3.org/TR/did-core
List of supported DID methods:
https://w3c.github.io/did-spec-registries/#did-methods
Verifiable Credentials data model spec:
https://www.w3.org/TR/vc-data-model/
BBS+ Signatures spec:
https://w3c-ccg.github.io/ldp-bbs2020/
Decentralized Identifiers (DIDs)
By Andrei
Decentralized Identifiers (DIDs)
- 286