Re: [webauthn] Add support for hinting at verbiage other than "sign in" during authentication (#2086)

@emlun  SPC looks like an excellent API to handle the more complex use-cases - thanks for sharing that!

Until browser support for that API improves, I suspect that RPs may use WebAuthn as it exists today for incremental progress towards the same goal even if they evolve to support SPC over time.

In any case, I don't want to over-index on the payment use-case since WebAuthn is valuable for many other situations. For example, I suspect a lot of folks here have used it in Github settings screens to re-authenticate an active session prior to a sensitive action (adding an SSH key, changing email, etc).

To expand on the proposed specifics a bit:
```typescript
const credential = await navigator.credentials.get({
  publicKey: {
    // ...
    displayHints: ['value-in-discussion', 'confirm', 'sign-in'],
  },
})
```

This would follow the same semantics of the existing [`hints`](https://www.w3.org/TR/webauthn-3/#enum-hints) field - send in order of specificity/importance. Unknown/unsupported values would be ignored by browsers, and the first understood value could be used to adjust the UI, falling back to the current behavior if none are known or provided.

Or for a more streamlined version, it could extend the existing `PublicKeyCredentialHints` enumeration and build on the existing semantics described in [§5.1.4](https://www.w3.org/TR/webauthn-3/#sctn-getAssertion) step 18:

```typescript
const credential = await navigator.credentials.get({
  publicKey: {
    // ...
    hints: ['security-key', 'confirm'],
  },
})
```
This would represent prompting for a physical security key to confirm an action rather than signing in, and the user-agent could adjust the UI accordingly. Since the existing semantics of Enum-as-DOMString (§2.1.1) says to "handle" unknown values and the hints are provided in order of decreasing preference, this would allow RPs to provide both the transport hints and dialog texts in the same place.

There's pros and cons to extending hints vs having a separate enumeration and `options` key, though based on my read of the currently published L3 spec, I think extending hints may provide the least overall friction to most RPs (and, likely, the least amount of change to the spec itself). I'd like to hear more from browser vendors on this one; it seems similar to how e.g. `autocomplete` tokens are parsed for `<input>` elements (notably the `webauthn` token) since they're at times overloaded for multiple somewhat-orthogonal ideas.

-- 
GitHub Notification of comment by Firehed
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/2086#issuecomment-2168581898 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 14 June 2024 18:51:07 UTC