Key Points

1. Wallets
2. DID - Decentralized Identities ( Self Sovereign Identities )
3. FID - Federated Identity across multiple environments
4. CID - Centralized identity

References

Key Concepts

Indy ledgers, SSI, DIDs concepts from Hyperledger course ***

https://github.com/hyperledger-archives/education/blob/master/LFS171x/docs/introduction-to-hyperledger-indy.md

• Introduction and Learning Objectives
  • Introduction to Hyperledger Indy
  • Learning Objectives
• Identity on the Internet
  • Today's Internet Identity Challenges
    • Identity in the Real World
    • Identifiers: User IDs and Passwords
    • Identity Attributes
  • Additional Problems
    • Unwanted Correlation
    • Centralized Identifiers
    • Data Breaches
  • Summary
• Internet Identity with Hyperledger Indy
  • Decentralized Identifiers - DIDs
    • Creating and Using DIDs
    • Agents and Wallets
    • Indy Public Ledger
    • How DIDs Help
  • Verifiable Credentials
    • Credentials and Verifiable Credentials
    • Selective Disclosure and Zero Knowledge Proofs (ZKP)
    • Using Verifiable Credentials
    • How VCs Help
  • Trying it Out
  • Privacy
  • Self-Sovereign Identity
• Hyperledger Indy in Context
  • Using Indy for Identity with other Blockchains
  • Indy's Blockchain Algorithms
    • Type of Blockchain
    • Blockchain Consensus Algorithm
  • Hyperledger Indy and Sovrin
    • Elements of the Sovrin Foundation
• Running Hyperledger Indy
  • Demonstration Overview
  • Running the Demonstration
  • What goes on the Blockchain

Indy example

https://www.devteam.space/blog/how-to-build-a-self-sovereign-identity-wallet/#6

Concept of Credentials Verification

The concept of identity has three components, as follows:

1. Claims: A person or a business makes an assertion of an identity claim.
2. Proofs: A document providing evidence for the claim.
3. Attestation: A third-party validates that the claim is correct according to their record.

SSI facts

“Self Sovereign Identity” (SSI) is the answer to the above issues. SSI has the following characteristics:

1. You own and control it fully.
2. Another person or entity can read it only with your consent.
3. No one can use it without your consent.
4. It‘s mathematically proven, hence, trustless, no one can decline the claims you made using your SSI.
5. SSI is permanent, no hacker can destroy it.
6. It‘s portable, you carry it on you.

The Indy ledger 

Indy is a distributed ledger, designed specifically for decentralized identity. The project provides tools, libraries, and reusable components to create blockchain-based digital identities.

The Indy distributed ledger stores ’identity records‘, which contain the following:

1. Public keys;
2. Service endpoints;
3. Credential schemas;
4. Credential definitions.

Each identity records are linked to one unique ’decentralized identifier‘ (DID), which the distributed ledger resolves it without any centralized authority. An identity owner can own multiple DIDs.

The Indy ledger is public permissioned, and if you want to publish DIDs, you need to become a ’Trust Anchor‘ on it. This signifies a facilitator role where the ledger already knows about a trust anchor.

Entities can have DIDs for each relationship with other Entities 

Indy uses DIDs to establish connections between two identities, such as a user and a service's website, so that they can securely communicate. Further, the expectation is that an entity - e.g. you - will have many, many DIDs - one for each relationship you have with another entity. Think of each DID like a userID/password pair, but one that is backed with strong cryptography in the form of public/private key pairs. As well, note that both sides of a relationship provide a DID for the other to use to communicate with them.

How Entity DIDs can create secure relationships using 2 way verification with DIDs

1. User creates new DID for new relation - A user registers for a service's website by creating and giving the service a new, never-used-before DID
2. Web site creates new DID for the new relation - user receives back from the service the same thing - a new, never-used-before DID created by the service.
3. Each records the "relationship" DIDs - so that when one wants to communicate with the other, they have an endpoint to send the message, and a public key to end-to-end encrypt the message.
4. When the user logs in, the user and the service exchange encrypted messages to confirm that each holds the private key to decrypt the messages.
5. The service knows the User - because the user used their DID
6. The user knows it's the service - because the service used its DID. 

Agents provide identity services for entities with DIDs and Wallets store DIDs

1. The "Agent" is the software that interacts with other entities (via DIDs and more)
   1. Agents communicate directly with Agents to accomplish Identity-related tasks
2. The term "Wallet" as a data store for the DIDs and related information (including private keys and more).

For example, a person might have a mobile Agent app on their smart devices, while an Organization might have an enterprise Agent running on a Cloud Server. All Agents have a secure Wallet for storing identity data.

Example - Using a user DID on a public ledger

https://www.devteam.space/blog/how-to-build-a-self-sovereign-identity-wallet/

Decentralized Identity - DID

https://w3c-ccg.github.io/did-primer/

new class of identifier that fulfills all four requirements: persistence, global resolvability, cryptographic verifiability, and decentralization.

DID specification, but the overall architecture for decentralized identity represented by the family of DID-related specifications currently under development. It covers:

• Background on the origin of DIDs and the DID specification.

• How DIDs differ from other globally-unique identifiers.

• How the syntax of DIDs can be adapted to work with decentralized networks.

• How DIDs resolve to DID Documents containing public keys and service endpoints.

• The key role that DID Methods play in the implementation of DID infrastructure.

• Privacy considerations for the use of DIDs.

• How DID infrastructure lays the foundation for verifiable credentials

DID Documents

the key is a DID, and the value is a DID document. The purpose of the DID document is to describe the public keys, authentication protocols, and service endpoints necessary to bootstrap cryptographically-verifiable interactions with the identified entity.

includes six components (all optional):

1. The DID itself, so the DID document is fully self-describing.

2. A set of cryptographic material, such as public keys, that can be used for authentication or interaction with the DID subject.

3. A set of cryptographic protocols for interacting with the DID subject, such as authentication and capability delegation.

4. A set of service endpoints that describe where and how to interact with the DID subject.

5. Timestamps for auditing.

6. A optional JSON-LD signature if needed to verify the integrity of the DID document.

DID Methods

Defining how a DID and DID document are created, resolved, and managed on a specific blockchain or “target system” is the role of a DID metDhod

DID method specifications typically define at least the following operations for a particular target system:

1. Create. Some DID methods may generate a DID directly from a cryptographic key pair. Others may use the address of a transaction or a smart contract on the blockchain itself.

2. Read. Some DID methods use blockchains that can store DID documents directly on the blockchain. Others may instruct DID resolvers to construct them dynamically based on attributes of a blockchain record. Still others may store a pointer on the blockchain to a DID document stored in one or more parts on other decentralized storage networks such as IPFS or STORJ.

3. Update. The update operation is the most critical from a security standpoint because control of a DID document represents control of the public keys or proofs necessary to authenticate an entity (and therefore for an attacker to impersonate the entity). Since verification of DID document update permissions can only be enforced by the target blockchain, the DID method specification must define precisely how authentication and authorization are performed for any update operation.

4. Delete. DID entries on a blockchain are by definition immutable, so they can never be “deleted” in the conventional database sense. However they can be revoked in the cryptographic sense. A DID method specification must define how this termination is performed, e.g., by writing a null DID document.

Privacy by Design best practices for DID

best practices such as:

1. Pairwise-pseudonymous DIDs. While DIDs can be used as well-known public identifiers, they can also be used as private identifiers issued on a per-relationship basis. So rather than a person having a single DID, like a cell phone number or national ID number, she can have thousands of pairwise-unique DIDs that cannot be correlated without her consent, yet can still be managed as easily as an address book.

2. Off-chain private data. Storing any type of PII on a public blockchain, even encrypted or hashed, is dangerous for two reasons: 1) the encrypted or hashed data is a global correlation point when the data is shared with multiple parties, and 2) if the encryption is eventually broken (e.g., quantum computing), the data will be forever accessible on an immutable public ledger. So the best practice is to store all private data off-chain and exchange it only over encrypted, private, peer-to-peer connections.

3. Selective disclosure. The decentralized PKI (DPKI) that DIDs make possible opens the door to individuals gaining greater control over their personal data in two ways. First, it enables it to be shared using encrypted digital credentials (see below). Second, these credentials can use zero-knowledge proof cryptography for data minimization, e.g., you can disclose that you are over a certain age without disclosing your exact birthdate.

DIDs are only the base layer of decentralized identity infrastructure. The next higher layer – where most of the value is unlocked – is verifiable credentials. This is the technical term for a digitally signed electronic credential that conforms to the interoperability standards being developed by the W3C Verifiable Claims Working Group.

DIDs can be used to identify various entities in the Verifiable Credentials ecosystem such as issuers, holders, subjects, and verifiers. More generally, DIDs can be used as identifiers for people, devices, and organizations.

Sample flow using DIDs and attestations to authenticate information for a principal

DID flow shows how verifiable credential is used

When opened, the first screen is blank - use right arrow to page to screen 2 then continue

DID Software Stack

file:///C:/Users/JIMMAS~1/AppData/Local/Temp/lab1-Hyperledger%20Aries%20-%20The%20Technical%20Bits.pdf

Aries agent logical view

Aries agents available

Indy and Aries work together for Identity Mgt

W3C Verifiable Credentials Primer

https://w3c.github.io/webpayments-ig/VCTF/primer/

Current State Issues

In existing attribute exchange architectures (like SAML, OpenID Connect, Login with SuperProviderX, etc.) users, and their verifiable claims, do not independently exist from service providers. This leads to vendor lock-in, fragmentation of identity across different services, reduced competition in the marketplace, and reduced privacy for all stakeholders. There is no interoperable standard capable of expressing and transmitting verifiable claims that works the same across industries (e.g., finance, retail, education, and healthcare). This leads to fragmented industry-specific solutions that are costly and inefficient.

Future State Design

subject, claim, issuer, holder, verifier 

Resources

• Verifiable Claims Working Group Draft Charter - The draft charter that is being proposed for approval by W3C membership. 15 minute read.
• Verifiable Claims Architecture - A proposed architecture for verifiable claims. 5 minute read.
• Demonstration of Support for Verifiable Claims - Survey results proving that the Verifiable Claims work is widely supported by industry. 10 minute read.
• Verifiable Claims FAQ - Frequently asked questions related to the Verifiable Claims work. 15 minute read.
• Verifiable Claims Use Cases - A selection of Verifiable Claims use cases that are representative of the work. 30 minute read.
• Proposed Verifiable Claims Data Model Specification - The input specification that the Verifiable Claims Working Group will attempt to standardize. 30 minute read.

When to use pair-wise DIDs

https://lists.w3.org/Archives/Public/public-credentials/2018Apr/0076.html

OR

segregate external permissioned access from internal data relations ( encryption, signatures ).

https://forum.sovrin.org/t/public-facing-dids-vs-private-pairwise-dids/243

SOVRIN - an Indy-based identity network service 

Sovrin extends Indy function adding more features to make SSI global identities secure and recoverable

Daniel Hardman on Sovrin identity recovery models

discusses a model to disable identity access from a registered device and grant access to a new device for identity access

https://sovrin.org/wp-content/uploads/2019/03/What-if-someone-steals-my-phone-040319.pdf

sovrin-identity-recovery-2020-What-if-someone-steals-my-phone-040319.pdf

1. many challenging design problems not solved for the average person in this solution which requires:
   1. Sovrin ( vs Indy ) for device revocation
   2. multiple registered devices so an individual has a recovery device
   3. potentially multiple private keys for M of N authorization
   4. potentially other MFA features 

Sovrin - DID usage concepts

https://www.evernym.com/wp-content/uploads/2017/07/What-Goes-On-The-Ledger.pdf

One of the most common questions about Sovrin is, “What goes on the ledger?” This paper answers that question and explains several key decisions the Sovrin Technical Governance Board (TGB) has made about why data should or should not go on the Sovrin Ledger Sovrin’s focus on decentralised self-sovereign identity is built on a foundation of Privacy by Design. Every design decision is intended to increase security and privacy while reducing undesirable impacts and correlation risk.The Sovrin ledger is designed specifically to be a public utility which can be used by any person or organisation. This has huge benefits in terms of scale, flexibility and adoption—full public accessibility ensures identity can be truly independent and self-sovereign.As a result, some of these policies differ substantially from other blockchain identity implementations where identity is a “bolt on” rather than the sole purpose of the ledger itself

Which DIDS go on ledger?  Public vs Private DIDs

A DID added directly to the Sovrin public ledger is called a ​public DID​​, whereas a pairwise pseudonymous DID shared and stored privately “off-ledger” between the agents for two identity holders is called a ​private DID​​. The ability for Sovrin infrastructure to support both is fundamental to both its Privacy by Design architecture as well as its ability to scale

Sovrin example for bank and customer using pair-wise DIDs

https://www.evernym.com/wp-content/uploads/2017/07/What-Goes-On-The-Ledger.pdf

This section explains at a high level how public and private Sovrin DIDs could be used toestablish and protect digital relationships.

Independent identity holder Andy wants to use a Sovrin identity to apply for a loan with Seagull Bank. Seagull Bank publishes their public DID on their website and all their literature using a QR code. Andy sees a particularly attractive offer on a poster in a bus station, and scans the QR code with his phone.

Andy’s Sovrin wallet app recognises the QR code as a Sovrin DID. It accesses Sovrin to look up the DID, and retrieve the current DID document. It verifies that the DID document is valid and signed by the holder of the DID. Within the DID document is the endpoint for the bank’s agent.

Andy’s Sovrin wallet app then automatically creates a new private DID for Andy’s relationship with Seagull Bank. This private DID will have it own private DID document containing a new public verification key, plus the unique agent endpoint that he wants Seagull Bank to use. Andy’s Sovrin wallet app then, through Andy’s agent, contacts the bank’s agent endpoint, peer-to-peer with no intermediaries, and establishes a new connection with the bank using this private DID, DID document, and agent endpoint that are shared only with Seagull Bank.

Seagull bank reciprocates, giving Andy back a private pairwise pseudonymous DID and DID document just for this new private relationship that Andy can verify using the bank’s public DID and DID document that are on Sovrin. The bank and Andy now have a secure, private way of communicating whenever they need it. Seagull bank can then use this channel to send Andy specific details on their loan offer. Andy can verify this using the private DID and DID document the bank supplied him with. The bank can do the same thing with Andy’s private DID and DID document when he responds to the bank’s offer.

Andy and Seagull Bank can use Sovrin first to find one another and then to negotiate a completely private channel that is unique to that particular relationship and has no intermediaries. They can then share verifiable credentials over this secure channel in order to establish the necessary level of trust to do business. This is like Andy calling the bank and the two of them instantly inventing a brand-new language together—that only Andy and the bank know. If someone were to tap the line and listen, they wouldn’t understand a thing.

In this example, Sovrin is only used for the lookup, discovery and verification of the bank’s public DID. Then each party establishes a private, pairwise pseudonymous DID with the other. From that point on, all further communication and data exchange takes place off-ledger. This ensures both greater privacy and stronger security as neither party is reusing a public key that they have used with any other party. It’s also much more scalable because the Sovrin ledger is only involved with the initial establishment of the relationship.

In the rare case of two agents “losing touch” because they both moved service endpoints at exactly the same time, the Sovrin public ledger can still provide a privacy-respecting “dead drop” service to enable the agents to re-establish their connection. This service is currently under development in the Hyperledger Indy project

Indy Concepts - Blockchain for SSI - Kindle book

Below are some of the key components of Indy

1. User has multiple DIDs
   A user can have multiple Decentralized Identifiers (DID) on Indy. For each of them a separate pair of public and private keys has to be generated. The users can login using their own private keys on the network to get access to their own wallet associated with that pair of keys. A corporate user can issue certificates to a holder user and a verifier user can also verify identity data of others on the ledger.
2. No Central Repository in Indy
   There is no centralized repository in Indy. Each user once created has his own endpoint and own wallet where individual data is stored. Each user with his mobile device, laptop etc can access his wallet through the User Agent and private key as shown in Figure 3.3 below.
3. Validator nodes are the Trust Providers
   Indy at its heart has a number of Validator nodes who are trusted parties who validate identities and transactions in a distributed network. The validator nodes run on Plenum protocol which is based on RBFT protocol that we would discuss later in this chapter. The Observer nodes are optional and would be needed if one opts to go for scalability with huge number of clients. Observers can be standbys from whom clients can read data on ledger

Potential Value Opportunities

Keyhole Virus Tracker open-source solution

https://keyholesoftware.com/wp-content/uploads/Tracking-Lab-Results-Better-with-Blockchain-Keyhole-Software-White-Paper.pdf

all done in Fabric.

a HIPAA-compliant blockchain solution and implementation for an efficient, near real-time single source of truth of lab results.

To comply with HIPAA requirements, the data must meet the De-Identification Standard, meaning that there is no reasonable basis to believe that the information can be used to identify a single individual.

Simple, permissioned identity management

Only identities needed in Fabric are for the service providers ( Doctor's labs )

Patient's identity not stored on chain, only a proxy-id and test details.

Only patient and doctor's office know patient identity AND the proxy-id.

The patient can find out from the Doctor the test result

Patient Anonymity
To anonymize the patient, only specific details are included like 10-year age range, sex, location, testing method, and result. There is no way to identify an individual patient with this information; any participant of the blockchain will not be able to determine which patient the lab result is for.

Old - Separate Systems

New - DLT System

Potential Challenges

Candidate Solutions

Indy DID Ledger Design

https://hyperledger-indy.readthedocs.io/en/latest/

Key Indy Features

• Distributed ledger purpose-built for decentralized identity
• Correlation-resistant by design
• DIDs (Decentralized Identifiers) that are globally unique and resolvable (via a ledger) without requiring any centralized resolution authority
• Pairwise Identifiers create secure, 1:1 relationships between any two entities
• Verifiable Claims are interoperable format for exchange of digital identity attributes and relationships currently in the standardization pipeline at the W3C
• Zero Knowledge Proofs which prove that some or all of the data in a set of Claims is true without revealing any additional information, including the identity of the Prover

Indy repositories

• Distributed Ledger:

  • indy-node
    services to manage indy nodes
  • indy-plenum
    
    • The system maintains a replicated ordered log of transactions called the ledger on nodes with a leader updated in batches

• Client Tools:

  • indy-sdk
     major artifact of the SDK is a c-callable library; there are also convenience wrappers for various programming languages and Indy CLI too
  • indy-agent

• Shared Components:

  • indy-hipe
    Hyperledger Indy Project Enhancements - standard Indy components
  • indy-crypto
    replaced by Hyperledger Ursa - https://github.com/hyperledger/ursa-docs

Sovrin Test Network

https://selfserve.sovrin.org/

Using the OLD Indy client, can test creating pools, DIDs, simple wallets, tokens on the buildernet

Sovrin SelfServe Instructions gdoc

sovrin-test-id-tokens-2020-lab-SelfServe Instructions.docx

Connect.me digital wallet

https://www.evernym.com/blog/connect-me-sovrin-digital-wallet/

Today, we’re proud to say we are one step closer to a world of self-sovereignty—to a world where anyone can take back ownership of their digital identity—with the “general availability” release of Connect.Me, the first digital wallet app built on Sovrin.

Connect.Me represents the first example of what giving control back to the individual consumer looks like. Using Connect.Me, individuals can:

• Form private, pairwise cryptographic connections with other entities in the Sovrin ecosystem
• Gather digital credentials
• Present digital proofs of part or all of your credentials, privately and securely
• Store (and restore from) a backup of your digital wallet wherever you want
• Answer secure messages from any connection you have

Early adopters of the app include Truu, a London-based platform working to provide a secure, verifiable digital identity for doctors, and CULedger, a Denver-based company focused on bringing cutting-edge innovation to the credit union industry. And, if you’re ever visiting Deloitte’s London office, you can even use the app to prove your age and unlock their blockchain-enabled beer fridge. Talk about versatility!

Connect.Me also includes an integration with the identity verification company Onfido. The integration—which we’re currently piloting in the US, Canada, and UK markets—allows users to verify their identity with existing physical credentials, such as a passport or driver’s license, and obtain a digital credential which can be used in pilots and trials across the Sovrin ecosystem.

On the integration, Onfido’s CEO Husayn Kassai commented, “We’re looking forward to jointly moving the identity debate beyond theory and whitepapers to pragmatic delivery of a solution that protects the privacy and security of individuals, whilst making it easier for them to get access to the financial products and services they need.”

And we’re only just getting started.

As the underlying technology for decentralized identity grows and matures, so will Connect.Me, and so will the number of truly decentralized applications worldwide. The core credential exchange technology that powers Connect.Me is being adopted on a global scale, via Hyperledger Indy, Hyperledger Ursa, and most recently, Hyperledger Aries. The launch of Connect.Me represents just the latest milestone in the rise of decentralized identity as we get ever closer to putting digital identity back into the hands of the consumer.

See Connect.Me in action

Wondering what a self-sovereign world looks like? Download the app (iOS, Android) and follow our Getting Started guide, which will walk you through the exercise of receiving and sharing credentials with three fictitious organizations.

Step-by-step guide for Example

DID Verifiable Credential Examples

https://drive.google.com/file/d/0B7Jt9-9f27gmTzhJTmgxSHBvcWNpbVVmMl81d1NfSFAzTm9j/view

Generic DID Verifiable Credential Example

Organizations SHOULD have a signing certificate from a root CA or intermediate CA to be a trusted source

GDPR DID Verifiable Credential Example

Organizations as verifiers should have signing certificates from root CA in a trust list

Compare Verifiable Credentials with and without a Ledger

tip> Create a DID in an Indy test environment using the SDK

https://hyperledger-indy.readthedocs.io/projects/sdk/en/latest/docs/how-tos/write-did-and-query-verkey/README.html

process to setup DIDs for individuals and organizations on Indy

setup steward DID and generate the Indy genesis transaction  ( the State )

create trust anchor DIDs that will create other DIDs as needed  ( key agencies: DMV, DOS )

option - generate DIDs for existing registered individuals and organizations

take applications from individuals and organizations to get an identity

create a script that creates a new DID and proves it can be queried from the ledger:

No sample scripts exist in the readthedocs

DID special roles - steward role, trust anchor role - create other DIDs

A few operations in indy can only be done by identities (DIDs) with special roles. For example, a DID that is a steward can add a node (the one they own) to the validator pool, and can create DIDs with a trust anchor role. A trust anchor DID can add arbitrary DIDs to the ledger.

Here, we are populating our identity wallet with DID+keypair material for one steward identity and one trust anchor identity. The steward identity is a bootstrapping step, whereas the trust anchor DID is the one we will query later.

Notice that the steward DID is created with a seed, but the trust anchor DID is not. This is because the steward DID and its verkey is already in the ledger; they were part of the genesis transactions we told the SDK to start with in the previous step. But we have to also put the DID, verkey, and private signing key (which the ledger doesn’t know) into our wallet, so we can use the signing key to submit an acceptably signed transaction to the ledger. We will use this steward’s signing key to create our next DID–the one for our trust anchor, which is truly new. This is why we use a hard-coded seed when creating the steward DID–it guarantees that the same DID and key material are created that the genesis transactions expect. In a production indy pool such as the Sovrin “live” network, the bootstrapping steward identities would not have known the seeds.

sample code block

Recommended Next Steps

Related articles