0.6 Release

[genaris]

A discussion to talk about the features we'd like to include in the 0.6.0 release.

Breaking Changes

• Move DIDComm out of core to separate @credo-ts/didcomm module #1796
• Move didcomm specific config options to DIDComm module #1762
• DIDComm v2 #1539
• Extract out of band invitation to DidCommMessageRecord (with addition of OOB v2 and DidComm v2)
• Use did:peer:4 by default in DID Exchange
• Wallet/Storage changes/fixes:
  • Wallet API discussion from 15th June 2023 meeting
  • Support pagination and offset when querying records #1007
  • Add option to query wallet key / check if a wallet key exists #1302
  • Askar does not sanitize wallet path based on wallet id #1670
  • Migrate from .afj data folder to .credo #1715
  • Better support for serverless architectures #1212

Non-breaking changes

TBD

For 0.7

TBD

[TimoGlastra]

Another one we'd like to work on: support disabling protocols/messages.

For e.g. Paradym we don't want to support credential proposals atm, we also don't want to allow receiving credential offers currently, only sending.

For the paradym wallet we want to disable basic messaging as they are now received but completely hidden.

[genaris]

That seems to be very useful! I think that removing didcomm from core (and making any protocol such as basic-messages, proofs, etc, a separate module) can help, but of course it does not add granularity in terms of messages. Maybe this could be a protocol module-specific setting? (e.g. in didcomm-credentials module we use a config parameter to determine the roles we want to support.

Another somehow related thing is about selective feature disclosure based on each connection setting: e.g. suppose I don't want to support basic-messages for a certain connection, so I don't return this feature when they ask me for it. This would be good to be done in a way that we also reject any incoming message for a given connection if we don't support it, but I imagine it can be complex to handle.

[TimoGlastra]

There's also a lot of OpenID4VC/HAIP/ARR stuff we're working on, but no strict timelines yet:

• hardware key support
• mDL
• High assurance interop profile
• openid4vc authorized flow
• x509 certificate support
• Toip trust registry v2
• SD-JWT toke status list
• wallet attestations

And probably a few more 😄

[genaris]

Nice! Lots of good stuff, we can think on prioritizing them and also classify them in terms of complexity

[TimoGlastra]

One more we'd like to work on (and is probably a good one to combine with the extraction of DIDComm out of core) is dynamic messaging. So send / receive messages for which no protocol handler is registered.

Could be solved by middleware, or we can have a dedicated API for it

[genaris]

The middleware concept, already mentioned in the early days of AFJ, is something I would like to revisit, since it can be useful for things like this and many others. For instance we can easily hook into it to add some specific metadata to both inbound and outbound messages (e.g. creation date or a flow_id or any custom field we want depending on our specific needs), and also we can use to prevent duplicated messages (by inspecting message id and returning in such a way that agent will stop processing).

[genaris]

Finally, this has been addressed in #1896 and part of 0.5.5 release.