Sovrin/Indy integration details

[Andrei0105]

Thread for details regarding Sovrin integration. Hyperledger Indy is a technology from the Linux foundation providing a decentralized ledger built for identity. Sovrin is an implementation of the Indy codebase. Hyperledger Aries is "infrastructure for blockchain-rooted, p2p interaction, it's not a blockchain and not an application".

[Andrei0105]

Aries includes (from https://www.hyperledger.org/blog/2019/05/14/announcing-hyperledger-aries-infrastructure-supporting-interoperable-identity-solutions):

1. A blockchain interface layer (known as a resolver) for creating and signing blockchain transactions.
2. A cryptographic wallet for secure storage (the secure storage tech, not a UI) of cryptographic secrets and other information used to build blockchain clients.
3. An encrypted messaging system for off-ledger interactions between clients using multiple transport protocols.
4. An implementation of ZKP-capable W3C verifiable credentials using the ZKP primitives found in Ursa.
5. An implementation of the Decentralized Key Management System (DKMS) specification currently being incubated in Hyperledger Indy.
6. A mechanism to build higher-level protocols and API-like use cases based on the secure messaging functionality described earlier.

• The interface will initially support the Indy resolver, but is flexible to allow other DID method resolvers (Does this mean that it could be used with uPort, Blockstack, etc. ?)
• Core message families that are necessary to facilitate interoperable interactions for a wide variety of use cases involving blockchain-based identity
• Aries is related to both Indy (resolver implementation) and Ursa (cryptographic functionality)
• One of the main purposes: change the client layers in Indy to be interoperable with other identity projects

Goals for 1.0 release:

• dynamic set of capabilities to store and exchange data related to blockchain-based identity (ranging from secured, secret storage of data such as private keys, up to the capability of globally accessible data that can be viewed and accessed by everyone) - example of such support - the creation of a secure storage solution similar to the wallet available in Indy
• Decentralized Key Management Solution (DKMS) which would add key recovery, social recovery and wallet backup and restore functionality. Using DKMS, clients will need a way to interact with one another peer to peer that is currently in development within Hyperledger Indy.

[Andrei0105]

Useful links: DIDComm-js https://github.com/decentralized-identity/DIDComm-js Simple extension https://github.com/dbluhm/super-simple-browser-static-agent Agent Messaging https://docs.google.com/presentation/d/1XSDaCIJhuQJm4SwhjylJ1cchTcfpspKWngeLsAvXzhM/edit?usp=sharing Aries-RFCs; issue-credential and present-proof are particularly relevant: https://github.com/hyperledger/aries-rfcs/blob/master/index.md The Aries Toolbox https://github.com/TelegramSam/aries-toolbox Aries WG Call Notes and Agendas (past and future meetings will be posted on this page): https://wiki.hyperledger.org/display/ARIES/Aries+Working+Group The Call the Toolbox was demoed on (Recordings at the bottom of the page): https://wiki.hyperledger.org/pages/viewpage.action?pageId=16322546

[Andrei0105]

Possible communication within the extension:

1. Websites are backed by full agents providing their service. Eg: A server run by Faber College, allowing it to issue credentials to its students.
2. The users have a backing full agent (local/cloud). This holds their identity wallet.
3. The extension is a static agent connected to the user's full agent. It should be able to send and receive messages from the user's full agent.
4. The extension should inject a javascript library to be used by the page to send DIDcomm messages to it (invites/credentials etc.).
5. The static agent of the extension forwards the messages to the user's Full Agent.

Current problems/to-dos:

• At 3., sending messages from the full agent to the extension, establishing a connection, see https://github.com/Andrei0105/identity-wallet/issues/4.
• 4. - 5. -Communication - The page's full agent can prepare wire messages for the user's full agent which are only received and forwarded by the extension (The extension reveals to the page the DID and VK of the user's full agent). The same way, the user's full agent can prepare wire messages which ar forwarded to the page via the extension. The extension acts only as a proxy.

Messaging protocols that must be supported:

• Present proof (Request credential) https://github.com/hyperledger/aries-rfcs/tree/master/features/0037-present-proof
  1. Request proof - page to user
  2. Present proof - user to page
• Issue credential https://github.com/hyperledger/aries-rfcs/tree/master/features/0036-issue-credential
  1. Propose credential (optional) (if the user wants to initiate the protocol)
  2. Offer credential - page to user
  3. Request credential - user to page
  4. Issue credential - page to user

[Andrei0105]

Structure of Daniel's static agent solution:

• The webpage uses a script to create a Websocket connection to the full agent. This can be moved to the extension since the connection is static
• The aries-didcomm.js script is used by the page if the extension exists to send a message containing the did message and vk of the fullagent to the content script.
• The content script sends the data to the background script and waits for a response.
• The background processes the message, packs it using the VK and generated private key, and sends it back, where it is send via the Websocket

[Andrei0105]

Possible solution:

• The extension helps the 2 agents (the page's and the user's) to establish a connection
• The 2 agents can then talk on their own, without involving the extension

[Andrei0105]

Implementing the solution from https://github.com/Andrei0105/identity-wallet/issues/3#issuecomment-519079669:

• Initial implementation for agents started with --auto-accept-invites --auto-accept-requests
• Only generating an invitation and receiving an invitation is required to establish a connection
• The extension should connect to the user's agent management console and use the connections/create-invitation endpoint to generate an invitation
• The extension passes the invitation to the page which then passes it to its agent to accept it
• This can also happen the other way around, since it is more likely for the page agent to be the one that initiates the connection. Then the extension should use /connections/receive-invitation on the user's agent
• The invitation message is not encrypted in any way (it is an agent message not a wire message) since there is no DID and verkey to use for encryption

[Andrei0105]

Basic implementation at commit https://github.com/Andrei0105/identity-wallet/commit/c45b10587ac793272435b42ffb918296de41304d. Update/desired features:

• The extension uses directly the user's agent API in the connection process
• The connection request is initiated upon user interaction (ie clicking a button).
• The invitation is generated by the service/page's agent and passed to the page when a function in the javascript library injected by the extension is called. The page can also generate an invitation on page load and keep it ready since an unlimited number of invitations can be generated. Creating invitations is handled by the page.
• The extension receives the invitation and prompts the user to accept or refuse it. It should also present some data about who the user is connecting to. Since this is not a connection to a public DID, but a pairwise unique connection, this data can be passed by the page.
• If the connection is accepted by the user, the extension uses receive-invitation and accept-invitation on the user's agent to accept the request. A confirmation that this step was performed (that the status of the connection request is now 'response') is sent to the page. If the connection is refused, the page is notified.
• The page receives the confirmation and instructs its agent to accept the request. When this step is done, it notifies the extension (by calling a function from the injected library).
• The extension can check by itself the status of the connection. It should be 'active'.
• At this point the connection between the two agents is active. Since the extension has full access to the user's agent it can display all the user's connections in a popup, where the user should be able to manage them (eg remove). This way, by enabling full management of the user's connections which create his identity, the extension acts as an 'identity wallet'.

Alternative/also needed: The connection to be initiated by the extension (the user's agent).

[Andrei0105]

Full connection protocol implemented at commit https://github.com/Andrei0105/identity-wallet/commit/538ebb73ccebdbc7154f9e1299a62c00dc548093.

[Andrei0105]

UI listing all connections with the ability to remove them implemented at commit https://github.com/Andrei0105/identity-wallet/commit/d435efc36a14c9a95554a94842f8cfb598669823.

[Andrei0105]

Issuing credentials:

• The page's agent needs a public DID to register a credential schema and a credential definition. This should be done by the agent without any intervention from the extension.
• The page's agent will send a credential exchange request to the connection to the user's agent. After this, it will notify the page which will notify the extension via a function from the injected library.
• The extension will check if the exchange request was received, and if it is, it will display the credential attributes to the user and prompt the user to either accept or reject the credential.
• If the user accepts the credential, the extension will instruct the user's agent to save the received credential in its wallet.

[Andrei0105]

If not using --auto-respond-credential-offer:

• After the page sends the credential exchange request, the extension has to request the credential (the state will be offer-received, after the request it will be credential-received).
• After this, the credential can be saved

Note: These steps assume the use of POST /credential_exchange/send by the page's agent to automate some communication steps.

[Andrei0105]

Basic credential exchange implemented at commit https://github.com/Andrei0105/identity-wallet/commit/d1a94cbd52a177695ed02d07702e3b73eabcbb6b.

[Andrei0105]

Presenting proofs (without --auto-respond-presentation-request):

• On user interaction (ie the user clicking a 'present proof' button), the page's agent will send a proof request to the user's agent. A function from the injected library also sends a message notifying the extension that the page initiated a proof request.
• The user will be prompted to accept or reject sending the proof
• If he accepts, the extension will use data from the received presentation request and the /presentation_exchange/{id}/credentials request to build a presentation.
• The generated presentation is sent to the page's agent. The extension also notified the page that the user presented a proof.
• At this point the extension's job is over. The presentation can be verified by the page's agent. Eventually, if the proof is not valid and cannot be verified, the page can ask the extension again for a proof.