aries-cloudagent-python
aries-cloudagent-python copied to clipboard
hyperledger
RFC 0211 Compliance: Use did:key for recipient keys
According to RFC 0211, recipient keys included in the various messages of the Coordinate Mediation protocol should be represented as did:keys. Currently ACA-Py uses raw Base58 encodings of the Ed25519 keys.
We should update our Coordinate Mediation protocol implementation to use did:key representations for all recipient keys, bringing us in line with the RFC. If possible, perhaps we should attempt to still process "raw" Base58 encoded keys to relieve some of the pains of breaking changes?
cc @swcurran
@andrewwhitehead is also going to be looking at this, but @frostyfrog should go ahead. @andrewwhitehead has been out of the office for a bit recently.
Heads up @JamesKEbert and @TimoGlastra. Thoughts on how we can ease this transition for Bifold/AFJ?
I think supporting both raw base58 keys and did:key is probably the way to go. If ACA-Py supports both, we're not really impacted on AFJ's side. It'll probably be best to wait for a release of ACA-Py that supports the new key format. Then we can look at updating AFJ. Thoughts?
I'd agree, I think my biggest concern will be with existing mediator deployments that don't use did:key yet--so if we can ensure backwards compatibility then I agree with Timo that upgrading AFJ/Bifold to use did:key then will be decently straightforward. Does that represent major headaches on the ACA-Py side?
I think the tricky piece is the format of the keys sent by the mediator in a mediation grant message. We can easily accommodate receiving a recipient key in either format but we'd have to have a CLI arg or something to determine which format the mediator should send out.
Hmm--I think that having a cli argument or just changing to use did:key & considering it as a breaking change would be appropriate. This would require that the AFJ/Bifold agents would need to update to support the different routing key format prior to updating the mediator, but that seems do-able. I lean towards making this a breaking change in ACA-Py to ensure that it's clear that this needs to be updated (rather than having it be a problem dragging on for a while with the use of an optional cli arg).
Agree with James here. The non did:key variant was form before the RFC was finalized. It should have probably been a breaking change.
I hadn't considered the mediation grant message. In that case we should probably first update AFJ to support receiving both, an then we can update ACA-Py to send out the new format.
A bit like the community coordinated update process (which have been terrible in it's execution for the ones we had). Breaking changes seem to die hard
Since this is only about mediation, perhaps we formalize this in the aries-mediator-service. Tag and release the 1.0 using the existing, and tag and release 2.0 with `did:key...". That will hopefully lead to more formalization in the handling of the aries-mediator-service repo -- tags and built artifacts.
Made the update to support receiving did:key dids in RFC 0211 in AFJ: https://github.com/hyperledger/aries-framework-javascript/pull/950. I think we can get this into the 0.2.2 release
Since this is only about mediation, perhaps we formalize this in the aries-mediator-service. Tag and release the 1.0 using the existing, and tag and release 2.0 with `did:key...". That will hopefully lead to more formalization in the handling of the aries-mediator-service repo -- tags and built artifacts.
My only thought would be that we would want to really push and make sure it's clear that people should be using the aries-mediator-service rather than ACA-Py directly for mediation (as I don't want to break people's mediators that aren't using aries-mediator-service, if that makes sense).
But, I think that could definitely be a good route for formalizing the handling.
AFJ 0.2.2 has now been released which includes support for this. So should be good to go on ACA-Py's side.
@frostyfrog -- are you working on this (as alluded to by Others above 😄 ), or is this still up for grabs? Thanks.
This is still assigned to me internally by @dbluhm, I just had another task come up last week which took priority at the time. Wrapping up that work this morning, after which I plan to focus on this task again.
