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

[proposal] Extend WebDIDProvider #1275

Open
cre8 opened this issue Oct 17, 2023 · 1 comment
Open

[proposal] Extend WebDIDProvider #1275

cre8 opened this issue Oct 17, 2023 · 1 comment
Labels
enhancement New feature or request pinned don't close this just for being stale

Comments

@cre8
Copy link
Contributor

cre8 commented Oct 17, 2023

Is your feature request related to a problem? Please describe.
Right now the did-web-provider is able to create/remove services.

According to @mirceanis these features are implemented when adding keys:

This is a limitation according to the W3C specification since you should be able to add all kind of key types as a verification method and then map then like you wish to the verification relationships.

Describe the solution you'd like
We need a separate storage for the mapping which key that was added via the provider.
After adding a key, the creator must be able to add and remove a key from the verification relationships. When adding the relationships, the creator is free to choose a unique id for the diddocument object that has to be unique. It should NOT be the keyid that we are using for the reference inside the datastore since a key can have many relationships.

Describe alternatives you've considered
The limitation to the hard coded options will make it difficult since there is no agility for the algorithms. Removing the logic and mapping each key to each verification relationship (like it's done in did:key and did:jwk) will ignore the least privilege approach.

Additional context
I am not sure right now how we can access the persistent storage. Do we need to pass a storageobject instance to the constructor of the did-web-provider or is it okay to pass a context when calling the different functions?

@cre8 cre8 added the enhancement New feature or request label Oct 17, 2023
Copy link

stale bot commented Dec 16, 2023

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix This will not be worked on label Dec 16, 2023
@mirceanis mirceanis added pinned don't close this just for being stale and removed wontfix This will not be worked on labels Dec 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request pinned don't close this just for being stale
Projects
None yet
Development

No branches or pull requests

2 participants