1A/ DID 101 – Decentralized Identifiers & how they are the key to interoperable self-sovereign ID

From IIW

DID 101


Wednesday 1A

Convener: Drummond Reed

Notes-taker(s): Andrew Hughes and Colin Jaccino


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


Notes by Dummond Reed:

Drummond Reed shared this presentation based on work funded by the U.S. Department of Homeland Security, and specifically Anil John, Program Manager for Identity and Data Privacy.

Here are a number of the questions asked and answered:

  1. Will the DID spec go to a full SDO (standard development organization)? At some point, yes, but no SDO has been chosen yet—currently it is just a community spec. See these links:
    1. PDF version (static).
    2. Google doc version (live version accepting comments).
  2. Can anyone create a DID method spec? Yes.
  3. Are all DID methods intended to be global in scope? Yes and no. Yes, the DIDs under the method must be globally unique. But no in that the method spec may only address the needs of a specific community that may be relatively narrow.
  4. Will there be a registry or authority for DID method specs to ensure uniqueness? No. The DID spec is explicit that uniqueness of DID method names will not use a centralized authority (after all, this is decentralized identity infrastructure), but will be accomplished by community consensus just like an open source project.
  5. What can be customized in a DDO (DID descriptor object) by a DID method spec? The main thing that can be customized is the control block. Usage of DID fragments, paths, or service endpoints that is still consistent with the DID spec is also an option.
  6. What other work is now being based on DIDs? They are the key to a number of other specs. For at list of five more specifications specifically based on DIDs, see The DID Family of Specifications.
  7. How can I get involved with continuing work on the DID spec? Contact Drummond Reed directly at first name drummond dot last name reed at evernym dot com, or join us at the Rebooting the Web of Trust, http://www.weboftrust.info/, or the Sovrin Forum, http://forum.sovrin.org/. 

See: DID (Decentralized Identifier) Data Model and Generic Syntax 1.0


Notes by Andrew Hughes


The DID spec was funded in part by a SmalL Business Research (SBIR) grant from the Dept. of Homeland Security.

DIDs are a new type of globally unique identifier

They enable internet-scale digital ID w/o centralized services.

DIDs are designed for “blockchain identity”. All verified cryptographically.


Requirements were:

- Something LIKE a URN

  • That can last forever
  • With no central registry
  • Cryptographically verifiable.


DID format:

{scheme}:{namespace}:{namespace-specific identifier}

urn:uuid:ae84-d5c2-2845f922d59842-2984252ae


DID Syntax:

did:sov:234927420kabaoerha9823h;af983h;a23;9a8

scheme:method:method-specific-id


Initial DID Method specs & prefixes:

Sovrin-   did:sov:

Bitcoin-  did:btcr:

Ethereum uPort - did:uport:

Ethereum Consent- did:cnsnt:


The 3 purposes of DID methods:

  • Specify the syntax of the method-specific identifier
  • Specify any method-specific elements of the DDO
  • Specify the CRUD ops on DIDs and DDOs.


{key: value}  :  {DID: DDO}


The DDO is what you get back from the DID.


The elements of a DDO:

  • Context (link to spec)
  • DID reference (to self)
  • List of public keys owned by
  • List of controlling DIDs (for key recovery)
  • List of service endpoints (for interaction)
  • Timestamps (for audit history)
  • Signature (for integrity)


Question from me: Could a DDO specify an arbitrary signature recovery mechanism? To allow for rolling forward cryptography, or implementing custom multi-sig logic, beyond the scope of the spec itself?


Answer: YES!  The owner and controller specs are extensible, and uPort for example already has complex smart-contract powered key recovery strategies.


Guardians: a guardian of a decentralized ID, that can later pass control over to that user. Useful in refugee camps where users don’t have key signing powers, or when minors are not legally permitted to manage their own identities.


Additional notes from Colin


Interrelation between Verifiable Claims, Distributed ID, and the W3C Web Payments working group.


DHTs - Distributed Hash Tables


Several groups came together with the need for another type of identifier.

Drummond Reed - Trustee of Sovirin Foundation.

DID’s (Decentralized Identifiers): Solving the Root Identity Problem

DID partly funded by a Small Business Innovation Research grant from US Dept of Homeland Security.

Google: Rebooting the Web of Trust Spring 2017.  Find DID family of specifications.


DIDs:

  • new type of globally unique identifier
  • enable internet-scale digital identity without centralized registry services.
  • DIDs are designed for “blockchain identity” - they are generated, registered, and verified cryptographically.


Why is this a breakthrough?

  • Distributed ledgers are massively secure, scalable, and reliable.
  • For digital identity, a distributed ledger can solve the “root of trust” problem: How can there be a global source of identity that everyone trusts, but isn’t owned or controlled by any one company?


Work  with all blockchain models:

  Axes - Validation vs Axis

  Access: Public/privat

   Validation: Permissionless,Permissioned.


Wat do DID’s look like?

  URN (RFC 2141)

  Examples:  UUID, DOI


How do we make DID’s work with any ledger?


DID syntax

did:sov:3k9dg356wdcj5gf2k9bw8kfg7a


Initial DID Method specs (in development as of May 3 2017):

Method                        DID Prefix

Sovran                        did:sov:

Bitcoin Reference:      did:btcr

Ethereal uPort            did:sport:

Ethereal Concent:      did:consent:


Three purposes of DID methods:

  1. Specify the syntax of the method-specific identifier
  2. Specify any method-specific elements of the DDO (DID descriptor objecT)
  3. Specify the CRUD (Create, Read, Update, Delete) operations on DIDs and DDOs for the target ledger.


What is a DID?

{“Key”: “Value”}

{ “DID”: “DDO” }


Elements of a DDO

  1. DID (self-describing)
  2. List of public keys (For the owner)
  3. List of controlling DIDs (for key recovery)
  4. List of service endpoints (for interaction)
  5. Timestamps (for audit history)
  6. Signature (for integrity)


DID and owner public key blocks

{ example JSON document }

Includes JSON LD (JSON Linked Data)


Spec example provides the “owner block"

“@context”

“id”

“owner”:

    “id”

    “type”

    “curve”

    “expires”

    “publicKeyBase64”

    “id”

    “type”

    “expires”

    “publicKeyPem”


Current spec draft does not define a specific type of key.  But as it develops, standard key descriptions will be provided, or may become best practice or de facto standard.


Another example:

“control and service endpoint blocks

“control”: [{

    “type”: “OrControl”,

    “signer”: [

    “did:sov:21tDAKCERh95uGgKbJNHYp”,

    “did:sov:8uQhQMGzWxR8vw5P3UWH1j”

   ]

}],

“service”: {

    “opened”: “https://openid.example.com/456”,

    “xdi”: “https://xdi.example.com/123”

},


(continued) Timestamp and signature blocks

“create”: “…date…”,

“updated”: “….date..””

“Signature”: {

    “type”: “RsaSignature2016”,

    “created”: “….date…”,

    “creator”: “did:sov:8uQhQMGzWxR8vw5P3UWH1j#key/1”,

    “signatureValue”: “IOmA4oaisjdoiajsdflkjasdf=“

    }

}


Discussion of JWT and JWS


What is a guardian?

A guardian manages a a DID for a Dependent

Sovrin spec will account for subordinate/child identities under the guardianship of a parent DID.

Retrieved from "https://iiw.idcommons.net/index.php?title=1A/_DID_101_–_Decentralized_Identifiers_%26_how_they_are_the_key_to_interoperable_self-sovereign_ID&oldid=20974"