Feature: Allow DID:WEB to be set as public in the wallet

[mkempa]

Hi. I've got a few changes prepared that allow a DID:WEB to be promoted to public in order to establish an AIP2 connection using that public DID:WEB. Locally it works fine, both explicit and implicit invitation.

I'd like to know if this topic is much broader than I think. I've got a hunch that I missed something because all I think about is the connection.

Do you have any suggestions on what to else to take into account? Thank you.

[swcurran]

Sorry for the far too long delay in responding.

We would like to see this implemented in ACA-Py. As part of the current work that is happy in using the Hyperledger AnonCreds implementation in ACA-Py, we plan to add support for using did:web with ACA-Py.

Our current thoughts are:

• create a (simple for now) "aries-didweb-service" file server that can be run to receive requests from an ACA-Py instance publishing did:web DIDs and AnonCreds objects (schemas, creddefs, revregdefs, revregentries).
• create within ACA-Py a capability (likely a plugin) that supports registering did:web files — e.g., by calling an instance of aries-didweb-service with files to be created on the file service, and resolving did:web DIDs and DID URLs.

The “aries-didweb-service” will eventually (and sooner than later) have authentication to be used by the ACA-Py (or other Aries agent) for posting to an instance of the service.

Comments welcome — and if you have existing code that might help with this effort, we’d love to have contributions.

[mkempa]

Thanks for the reply. It looks like a great effort ahead of you.

The point 2 looks like a DID registrar to me. Perhaps you could make use of an external (universal) registrar as a config parameter just like the universal resolver.

But by no means my thoughts went so deep into the did:web.

My changes are based on a few premises:

• An ACA-Py plugin set for the did:web method, as described here
• A universal-resolver config param set
• A did:web created in the wallet (thanks to the plugin) and its respective DIDDocument stored and available

Then the changes revolve around additional conditions to avoid ledger operations for other DIDs than the did:sov in the POST /wallet/did/public?did= I have to admit in comparison to your expected/planned work it looks like a quick-and-dirty solution. However, in our use-case we greatly benefit from it. Now my doubts are whether it really should be incorporated into the ACA-Py main.

Perhaps it would be the best to open a PR to see for yourselves.

[swcurran]

Please do — we’d very much appreciate it.

[dbluhm]

@mkempa looks like this is closed by #2295 so I'll go ahead and close. Feel free to repoen if there are further items that need discussion or open another issue if there are other did:web compatibility issues to address.