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

*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/

Made with Slides.com