owned this note
owned this note
Published
Linked with GitHub
# AFJ DIDComm V2
Thougts on implementing DidComm V2 in AFJ
## Notes from ACA-Py approach
See [this document](https://docs.google.com/document/d/1piGZ-0FW9DWEFRetviV1Vjxv7DDkIFQDWUs38VGqZ-Y/edit#) for notes about the implementation of DIDComm V2 for ACA-Py.
- Use same message class, but use a different serializer for v1 / v2
- Mechanically transform DidComm v1 messages to DidComm v2 messages
## DidComm v2 message
Each protocol can choose to extend either the `DidCommV1Message` or the `DidCommV2Message`. The `MessageSender` now accepts either of those, and can use different underlying code to handle the v1 and v2 messages. However, the shared didcomm methods allow common processing between the two.
```ts
interface DidCommMessage {
id: string
type: string
threadId: string
// ... other common didcomm methods and properties ... //
}
class DidCommV1Message implements DidCommMessage {
@Expose({ name: '@id' })
public id: string
@Expose({ name: '@type' })
public type: string
public get threadId() {
return this.thread.thid ?? this.id
}
}
class DidCommV2Message {
public id: string
public type: string
@Expose({ name: 'thid' })
public threadId: string
}
```
- Do we need to add a mechanical way to transform DidCommV1 to DidCommV2 format?
- Adds a lot of complexity -- Personally I'd like to define different implementation for V1 and V2
## V3 Issue Credential & Present Proof protocols
- Module (and public API) can stay exactly the same
- Move more shared logic to the module level from the service (auto-accept, state checks, etc...)
- Add a CredentialProtocolVersion and ProofProtocolVersion V3
- Add V3 messages, handlers and services (copy from V2 protocol -> transform to DIDComm v2 structure, so it can version seperately)
- Reuse the format services
- Messages are not stored in the credential and proof exchange records so we can reuse the same record types
- Minimal overhead to the user whether v1 or v2 or v3 is used (all same api)
- Extend `DidCommMessageRecord` to also support DidCommV2 messages
- It just stored Json so should be relatively simple
## DidCommV2 Envelope
- No support for DidCommV2 envelope yet
- Extend the wallet interface to support DidComm v2 envelopes in addition to DidComm v1 envelopes
- Working on adding Aries Askar
- Usability of SICPA didcomm js library for AFJ?
- Can't run Wasm natively in React Native
- Looking at adding a JSI interface to add a WASM interface for React Native
- Would make future additions to AFJ a lot easier as we automatically support Browser, RN, Node
- Will be a lot of work
## DidCommV2 Routing and Connections
- Already supports generic did resolver with support for `did:key`, `did:web`, `did:sov`, `did:peer`
- Working on generic did registrar with suport for `did:key`, `did:sov`, `did:peer`
- Extend connection record to store the supported didcomm profile? (ACA-Py)
- Includes both the
- Probably not needed, we can exract this from the did document
- Add support for OOB v2 protocol
- Just need to send and accept an invitation
- https://github.com/hyperledger/aries-agent-test-harness/blob/main/aries-test-harness/features/oob-v2.feature
- Create a connection record
- Set their did to did from invitation
- Generate peer did (or use already existing public did) for our did
- Can still use Oob V1 invitation with `didcomm/v2` accept
- Using didcomm v2
- Look at `accept` in oob invitation
- Look at `accept` in Did document services (if using public did for connection we can auto update by adding a didcomm v2 service, the other agent should then pick it up)
- Updating peer dids to add a service
- Is this possible in DidComm v1?
- ACA-Py call mentioned defining a decorator to update to new envelope
- Community Coordinated Update to migrate unqualified dids to qualified dids
- Can add a method to the message sender `sendMessageToDid` (in addition to `sendMessageToService` and `sendMessage`)
- How different is DidCommV2 routing compared to DidCommV1 routing?
- Add a DidCommV1Router and a DidCommV2Router?
- Handles the packing, routing, mediators, return routing etc... for a specific didcomm version
- Abstracted in the MessageSender, so the framework user
## DidComm v2 implementation (Jakub)
I briefly looked at didcomm-rust, and I don’t understand all the differences introduced by DIDComm v2. Still, it doesn’t have to be so difficult to re-implement missing parts of DIDComm v2 instead of adding and using the whole didcomm-rust library, assuming we’ll add support for aries-askar. AFJ’s `MessageReceiver` and `MessageSender` do have quite similar responsibilities as public methods of [didcomm-rust library](https://github.com/sicpa-dlab/didcomm-rust/blob/main/wasm/README.md). It can be possible to update AFJ's internal structure and allow to call `didcomm.sendMessage(message, toDid, fromDid)` from other parts of the framework (`MessageReceiver` and `MessageSender` would be part of `didcomm` - look at [re-architecture issue](https://github.com/hyperledger/aries-framework-javascript/discussions/722)). DIDComm module would encrypt the message based on DIDDocuments resolved from `toDid` and `fromDid`. I don’t know if it would be required to somehow modify internal `sendMessage` internal behavior from outside.