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
Is your feature request related to a problem? Please describe.
When building a multi-tenant and/or multi-user system using Veramo, it's likely you'll need to store private keys which can be accessed/used by multiple parties. For example, an organization might have a private key associated with did:web:organization.com. You'd want this key to be owned by the organization itself rather than a specific user, so that in the event that the underlying organization ownership is transferred the key can follow without additional changes.
There are likely other use-cases where you'd want to attach metadata to the private key outside of authz. At the moment there is no way to pass metadata to an AbstractPrivateKeyStore.
Describe the solution you'd like
We already have the KeyMetadata interface on ManagedKeyInfo. The meta object could also be added to the ManagedPrivateKey interface.
Describe alternatives you've considered
You can currently work around this by implementing a custom AbstractKeyManagementSystem, but this either requires a non-compliant AbstractPrivateKeyStore class (to receive the metadata), or separately associating the metadata after creating the key (which is also not ideal).
Additional context
It's worth considering how the existing algorithms property of KeyMetadata should be handled. Generating it dynamically (currently via asManagedKeyInfo) is probably preferable to storing alongside the key.
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.
When building a multi-tenant and/or multi-user system using Veramo, it's likely you'll need to store private keys which can be accessed/used by multiple parties. For example, an organization might have a private key associated with
did:web:organization.com
. You'd want this key to be owned by the organization itself rather than a specific user, so that in the event that the underlying organization ownership is transferred the key can follow without additional changes.There are likely other use-cases where you'd want to attach metadata to the private key outside of authz. At the moment there is no way to pass metadata to an
AbstractPrivateKeyStore
.Describe the solution you'd like
We already have the
KeyMetadata
interface onManagedKeyInfo
. Themeta
object could also be added to theManagedPrivateKey
interface.Describe alternatives you've considered
You can currently work around this by implementing a custom
AbstractKeyManagementSystem
, but this either requires a non-compliantAbstractPrivateKeyStore
class (to receive the metadata), or separately associating the metadata after creating the key (which is also not ideal).Additional context
It's worth considering how the existing
algorithms
property ofKeyMetadata
should be handled. Generating it dynamically (currently viaasManagedKeyInfo
) is probably preferable to storing alongside the key.The text was updated successfully, but these errors were encountered: