DIDComm V2 integration

[Artemkaaas]

Plan

The related work was already started in the PR but the branch got significantly outdated due to AFJ architecture changes and there are tons of the conflicts which may be difficult to resolve. Also there was architecture concern regarding the provided implementation.

Now we have time and intention to resume and complete the contribution but before the resuming we need to answer important questions and decide on the approach: Q1: Whether DIDComm V2 must be an independent module or it can be integrated directly into the wallet module? Q2: Do we really need DIDComm implementation plug-ability for the wallet? Q3: Do we DIDComm V2 support for Indy wallet?

About DIDComm V1 implementation

• DIDComm V1 implemented directly in the wallet implementation
• Pack/Unpack is part of the Wallet interface
• There is no option to override DIDComm V1 implementation

Putting DIDComm V2 library (Sicpa) directly into the wallet

• In fact, SICPA uses Aries Askar under the hood (crypto functions), so logically it is not bad idea to put Sicpa's library into Askar wallet
  • Should we mark Indy wallet as not supporting DIDComm V2 or should we support it?
• Sicpa's DIDComm library does some usefully stuff internally (like finding appropriate encryption/decryption keys based on used DID's of sender and receiver and building JWE/JWS structure, wrapping into Forward message). So we do not need to implement it in the AFJ wallet (what we currently do for DIDComm V1)
• Sicpa's interface requires implementation of interfaces for DID Document resolving and secret key resolving
  • DID-resolver currently is implemented inside the core package. There will be circular dependency between core and wallet as DID-resolver depends on the wallet. Is it issue?.
    • Askar already resolves dependencies registered in the core, but they do not depend on the wallet.
    • If we need to resolve this circular dependency we can:
      • O1: Extract DID-resolving into independent package?
      • O2: Change the interface of Sicpa's DIDComm library to accept key ids instead of DID's and resolve them on the AFJ layer. (BUT we also have to move resolving out of the wallet what seems wrong)
      • O3: Put DID resolver into Wallet? So it will be part of the wallet interface.
      • O4: Split wallet into storage and crypto? So DidResolver will depend on storage.
  • Secrets resolver: There is no issue with implementation of secret resolver if this approach is selected.
  • Method to retrieve secret key will be public within the wallet module but not exported through the public API.
• Ability to inject another implementation - Sicpa will be default implementation, and we can provide an ability to override it by injecting another service ba a symbol in the container if needed.
  • Can be done separately as the enxt step once the general implementation is done

Putting DIDComm V2 (Sicpa) library into independent package and make Wallet pluggable?

• SICPA library is badly applicable for this architecture because we need to expose method for getting of private key from the Wallet.
  • In order to use SICPA's library for this architecture we can change/add the interface to accept already resolved private/public key bytes instead of the resolver functions.
    • It means cutting (duplicating in AFJ wallet) big chunk of useful functionality regarding finding proper keys for DID's.
• DIDComm V2 injection ability is assumed by default. So we can use different implementations of DIDComm V2 messaging libraries.
  • Do we need similarly extract DIDComm V1 messaging?

Desicion?

Will updated this section with selected path.

Simplest developing path from our perspective: Step 1. Put Sicpa DIDComm service into Askar wallet + Mark Indy wallet as not supporting DIDComm V2 + Keer DID-Resolver as is if it's posible. Step 2. Make Sicpa's implementation using as default + Add ability to inject another implementation.

[TimoGlastra]

Hey @Artemkaaas. This is great, do you have time tomorrow to discuss this at the AFJ working group call? I'll make sure it gets discussed either way, and will provide the feedback from the call here if you can't make it

[TimoGlastra]

• option 1: implement didcomm library in wallet
• option 2: modify didcomm library to allow callback for signing/encrypting so we don't have to expose the private keys outside of the wallet, but the didcomm layer can be built on top of the wallet. implement crypto using Askar.
  • how feasible is this?
  • issue with sicpa design is that the key isn't freed / removed after usage, so it's dependant on JS garbage collection
• option 3: do not use didcomm library, implement crypto using Askar and didcomm logic in AFJ itself (based on the current didcomm v1 implementation)
  • berend has started with a crypto independant DIDComm v2 library, maybe we can use some parts from it
  • we can look at the ACA-Py
  • are there other didcomm v2 TS libraries out there?

custom didcomm v2 implementation with askar in ACA-Py: https://github.com/hyperledger/aries-cloudagent-python/blob/964f2c48e825b7bfceffe5bf8914a18314180b1b/aries_cloudagent/askar/didcomm/v2.py#L4

Questions:

• will it be a separate package (dependant on the broader discussion)

[Artemkaaas]

Agree. Option 3 looks like the best choice.
Askar JS packages expose all needed crypto methods. I will work on implementation using this option.

[swcurran]

FYI @andrewwhitehead on this discussion.

[swcurran]

Any updates on DIDComm V2 in Credo? Is there any movement towards that?

FYI @dbluhm -- notably the PR that was started.

[TimoGlastra]

We're 90% there i think so we should be able to get this wrapped up quite quickly. If someone wants to champion it, i'm happy to assist with merging and reviews (but we won't have time in the near future to complete the work)

[dbluhm]

@TimoGlastra I'd like to point out this library that we have been using at Indicio and plan to use in the ACA-Py DIDComm v2 implementation: https://github.com/Indicio-tech/didcomm-messaging-python/blob/main/didcomm_messaging/crypto/backend/askar.py

This implementation was based on the v2 code in ACA-Py you linked to but we corrected bugs and interop issues that were present in that original code.