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

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/