Give the web wallet a way to answer a key rotation - #67
Merged
Conversation
#66 made an announced signing-key rotation a decision rather than something the wallet takes on its own. It gave the CLI a flag and left the browser with a refusal it could not show: main.ts catches BadSignatureError and rethrows anything else, so a KeyRotationError left `take()` as an unhandled rejection. The receive would fail with nothing on screen and no way past it. So the PWA gets its own refusal card. It is deliberately not the signature card with different words, because the two refusals are different in kind. A signature that does not verify is a fact about the note in your hand. A mint presenting a new signing key is a question about the mint, and one the wallet genuinely cannot answer: a mint rotating properly and a mint somebody else now runs publish the same two claims from the same server. The card says exactly that, and says the one thing a holder can actually do about it - check the new key by some route that is not this mint. It also says that notes already held keep working, because the old key is kept, so the decision is not being made under a false clock. Two taps to accept, matching the signature override, and for the same reason: the honest case for overriding is that you already know something the wallet does not. 324 tests pass, web typecheck clean.
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
#66 made an announced signing-key rotation a decision rather than something the wallet takes on its own. It gave the CLI a flag and left the browser with a refusal it could not show.
main.tscatchesBadSignatureErrorand rethrows anything else, so aKeyRotationErrorlefttake()as an unhandled rejection. The receive would fail with nothing on screen and no way past it. That is a regression #66 introduced and this closes it before either half ships.Why it is a separate card, not the signature card with new words
The two refusals differ in kind.
A signature that does not verify is a fact about the note in your hand. A mint presenting a new signing key is a question about the mint, and one the wallet genuinely cannot answer: a mint rotating properly and a mint somebody else now runs publish the same two claims from the same server.
The card says exactly that, and says the one thing a holder can actually do about it - check the new key by some route that is not this mint. It also says notes already held keep working, because the old key is kept, so the decision is not being made under a false clock.
Two taps to accept, matching the signature override, and for the same reason: the honest case for overriding is that you already know something the wallet does not.
Verification
324 tests pass,
npm run checkandtypecheck:webclean.