DevDay: Extending CorDapps with Self-Sovereign Identity: Technology Deepdive and Sample Applications, Vasiliy Suvorov
Download as PPT, PDF0 likes391 views
The document discusses self-sovereign identity and decentralized identifiers (DIDs). It introduces emerging standards for decentralized identity being developed by the Decentralized Identity Foundation. Key concepts discussed include DIDs, DID documents, verifiable credentials, and implementations like uPort, Ethereum, IPFS, Blockstack, and Sovrin/Indy. The document provides examples of how DIDs can represent identities and how verifiable credentials issued to DID subjects can be verified.
![www.luxoft.com
Indy/Sovrin under the hood - 1/3
credential definition: {
"ver":"1.0",
"id":"V4SGRU86Z58d6TV7PBUe6f:3:CL:12:TAG_1",
"schemaId":"12",
"type":"CL",
"tag":"TAG_1",
"value":{
"primary": {
"n":"104273...84493",
"s":"824420…08151",
"rms":"52810…7940757153551267",
"r":{
"attr2":"73…809361",
"attr1":"88653…3706"
},
"rctxt":"6775...3821855822433",
"z":"418407...5877279897334588"
}
}
}
schema: {
"ver":"1.0",
"id": "V4SGRU86Z58d6TV7PBUe6f:2:schema_name:1.0",
"name":"schema_name",
"version":"1.0",
"attrNames":["attr1","attr2"],
"seqNo":12
}
new schema
by authority
schema
from authority
new definition
by issuer #1
new definition
by issuer #2
new definition
by issuer #3
What’s in the blocks?
Schema
A structure that defines future credential
format or credential specification.
Credential
A digital assertion about identity attributes made
by a Ledger Entity about itself or another Ledger
Entity.
A Credential may be Public Data or Private
Data.
Credential Definition
A machine-readable definition of the semantic
structure of a Credential. (i.e. Public Key)
Proof
Cryptographic verification of a Credential.
PlenumLedger
Who interacts with the Ledger?
Authority
Creates Schemas
Issuer
Creates Credential Definitions
Prover
A Prover receives Credentials from the
Issuers. Both Prover and Issuer interact to
agree on some facts.
Verifier
Requests Proofs](https://image.slidesharecdn.com/1445-vasiliysuvorov-extendingcordappswithself-sovereignidentity-180924161626/85/DevDay-Extending-CorDapps-with-Self-Sovereign-Identity-Technology-Deepdive-and-Sample-Applications-Vasiliy-Suvorov-9-320.jpg)
DevDay: Extending CorDapps with Self-Sovereign Identity: Technology Deepdive and Sample Applications, Vasiliy Suvorov
- 1. www.luxoft.com v Extending CorDapps with Self-Sovereign Identity: Vasily Suvorov VP Technology Strategy Sep 12, 20018 / CordaCon 2018 Technology deep dive and sample applications.
- 2. www.luxoft.com Emerging standards for decentrilized identity DECENTRALIZED IDENTITY FOUNDATION DECENTRALIZED IDENTITIES Anchored by BLOCKCHAIN IDs Linked to ZERO-TRUST DATASTORES That are UNIVERSALLY DISCOVERABLE for people, organizations, apps and devices. Credentials Community Group Verifiable Claims Working Group
- 3. www.luxoft.com Decentralized Identifiers (DIDs) and DID Documents Key enablers for decentralized self-sovereign identity Decentralized Self-Sovereignty Privacy Security Proof-based Discoverability Interoperability Portability Simplicity Extensibility DESIGN GOALS DID DID Document Also Service end-points, Proofs, Extensions, etc See https://w3c-ccg.github.io/did-spec/ for details
- 4. www.luxoft.com 4 ISSUED BY CORRECT, REVOCABLE INCORRUPTIBLE, CORRECT OWNERSHIP By decoupling the trust between the identity provider and the relying party, a more flexible and dynamic trust model is created such that market competition and customer choice is increased. REPOSITORY ISSUER + HOLDER = IDENTITY PROVIDER ISSUER DOESN’T NEED TO TRUST VERIFIER Verifiable claims/credentials – roles & trust under Self-Sovereignty
- 5. www.luxoft.com Verifiable credentials How DIDs become (use-case specific) Identities W3C Example DMV – issuer Traveler – Holder/Subject DID:EXAMPLE:EBFEB… Bar - inspector/verifier Credential Credential
- 6. www.luxoft.com DID/Verifiable Credentials implementation uPort, Ethereum (ERC725), IPFS, Blockstack, Ontology Foundation and others support DID/DDO OSS Project under Hyperledger Provides key enabling components: BFT Ledger / Nodes Cryptographic primitives Client SDK Can be used for Dev/Private Network Public Utility Network for SSI Based on Indy Technology Governance Board Trust Framework Network Operations & Growth Supports scalable, global SSI based applications
- 7. www.luxoft.com Sovrin/Indy – key features overview Dedicated, public but permissioned ledger Pair-wise DIDs Agents based claims/proofs exchanges Implements Attribute Based Claims (ABCs) ZKPs for selective disclosure & revocation Owner Issuer Verifier Existing Trust Relationship ZKP Verifying Protocol Issuing Protocol ZK Verifiable Credential Zero Knowledge Proof Edge Agent Edge Wallet Edge Agent Edge Wallet Edge Layer Cloud Agent Cloud Wallet Cloud Agent Cloud WalletCloud Layer DID Layer Verifiable Claim
- 8. www.luxoft.com The case for combining blockchain/DLT technologies „Orchestration” Use-Cases Buying & Selling: Property, Cars, … Healthcare Supplier Management Multi-Party Business Process: Order of activities is well defined Strong pre-conditions & dependencies Relationships and Attestations serve as “Checkboxes” Strong Privacy requirements / preferences DECENTRALIZED IDENTITY LEDGER DEFs / SCHEMAS DIDs Rules State DLT
- 9. www.luxoft.com Indy/Sovrin under the hood - 1/3 credential definition: { "ver":"1.0", "id":"V4SGRU86Z58d6TV7PBUe6f:3:CL:12:TAG_1", "schemaId":"12", "type":"CL", "tag":"TAG_1", "value":{ "primary": { "n":"104273...84493", "s":"824420…08151", "rms":"52810…7940757153551267", "r":{ "attr2":"73…809361", "attr1":"88653…3706" }, "rctxt":"6775...3821855822433", "z":"418407...5877279897334588" } } } schema: { "ver":"1.0", "id": "V4SGRU86Z58d6TV7PBUe6f:2:schema_name:1.0", "name":"schema_name", "version":"1.0", "attrNames":["attr1","attr2"], "seqNo":12 } new schema by authority schema from authority new definition by issuer #1 new definition by issuer #2 new definition by issuer #3 What’s in the blocks? Schema A structure that defines future credential format or credential specification. Credential A digital assertion about identity attributes made by a Ledger Entity about itself or another Ledger Entity. A Credential may be Public Data or Private Data. Credential Definition A machine-readable definition of the semantic structure of a Credential. (i.e. Public Key) Proof Cryptographic verification of a Credential. PlenumLedger Who interacts with the Ledger? Authority Creates Schemas Issuer Creates Credential Definitions Prover A Prover receives Credentials from the Issuers. Both Prover and Issuer interact to agree on some facts. Verifier Requests Proofs
- 10. www.luxoft.com 1. Insurance#3 issues credential based on a definition Insurance#3 Government 2. Ask to proof some data issued by insurance#3 without revealing it 3. ZKP PRIVATE WALLET Keys Credentials Validity Proofs Indy/Sovrin under the hood - 2/3 digital verification takes 2 steps: tting a credential from an issuer eating proof for a verifier re 2 types of proofs: nsparent – all Attrs are revealed P – Attrs are selectively disclosed DID DID’ • Pairwise DIDs are used • Agents (secure exchange) are not out-of-the-box.
- 11. www.luxoft.com tcp/ip POOL HANDLES INDY/SOVRIN LEDGER CONNECTION CONFIGURATION 1. Trustee 2. Steward 3. Trust Anchor 4. User PRIVATE, TEST, PUBLIC NETWORKS Pool genesis file • Contains initial set of Nodes a Pool is started from • New Nodes will be added by sending new NODE trx to be written into the Ledger • All new Nodes and Clients will use genesis transaction file to connect to initial set of Nodes, • Will discover new Nodes based on NODE trx in the Ledger Genesis transactions files initialize the ledger. TEST NETWORKDEV. DOCKER NETWORK PUBLIC NETWORK NYMs INDY SDK DID LEDGER WRAPPERS PRIVATE WALLET Keys Credentials Validity Proofs Indy/Sovrin under the hood 3/3
- 12. www.luxoft.com 1 2 3 4 SDK modules and interfaces Ledger Ledger is responsible for public information exchange: schema, definitions, revocation registry Anoncreds Functionality for anonymous credentials: schema, credential definition, revocation, proof and request generations, etc. It provides cryptographic primitives to generate proofs and sign messages DID DID & DDO management functionality Pool Pool manages the local ledger configuration that can be used later to connect to “pool nodes." Pairwise Individual keys pair to prevent relationships between issued credentials. Extends DID functionality. Wallet Secure private wallet exposes interfaces to operate with private information: credentials, keys, etc. fun issuerCreateAndStoreCredentialDef(…) fun proverCreateProof(…) fun issuerCreateCredential(…) NEW SCHEMA HAS TO BE REGISTERED ON PUBLIC LEDGER ISSUER HAS TO CREATE CREDENTIAL DEFINITION (PK) AND PUBLISH ON LEDGER PROVER ASKS FOR NEW CREDENTIAL PROVER CREATES DIGITAL PROOF TO CONVINCE VERIFIER fun issuerCreateSchema(…) SKD JAVA WRAPPER
- 13. www.luxoft.com CORDAPP #Y … CORDAPP #X … FLOWS FLOWS CORDAPPS Corda applications running on private client’s node FLOWS FLOWS FLOWS FLOWS CORDAPPS Corda applications running on private company’s node FLOWS FLOWS FLOWS FLOWS INDYSDK INDY- UTILS CORDENTITY Indy specific flows to work with the Credentials and Proofs Application specific flows to implement required business process Cordentity is an utility CorDapp which exposes high level APIs hiding complexity of Hyperledger Indy Cordentity doesn’t require deep knowledge of cryptography or Indy’s functionality. It operates with basic primitives: schema, definition and proofs. Cordentity utilizes Corda’s flows, states and contracts DID:SOV:12345689ABCDEFGAB Corda + Indy = Luxoft’s Cordentity PRIVATE WALLET Keys Credentials Validity Proofs INDY-CREDENTIAL: CredentialRequest & Credential INDY-CREDENTIAL-PROOF: ProofReq & Proof STATES Holder/Issuer Prover/Verifier
- 14. www.luxoft.com Cordentity – usage overview class Authority( private val schemaName: String, private val schemaVersion: String, private val schemaAttributes: List<String> ) : FlowLogic<String>() CREATE SCHEMA FLOW class Authority(private val schemaId: String) : FlowLogic<String>() CREATE CREDENTIAL DEF FLOW class Issuer(private val identifier: String, private val credDefId: String, private val credProposal: String, private val proverName: CordaX500Name) : FlowLogic<Unit>() ISSUE CREDENTIAL FLOW class Verifier( private val identifier: String, private val attributes: List<ProofAttribute>, private val predicates: List<ProofPredicate>, private val proverName: CordaX500Name ) : FlowLogic<Boolean>() VERIFY CREDENTIAL FLOW AUTHORITY & ISSUER Legal entities create new schema as a definition of future credentials Authorities authorized to issue user’s credentials create credentials definition on top of the existing schemas User requests new credential from one of the authorities Two users check/verify credentials PROVER & VERIFIER Every individual Corda Node that uses Cordentity has a private wallet Cordentity’s flows interact with a specified Indy network Indy network should be specified via file with genesis transactions. There are 3 type of networks: docker powered (development), STN and production. Authority or Issuer have to get permissions. AssignPermissionsFlow provides suitable interfaces. 1. AssignPermissionsFlow 2. CreateCredentialDefFlow 3. CreateSchemaFlow 4. IssueCredentialFlow 5. VerifyCredentialFLow Flows Party#1 Party#2 Two type of data in a proof: Predicates and Attributes. •A predicate is never revealed and just checked on a criteria. •An attribute will be revealed.
- 15. www.luxoft.com AUTHORITY ISSUER #1 ISSUER #2 ISSUER #3 PROVER VERIFIER AUTHORITY INSURANCE PROVER PATIENT VERIFIER TREATMENT CENTER ISSUER INSURANCE AUTHORITY GOVERNMENT ISSUER GOVERNMENT SCHEMA #2SCHEMA #1 CREDENTIAL DEFINITION #2 CREDENTIAL DEFINITION #1 CREDENTIALS CREDENTIAL DEFINITIONS CREATE SCHEMA CreateSchemaFlow ASSIGN PERMISSIONS AssignPermissionsFlow CREATE CREDENTIAL DEFINITION CreateCredentialDefinitionFlow ISSUE CREDENTIAL IssueCredentialFlow DATA VERIFICATION VerifyCredentialFlow BASIC RELATIONSHIPS MODEL USE-CASE SPECIFIC RELATIONSHIPS MODEL Trust / Attestations Mapping
- 16. www.luxoft.com Complete Sample Application Personalized Medicine End-to-End Ecosystem 3 Treatment Center places pers. medication order to the assigned Manufacturer DID:SOV:135473839JFGDFEDH 1 DID:SOV:12345689ABCDEFGAB Patient is prescribed with a personalized medicine therapy 2 Insurance company confirms the coverage of therapy costs DID:SOV:937472047DEFHASGCC 5 Courier delivers the package to the Treatment center 4 Manufacturer produces and ships the pers. medication package 6 Patient receives the therapy at the Treatment center Personal data is kept privately and not shared with external participants Participants’ data is verifiable and immutable against fraud Selective data visibility Isolated pairwise relationships between participants
- 17. www.luxoft.com PRODUCTION & SHIPMENT AUTHENTICATION PRECONDITIONS: •Patient gets Credentials from a number of different Authorities and stores them privately. •Two Authorities are required for processing: Insurance and Government. Business Rules PICK-UP Patient creates proof for Treatment Center based on Claims from well known Authorities. Some data are revealed during the interaction and other is kept secret. The Prover needs to reveal: medical package, diagnosis and treatment recommendation. The Prover also needs to prove to the Verifier nationality, age (above 18) and stage (above 3) of disease. If patient is authenticated successfully the production process starts. The Treatment center connects to Manufacturer to request new production. On every steps all involved participants get notifications about the status. Finally, the Patient returns back to the Treatment center to collect the package. He confirms his rights and gets the product.
- 18. www.luxoft.com Phase I – Initiate Manufacturing Treatment Center Manufacture r Patient Age, nation, diagnosis, Insurance IndyCredentialProof Corda State Manufacturing Request PackageRequest CordaState observers: patient Digital Order Confirmation subflow subflow subflow IndyCredential, Corda State 3 Treatment Center places pers. medication order to the assigned Manufacturer DID:SOV:135473839JFGDFEDH 1 DID:SOV:12345689ABCDEFGAB Patient is prescribed with a personalized medicine therapy 2 Insurance company confirms the coverage of therapy costs DID:SOV:937472047DEFHASGCC ctual Relationships are created VerifyCredentialFlow IssueCredentialFlow
- 19. www.luxoft.com M anufacturer Treatment center … Shipment lifecycle Courier1 CourierN Custom s …( () ) ( ) Phase II – Shipment / Delivery Patient receives delivery notifications on every step 5 Courier delivers the package to the Treatment center 4 Manufacturer produces and ships the pers. medication package ulti-step chain of custody Verifiable Handoff Holder Receiver
- 20. www.luxoft.com Patient can collect his package and be serviced at any participating treatment center Treatment center confirms Patient’s identity Phase III – Therapy/Treatment subflowTreatment Center ask for Order Confirmation proof IndyCredentialProof (initial authent.) PackageRequest(s) IndyCredential (copy of digital receipt) Treatment is delivered to patient DID:SOV:135473839JFGDFEDH 6 Patient receives the therapy at the Treatment center Treatment Center Has the package Patient’s personal info is kept private at all stages IndyCredentialProof Corda State VerifyCredentialFlow
- 21. www.luxoft.com Summary • Self-Sovereign Identity & Verifiable Credentials is a very powerful mechanism • Scalable, DLT-enabled Business Ecosystems benefit from SSI integration • Corda is the next generation DLT that simplifies integration with other technologies • Cordentity makes it easy to use Hyperledger Indy / Sovrin powered SSIs / Credentials from CorDapps ource – please use it and let us know how to make it better!
Editor's Notes
- #15: subFlow(VerifyCredentialFlow.Verifier(serial, attributes, predicates, proverName))