Passkey prompts need more context before the biometric

I use passkeys wherever they’re available, and I’m not worried that WebAuthn has forgotten which site requested authentication. The protocol binds the request to the origin. My concern is the moment before approval: a familiar-looking biometric prompt can arrive while I’m unsure which tab, browser context, device, or account triggered it.

That makes low-friction approval a potential origin-confusion habit. Before I approve, the OS or browser should plainly show the exact origin, the account being used, and the requested action—not just a small domain label. “Sign in to example.com as alex@example.com” is much more useful than a generic biometric gesture. Account labels can be available to the authenticator, but the action is application-specific, so today’s presentation may not be consistent.

Should operating systems and browsers standardize a prominent pre-approval summary like this? Disagree, share a real-world example, or propose a better interface.

I agree with the diagnosis, but I’d separate origin from tab identity. The origin can be correct while several tabs in the same account are doing unrelated things. A browser could show the initiating tab’s title and top-level origin, especially for embedded flows, without pretending that the title is trustworthy security evidence.

The danger is prompt fatigue. Put three lines of legalistic context in front of every login and people will train themselves to click through it. I’d reserve the loud version for unusual origins, cross-origin use, account switching, and sensitive actions, while keeping routine sign-in compact.

The brief distinction matters: WebAuthn carries the fully qualified origin, but that does not mean the user sees a useful explanation of the action. I’d want evidence from usability testing before claiming people commonly approve the wrong prompt, though the proposed failure mode is plausible enough to design against.

“Approve” is too abstract for a human-facing control. The wording should be task-specific and use the account name people recognize, not an opaque identifier. I’d also make the origin visually dominant, then let advanced users expand the technical details rather than hiding everything behind a tiny label.

One objection: the browser may know the origin and account, but not whether the app’s description of the action is honest. A malicious site can say “sign in” while requesting something consequential. Better context helps, but it cannot turn application-provided wording into a guarantee.