docs: state device approval as an API rendezvous in the blueprint - #1263
Closed
FSM1 wants to merge 3 commits into
Closed
docs: state device approval as an API rendezvous in the blueprint#1263FSM1 wants to merge 3 commits into
FSM1 wants to merge 3 commits into
Conversation
Three files described MFA and device approval as chrome-side Core Kit UX. That framing concealed an API slice: the Core Kit has no native cross-device share transfer, so approval is a server-mediated rendezvous, and v1 built an API module with its own table to provide one. Records the rendezvous beside the other API surfaces, the client's part in it, the recovery phrase as the guaranteed path on every host, and the fact that the Core Kit staging-dispatch exemption does not extend to a flow over our own API. v1 skipped every cross-device case for want of a second device, which is how a desktop path that could never succeed reached a verified status. Stacked on the ADR 0008 blueprint branch — both edit the same login sections. Entire-Checkpoint: 55e6165b54f5
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Entire-Checkpoint: 87854abeea41
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
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.
Records ADR 0009 (FSM1/cipher-box-next#65) in the blueprint. Documentation only, no code surface.
Based on #1255, not on
main. Both PRs edit the same login sections ofweb-client.mdanddesktop.md, so this is stacked to avoid a conflict. Merge #1255 first; the base then collapses tomain.Draft until FSM1/cipher-box-next#65 is accepted — the decision corpus is normative and this repo carries the as-built statement of it.
The framing being corrected
Three files described MFA and device approval as chrome-side Core Kit UX. Device approval cannot be UI-side: the Core Kit has no native cross-device share transfer (Web3Auth confirmed as much to the v1 build), so approval is a server-mediated rendezvous — and v1 built an API module with its own table and migration to provide one. The mislabel is why v2 has no endpoint, no UI, and until today no issue.
What changed
api.md— the rendezvous joins the other API surfaces: request, poll, respond, cancel and a pending list, under a scoped non-refreshable pre-reconstruction token, with the API as a bulletin board that relays ciphertext and never holds plaintext key material. Both halves carry a device-key signature, and a row's life ends at collection or expiry.device_approvalsjoins the table list.web-client.md— the Core Kit bullet keeps MFA enrollment and loses device approval. A new bullet states the client's part: mint the ephemeral key, display the comparison value both devices must match, sign both halves with the device identity key, and seal a fresh factor rather than the approver's own. The/settingsrow now distinguishes enrollment and recovery from authorized devices and approval.desktop.md— records that the recovery phrase always works on this host, with no second device and no rendezvous, and that desktop's participation in approval is a scope decision to be made rather than left open. v1 shipped a requester UI that could never work beside a settings string saying MFA was web-only; the affordance and the truth have to agree.testing.md— the Core Kit staging-dispatch exemption covers interactive login and MFA enrollment, and explicitly does not extend to device approval, which runs over our own API and needs a harness driving two sessions. v1 skipped every cross-device case for want of a second device, which is exactly how a desktop path sending a 33-byte key where 65 were required reached a verified status.Checks
markdownlint-cli2andprettier --checkclean on all four files.Note
Document device approval as a server-mediated API rendezvous in the blueprint
Updates four blueprint documents to describe device approval (per ADR 0009) as a server-mediated rendezvous rather than a client-side concern.
device_approvalstable entry.Macroscope summarized b8edcd7. (Automatic summaries will resume when PR exits draft mode or review begins).