Intent to Ship: WebAuthn hints

[Adam Langley]

Contact emails

a...@chromium.org

Specification

https://w3c.github.io/webauthn/#enum-hints

Summary

The new `hints` parameter[1] in WebAuthn requests allows sites to provide guidance to browsers to guide their UI. The canonical use case are enterprises which know that their internal sites use only security keys and want to be able to communicate that so that browsers focus the UI on that case. But hints also resolve a tension where the current `authenticatorAttachment` parameter is strict: setting it to `platform` excludes all cross-platform options and vice versa. This has proven less than ideal in some cases. [1] https://w3c.github.io/webauthn/#enum-hints

Blink component

Blink>WebAuthentication

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

None: new option which only tweaks UI.

Gecko: No signal

WebKit: No objections when asked in person.

Web developers: Positive. Several sites have requested this functionality, which motivated the spec change. They continue to want it and have done so for quite a while now.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No.

Debuggability

Not really. This causes the browser UI to switch emphasis, but doesn't other change any site-observable behaviour.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

On Android & Android WebView, support would require changes to other components: the android.credentials code in the framework and, for older Android versions, Play Services. That might come in the future, but it's not part of the Blink and Chrome work. (The Blink change is, of course, required for anything else in the system to be able to handle this parameter.)

Some versions of Windows handle WebAuthn UI themselves and, while Chrome can change it's UI, this parameter won't immediately change the Windows UI. However, Microsoft is positive about this change and Chromium will be updated to pass this parameter on as soon as the Windows API is able to receive it.

Is this feature fully tested by web-platform-tests?

No

Hints only affect the browser UI and unknown parameters are ignored in WebAuthn already.

Flag name on chrome://flags

None

Finch feature name

WebAuthenticationHints

Requires code in //chrome?

True: Chrome-specific WebAuthn UI is handled in //chrome and needs to respond to these hints. Other embedders would have to do the same to benefit from this change.

Estimated milestones

Shipping on desktop	128

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5145737733341184?gate=5155815622443008

[Mike Taylor]

Hi Adam,

Could you please request reviews (or N/A, if you have internal approvals) for Privacy, Security, and Enterprise bits in your chromestatus entry?

thx,
Mike

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL9PXLzcnJ9xLwJZzQJBL0UJdnDGb7tB5Uu7cYqB%2Bdcdb%2BCfTQ%40mail.gmail.com.

[Mike Taylor]

(oops, accidentally removed agl@ from To, fixing)

[Adam Langley]

On Mon, Jun 3, 2024 at 7:36 PM Mike Taylor <mike...@chromium.org> wrote:

(oops, accidentally removed agl@ from To, fixing)

On 6/4/24 11:35 AM, Mike Taylor wrote:

Hi Adam,

Could you please request reviews (or N/A, if you have internal approvals) for Privacy, Security, and Enterprise bits in your chromestatus entry?

Reviews have been requested for some time now.

Cheers

AGL

[Mike Taylor]

On 6/4/24 9:50 PM, Adam Langley wrote:

On Mon, Jun 3, 2024 at 7:36 PM Mike Taylor <mike...@chromium.org> wrote:

(oops, accidentally removed agl@ from To, fixing)

On 6/4/24 11:35 AM, Mike Taylor wrote:

Hi Adam,

Could you please request reviews (or N/A, if you have internal approvals) for Privacy, Security, and Enterprise bits in your chromestatus entry?

Reviews have been requested for some time now.

Sorry - unsure if this is a chromestatus bug or I am missing something - I see that Privacy, Security, and Enterprise were requested 9 hours ago. Either way - thanks. :)

[Adam Langley]

On Tue, Jun 4, 2024 at 7:26 PM Mike Taylor <mike...@chromium.org> wrote:

Reviews have been requested for some time now.

Sorry - unsure if this is a chromestatus bug or I am missing something - I see that Privacy, Security, and Enterprise were requested 9 hours ago. Either way - thanks. :)

Reviews were requested 2024-05-18, but three of the five seemingly require another button to be clicked. More buttons have now been clicked and schedules have been updated to M128.

Cheers

AGL 

[Yoav Weiss (@Shopify)]

On Mon, Jun 3, 2024 at 10:59 PM Adam Langley <a...@chromium.org> wrote:

Contact emails

a...@chromium.org

Specification

https://w3c.github.io/webauthn/#enum-hints

Summary

The new `hints` parameter[1] in WebAuthn requests allows sites to provide guidance to browsers to guide their UI. The canonical use case are enterprises which know that their internal sites use only security keys and want to be able to communicate that so that browsers focus the UI on that case. But hints also resolve a tension where the current `authenticatorAttachment` parameter is strict: setting it to `platform` excludes all cross-platform options and vice versa. This has proven less than ideal in some cases. [1] https://w3c.github.io/webauthn/#enum-hints

Blink component

Blink>WebAuthentication

TAG review

None

TAG review status

Not applicable 

Risks

Interoperability and Compatibility

None: new option which only tweaks UI.

Gecko: No signal

WebKit: No objections when asked in person.

Can you ask for positions? https://bit.ly/blink-signals

 

--

[Vladimir Levin]

Hi,

Is it possible to put together a small explainer for this. It's a bit difficult to understand what this hint would control. Do you have examples?

Thanks,

Vlad

[Adam Langley]

On Mon, Jun 10, 2024 at 9:36 PM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

TAG review status

Not applicable

Can you clarify why that's the case?

This is a tiny change that is already in a WG's editor's draft.

 

Interoperability and Compatibility

None: new option which only tweaks UI.

Gecko: No signal

WebKit: No objections when asked in person.

Can you ask for positions? https://bit.ly/blink-signals

https://github.com/WebKit/standards-positions/issues/365
https://github.com/mozilla/standards-positions/issues/1043

> Is it possible to put together a small explainer for this. It's a bit difficult to understand what this hint would control. Do you have examples?

I'm not sure that this is big enough for a formal explainer, but I can summarize quickly here:

In the beginning, WebAuthn was a spec purely for security keys and overwhelmingly for enterprises. Those enterprises were eventually happy once the spec was fleshed out to cover all their needs.

Then WebAuthn started being useful for non-enterprise cases too, and browser UI now includes those options. Also, the UI shows non-security-key options prominently because most users are no longer using security keys.

But that makes the enterprises sad: they issue security keys to their employees and liked the old UI a lot better.

So this "hints" parameter lets sites express that they want the UI to default to security keys because they know that it's an internal website and all the users are required to use their company-issued security keys with it.

That's 90% of the motivation. There is also some desire in the WG to tweak the ways that some existing, somewhat similar mechanisms work and so the start of that also exists as a couple of other hints that can be expressed. The Chromium implementation does currently also recognise and respect those values too because it's trivial to include them.

Cheers

AGL

[Daniel Bratell]

LGTM1

/Daniel

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL9PXLzHtofcaVHUT9FZfCtqNbsU00%3DxnLRZqA58QcJU%2BcaM5A%40mail.gmail.com.

[Chris Harrelson]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f59010fb-4c35-4c9f-85fb-9cf81f9fe7d4%40gmail.com.

[Philip Jägenstedt]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9LnqddiFsp5pkWQWAsK4wA6FodjSkgemqYewyic_SVUA%40mail.gmail.com.