-
Notifications
You must be signed in to change notification settings - Fork 521
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
Allow any did to be public #2295
Allow any did to be public #2295
Conversation
Signed-off-by: Matus Kempa <[email protected]>
Signed-off-by: Matus Kempa <[email protected]>
Signed-off-by: Matus Kempa <[email protected]>
Signed-off-by: Matus Kempa <[email protected]>
@@ -106,7 +106,7 @@ class Meta: | |||
example="Bob", | |||
) | |||
did = fields.Str( | |||
required=False, description="DID for connection invitation", **INDY_DID | |||
required=False, description="DID for connection invitation", **GENERIC_DID |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When making these changes I had a did:web specifically in mind. I have no experience with other formats, that's why I have doubts whether GENERIC_DID is the right choice or be more restrictive.
@chumbert Interested in your thoughts on these changes |
Hello ! The changes themselves are fine. My personal preference would be quite outside of the scope of this PR. Lately people have been contributing code that got us rid of the
logic for DIDs and verification methods. I think it is time we also consider a pluggable way to handle did registration. Now back to reality: in our deployments we have side-stepped the
I'm working internally to be able to publish and share with you our whole plugin soon. In addition to marking DIDs public, it also has an endpoint to configure wallet routing for public did in multitenancy scenarios (impossible to receive connection requests based on implicit invitations otherwise), and other things less relevant to this discussion. |
Quick update on the plugin we currently use: https://github.com/sicpa-dlab/aries-acapy-plugin-did-management |
Signed-off-by: Daniel Bluhm <[email protected]>
Kudos, SonarCloud Quality Gate passed! |
Having a universal resolver set in the configuration, I want to be able to create and receive invitations containing a public DID other than did:sov (Indy DID). In order to do that I must promote the DID to public after it has been created in the wallet.
This PR adds checks of the DID format to associate ledger operations to the did:sov only in the said operation, thus allowing any DID format to be set as public.