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] Metadata for ManagedPrivateKey #1361

Open
0x62 opened this issue Mar 13, 2024 · 3 comments
Open

[proposal] Metadata for ManagedPrivateKey #1361

0x62 opened this issue Mar 13, 2024 · 3 comments
Labels
enhancement New feature or request key-manager pinned don't close this just for being stale

Comments

@0x62
Copy link

0x62 commented Mar 13, 2024

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.

@0x62 0x62 added the enhancement New feature or request label Mar 13, 2024
@nickreynolds
Copy link
Contributor

We discussed this in the User Group and it seems like a good idea. Do you have bandwidth to implement this @0x62 ?

@0x62
Copy link
Author

0x62 commented Apr 6, 2024

@nickreynolds Sure, will create a PR

Copy link

stale bot commented Jun 16, 2024

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 Jun 16, 2024
@mirceanis mirceanis added the pinned don't close this just for being stale label Jun 18, 2024
@stale stale bot removed the wontfix This will not be worked on label Jun 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request key-manager pinned don't close this just for being stale
Projects
None yet
Development

No branches or pull requests

3 participants