exp/services/recoverysigner: add support for configuring and using multiple signing keys #2627
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
PR Checklist
PR Structure
otherwise).
services/friendbot
, orall
ordoc
if the changes are broad or impact manypackages.
Thoroughness
.md
files, etc... affected by this change). Take a look in the
docs
folder for a given service,like this one.
Release planning
needed with deprecations, added features, breaking changes, and DB schema changes.
semver, or if it's mainly a patch change. The PR is targeted at the next
release branch if it's not a patch change.
What
Add support for configuring and using multiple signing keys where the
first signing key in the list is the default used for signing and the
others can be selected according to SEP-30 v0.3.0.
Why
The reference implementation adheres to the API changes defined in
SEP-30 v0.3.0 that supported multiple signing keys per registered
account for the purpose of rotating signing keys, however the reference
implementation does not actually support multiple signing keys being
configured at one time.
Closes #2620.
Note
Much of this code is possibly going to be rewritten for #2343 where
global keys will be supplemented with unique keys for each account that
get stored in the database.
Known limitations
There is some code duplicity in this PR that I don't think is worth
optimizing on until unique keys are implemented as trying to abstract
commonalities may make @howardtw's job harder if the abstraction
doesn't quite align with the logic he inserts. I think we should revisit any
duplicate code once the unique key logic is added.