Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DIDComm V2 Interopathon #3329

Draft
wants to merge 27 commits into
base: main
Choose a base branch
from

Conversation

TheTechmage
Copy link
Contributor

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
  • Connections via HTTPS
  • Discover Features - 2.0
  • Trust Ping - 2.0
  • Forward (Routing Protocol 2.0)
  • Out-of-band - 2.0
  • Basic Message - 2.0

Bonus:

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

mepeltier and others added 7 commits November 1, 2024 11:03
Signed-off-by: Colton Wolkins (Laptop) <[email protected]>
Signed-off-by: Colton Wolkins (Laptop) <[email protected]>
Signed-off-by: Colton Wolkins (Laptop) <[email protected]>
Signed-off-by: Colton Wolkins (Laptop) <[email protected]>
@PatStLouis
Copy link
Contributor

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

Is credential issuance/presentation on the roadmap?

@TheTechmage
Copy link
Contributor Author

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, decentralized-identity/didcomm.org#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
Copy link
Contributor

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
Copy link
Contributor

dbluhm commented Nov 6, 2024

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

Signed-off-by: Colton Wolkins (Laptop) <[email protected]>
Signed-off-by: Colton Wolkins (Laptop) <[email protected]>
Signed-off-by: Colton Wolkins (Laptop) <[email protected]>
- Respond to the target list via did resolution
- Fix response to incoming messages (hack it till it works)

Signed-off-by: Colton Wolkins (Laptop) <[email protected]>
Signed-off-by: Colton Wolkins (Laptop) <[email protected]>
Signed-off-by: Colton Wolkins (Laptop) <[email protected]>
Signed-off-by: Colton Wolkins (Laptop) <[email protected]>
Signed-off-by: Colton Wolkins (Laptop) <[email protected]>
The complexity of a single protocol for DIDComm V2 was a bit much, and
adding more protocols would cause unnecessary copy-pasting of
boilerplate code that could otherwise be pulled out into their own
function.

For the time being, I'm planning to include all protocols for the
DIDComm V2 Interop within the same protocol plugin (and the same file).
In the future, I plan to break this logic out of this file and into
their own respective files. I also had a discussion with @dbluhm today
about future plans for retrieving our DID for DIDComm V2, as the current
implementation is very fragile and requires that, not only is a DID of
the appropriate type already created, but that we grab the latest one.
For a production system, this is unnacceptable. But for a "cobbled
together POC" for the interop? It should be fine. Especially considering
that we have plans to change how this all works in the future.

Signed-off-by: Colton Wolkins (Laptop) <[email protected]>
Signed-off-by: Colton Wolkins (Laptop) <[email protected]>
Signed-off-by: Colton Wolkins (Laptop) <[email protected]>
Signed-off-by: Colton Wolkins (Laptop) <[email protected]>
Signed-off-by: Colton Wolkins (Laptop) <[email protected]>
Signed-off-by: Colton Wolkins (Laptop) <[email protected]>
Signed-off-by: Colton Wolkins (Laptop) <[email protected]>
Signed-off-by: Colton Wolkins (Laptop) <[email protected]>
Signed-off-by: Colton Wolkins (Laptop) <[email protected]>
Signed-off-by: Colton Wolkins (Laptop) <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants