Investigate, debate and add support for Peer DID 3 to ACA-Py

[swcurran]

A follow up to issue #2156 — for high level details see the presentation and recording from today’s ACA-Pug meeting. Also relevant is the Peer DID Method Specification, where DID Peer 3 is defined.

In this ticket, we want to add support for did:peer:3 to ACA-Py such that when a DID initially created as a did:peer:2 is used for messaging, did:peer:3 is used in its place. I think (not certain) that only the peer of the other party would ever use this — I don’t think the creator of the DID ever references itself in a presentation.

The issue of two DIDs (the 2 and 3 forms) needs to be “handled” in the connection record and possibly the DID record. Perhaps “their_did” should always be the did:peer:3 whenever a DID Peer 2 is created? Or perhaps there needs to be the idea of a synonym DID so that multiple identifiers can be used for a single DID. That might be needed for the transition of unqualified DIDs to qualified ones, where we would like to use did:peer:3.

[Jsyro]

Existing work for Peer:did:1 to be repurposed for this new requirement.

#2174

[Jsyro]

Update: I have taken the branch related to #2174, resolved a few outstanding issues, and am now developing some unit tests to explore his existing work. Will be working to create tests that represent the spec for peer:did:2.

[Jsyro]

ok, been reading lots. Couple of question @swcurran

This describes the did exchange itself (how to serialize and encode the document). https://identity.foundation/peer-did-method-spec/#multi-key-creation
For each of those 'purposecodes' there is a corresponding b64encoded json payload, we are focused on 'Method 2' here

I'm trying to figure out what the spec actually says about those payloads?
Do we need to support all of those purpose codes right away?
How many of these json objects might be in used by aca-py already? (e.g. Do we need to define all of these classes, or just the way they are packaged/exchanged?

[swcurran]

Regards the purposecodes. I think we need code that given a DIDDoc will encode it into a did:peer:2, and given a did:peer:2 will decode it into a DIDDoc. As such, for purity, all purpose codes should be supported. In practice with Aries, there will only be a V verification key, as where we are will be using this, the DIDDoc will contain only a single Verification key. Depending on what key types we will be using, an E encryption/key agreement key may also be needed.

I’d say start with the DIDDoc we have today for peer DIDs, support that in a relatively generic way. That will uncover some other questions — like how far down the multibase encoded, multicodec-encoded rabbit hole we should go. Is there a library that we could depend on to provide that? It would be worth looking at how we are handling did:key in ACA-Py (and perhaps AFJ).

For other than V and E, we could add an error that the purposecode is not supported — and others could add such support when we know it is needed.

Why V for sure and only “perhaps E”? An Ed25519 Verification key can be converted determininstically into an x22519 key agreement key. As such, the unqualified Peer DIDs we create generally only have a verification key. However, not all key types support such a transformation, and many in the Aries community do not like to use the same key for multiple purposes. In those cases, there will be both a V and an E key in a peer:did:2 to be encoded/decoded.

@dbluhm @andrewwhitehead @TimoGlastra @ashcherbakov — any comments on this? Any existing code we should be using?

[swcurran]

@Jsyro — I was pointed to this repository within SICPA — https://github.com/sicpa-dlab/peer-did-python. You should definitely be looking at this. It will likely have most/all of what you need for peer:did:2 and likely we’re better off putting peer:did:3 into that repo, and using it in ACA-Py.

[ashcherbakov]

Agree, it makes sense to use https://github.com/sicpa-dlab/peer-did-python. It doesn't have peer:did:3 support, but it's not so hard to add it there.

[Jsyro]

I have been able to resolve did:peer:2's into the full did doc and generate the did from the document, with examples to work from.
This issue appears to be rooted in the examples on the spec website having possible issues (b64 padding and a mismatched encryption key).

[swcurran]

The library should be able to deal with padding — which is always a pain.

Does the library also have did:peer:1 support? I notice that currently AFJ is using did:peer:1, so perhaps we do have to support that as well. Or we push on AFJ to move quickly to did:peer:2/3 support ASAP and skip the did:peer:1 stage.

[Jsyro]

It does not appear to have did:peer:1 support. @andrewwhitehead ?

[Jsyro]

Interesting Curveball, the spec actually provides a regex for identifying dids.... which allows for = signs.

https://identity.foundation/peer-did-method-spec/index.html#matching-regex

Should I open an issue on the spec? or in the sicpa library? or both? @swcurran @andrewwhitehead

[andrewwhitehead]

Method 1 support is a draft PR: sicpa-dlab/peer-did-python#46

[swcurran]

Fascinating….my $0.02CDN (which is worth exactly that) would be to try the regex in the spec in the implementation and see if the tests pass (and add some more…). If it works, I’d say go with it….

But don’t listen to me.

[Jsyro]

DID Spec conflict has been resolved here.

Focused on constructing did:peer:2 from existing connection information.