Blockchain Engineering Workshop for World Blockchain Conclave organised by 1point2GWS. Session on Hyperledger Indy Framework, Architecture Model, Components, Modules, Workflows. Demonstrated Verifiable Organisation Networks and Decentralised Workflows on Hyperledger Indy. Demonstrated Hyperledger Indy CLI and Indy Sandbox. Deep Dive on Decentralised Identifiers ( DID ) and the goals of DID. An overview of Sovrin platform is included.

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