Public DIDs other than did:sov

[thiagoromanos]

Currently the only DID method allowed to be set as public is did:sov. However, any resolvable DID with a endpoint service set (for making connection invites using public DID) should be good to set as public.
The wallet object assumes that the public did is published in a indy network (using the BaseLedger to upadte the endpoint), which could not be true thinking in using a different to store the published DID.

[dbluhm]

I'm unable to attend ACA-PUG today so apologies if I missed important discussion items. My two cents on this, I think I'd like to see the idea of a "public DID," as in a singular DID reused across API calls, be phased out in favor of simply specifying a DID in operations that require it.

ACA-Py is mid transition to enabling more DID Methods so we are in a state where some operations retain the old assumptions about DIDs (i.e. only did:sov) while other operations better support DIDs in general. For instance, the old AnonCreds artifact creation endpoints are strictly expecting the public DID to be a DID on an indy network, as you called out. But the new ledger-agnostic AnonCreds endpoints accept an Issuer DID and don't make undue assumptions about that DID.

Which operations are you wanting to support other DID methods where only the public DID is accepted today? Is it just in connection formation or something else?

[thiagoromanos]

@dbluhm , in my use case I only have the invitations issue (both connections and did-exchange protocols). But in the endpoint to set the public did ([POST] /wallet/did/public) it does require that the did must be a did:sov one as well. I managed to get rid of this limitation by overrinding this route in my plugin, but that is really not the best option.
Following the thought on acapy being ledger-agnostic, one thing I noticed is that if your agent is a single tentant one, and the public did is set, it will try to call to a ledger method to update the did's service endpoint to the endpoint set to the agent. Thinking that I could use a public did in a ledger other than indy, this call will fail (I saw it happening in my implementation).

One thing mentioned in yesterday's acapug is the renaming from "public did" to "published did".

Anyway, I believe this issue requires some more discussing.

[swcurran]

This was discussed at this point in the ACA-Py Maintainers meeting on Feb. 11 -- from about 1:30 to the 10:00 minute mark.

One point is that we want to eliminate the concept of the "one public DID for an ACA-Py tenant" and instead allow an explicit note the DID to be used.

Towards that goal, here are some things to be done in the code base:

Phase out the use of an overall "Public DID" and just reference the DIDs by identifying where public DIDs are used, trace back to endpoint(s) that invoke the code containing the reference, and add a DID to the endpoint. Then, update the use of the Public DID to default to the DID passed via the endpoint, falling back to the (deprecated) Public DID.

That said -- when forming the connection there are actions triggered related to Indy that are automatic. Notably, the endpoint of the public DID is published to an Indy ATTRIB transaction. We need to break that. Some of that was done in the move to did:peer:4, but it may not be complete. In that work, the specific DID to be used is provided via an endpoint (tactic described above) and that is used in place of the configured "Public DID".

@jamshale has been looking at the DID management, and there is work to be unwound to see where the Public DID is used. Working on a plan.

It would be good to get an idea where the "public did" (set via [POST] /wallet/did/public)) is used, and if possible, what endpoints lead to those references. Then we can see about deprecating the single "public DID" concept.