Skip to content

P2P agent communication protocol (IndyComm)

Jump to bottom
osancus edited this page Jun 26, 2020 · 2 revisions

All of indy Hyperledger Indy Project Enhancements (HIPEs) were moved to Hyperledger Aries with new updates. Old indy hypes about agent communication protocols can be found here: https://hyperledger-indy.readthedocs.io/projects/hipe/en/latest/text/index.html

For indy communication refer:

Hyperledger Aries formulated the Indy HIPEs and enhance them but overall follow the same core logic so can be referred to understand agent communication. The capability of securely exchanging verifiable data and signing two-way agreements (e.g. consents), is made possible by using a secure peer-to-peer (P2P) method of creating and verifying a connection between two previously unknown software systems. This method is called DID-based Communication (DIDComm). In order to implement DIDComm, one needs to implement Agents that possibly support one or more DID-methods and thus are connected to an identity infrastructure.

How the DIDComm works?

A typical DIDComm interaction works like this (transcript taken from the Aries DIDComm documentation):

Imagine Alice wants to negotiate with Bob to sell something online, and that DIDComm, not direct human communication, is involved. This means Alice's agent and Bob's agent are going to exchange a series of messages. Alice may just press a button and be unaware of details, but underneath, her agent begins by preparing a plaintext JSON message about the proposed sale. (The particulars are irrelevant here, but would be described in the spec for a "sell something" protocol.) It then looks up Bob's DID Doc to access two key pieces of information:

An endpoint (web, email, etc) where messages can be delivered to Bob. The public key that Bob's agent is using in the Alice:Bob relationship. Now Alice's agent uses Bob's public key to encrypt the plaintext so that only Bob's agent can read it, adding authentication with its own private key. The agent arranges delivery to Bob. This "arranging" can involve various hops and intermediaries. It can be complex.

Bob's agent eventually receives and decrypts the message, authenticating its origin as Alice using her public key. It prepares its response and routes it back using a reciprocal process (plaintext -> lookup endpoint and public key for Alice -> encrypt with authentication -> arrange delivery).

So, DIDComm is about creating a secure two-way messaging protocol and standardising common message exchange sequences (aka. protocols).

Basic DIDComm exchange set

The high-level DIDComm-based communication has three distinct phases:

  1. Establish DID-connection (DID-exchange)
  2. Execute one or more protocols that satisfy the business requirements of the use case (this may happen over period of time)
  3. Close the DID-connection by revoking the keys used to establish the DID-connection (also a possibility to rotate the keys).

MyData Agency protocols

The MyData agency system implements the following protocols:

  1. DID-exchange
  2. Issue Authentication (& Guardianship) Credentials
  3. Issue consent credential
  4. Revoke issued credentials

Clone this wiki locally