feat(passkey): drop the naming step from enrollment - #140
Merged
Conversation
Choosing "Register Passkey" opened a modal asking for a friendly name, and the browser's own passkey prompt only appeared once that form was submitted. A user who came to the screen to press one button was handed a text field first, at the point in the flow where they had the least idea what to type. Registration now starts on the click. The credential still carries a friendlyName, filled with the device it was enrolled on, which is what the prompt suggested people write anyway. Renaming stays available through updateCredential. The public API does not move: PasskeyMetadata.friendlyName is unchanged and a caller building their own enrollment screen keeps setting it. Only the bundled /register-passkey view changes.
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.
What
Removes the "Name This Device" modal from the bundled
/register-passkeyview. Choosing Register Passkey (or Use a security key instead) now goes straight to the browser's WebAuthn prompt.Why
The modal sat between the button and the ceremony: a user who came to the screen to press one button was handed a text field first, at the point in the flow where they had the least idea what to type. The placeholder ("e.g., MacBook Pro, iPhone, YubiKey") was asking them to describe the device they were already sitting at.
How
DeviceNameModal.tsx, its stylesheet, andtests/DeviceModal.test.tsx.PassKeyRegistration.tsxloses theshowDeviceModal/pendingMetadata/pendingAttachmentstate and the two-stepopenDeviceModaltocontinueRegistrationsplit, collapsing to oneregisterPasskey(attachment?).friendlyNameis filled fromparseUserAgent().deviceInfo(for examplemac • chrome), which is what the naming prompt suggested people write anyway. Renaming stays available throughupdateCredential.Scope
PasskeyMetadata.friendlyNameis unchanged, so a caller building their own enrollment screen keeps setting it. Only the bundled view changes, which means an adopter relying on that screen to collect a name needs their own screen for it. Called out in the changeset.Checks
npm run typecheck,npm run lint,npm run format:check, andnpm testall pass (309 tests, 31 suites). Test coverage forPassKeyRegistration.tsxstays at 100% of statements and lines.