Skip to content
This repository has been archived by the owner on Dec 12, 2024. It is now read-only.

added utility on new key store service from keystorage #294

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

andorsk
Copy link
Contributor

@andorsk andorsk commented Feb 21, 2023

Overview

Helper to build a keystorage service form an existing keystore.

Description

I wanted to use an existing keystore.keyStorage for ssi-service. The main issue is that https://github.com/TBD54566975/ssi-service/blob/main/pkg/service/keystore/service.go#L51 generates a new service key, and I wanted to read an existing service key stored in a db. It wasn't clear how to spin up a KeystoreService with an existing ServiceKey, and the storage and config methods are privately scoped, so other applications can't read it. Therefore, I decided to add a helper method that adds a way to create a new keystore service with an existing storage configuration.

How Has This Been Tested?

Checklist

Before submitting this PR, please make sure:

  • I have read the CONTRIBUTING document.
  • My code is consistent with the rest of the project
  • I have tagged the relevant reviewers and/or interested parties
  • I have updated the READMEs and other documentation of affected packages

@andorsk andorsk marked this pull request as ready for review February 21, 2023 07:45
@codecov-commenter
Copy link

Codecov Report

Merging #294 (b663180) into main (d1e9c54) will increase coverage by 0.09%.
The diff coverage is 50.00%.

@@            Coverage Diff             @@
##             main     #294      +/-   ##
==========================================
+ Coverage   24.57%   24.67%   +0.09%     
==========================================
  Files          32       32              
  Lines        3182     3194      +12     
==========================================
+ Hits          782      788       +6     
- Misses       2281     2285       +4     
- Partials      119      121       +2     
Impacted Files Coverage Δ
pkg/service/keystore/service.go 42.48% <50.00%> (+0.63%) ⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

@@ -46,6 +46,22 @@ func (s Service) Config() config.KeyStoreServiceConfig {
return s.config
}

// NewKeyStoreFromKeystoreStorage uses a keystore service directly from storage object
func NewKeyStoreFromKeystoreStorage(config config.KeyStoreServiceConfig, keyStoreStorage *Storage) (*Service, error) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

where would this key store be coming from in practice?

Copy link
Contributor Author

@andorsk andorsk Feb 21, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@decentralgabe so it's a good question. I was writing some personal stuff for testing around this and I needed an entry point that did not generate a new service key and salt, which is why I needed a method to support this action. I'm happy to just support this entrypoint on my own fork of this, or if there's a better way to handle this I'm open to it.

my main problem was with this line

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what about adding a parameter to the config to not generate a new key and instead look for an existing one?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@decentralgabe I think that's separate concerns. How it's managed in the config (optional/default behavior) is certainly important, but in the end of the day you'd still need to provide the logic in the NewKeyStoreService function to ignore re-generating the service keys, and/or to load the existing one. You then need to address the behavior of how they are loaded internally, etc, which was out of scope for this PR. Certainly a valid point, just not sure if that's addressed best somewhere else.

Copy link
Contributor Author

@andorsk andorsk Feb 22, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW: How I did it, I checked if ssi-service key was set, and if it was, unmarshalled it into a ServiceKey, and created a Keystore Service using the method in this PR. There are other possible ways to handle this, which is why I didn't want to tackle the logic around configuration/loading existing keys in this PR. The blocker I was having was specifically that there needed to be separation between ServiceKey generation/the keystore service and the rest of the NewKeyStoreService logic.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This parameters of this new constructor makes sense to me. I recommend only having a single constructor, instead of 2. It seems to me that it makes sense to update all callers to use the new constructor, and remove the old one.

Keeping a single constructor can then be named NewKeyStoreService.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea..@andresuribe87 that works and I think is a reasonable way forward.

@decentralgabe
Copy link
Member

Would like to get @andresuribe87 's perspective before continuing

@decentralgabe
Copy link
Member

@andorsk are you still interested in pushing this along? if so what's needed?

@andorsk
Copy link
Contributor Author

andorsk commented Apr 30, 2023

@decentralgabe thanks. This is probably still a good idea, but I'm OK with backlogging it for now. Currently it's not a priority with me.

@decentralgabe
Copy link
Member

Thanks @andorsk I'll keep it open - agree it's useful.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants