The document discusses the integration of self-sovereign identity (SSI) into decentralized applications using blockchain technology, primarily focusing on Hyperledger Indy and Corda. It highlights the framework for decentralized identifiers (DIDs), verifiable credentials, and their roles in creating a dynamic trust model that enhances privacy and security. Various use cases, such as personalized medicine and supply chain management, exemplify the practical applications of these technologies in developing scalable, secure, and efficient identity solutions.

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!