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
![](https://s3.amazonaws.com/media-p.slid.es/uploads/377385/images/9133152/pasted-from-clipboard.png)
- URLs - locate resources
- URIs - identify people, concepts, things, etc.
- URNs - persistent names that do not change, no matter their location
![](https://s3.amazonaws.com/media-p.slid.es/uploads/377385/images/9133199/pasted-from-clipboard.png)
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
![](https://s3.amazonaws.com/media-p.slid.es/uploads/377385/images/9133236/pasted-from-clipboard.png)
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
![](https://s3.amazonaws.com/media-p.slid.es/uploads/377385/images/9133283/pasted-from-clipboard.png)
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
![](https://s3.amazonaws.com/media-p.slid.es/uploads/377385/images/9133152/pasted-from-clipboard.png)
The DID methods support the same basic functionally (creation, update, etc.), but they differ in how that functionality is implemented.
![](https://s3.amazonaws.com/media-p.slid.es/uploads/377385/images/9133384/pasted-from-clipboard.png)
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
![](https://s3.amazonaws.com/media-p.slid.es/uploads/377385/images/9137768/pasted-from-clipboard.png)
* 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
![](https://s3.amazonaws.com/media-p.slid.es/uploads/377385/images/9137749/pasted-from-clipboard.png)
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/
Decentralized Identifiers (DIDs)
By Andrei
Decentralized Identifiers (DIDs)
- 1,123