Hyperledger Indy Platform - Privacy, Security and Power for Digital Identity Systems
6 likes984 views
Hyperledger Indy is a software ecosystem that empowers individuals to have control over their private identities and privacy decisions, while enabling secure interactions such as loan qualifications and private voting without compromising personal information. It features decentralized identifiers and a framework for self-sovereign identity, promising improvements in privacy, security, trust interactions, and efficient digital credential management. The architecture aims for decentralization, interoperability, and simplicity, while utilizing advanced cryptographic techniques like zero-knowledge proofs for enhanced privacy.
![HYPERLEDGER INDY
SELF MANAGED DID DOCUMENT
{
"@context": "https://w3id.org/did/v1",
"id": "did:example:123456789abcdefghi",
"authentication": [{
// this key can be used to authenticate as did:...fghi
"id": "did:example:123456789abcdefghi#keys-1",
"type": "RsaVerificationKey2018",
"controller": "did:example:123456789abcdefghi",
"publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----
rn"
}],
"service": [{
"type": "ExampleService",
"serviceEndpoint": "https://example.com/endpoint/8377464"
}]
}](https://image.slidesharecdn.com/hyperledgerindydeveloperecosystem1point2gwsmarch2019-190315132301/85/Hyperledger-Indy-Platform-Privacy-Security-and-Power-for-Digital-Identity-Systems-44-320.jpg)
Hyperledger Indy Platform - Privacy, Security and Power for Digital Identity Systems
- 1. HYPERLEDGER INDY A DEVELOPER ECOSYSTEM WALKTHROUGH
- 2. INDY IS A SOFTWARE ECOSYSTEM FOR PRIVATE, SECURE, AND POWERFUL IDENTITY. Once it is implemented, it puts people — not the organizations that traditionally centralize identity — in charge of decisions about their own privacy and disclosure.
- 4. INDY PRIVACY PROPOSITION HYPERLEDGER ALLOWS US TO CONSTRUCT INTERACTIONS WHERE THE DEGREE OF DISCLOSURE IS EXPLICIT AND MINIMAL
- 5. INDY MAKES IT POSSIBLE TO PREQUALIFY FOR A LOAN AT A THOUSAND BANKS, IN A WAY THAT PROVES CREDIT WORTHINESS, INCOME, AND CITIZENSHIP, WITHOUT FORFEITING PRIVACY. USED CORRECTLY, IT CAN INSULATE CAUTIOUS WHISTLEBLOWERS; IT CAN ENABLE SECURE, PRIVATE VOTING; IT CAN MAKE ONLINE DATING SAFER.
- 6. HYPERLEDGER INDY POSSIBILITIES ‣ Connection contracts, ‣ Revocation contracts ‣ Novel payment workflows ‣ Document management features ‣ Creative forms of escrow ‣ Curated reputation
- 7. HYPERLEDGER INDY PRIVACY PRESERVING FEATURES ▸ Pairwise Decentralised Identifiers ▸ Semi Trusted Agents ▸ Agent to Agent Communication ▸ Agent Communication using LibSodium ▸ LibSodium Sealed Box ▸ Authenticated Encryption ▸ Zero Knowledge Proofs ▸ Credential Revocation Features ▸ Affinity for Data and Key Storage at the Edge ▸ Privacy Preserving Agent Revocation
- 9. HYPERLEDGER INDY HYPERLEDGER INDY TOOLS ▸ Distributed Ledger ▸ Client Tools ▸ Shared Components ▸ Reference Implementations ▸ Integration Implementations
- 11. DISTRIBUTED LEDGER INDY NODE, INDY PLENUM
- 12. CLIENT TOOLS INDY SDK, INDY AGENT
- 13. SHARED COMPONENT INDY CRYPTO, INDY HIPE
- 15. INDY SSI VC DEMO
- 17. A POSSIBLE SCENARIO Alice, a graduate of the fictional Faber College, wants to apply for a job at the fictional company Acme Corp. As soon as she has the job, she wants to apply for a loan so she can buy a car. She would like to use her college transcript as proof of her education on the job application; once hired, Alice would like to use the fact of employment as evidence of her creditworthiness for the loan.
- 19. CURRENT CHALLENGES The sorts of identity and trust interactions required to pull this off are messy in the world today; they are slow, they violate privacy, and they are susceptible to fraud. We’ll show you how Indy is a quantum leap forward.
- 20. DIGITAL TRANSCRIPTS As a graduate of Faber College, Alice receives an alumni newsletter where she learns that her alma mater is offering digital transcripts. She logs in to the college alumni website and requests her transcript by clicking Get Transcript.
- 21. TRUST ANCHOR Faber College has done some prep work to offer this service to Alice. It has the role of trust anchor on the ledger. A trust anchor is a person or organization that the ledger already knows about, that is able to help bootstrap others.
- 22. SELF SOVEREIGN IDENTITY Alice doesn’t realise it yet, but in order to use this digital transcript she will need a new type of identity -- not the traditional identity that Faber College has built for her in its on-campus database, but a new and portable one that belongs to her, independent of all past and future relationships, that nobody can revoke or co-opt or correlate without her permission. T
- 23. IDENTITY AGENTS In normal contexts, managing a self-sovereign identity will require a tool such as a desktop or mobile application. It might be a standalone app, or it might leverage a third party service provider that the ledger calls an agency. For example, leaders in this technology such as the Sovrin Foundation and companies like Evernym, publish reference versions of such tools.
- 24. INDY CLI The CLI could play the role of multiple identity owners (a person like Alice, an organization like Faber College, or an IoT - style thing; these are often called "principals" in security circles). In this guide we will just be Alice but to keep things clear and explore functionality let's change the prompt:
- 25. IDENTITY WALLET Creating a new empty wallet basically resets the agent to a clean slate. Because this is the first time you're setting this up, this step is not actually necessary. If you're wanting to interact with other DIDs held by the agent then this does become necessary.
- 26. STATUS COMMAND ALICE> STATUS NOT CONNECTED TO INDY NETWORK. PLEASE CONNECT FIRST.
- 27. HYPERLEDGER INDY EVALUATING A CONNECTION REQUEST ALICE> show sample/faber-request.indy { "connection-request": { "name": "Faber College", "DID": "ULtgFQJe6bjiFbs7ke3NJD", "nonce": "b1134a647eb818069c089e7694f63e6d" }, "sig": "4QKqkwv9gXmc3Sw7YFkGm2vdF6ViZz9FKZcNJGh6pjnjgBXRqZ 17Sk8bUDSb6hsXHoPxrzq2F51eDn1DKAaCzhqP" } Try Next: load sample/faber-request.indy
- 28. HYPERLEDGER INDY LOADING A CONNECTION REQUEST ALICE> load sample/faber-request.indy 1 connection request found for Faber College. Creating Connection for Faber College. Try Next: show connection "Faber College" accept request from "Faber College"
- 29. HYPERLEDGER INDY SHOW CONNECTION REQUEST Expanding Faber to "Faber College" Connection (not yet accepted) Name: Faber College DID: not yet assigned Trust anchor: Faber College (not yet written to Indy) Verification key: <empty> Signing key: <hidden> Remote: FuN98eH2eZybECWkofW6A9BKJxxnTatBCopfUiNxo6ZB Remote Verification key: <unknown, waiting for sync> Remote endpoint: <unknown, waiting for sync> Request nonce: b1134a647eb818069c089e7694f63e6d Request status: not verified, remote verkey unknown Last synced: <this connection has not yet been synchronized> Try Next: sync "Faber College" accept request from "Faber College"
- 30. HYPERLEDGER INDY INDY AGENTS ▸ Python Reference Agent ▸ Node Js Reference Agent ▸ Sovrin Connector ▸ IndyCat ▸ StreetCred ▸ Verity ▸ Connect.Me
- 31. DECENTRALISED IDENTIFIER DID (Decentralized Identifier) is an opaque, unique sequences of bits, (like UUIDs or GUIDs) that get generated when a user tries to accept the connection request. That DID will be sent to Faber College, and used by Faber College to reference Alice in secure interactions. Each connection request on the Indy network establishes a pairwise relationship when accepted. A pairwise relationship is a unique relationship between two identity owners
- 32. DIGITAL IDENTITY SYSTEMS DEEP DIVE ON DID DIDs are fully under the control of the DID subject, independent from any centralized registry, identity provider, or certificate authority. DIDs are URLs that relate a DID subject to means for trustable interactions with that subject. DIDs resolve to DID Documents — simple documents that describe how to use that specific DID. Each DID Document may contain at least three things: proof purposes, verification methods, and service endpoints. Proof purposes are combined with verification methods to provide mechanisms for proving things.
- 33. HYPERLEDGER INDY DESIGN GOALS OF DID ARCHITECTURE ▸ Decentralisation ▸ Self sovereignty ▸ Privacy ▸ Security ▸ Proof Based ▸ Discoverability ▸ Interoperability ▸ Portability ▸ Simplicity ▸ Extensibility
- 34. DECENTRALISATION DID architecture should eliminate the requirement for centralized authorities or single points of failure in identifier management, including the registration of globally unique identifiers, public verification keys, service endpoints, and other metadata.
- 35. SELF SOVEREIGNTY DID architecture should give entities, both human and non- human, the power to directly own and control their digital identifiers without the need to rely on external authorities.
- 36. PRIVACY DID architecture should enable entities to control the privacy of their information, including minimal, selective, and progressive disclosure of attributes or other data.
- 37. SECURITY DID architecture should enable sufficient security for relying parties to depend on DID Documents for their required level of assurance.
- 38. PROOF BASED DID architecture should enable the DID subject to provide cryptographic proof of authentication and proof of authorization rights.
- 39. INTEROPERABILITY DID architecture should use interoperable standards so DID infrastructure can make use of existing tools and software libraries designed for interoperability.
- 40. PORTABILITY DID architecture should be system and network-independent and enable entities to use their digital identifiers with any system that supports DIDs and DID Methods.
- 41. SIMPLICITY To meet these design goals, DID architecture should be (to paraphrase Albert Einstein) "as simple as possible but no simpler".
- 42. EXTENSIBILITY When possible, DID architecture should enable extensibility provided it does not greatly hinder interoperability, portability, or simplicity.
- 43. DISCOVERABILITY DID architecture should make it possible for entities to discover DIDs for other entities to learn more about or interact with those entities.
- 44. HYPERLEDGER INDY SELF MANAGED DID DOCUMENT { "@context": "https://w3id.org/did/v1", "id": "did:example:123456789abcdefghi", "authentication": [{ // this key can be used to authenticate as did:...fghi "id": "did:example:123456789abcdefghi#keys-1", "type": "RsaVerificationKey2018", "controller": "did:example:123456789abcdefghi", "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY----- rn" }], "service": [{ "type": "ExampleService", "serviceEndpoint": "https://example.com/endpoint/8377464" }] }
- 45. SOVRIN Integrated anonymous credentials with revocation for privacy, unforgeability, performance, unlinkabaility and a distributed ledger with best practices from ethereal and BFT Protocols
- 47. ANONYMOUS CREDENTIALS It is well known that the anonymity and unlinkability properties are provided by various kinds of anonymous credentials, the concept dating back to seminal works by David Chaum in 1980s. Zero- knowledge proofs allow a User to prove the possession of a credential without showing the credential itself, thus providing unlinkability. Additional features include delegation and revocation
- 48. REVOCATION FEATURE The revocation procedure assumes that each credential has special Revocation-ID attribute with value iR, and Issuer can at any moment revoke a particular iR. For Verifiers this means that if a User with a revoked iR presents his credential, this can be detected by the Verifier. the revocation feature provides quite a privacy leak.
- 49. BLOCKCHAIN FOR DID Public User Pseudonyms Issuer Credential Definitions and Public Keys Revocation Updates
- 50. HYPERLEDGER INDY SOVRIN SOLUTION ARCHITECTURE It is an Ethereum based ledger, which records transactions and root hashes of the Merkle tree over the state of public pseudonyms, Issuer public keys, revocation data, credential definitions, etc. The immutable data such as revocation tails are stored off-chain in distributed file systems such as IPFS with relevant links from the ledger state. For the consensus protocol BFT family of protocols are chosen as the number of nodes are limited to a few hundred, impose restricted membership and have partial control over many of them. Our BFT protocol is called Plenum and it is an enhancement of RBFT, which was chosen its resilience and fast recovery properties and implemented it. MACs are replaced with EdDSA signatures as very fast implementations now exist, designed a leader election protocol, and added new blacklisting strategies.
- 51. TEXT INDY ROADMAP ▸ Micro Ledgers ▸ Sophisticated Policies ▸ AI for Agents ▸ Mix Networks for Transaction Submitting ▸ Agent Routing