Closed swcurran closed 4 years ago
Hi @swcurran , have you been able to make any progress on this issue? We're interested in extending ACA-Py to support any did method resolution and this commit work would be a good place to start. Well, actually, we're also interested in did:https
, but we can make it the right way from the very beginning (meaning to be able to add any did method support).
I'm working on this issue this week
@blelump -- This issue is not about did resolution, so I don't think it will help with what you are after. This issue aside, we are interested in what you are proposing.
@swcurran , thanks for response. Introducing did:https
wouldn't enforce a significant changes to the implementation that would open a possibility for any did resolution?
My mistake. I'm verifying that we support receipt of message types on the new prefix, and emitting messages by default with the new type prefix, allowing for a run-time argument to emit messages with the old.
Sorry for the delay in answering @blelump -- this is not about "did:https" support. This is about the prefix of DIDComm messages types. Currently, Aries DIDComm protocols are namespaced using "did:sov:...." and the community is changing that to use "https://didcomm.org".
Work completed #705; new startup parameter is --emit-old-didcomm-prefix
In prior work we implemented Step 1 of the DID Message type change over, enabling the receipt of DID messages using either message type format -- https or did:sov. For the next step in the process, please add a startup option that causes the ACA-Py instance to use the https version when sending messages.
As part of that work, please make sure that two ACA-Py instances can communicate when one is sending the old message type format and the other the new.