You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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.
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:
veramo/packages/remote-server/src/web-did-doc-router.ts
Line 41 in 5202ef1
veramo/packages/remote-server/src/web-did-doc-router.ts
Line 44 in 5202ef1
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?
The text was updated successfully, but these errors were encountered: