feat: persist extern AID metadata for alias-based lookup and rotation#418
feat: persist extern AID metadata for alias-based lookup and rotation#418yeomjaeseung wants to merge 2 commits intoWebOfTrust:mainfrom
Conversation
yeomjaeseung
changed the title
yeomjaeseung
changed the title
|
Thank you for your contribution. If you are able, please post a sample project showing how this is used with SignifyTS so we can properly evaluate the PR. If you'd like, you can submit the sample project in a new |
|
And, ideally with something like Google KMS or other KMS that makes it easy to validate and test. I have a GCP account and can easily test with GCP, though will test with a different service if you submit with a different service, within reason. |
Codecov Report❌ Patch coverage is
❌ Your patch check has failed because the patch coverage (61.22%) is below the target coverage (75.00%). You can increase the patch coverage or adjust the target coverage. Additional details and impacted files@@ Coverage Diff @@
## main #418 +/- ##
==========================================
- Coverage 86.91% 86.58% -0.34%
==========================================
Files 25 25
Lines 5451 5507 +56
==========================================
+ Hits 4738 4768 +30
- Misses 713 739 +26 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
@kentbull I have submitted a sample project to the signify-react-ts repository to demonstrate how this is used with SignifyTS. You can review the SignifyTS example here: |
|
Thank you, I will review this and reply. |
| raise ValueError("Attempt to load nonexistent or invalid pre={}.".format(pre)) | ||
| # Default extern params | ||
| if (ep := self.rb.eprms.get(pre)) is None: | ||
| return dict(extern=dict(extern_type="", pidx=pp.pidx)) |
There was a problem hiding this comment.
For consistency, shouldn't we also raise ValueError here as eprms should be set in incept?
|
|
||
| ep.extern_type = val.get("extern_type", ep.extern_type) | ||
| if "pidx" in val: | ||
| ep.pidx = val["pidx"] |
There was a problem hiding this comment.
This makes me wonder if there's actually value in storing any metadata at all with eprms, or if it's enough to just populate pres and keep it more lightweight.
|
@yeomjaeseung please rebase this on the latest code from main. |
3 participants
Description
Resolves #415
This PR completes the
ExternKeeperimplementation as discussed in the issue. Previously,externtype AIDs (managed by external modules) lacked a persistence layer in the KERIA database, which led to 500 Internal Server Errors during alias-based lookups and rotations.By introducing
eprmsstorage, this PR ensures thatexternAIDs achieve functional parity withsaltyandrandytypes, allowing them to be fully managed via aliases within KERIA.Key Implementation Details:
extern_typeandpidxare persisted. Assumption-free handling of externally managed key material is preserved.info()helper, preventing lookup failures inRemoteManager.Changes
keeping.pyExternPrmdataclass to storeextern_typeandpidx.eprmssub-database intoRemoteKeeperfor persistence.incept,rotate, andparamsmethods inExternKeeperto manage the metadata lifecycle.aiding.pyIdentifierResourceEnd.rotateto supportAlgos.externmetadata updates.AgentResourceEnd.on_putto allow client-side updates ofextern_typeandpidx.Verification Results
identifiers().get(alias)returns the correct metadata without 500 errors.externAID successfully updates the local DB state.pytestsuite — all tests passed with no regressions observed.