101 Introduction to DID’s, Verifiable Claims and Blockchains

From IIW
Jump to: navigation, search

101 Introduction to DID’s, Verifiable Claims and Blockchains 


Tuesday 5B

Convener: Drummond Reed

Notes-taker(s): Colin Jaccino


Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:


A brief overview of Decentralized Identifiers, Verifiable Claims, and the Sovrin Public Permissioned Ledger


The work was initially driven by Web Payments work at the w3c, also in the verifiable claims subgroup.


Verifiable claims are essentially your ID card, credit card, etc.

If someone controls your claim, then it’s not yours.  It’s not necessarily portable.


DID is decentralized identifier.

Self-sovereign identifier is another term to refer to the same, but with an emphasis on owner control.


DID can be used with any form of decentralized network, not just blockchains.


How do you do privacy-respecting identity on a publicly readable blockchain.


Sovrin Identity proposed publishing only public information.  The private information handled by agents off the blockchain.  


Self-soverign identity is…


Lifetime portable digital identify for any person, organization, or thing that does not depend on any centralized authority and can never be taken away.


“Show me a globally resolvable identity that you have that cannot be taken away from you?”


This is only possible with…

Decentralized Identifiers (DIDs):  a new type of globally resolvable, cryptographically-verifiable identifier registered directly on a distributed ledger.


Breakthrough: we use standard URN syntax for the DID syntax

URN syntax  (RFC 8141)

urn:uuid:ae84-d5c2-9fb785ea-72ccd34

Scheme, Namespace, Namespace-specific Identifier


DID syntax:

did:sov:3k99dg356wdcj5gf2k9bw8kfg7a

Scheme, Method, Method-specific identifier

Method-specific identifier: generated as defined by the particular DID method specification


Initial DID Method Specs


Sovrindid:sov:

Bitcoin Referencedid:btcr

Ethereum uPortdid:uport:

Veres Onedid:v1:

IPFSdid:ipid:

IPDBdid:ipdb:


{ “Key”: “Value” }


{ “DID”: “DID Doc” }

Decentralized Identifier

DID Document (JSON-LD == JSON Link Data )

JSON Link Data provides a means to reference an RDF Ontology, enabling validation and interpretation of the document.


The six primary elements of a DID doc.  

  1. DID (i.e., the JSON-LD is self-describing)
  2. List of public keys (for the owner)
    • This is the answer to public key infrastructure and the problems of adoption.  Now you can locate the public key of an identified party.
  3. List of service endpoints (for interaction)
    • service endpoints will probably evolve into a standard set of endpoints 
  4. Access control branch (for key mgmt)
    • Information required to ensure that only an authorized party can make updates to the DID doc
  5. Timestamps (for audit history)
  6. Signature (for integrity)


Decentralized Identity Stack”

  • Identity Owners
  • Identity owners need not be humans.  
  • Edge Layer
  • Edge Agent
  • Service pointers may point to these
  • Edge Wallet
  • Cloud Layer
  • Cloud Agent
  • Service pointers may point to these
  • Encrypted P2P verifiable claims exchange
  • Cloud Wallet
  • DID Layer
  • If the economics of the DID Layer are set up correctly, one could have a different DID for every relationship.  By having a different DID per relationship, it may be possible to avoid correlating relationships, undesired association.
  • DIDs can be mapped into legacy systems.


Nothing about the parties described in the decentralized identity stack that requires self-sovereign identity.  But the idea is this kind of architecture would support this model for identity.