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?
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:
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?