Push prompts need to tell us what we are approving

Push fatigue is a boring failure mode in ordinary account use: someone keeps tapping “Approve” because the prompt is vague and the interruption is annoying.

I’d like authenticator apps to show richer, signed login context: the exact domain, requesting device, approximate location, and request time. A deliberate confirmation gesture—number matching or a hold, rather than one-tap Approve—could make the decision harder to make absent-mindedly. Microsoft Authenticator already documents application-name and approximate-location context, and Microsoft supports number matching; the rest sounds more like a design proposal than a broadly deployed standard.

This could slow legitimate logins, create accessibility problems, expose uncomfortable location signals, or still fail when users have learned to approve everything. It is also not phishing-resistant authentication by itself; adding friction is not the same as cryptographic session binding. Would you trust richer prompts, prefer hardware-key confirmation, or consider this the wrong threat model? Real-world examples welcome.

I like the direction, but I’d be careful with “exact domain.” The app needs an authenticated, canonical representation of the verifier, not just a string supplied by the requester. Otherwise we are polishing the same trust boundary. Number matching is a useful speed bump; the signing and binding details matter more than the extra fields.

The deliberate gesture is probably more important than packing the screen with context. Most people do not inspect four fields during a routine login. A clear “type the number shown in your browser” teaches a different habit than “tap approve,” though accessibility testing would be essential.

The distinction between “reduces accidental approval” and “prevents phishing” should stay prominent. NIST’s definition of phishing resistance specifically does not count manually entered OTP or out-of-band approval as resistant, because the output is not bound to the session. Rich prompts can still be worthwhile without making the stronger claim.

There is a product tradeoff here: every extra confirmation step spends a little of the user’s patience. I’d reserve the richer flow for unusual device, location, or time combinations and keep routine sign-ins calmer. Of course, that requires a risk engine users can actually trust.

Location is a particularly weak signal. It can be wrong, and displaying it may create privacy questions without adding much assurance. I would show it as “approximate” and never present a familiar location as proof. The domain and verifier binding seem more valuable.

The failure case I worry about is support training: “If the prompt looks different, just keep approving until it works.” Any rollout needs an obvious reject-and-report path, plus recovery that does not teach people to bypass the control. The interface cannot carry the whole policy.

A hold gesture sounds like the sort of thing that is delightful in a mockup and irritating at 8:02 every morning. Number matching at least has a comprehensible relationship to the browser window. I’d take boring and explicit over clever.

Hardware keys are stronger, but deployment is not just a cryptography decision. Lost keys, enrollment, replacements, shared workstations, contractors, and recovery all become procurement and operations questions. Rich prompts may be a reasonable bridge, provided nobody labels the bridge phishing-resistant.

Signed context only helps if the verifier signs the right context and the client validates it correctly. “Signed” is not magic metadata. I’d want the protocol specified before debating whether the screen has device name or timestamp. Still, replacing one-tap approval is a low-regret idea.

For a small business, the practical question is whether staff can understand the prompt while serving a customer. Number matching seems teachable; exact device and location may be noise. I’d rather have one meaningful check people follow than five details they ignore.

Maybe the threat model is narrower than we think. If an attacker already has the password and can repeatedly trigger prompts, a user-facing warning is useful, but the durable answer is moving important accounts to passkeys or security keys. Improving push is housekeeping, not a destination.

I would absolutely choose a hardware key for admin access, but not pretend every ordinary account will get one. For consumer flows, number matching plus a visible relying-party name is a decent compromise. Just make the fallback path less convenient than the secure path, not impossible.

The metric I’d watch is not prompt completion time; it is unwanted approvals and support volume after rollout. If richer context cuts the first while exploding the second, the design failed operationally. I’d pilot it on higher-risk actions before forcing it everywhere.