Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Public DIDs other than did:sov #3462

Open
thiagoromanos opened this issue Jan 24, 2025 · 2 comments
Open

Public DIDs other than did:sov #3462

thiagoromanos opened this issue Jan 24, 2025 · 2 comments

Comments

@thiagoromanos
Copy link
Contributor

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
Copy link
Contributor

dbluhm commented Feb 4, 2025

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
Copy link
Contributor Author

thiagoromanos commented Feb 5, 2025

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants