Meetings 12 noon EDT (16:00 UTC April 17) and 9 pm EDT (01:00 UTC April 18)

Meeting at 12 noon EDT

  • Anton Khvorov - Hyperledger Iroha project- possibly write an Iroha section
  • Steve Magennis
  • Daniel Hardman- Chief Architect Evernym, technical ambassador
  • Axel Simon-Redhat
  • Luca Boldrin building bridges between legacy and SSI: Europe Blockchain Partnership
  • Ramesh Thoomu - Hyperledger Fabric
  • Stephane Mouy - KYC Consultant- Data protection legal and regulatory expert
  • Stan Liberman - CME group
  • Vipin Bharathan -



Notes: The details can be found in the slides

Agent 2 Agent communication was the focus of the call.

Daniel's excellent presentation can be fully experienced through the video. You also have a link here.

Main points:

What are agents?

  • An agent is attached to a a single user, performs delegated duties for the user
  • A user can have multiple agents, they need not know each other
  • The cryptographic material help by the Agent allows the agent to act on behalf of the Agent
  • Agents communicate with each other using a DID Comm protocol.

Where do they sit in the DID stack?

  • Just above the Anchor, in other words above the Blockchain layer.

What are the layers? and Why?

The why question is answered by the functional requirements:

  • Secure and Private Interaction - including E2E and at Rest
  • Developer Friendly
  • Transport Agnostic
  • Interoperable
  • Extensible

Layers are:

  • The wire protocol: the lowest layer is packed, encrypted and serialized JOSE-(ish) on the wire
  • Plaintext is JSON
  • Since the object model is how the program interacts, there are easy (tools available) to go back and forth from Object->Plaintext→Wire.

How are the layers separated? Mainly through the representation as well as how the data flows in the context. That is the wire transport takes care of the fact that the data as it leaves the device is encrypted appropriately. The plaintext and object are only available once the data is unpacked and decrypted, and only on the device. The data stored locally is also encrypted.

Cryptography in the layers? Wire

Multicasting...One to many communications using encryption on the target (wrapped symmetric key is used-unwrapping requires targets private key- to get at the symmetric key), so K1..Kn targets have separate symmetric keys wrapped in pubkey of K1..Kn. This wrapping can be wrapped again, so that we can do routing as well as multicast.

What are the message types- depends on the protocol (see below).

Higher level constructs are protocols

  • What are the roles?
  • What are the message types? - this is where the schema comes into play.
  • What state/sequencing rules apply?
  • How are trust and incentives managed?

Example of protocols:

  • Trust Ping (simple)
  • Forward
  • Connect
  • Introduce
  • Issue Credentials
  • Get Proof
  • ACK
  • Report a problem

Questions that arose:

Meeting at 9 pm EDT

  • Sze Wong - Land rights in Zambia
  • Jim Wowchuk
  • Vipin Bharathan -
  • Daniel Hardman - see above
  • Ajay Jadhav - Ayanworks - working on Indy & Iroha



Jim Wowchuk presented on the schemas. His point was that the adoption of a taxonomy that focuses on semantics of the fields would allow international interoperability.

He drew on some examples from passports (since these need to be internationalized), also from the Australian data regulation for governmental documents. Another example that can be cited is the Singapore MAS data.

These schemas would operate on the message types and data exchanged during credential issuance and verification.

Daniel repeated the mornings A2A (also called DiD communication) presentation slightly speeded up (see the morning session).

The A2A project will be carved out from Indy as a separate project (HL Aries) and possibly nurtured inside the IETF or W3C. IETF would be preferred.

To collaborate at IIW Daniel Hardman and Jim Wowchuk would talk about the relationship between the schemas and the (A2A) DID Communication project.

Have one or either of them present here about the IIW work at the next meeting May 1st.

  • No labels