This document discusses self-sovereign identity and decentralized identifiers (DIDs). It provides an overview of identity evolution from centralized to user-centric models. Self-sovereign identity allows individuals to control their digital identities across systems without relying on centralized authorities. DIDs are a new type of identifier that can be registered on a distributed ledger without a centralized registration authority. The document outlines the goals and components of DID specifications and describes how DIDs and verifiable claims work on networks like Sovrin to enable self-sovereign identity.

1. With HUGE thanks to
Drummond Reed of Evernym for
the DID Primer slides!
Biometric Identity
Assertion
Via
Sovrin Blockchain
John R. Callahan
CTO Veridium

2. Identity Evolution
• Centralized Identity
– administrative control by a single authority or hierarchy
• Federated Identity
– administrative control by multiple, federated authorities
• User-Centric Identity
– individual oradministrative control across multiple
authorities without requiring a federation
• Self-sovereign identity
– individual control across any number of authorities
2
*Christopher Allen (The Path to Self-Sovereign Identity)
http://www.lifewithalacrity.com/2016/04/the-path-to-self-soverereign-identity.html

3. Self-sovereign identity is…
3
Lifetime portable digital identity
for any person, organization, or
thing that does not depend on
any centralized authority and
can never be taken away

4. 4
Decentralized Identifiers (DIDs):
a new type of globally
resolvable, cryptographically-
verifiable identifier registered
directly on a distributed ledger
This is only possible with…

5. URN Syntax (RFC 8141)
5
urn:uuid:ae84-d5c2-9fb785ea-72cd34
Namespace
Scheme
Namespace-Specific Identifier

6. 6
did:sov:3k9dg356wdcj5gf2k9bw8kfg7a
Method
Scheme
Method-Specific Identifier
DID Syntax
Generated as defined by the
particular DID method
specification

7. DID Design Goals
• Decentralization: DID architecture should eliminate the requirement for centralized authorities or single points of failure
in identity management, including the registration of globally unique identifiers, public verification keys, service endpoints,
and other metadata.
• Self-Sovereignty: DID architecture should give entities, both human and non-human, the power to directly own and
control their own digital identities without the need to rely on external authorities.
• Privacy: DID architecture should enable entities to control the privacy of their digital identities, including minimal,
selective, and progressive disclosure of attributes or other identity data.
• Security: DID architecture should enable sufficient security for relying parties to depend on DID records for their required
level of assurance.
• Proof-based: DID architecture should enable an entity to provide cryptographic proof of authentication and proof of
authorization rights.
• Discoverability: DID architecture should make it possible for entities to discover DIDs for other entities to learn more
about or interact with those entities.
• Interoperability: DID architecture should use interoperable standards so DID infrastructure can make use of existing tools
and software libraries designed for interoperability.
• Portability: DID architecture should be system and network-independent and enable entitys to use their digital identities
with any system that supports DIDs and DID Methods.
• Simplicity: To meet these design goals, DID architecture should be (to paraphrase Albert Einstein) "as simple as possible
but no simpler".
• Extensibility: When possible, DID architecture should enable extensibility provided it does not greatly hinder
interoperability, portability, or simplicity.
7 Source: Christopher Allen (Life with Alacrity blog)

8. DID Layer
The decentralized identity “stack”
Cloud Layer
Cloud Wallet Cloud Wallet
Cloud Agent Cloud Agent
Identity Owners
Edge Layer
Edge Wallet Edge Wallet
Edge Agent Edge Agent
Encrypted P2P verifiable claims exchange

9. 9
Method DID prefix
Sovrin did:sov:
Bitcoin Reference did:btcr:
Ethereum uPort did:uport:
Veres One did:v1:
IPFS did:ipfs:
IPDB did:ipdb:
Initial DID Method Specs

10. 10
{ “Key”: “Value” }
{ “DID”: “DID Doc” }
DID Document
(JSON-LD)
Decentralized
Identifier

11. 11
Source: Daniel Buchner (Microsoft Blockchain Identity lead)
https://github.com/decentralized-identity/hubs/blob/master/diagrams/full-system.png

12. 1. DID (i.e., the JSON-LD is self-describing)
2. List of public keys (for the owner)
3. List of service endpoints (for interaction)
4. Access control branch (for key mgmt)
5. Timestamps (for audit history)
6. Signature (for integrity)
12
The primary elements of a DID doc

13. Minimal self-managed DID Document
13
Source: https://msporny.github.io/did-spec/

14. Basic delegate-managed DID Document
14
Source: https://msporny.github.io/did-spec/

15. IEEE 2410
Biometric Open Protocol Standard (BOPS)
(2017 version)

16. VE RI DI U MI D E NRO L L ME NT

17. VE RI DI U MI D E NRO L L ME NT
did:method:abcdef1234567890
Identity
Assertion
(BOPS2)

18. VE RI DI U MI D AU T H E NT I C AT I O N
did:method:abcdef1234567890

19. 19
The new format for interoper-
able digital credentials being
defined by the W3C Verifiable
Claims Working Group
Verifiable claims are…

20. Holder
Wallet
Issuer Verifier
Issues
Verifiable
Claims
Presents
Verifiable
Claims
Decentralized Identifiers (DIDs)
Blockchain or other Decentralized Network
W3C Verifiable Claims Ecosystem

21. 21

22. 22
A public permissioned ledger
designed exclusively to operate
as a global public utility for DIDs
and verifiable claims exchange

23. Bitcoin,
Ethereum,
IOTA
Permissionless Permissioned
Public
Private
Validation
Access
Hyperledger Sawtooth*
Sovrin,
IPDB
Hyperledger (Fabric,
Sawtooth, Iroha),
R3 Corda,
CU Ledger
Blockchain governance models
* in permissionless mode

24. Governance: The Sovrin Foundation
• International non-profit foundation
– http://www.sovrin.org/
• Board of Trustees – currently 12 members
– Governs the Sovrin Trust Framework
– Sets policy for selecting stewards
• Technical Governance Board – currently 8
members
– Governs the Sovrin open source code
– Sets the tech policies implemented in code
24

25. Sovrin
Validator Pool
Sovrin
Observer Pool
Edge Agents & Edge Wallets
Cloud Agents
& Cloud Wallets
Logical Overview of the Sovrin Network
Distributed
agent layer
for private
off-ledger
P2P comms
Secure
exchange of
verifiable
claims
between any
two agents

26. DID
DID Doc
Rich tree of contextual,
verifiable claims behind
a private service
endpoint
Any distributed ledger
SSI

27. 27
DID Specification Links
Implementer’s Draft 01 November 21 2016
Implementers: please send feedback!
Current version https://opencreds.github.io/did-spec/
Github Issues https://github.com/w3c-ccg/did-spec/issues/
Discussion Forums
https://w3c-ccg.github.io/
http://forum.sovrin.org/c/technical/did

28. • W3C Verifiable Claims Working Group
– https://www.w3.org/2017/vc/charter.html
• Sovrin White Papers
– https://sovrin.org/library/
• Sovrin Trust Framework
– https://sovrin.org/trust-framework/
28
Other Links

29. 29
Work on the DID specification has been funded in part
by a Small Business Innovation Research (SBIR) grant
from the U.S. Department of Homeland Security
Science and Technology Directorate.
The content of this specification does not necessarily
reflect the position or the policy of the U.S. Government
and no official endorsement should be inferred.

30. Thank You
https://www.csoonline.com/author/John-Callahan/
© 2017 Veridium IP Ltd. All Rights Reserved