feat: use did:key flag

[genaris]

An initial step to support Aries RFC 0360 by adding an optional configuration flag useDidKeyInProtocols that will define how agent should format keys in protocols where keys are exchanged: 'naked' (base58) or did:key encoded.

This setting will be used unless the other party has already sent us keys (for instance, a Mediator sent us the routing key in a Mediation Grant message). In such case, their format will be used in subsequent messages for that protocol (e.g. KeyList Update). This is achieved by adding a specific metadata key UseDidKeysForProtocol to the related connection record, which intended to track the other party support of did:key in different RFCs.

Currently, only Coordinate Mediation (RFC 0211) uses this feature, but in further versions other protocols will use this metadata/settings key (such as Pickup V2 - RFC 0685).

For key reception, the agent will always accept both formats and internally store in base58.

[codecov-commenter]

Codecov Report

Merging #1029 (5fb4e86) into main (c789081) will increase coverage by 0.03%.
The diff coverage is 96.66%.

@@            Coverage Diff             @@
##             main    #1029      +/-   ##
==========================================
+ Coverage   88.66%   88.69%   +0.03%     
==========================================
  Files         520      521       +1     
  Lines       12099    12115      +16     
  Branches     1996     2001       +5     
==========================================
+ Hits        10727    10745      +18     
+ Misses       1310     1308       -2     
  Partials       62       62              

Impacted Files	Coverage Δ
...modules/connections/repository/ConnectionRecord.ts	95.65% <ø> (ø)
packages/core/src/types.ts	100.00% <ø> (ø)
...ules/routing/services/MediationRecipientService.ts	85.05% <93.33%> (+0.91%)	⬆️
packages/core/src/agent/AgentConfig.ts	85.71% <100.00%> (+0.42%)	⬆️
.../connections/repository/ConnectionMetadataTypes.ts	100.00% <100.00%> (ø)
packages/core/src/modules/dids/helpers.ts	95.65% <100.00%> (+0.41%)	⬆️
...c/modules/routing/messages/KeylistUpdateMessage.ts	100.00% <100.00%> (ø)
...s/routing/messages/KeylistUpdateResponseMessage.ts	100.00% <100.00%> (ø)
...re/src/modules/routing/services/MediatorService.ts	91.75% <100.00%> (+0.17%)	⬆️
.../modules/connections/services/ConnectionService.ts	87.80% <0.00%> (+0.81%)	⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[swcurran]

@andrewwhitehead -- heads up on this. We probably want to have ACA-Py doing the same thing.
@ianco, @shaangill025 -- heads up on this. We need some AATH tests that use this, with the ACME agent started with this option.
@genaris -- it would good to get this added to AATH so that compatibility with other Aries Frameworks can be verified.

[TimoGlastra]

Nice 👍

[TimoGlastra]

Specific reason for making this a key/value object instead of an array with string uri's?

[genaris]

The goal of this metadata key is to override agent settings, based on what we learn from the connection. So if our agent is set to always use did:key by default and we learn that the other side is not using it for a certain protocol, we'll set the key for that protocol to false.

And we could also have the opposite case: we don't use did:key but it happens that the other side is using them, so we set the key for that protocol to true. Also we might change our agent settings afterwards, and it will still take into account the metadata key for the given connection.

[TimoGlastra]

Makes sense. I thought we would only use it to say a protocol does support did:key, but there is also the case where we explicitly store a protocol doesn't store it.

Is this also updated autmoatically when this changes? E.g. we have stored false so we keep sending base58 keys, but then the other agent sends a did:key, do we update it automatically? Or is it set once and kept like this forever?

[genaris]

Is this also updated autmoatically when this changes? E.g. we have stored false so we keep sending base58 keys, but then the other agent sends a did:key, do we update it automatically? Or is it set once and kept like this forever?

I think it depends on each protocol/service but generally the best would be to update it automatically. As of current AFJ support for mediator role, it does not add so much value because we only support Mediation Grant and Keylist Update request/response. However, considering a future support of Keylist queries and responses it's better to handle it right from the start.

So I'm adding automatic handling for both recipient and mediator in the messages we currently support. Hopefully in 0.3.x we'll support all of them 😄

[TimoGlastra]

How does this work with minor version updates?

[genaris]

This is tied to a specific protocol major.minor version. If a new interaction is started with a newer protocol version, a new key/value will be added. Not super nice in terms of storage optimization, but I guess this will be mostly limited to specific connections (such as mediators), so should not represent a big issue 🤔

[TimoGlastra]

Ok, something to look out for. We maybe don't need to store it separtely per minor version (however if ACA-Py updated to mediator coordinator 1.1 and 1.0 already supported did:key I would assume the newer version also does).

[TimoGlastra]

Do we need a migration script to update non did keys?

[genaris]

No, actually it was supposed to be a fix for the case where we receive keys in did:key format and it made it worst 😝.

It should use didKeyToVerkey instead. I'll add a test to MediationRecipientService.test.ts to make sure it stores all keys in base58 and it behaves exactly as current wallets.

[TimoGlastra]

Ready to merge?