Define how to align did:peer usage for DID Exchange with Aries RFCs and AFJ

[swcurran]

We want ACA-Py to work seemlessly in the use of DIDs with AFJ. The following adjustments to ACA-Py have been noted in accomplishing this. This issue will be used to track the overall issues and a design for moving forward. Existing and new issues in ACA-Py will be used to track specific activities once the design has been developed. The following notes come from a meeting held with @andrewwhitehead @shaangill025 @ianco and @swcurran about this task (2023.03.03).

A background activity to this work is an effort by the Aries Working Group to eliminate unqualified Peer DIDs that are currently used in Aries implementations. The ACA-Py community is participating in that discussion and will work to implement the decisions that come out of that effort.

For DID Exchange, AFJ supports did:peer method 1. Since the did:peer specification lacks precise details on Method 1, the AFJ implementation will be taken as the definitive implementation, including the use of the test vectors within AFJ. A document (HackMD or just a comment on this issue) should be added to summarize the details of the implementation. We will then consider submitting a PR to update the did:peer specification.

Notes about this:

• It has been suggested to implement the mechanism directly in Python vs. using the existing SICPA library.
• A review of the Aries Go implementation should be made to try to see what they are doing.
• The Indy-SDK library may not support setting the identifier part of the DID to the desired value. That is, the Indy-SDK may set the identifier part of the DID automatically, without input from the caller. If that is the case, we may do this implementation for Askar only, and not support it with the Indy-SDK. @andrewwhitehead to investigate and report back.
  • Assume there will not be a release of the Indy-SDK to support this, so please raise a flag if it will not be possible to support using the existing Indy-SDK.
• Ideally, the implementation will support receiving, and in response, generating existing format unqualified DIDs in establishing a connection. If including such a capability wil over-complicate the code, this requirement MAY be dropped. As you review the code and plan the implementation, please raise a flag if you think it worth recommending or discussing if we keep or remove this requirement.
• For DID Exchange, the default option should be to support initiating connections with the new did:peer method 1 DIDs. If unqualified DIDs do continue to be supported, a flag can be added to default to initiating new connections with unqualified DIDs.
• For existing 0160 Connections protocol, the existing functionality should be continued to be support. Again, raise a flag if this is deemed to be overly complicated.
• Based on a current conversation in the Aries Working Group, we may be asked to update existing connections from using unqualified DIDs to qualified DIDs of some form. We’ll wait until how that update is to occur before deciding how to proceed.
• In implementing this, care should be taken to review the DIDComm service endpoint JSON to make sure that it aligns with AFJ (most importantly), but also to the DID Peer specification (in case AFJ is not aligned). Notably, look at the mime type, the service type and the use of did:key in the routingKeys item.

The plan is for @shaangill025 to create the document for this and for others in the community to review.

[shaangill025]

First draft design document outlining high level ACA-Py changes needed for this implemented. https://hackmd.io/@gbeoESqjRxm7oQacVc_3OQ/SylWqdwkn/edit

[swcurran]

A new direction on this issue. Per the presentation and recording from today’s ACA-Pug meeting, we want to look at updating PR #2174 to replace (or supplement?) Peer DID 1 with Peer DID 2/3 support.

As per the presentation/recording:

• Review the HackMD (previous comment — https://hackmd.io/@gbeoESqjRxm7oQacVc_3OQ/SylWqdwkn/edit) and PR #2174.
• Have a mechanism that triggers the use of Peer DID 2/3 instead of the current unqualified DIDs. This is likely already in #2174, but might need to be updated if it is Peer DID 1 specific.
• Replace (or if you think we should…supplement) Peer DID 1 support with Peer DID 2 support on creation.

In the interest of keeping the PRs smaller, we can stop here with this issue and have a separate issue for dealing with the addition of the use of Peer DID 3. However, we will do the issues/PRs together in a single release.

[swcurran]

Approach is now defined as:

• support did:peer:1, aligned with the AFJ implementation #2611
• support did:peer:2 -- emitting and receiving #2578
• support did:peer:4 -- parallel to did:peer:2 support #2640
• support did-rotate RFC #2494

Closing this issue as the definition part is completed, and the doing is defined elsewhere.