Aries DIDCommV2 Working Group 2023-04-10 meeting

Apr 10, 2023 (6AM Los Angeles, 9AM New York, 2PM London, 3PM CET, 17H Moscow)

• @Lance Byrd (RootsID) <lance.byrd@rootsid.com>

• @Björn Sandmann (Blocktrust) <sandmann@blocktrust.dev>

• @Rodolfo Miranda (RootsID)<rodolfo.miranda@rootsid.com>

• @bruce_conrad@byu.edu (Pico Labs) <bruce_conrad@byu.edu>

• @Alex Andrei (RootsID)<alex.andrei@rootsid.com>

• @Alexandra Walker (Indicio PBC) <alex.walker@indicio.tech>

Release Status and Work Updates

• Aries WG

  • Presented a comparison of did:keri (lite) and did:peer (algo2... algo1 is used in AFJ)

  • Need to do pros/cons spreadsheet comparing the priorities/reqs/community needs

• Aries Agent Test Harness (https://aries-interop.info)

• Aries Askar secure storage - https://github.com/bcgov/aries-askar

• Frameworks:

  • Aries-CloudAgent-Python (https://github.com/hyperledger/aries-cloudagent-python, Meetings: ACA-Pug Meetings)

    • Encryption envelope (Askar impl) not fully-developed yet. We could use different libraries (SICPA Rust). SICPA DIDComm impl is what will be used... resolves did peers natively. The keys will have to be transported out of Askar, but that is acceptable for now. SICPA is the most widely used.

      • SICPA for DIDComm and did:peer https://github.com/sicpa-dlab/didcomm-python

      • No near-term Askar support for the DIDComm v2 encryption envelope and core protocols.

    • Protocols related to credential exchange and connection establishment. Distinguish between DIDComm v1 and v2. DID Exchange will be adapted.  The main focus is on Out-of-Band protocol.

    • Very important to extend the AATH.

  • Aries-Framework-JavaScript (https://github.com/hyperledger/aries-framework-javascript, Meetings: Framework JS Meetings)

    • https://github.com/hyperledger/aries-framework-javascript/pull/1096#issuecomment-1343833016

    • https://github.com/hyperledger/aries-framework-javascript/pull/1211

    • Issue related to multi-base from SICPA for DID peer

  • Picos as Aries agents (DIDComm v1: https://github.com/Picolab/aries-cloudagent-pico ; DIDComm v2 work in progress)

    • students have returned and they are using SICPA for envelope encryption, pack/unpack and hopeful sending messages

    • DIF Picos working group, useful for IoT devices.

    • Rich API and Internet connected to be a capable L2 agent.

    • Using Trinsic as VC as a service.

  • Swift Framework

  • Veramo Framework

    • WACI support https://github.com/uport-project/veramo/issues/1106

    • DID Peer support https://github.com/uport-project/veramo/issues/1105

      • Using Brian's (AviaryTech) DID Peer impl, adapting it as a plugin

        • PR submitted and in review https://github.com/roots-id/didpeer-plugin

    • Merged Mediation, agent can mediate. A Veramo mediator will be published soon.

• Mobile:

  • Aries Mobile Agent React Native, aka Aries Bifold (https://github.com/hyperledger/aries-mobile-agent-react-native, Meetings: Aries Bifold User Group Meetings)

• aries-mediator-service – a DIDComm Mediator in a Box

  • working on Pickup support

  • DIDComm v2 support would probably originate from this meeting/community

• AviaryTech DIDComm TS impl

  • https://github.com/aviarytech/didcomm

  • https://github.com/aviarytech/did-peer

  • Focused on OIDC lately

• KERI Working Group

  • Alternative to peer DID.  More refinements to the proposal. Then present it to the Aries groups.  Similar to Algo2 of the peer DID.

    • KERI parameter on the DID in order to get the document. Public encryption key and serviceEndpoint.

    • Query param w/ base 64 path that you can decode

      • encryption keys, service endpoint, etc.

      • Compared to did:peer, the keri long form is longer

        • inception event only

        • But follow-on messages only need to use the short-form of KERI DID

      • So, this is not a Persistent did

    • @Rodolfo Miranda Will add a README and sample output.

• ToIP Trust Spanning Protocol

  • Good back and forth between Sam, Daniel, and others https://github.com/trustoverip/trust-spanning-protocol/discussions/17

  • Daniel present his proposal this week, at the Wednesday TSPTF

  • Sam joins the task force and has a video of Sam's that diagrams his TSP vision https://zoom.us/rec/play/1EcHtXeGPPynwwBvU3X4uAAw0xhFPC3CwwAIXwQ-P_E6tPlzvBskHuzTYftS1ZrmjPw5EiBZWYwiTgdI.tx021j9JATi2l5Xq?continueMode=true&_x_zm_rtaid=noVlj_2fRpuccKG26Jmytw.1675686252575.5cf45b925f44c52d0118a3fdef8541ea&_x_zm_rhtaid=714

April 2023 IIW is coming and a bunch of us will be there! Lets start stitching together as many DIDComm v2 agents, services, mediators as possible in preparation

• https://hackmd.io/j6U6JpQ2SRexSUKL7i2XRg

From our last meeting:

Nessus Demo

• Amazing progress by @Thomas Diesler on his client showing an airport scenario with multi-tenant, multi-credential presentation for travel with a minor

• 2023 04 03 Aries DIDComm V2 User Group Meeting.txt

• OOB with a 'public' did document that anyone can use. Chicken and the egg for Root-of-trust.

  • Start with a trust ping.

  • Request a credential? For extra validation.

• SICPA did peer Java PRs have brought it to usable place 

• Demo in two weeks

  • OPA verification policies

  • W3C JSON-LD and JWT

    • We will check with @Alex Andrei to see if we can accept an issued credential from @Thomas Diesler 

  • Technology Compatibility Kit (TCK) in java provides compliance for J2EE, similar concept to AIP

    • This is a large market for licensing in the java world

    • DIDComm could have a similar

  • Reference implementation

    • First or most complete Agent that passes the TCK

  • Can DIF own the TCK?

    • Create a test harness similar to what Fabio Pinheiro is asking for in DIDComm v2

• IBM w/ DIF?

• How can we get the word out?j

  • @Lance Byrd posted on Discord https://discord.com/channels/905194001349627914/1032736844053483621/1082338707597697055

• Receive a credential over OIDC (OIDC4VC) and present proof with DIDComm

  • Who in the OIDC to connect with? Also, connect with Sam. Ask Drummond.

  • Walt.id supports OIDC 

• Which agents might participate:

  • AFJ

    • @Ariel Gentile 

    • Animo

  • Veramo

    • Nick

    • Cody

  • BlockTrust

    • @Björn Sandmann 

  • AviaryTech

    • @Brian Richter 

  • Indicio

    • @Alexandra Walker @Sam Curren @Char Howland @Mike Ebert 

  • PicoAgents

    • @bruce_conrad@byu.edu

  • RootsID

    • RootsWallet

  • Atala Prism

    • @Alex Andrei @Rodolfo Miranda 

    • Anyone from Atala team attending?

  • Nessus

    • @Thomas Diesler might be a recording

• What protocols do we want to highlight/use

  • Basic Message

  • Trust Ping

  • Mediation

  • Issue Credential

    • This is more complex, which format, etc.

  • Verification

  • Schema Validation

• Pre-record video showing the interop between them

  • For the session it needs to be very scripted so that everyone is successful

    • Group chat? New protocol, maybe in Fall IIW?

• Veramo agent as a test harness for DIDComm?

• BlockTrust is implementing mediator, etc and will be at IIW

  • No usable .NET lib, had to write it from scratch

    • Crypto is especially challenging

  • Reference implementations help a lot

    • SICPA libs continue to gain adoption and are nice for reference

Interop Profile

• AIP3 hackmd table created to compare did peer/keri/key/ etc. pros/cons/needs

  • https://hackmd.io/_Kkl9ClTRBu8W4UmZVGdUQ?both

• Initial contact through OOB

  • DID Doc should contain the endpoint which should establish the connection

DWN & KERI & DIDComm comparison

• https://hackmd.io/S7RczUDxQgyHxWKBmBVW_A

DIDComm short DIDs

• Agents can cache DIDs to know if they have resolved the long-form, etc. This cache needs to be well protected or the conversation is lost.

• DIDComm provides a way to rotate Ephemeral DIDs, specifying a new DID (even from a different DID method).

• Ecosystem of DIDCommV2 Services or local agents

  • One other DCV2 agent required to work on true interop

  • Plus one agent agnostic Technology Compatibility Kit (TCK)

  • Nessus-tech domain service

  
  
  

• Nessus

  • Nessus DIDComm 23.2.0 First Release

    • Wallet abstraction for AcaPy + Nessus native

    • Camel Http Endpoint for Nessus agent

    • Support for RFC0434 Out-of-Band Invitation V1 & V2

    • Support for RFC0023 Did Exchange V1

    • Support for RFC0048 Trust Ping V1 & V2

    • Support for RFC0095 Basic Message V1 & V2

    • CLI to work with supported protocols and model 

    • Uses SICPA and Walt.id

      • Recently accepted PR with SICPA

    • Will eventually be wrapped in a Camel component, enabling Camel endpoints to support DIDCommV2

      • open the doors for adoption from the Camel enterprises

• DIDComm v1 vs v2

  • https://didcomm.org/book/v2/whatsnew

    • simple explanation of the benefits of upgrading

  • DIDComm v1 is tightly coupled to the Aries RFCs (encryption envelope) and v2 introduces some simplicity in terms of connections

  AIP3

  • HackMD from the last Aires WG meeting, regarding AIP 3.0 

  • Should we specify how the did methods (like did peer) are used?

    • We are focused on DIDComm v2 communication but does the rest of the AIP community know that?

    • WACI issuance

      • Do you need to be able to resolve indy, cheqd, etc. in order to issue credential

  • Discussed sub-roles https://raw.githubusercontent.com/hyperledger/aries-rfcs/main/features/0453-issue-credential-v2/credential-issuance.png

  Aries Agent Test Harness

  • What did methods are supported? And how do you configure to use did indy, orb, etc.

  • What is the priority of tests to create that will eventually be AIP3 tagged tests?

  • How is mediation tested?

    • With the mediation role (what is the name like bob, alice, faber, etc) and show you support the mediation features.

  • Current DIDComm-V2 specific tests:

    DIDComm-V2 tests

    aries-agent-test-harness % ./manage tests --tags @DIDComm-V2 Selecting: ['@DIDComm-V2'] Feature: WACI Issuance @T001-IssueCredentialV3 @DIDComm-V2 - WACI issuance flow Feature: DIDComm V2 Establishing Connections @T001-OobV2 @DIDComm-V2 - Establish a connection between two agents using DIDComm V2 Feature: Aries agent present proof v3 @T001-PresentProofV3 @DIDComm-V2 - Present Proof of specific types and proof is acknowledged with a Citizenship credential type with a DID Exchange Connection

  • New tag in AATH that are not credential related, maybe:

    • DIDCommV2_Peer

    • DIDCommV2_Simple

    • Didcommv2_base

    • Didcommv2_layer2

  • See https://github.com/tdiesler/aries-agent-test-harness/tree/camel/aries-backchannels/camel#aip-10-status

  Grand Unified Theory (GUT) Alliance

  • There is a warning about did peer on the spec now https://identity.foundation/peer-did-method-spec/

  • https://daniel-hardman.medium.com/sentries-confessionals-vaults-and-envelopes-4a58cf4f8a5a

  • original did keri impl https://github.com/WebOfTrust/ietf-did-keri

    • Needs to transition to a did keri lite (subset of did keri)

    • Signify is a typescript impl that might serve as the the keri lite impl

  • Newer than even AIP3.0. KERI and DIDComm v3.0 (likely)

  • Link to Daniel’s GUT presentation:

• Apache Camel: https://camel.apache.org/ and we discussed Daniel Hardman's presentation to W3C that talks about classic API/Swagger Endpoints vs. a DIDComm connected ecosystem https://youtu.be/TBxWgNmsnvU

• Our current spreadsheet https://docs.google.com/spreadsheets/d/15noWiG_zhhUpornhrZm9cLEjQ1aa6z9qgJgPCaaIbtY/edit?usp=sharing

• AIP3

  • HackMD from the last Aires WG meeting, regarding AIP 3.0 

  • Great document by Hakan, looking at past AIP definitions and beginning to consider AIP3 definition 

  • Connectionless DIDComm v2 still needs management of the 'connection' between agents.  How should agents handle this?

    • Is this worth detailing/discussing or is it just agent specific?

    • OOB/handshake/discovery RFP for Aries agents?
      
      

      • WACI and what the overlap and distinction would be between the AIP and WACI.

        • There is some nuance to cred formats you have to support (Indy, BBS+, LD).  

        • Can we use Discovery protocol to understand the level of WACI support?

          • perhaps we need more detailed information from the discovery protocol

          • per application protocol supported (formats, messages, crypto).

          • Some WACI information to consider https://identity.foundation/waci-presentation-exchange/#format-property.

      • Encryption envelope selection

• @bruce_conrad@byu.edu is working with students to implement DIDComm v2 in their Pico environment.  Might benefit from JFF work

• DIDComm v2 agent discoverability/interop

  • https://identity.foundation/didcomm-messaging/spec/v2.0/#iana-media-types

  • https://identity.foundation/didcomm-messaging/spec/v2.0/#discover-features-protocol-20

• Documentation in terms of Trust Over IP (ToIP) tech stack?

  • https://trustoverip.org/toip-model/

  • Find Drummond's DIDComm v2 stack https://trustoverip.org/toip-model/

  • https://trustoverip.org/wp-content/uploads/ToIP-Technical-Architecture-Specification-V1.0-PR1-2022-11-14.pdf

  • https://github.com/trustoverip/TechArch/blob/main/spec.md

• ACA-PUG

  • Libraries for message envelope (Askar, Python impl, Rust impl)

https://youtu.be/M5f3EYBdBRM