Re: [webauthn] Add a `hints` element for both `create` and `get`. (#1884)

> That would be a bug in that user-agent then, because any rp could fill them with unknown values today and cause issues. So I think authenticator attachment still seems like a better place for this.

A WebAuthn level one implementation can reject any unknown values for authenticatorAttachment. A level two implementation should ignore unknown values. But my point is that, as an RP, you can't start using new values of authenticatorAttachment without knowing that the user-agent supports them, lest your attachment preference becomes completely ignored.

That's one of the things that this proposal is trying to address: by having a list of strings we can define new hints in the future without RPs needing to worry that adding them will break older user agents.

> It's a bit of a concern that we are adding a third area for authentication selection, given that we already have transports and attachament selectors. So I think the bigger risk is for there to be inconsistent and odd behaviours if you specify multiple or combinations of these parameters.

I agree, but I think the direction that we should head in is to move away from the current authenticatorSelection and transport hints.

The platform/cross-platform values were intended to express whether a credential was desired for local reauth or for signing in. And the transport hints were intended to guide the UI between prompting for a security key or not. But both are getting quite awkward:

People took "cross-platform" to mean "security key", but now it means phones too and doesn't even mean "not platform" any more: if the platform authenticator is syncing to a phone then it's a candidate for attachment=cross-platform. Likewise, attachment=platform can get you a credential that you can use on another machine (e.g. making a credential on a hybrid-capable phone).

Transports are stressed by the fact that authenticators can gain transports now—they're not fixed-function. Lots of credentials with transports=["internal"] became effectively ["internal", "hybrid"] when we updated Android, but of course weren't actually updated.


So, overall, my thoughts are that:
* A list of strings is more future proof than single values.
* This mechanism isn't just about attachment, it should be the mechanism for any number of things in the future.
* authenticatorAttachment and transports are increasingly inapplicable.

-- 
GitHub Notification of comment by agl
Please view or discuss this issue at https://github.com/w3c/webauthn/pull/1884#issuecomment-1533808940 using your GitHub account


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

Received on Wednesday, 3 May 2023 22:01:32 UTC