DIDComm V2 Interopathon

[TheTechmage]

ACA-Py currently supports the bare minimum of DIDComm V2 communication (we respond with a problem report). The DIF is hosting an Interop-a-thon for DIDComm V2 before the end of the year. We're working to implement the features to support DIDComm V2 before the interop occurs.

Goal/Theme: "DIDComm V2 Communication Basics" Must support:

• [ ] Connecting via did:peer:4
• [x] Connections via HTTPS
• [ ] Discover Features - 2.0
• [x] Trust Ping - 2.0
• [ ] Forward (Routing Protocol 2.0)
• [ ] Out-of-band - 2.0
• [x] Basic Message - 2.0

Bonus:

• [ ] Coordinate Mediation - 3.0
• [x] Empty messages - 1.0
• [ ] Pickup - 3.0 or 4.0 (if it's ready)
• [ ] Demonstration of DID rotation

[PatStLouis]

Can you expand on the Pickup - 3.0 or 4.0 protocol?

Is credential issuance/presentation on the roadmap?

[TheTechmage]

Can you expand on the Pickup - 3.0 or 4.0 protocol?

I copied the list from my email that was sent out. At present, https://github.com/decentralized-identity/didcomm.org/pull/110 has not been merged in as I believe we were still waiting on some comments or updates to be made.

Is credential issuance/presentation on the roadmap?

Not for the interopathon. The goal was to get people moved over and communicating via DIDComm V2 instead of V1. Implementing credential issuance/verification is way more work than what can be done in ~1 month's worth of time. Once we've achieved "basic communication", it should be more feasible to do something a bit more advanced.

Does this sound about right, @dbluhm?

[PatStLouis]

This makes sense to me and I agree. I was sort of wondering if the pickup protocol could be used as an intermediary way to offer a credential to be "picked up" at an endpoint. This is a fairly common pattern in education, where an application/vc resource is temporarily hosted at an endpoint for a holder to pickup.

But from reading the issue/pr this is more of a message-pickup and not an arbitrary resource.

[dbluhm]

Yep, interopathon goals are deliberately narrower than our overall ambitions. Support for more protocols will come.

[sonarqubecloud[bot]]

Quality Gate failed

Failed conditions
49.1% Coverage on New Code (required ≥ 80%)
37.4% Duplication on New Code (required ≤ 3%)
C Reliability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE