This document summarizes a webinar about self-sovereign identity. It discusses traditional centralized identity systems and how self-sovereign identity uses decentralized networks and blockchains to allow individuals to control their own identity information. It also describes the Indy platform for self-sovereign identity and how it works using decentralized identifiers, credentials, and blockchains without a central authority. Challenges around privacy, regulation and ease of use for self-sovereign identity are also mentioned.

1. Daniel Hardman
Chief Architect Evernym and Secretary of the Technical Governance Board
Sovrin Foundation
@dhh128
https://creativecommons.org/licenses/by-sa/4.0/
Webinar: Identity and the quest for
Self-Sovereign Identity
SSIMeetup.org18 June 2018

2. 1. Empower global SSI communities
2. Open to everyone interested in SSI
3. All content is shared with CC BY SA
SSIMeetup.org
Alex Preukschat @SSIMeetup @AlexPreukschat
Coordinating Node SSIMeetup.org
https://creativecommons.org/licenses/by-sa/4.0/
SSIMeetup objectives
18 June 2018

3. What is “identity”?
SSIMeetup.org

4. Aspects of Identity: Relationships
Relationships
you
you to Acme as employee
you to UKGov as citizen
you to Bob as friend
you to Carol as sibling
You are
who you know
From ideas first articulated by Jason Law (private communication).
SSIMeetup.org

5. Aspects of Identity: Attributes
Attributes
your credit history
your health records
your facts of birth
you
your education
You are
your data
From ideas first articulated by Jason Law (private communication).
SSIMeetup.org

6. Aspects of Identity: Agents
Agents
your realtor
your iPhone app
your lawyer
you
your cloud service
You are
your agents
From ideas first articulated by Jason Law (private communication).
SSIMeetup.org

7. You are
all of these
you
Relationships
Attributes
Agents
From ideas first articulated by Jason Law (private communication).
SSIMeetup.org

8. Who knows what about me?
you
Relationships
Attributes
relationship~attribute
Agents
From ideas first articulated by Jason Law (private communication).
SSIMeetup.org

9. you
Agents
Relationships
Attributes
agent~relationship
Which proxy
represents
me
where?
From ideas first articulated by Jason Law (private communication).
SSIMeetup.org

10. you
Agents
Relationships
Attributes
agent-attributeWhich proxy
can share what
about me?
From ideas first articulated by Jason Law (private communication).
SSIMeetup.org

11. What is “self-sovereign identity”?
Why is it decentralized?
SSIMeetup.org

12. Traditional / Siloed Identity (Centralized)
From ideas first articulated by Timothy Ruff; see http://bit.ly/2rB180M
SSIMeetup.org

13. Third-Party IDP (Federated)
From ideas first articulated by Timothy Ruff; see http://bit.ly/2rB180M
SSIMeetup.org

14. Decentralized
From ideas first articulated by Timothy Ruff; see http://bit.ly/2rB180M
SSIMeetup.org

15. Defining Characteristics of Self-Sovereign Identity
● No central authority grants, monitors, controls, manages, deletes it
● High privacy and high security are achievable (though not guaranteed)
● You choose how and where it’s used
● Portable by you across contexts (bring your own identity)
● All identities are peers (corrects power imbalance)
● Surprising ramifications for regulation, UX
SSIMeetup.org

16. SSI (Decentralized+)
DKMS
SSIMeetup.org

17. Approaches to SSI
SSIMeetup.org

18. The Great Enabler
A source of truth not under central control,
that all parties can trust. Can’t be gamed.
Gives same answer to everyone. Anyone
can write.
SSIMeetup.org

19. Different Ledgers, All Decentralized
public unpermissioned
Bitcoin, VeresOne
public permissioned
Sovrin (Indy)
private unpermissioned
Enterprise Ethereum Alliance
private permissioned
R3, CULedger
governed by code(rs)
governed by constitution
owned championed
SSIMeetup.org

20. Unpermissioned -- Governed by Code(rs)
public unpermissioned
Bitcoin, VeresOne
public permissioned
Sovrin (Indy)
private unpermissioned
Enterprise Ethereum Alliance
private permissioned
R3, CULedger
governed by code(rs)
governed by constitution
owned championed
Usually use proof of work -- an expensive,
pre-agreed mathematical computation to prevent
gaming system. Challenges = scale, latency,
volatility of cryptocurrency, regulation.
SSIMeetup.org

21. Permissioned -- Governed by Constitution
public unpermissioned
Bitcoin, VeresOne
public permissioned
Sovrin (Indy)
private unpermissioned
Enterprise Ethereum Alliance
private permissioned
R3, CULedger
governed by code(rs)
governed by constitution
owned championed
Consensus algorithm: faster, more scalable. May
not be censorship-resistant. Can accommodate
regulation--but what if you don’t like the
constitution?
SSIMeetup.org

22. Challenges to Sovereignty - Control
● Putting data in a cloud owned by someone else
● Mismanaging keys - impersonation
● Inability to take identity somewhere else
SSIMeetup.org

23. Challenges to Sovereignty - Privacy
● Having a single DID or a single endpoint
● Presenting credentials that are correlating
SSIMeetup.org

24. Challenges to Sovereignty - Regulation
● Inability to comply with AML/KYC regs
● Hostility of governments - refuse to participate
SSIMeetup.org

25. More Challenges
Cost
Ease of Use
Divergent Standards

26. Indy = Independent Identity
● Project under the Hyperledger Initiative
● Identity on a special-purpose blockchain
○ Uses byzantine consensus instead of proof of work
○ Radically reduce costs (identity should be free)
○ Improve throughput (latency in tenths of second, not in tens of seconds)
● No constitution -- bring your own
SSIMeetup.org

27. What can you do with Indy?
● Establish a secure, private channel with another person, organization, or
IoT thing -- like an authentication + a VPN, but with no session and no login.
● Send and receive arbitrary messages with high security and privacy
● Prove things about yourself; receive and validate proofs about others.
● Create agents that proxy you in the cloud or on edge devices.
● Manage your own identity:
○ Authorize/revoke devices
○ Create/update/revoke keys
To do this, all you need is an Indy client.
You can build one for free with the Indy
SDK.
SSIMeetup.org

28. Code
https://github.com/hyperledger/indy-sdk (for writing clients)
● stable branch is about 2 months old
● evolving quickly; suggest you use master branch
● can build from source; pip3/maven/apt installs also available
● wrappers: ./wrappers/{dotnet | objectivec | java | python | node | go}
https://github.com/hyperledger/indy-node (the ledger code itself)
● python 3.5
● Installs from .DEBs
SSIMeetup.org

29. Instances of Indy
Sovrin Live Network
● Public
● For production but limited use
● Guarantees: data integrity/permanence, trust framework
Sovrin Test Network
● Public
● For experimental use
● Guarantees: none
Your Own Network -- see http://bit.ly/indy-in-docker
● If you already have docker, stand up in 1 minute
● Use however you like
● To share with others, requires port forwarding
Sovrin adds a formal, legal constitution,
called a “Trust Framework”, to Indy. It is
a global public utility for identity.
SSIMeetup.org

30. Artifacts
● libindy: c-callable library that lets client call identity ledger
● wrappers: easier usage in common languages
○ python
○ java
○ .net
○ iOS (ObjectiveC)
○ node.js
○ go (in PR; not yet tested)
● documentation
○ https://github.com/hyperledger/indy-sdk/blob/master/doc/getting-started/getting-started.md
○ https://github.com/hyperledger/indy-sdk/tree/master/doc/how-tos
● CLI
SSIMeetup.org

31. Appendix
SSIMeetup.org

32. Core Concept - DIDs
A DID (decentralized identifier) is like a uuid for your identity.
DIDs are 128-bit nums written in Base58: did:sov:AKRMugEbG3ez24K2xnqqrm
A DID is controlled by one or more Ed25519 pub/priv key pairs. Pub key is called
a “verkey” (verification key); priv key is called a “signing key”.
DIDs can be created on many different blockchains; right now, Indy only supports
Sovrin-style DIDs (would love PR for did:BTC, did:ETH, etc…)
More info: the DID spec at W3C (https://w3c-ccg.github.io/did-spec/) and here
case-sensitive
SSIMeetup.org

33. Core Concepts - Byzantine Consensus
Instead of proof of work, many nodes confer and reach consensus to prevent
double-spend.
3f + 1 = total nodes, out of which f can be exhibiting faults
● f = faults = malicious, malfunctioning, offline
● Must submit to f+1 nodes to guarantee at least 1 is not malicious/faulting
● Must receive state proof or responses from f+1 nodes
SSIMeetup.org

34. Core Concept - Ledger Roles
Most work on indy can be done by any identity, but a few operations are special:
● Only trustees can add a steward.
● Only stewards can add a node.
● Only trust anchors can add a DID (spam preventer; may go away soon)
In Sovrin, there is a trust framework that governs who can be a trustee or steward;
requires signing pledge to support SSI principles. In your own indy network, you
can assign these roles to anybody.
SSIMeetup.org

35. Core Concept - Genesis Transactions
● The code is published with some genesis transactions that identify the initial
nodes and the trustees that will set the rules for the network. (Rules can be a
free-for-all, but can also be stricter to fit circumstances.)
● Genesis transactions are the root of trust.
SSIMeetup.org

36. Core Concept - Wallets
DIDs and their keys are stored in an identity wallet.
Identity wallets are like cryptocurrency wallets, but store additional types of data.
More info here.
Indy SDK includes a default implementation of a wallet that works out of the box.
SSIMeetup.org

37. Safe handling of secrets in an API
● Prefer to generate the secret in its final
resting place, possibly using a seed if
you need determinism.
● Use the secret in its safe place--don’t
pass out to untrusted parties.
● TPMs, HSMs, and so forth follow these
rules.
● Indy’s current wallet interface does,
too. You can’t get private keys out.
photo by UNMEER
SSIMeetup.org

38. Core Concepts - Credentials
Credentials are JSON docs, digitally signed in a special way by an issuer.
Credentials can be used by their holder to generate cryptographic zero-knowledge
proofs that can be checked by a verifier.
SSIMeetup.org

39. Submitting a Transaction to an Indy Ledger
1. Build the JSON that describes the transaction
2. Sign it
3. Submit it to f+1 nodes
4. Wait for enough responses to trust the answer
SSIMeetup.org

40. Next Steps
Try the Getting Started Guide
Explore the How-Tos
Ask questions: #global-digital-id or #indy, or #indy-sdk on chat.hyperledger.org
Daniel Hardman, github @dhh1128, daniel.hardman@evernym.com
SSIMeetup.org

41. Gartner on Siloed Identity
“Organizations require these digital identities before they can offer their services or
allow any access to their resources. It is common for people to lose track of their
siloed digital identities or not even have the ability to control their identity profile in
many of these organizations. Both people and organizations increasingly feel the
pain, and learn that this model is neither scalable nor sustainable as the use of
digital services become more pervasive.”
December 2017 Gartner report, Blockchain: Evolving Decentralized Identity
Design
SSIMeetup.org

42. 4 Trillion = Annual Cost of Fraud
https://www.croweclarkwhitehill.co.uk/wp-content/uploads/sites/2/2017/02/crowe-t
he-financial-cost-of-fraud-2017.pdf
SSIMeetup.org

43. Daniel Hardman
Chief Architect Evernym
@dhh128
https://creativecommons.org/licenses/by-sa/4.0/
Webinar: Identity and the quest for
Self-Sovereign Identity
SSIMeetup.org18 June 2018