Decentralized Identifiers (DIDs)

&

Verifiable Credentials

by Andrei Sambra

A DID is a self-sovereign identity - a lifetime, portable, and verifiable digital identity, that does not depend on any centralized authority.

Identifiers - 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 (especially in the browsers)
existing specifications already apply to DIDs:
- <a href="did:example:123">John</a> is valid HTML and can be deep linked into applications

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.
Contain one or more services associated with the DID subject that can be used for different types of interactions.
May contain 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 150 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)

Verifiable Credentials

* graphics from Mattr

At the most basic level, verifiable credentials, or VC in short, are tamper-proof credentials that can be verified cryptographically.

There are three essential properties of verifiable credentials:

They are machine verifiable
They are secure and tamper-proof
They have been issued by a competent/trusted authority

Verifiable Credentials - in practice

* graphics from Mattr

Verifiable Credentials - example

{
  "@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 Credentials - use cases

Verifiable Credentials - privacy through ZKPs

Privacy-preserving VCs with the help of BBS+ LD-Proofs.
- What BBS+ LD-Proofs reveal is a proof of knowledge of the original signature alongside any of the messages you would like to reveal that were signed when producing the signature.
Benefits of BBS+ LD-Proofs:
- selective disclosure (n of m properties of a claim)
- non-linkability of VC signatures and credential holders
Based on BLS12-381 curve
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.

Example of ZKP VCs using BBS+ (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=="
  }
}

ZKP VCs using BBS+ - 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": {}
  }
}

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). The reveal document is what a verifier is requesting from the prover/holder in terms of information it needs (think of it like a template with a list of attributes).

ZKP VCs using BBS+ - derived proof

{
  "@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="
  }
}

ZKP VCs using BBS+ - Performance

Crypto operations*:

Key generation - 1ms
Signing - 2.50ms / 10 messages
Verifying - 5.20 ms / 10 messages
Proof generation - 10.50ms / 10 messages

Size:

Public Keys: 96 bytes
Signatures: 112 bytes

*In practice the speed depends on the size of the data

Things to consider

Adoption rate (both DID and VC specifications are now W3C Recommendations -- i.e. W3C standards)
Interoperability (i.e. the "decentralised" angle)
Neither spec covers 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