Re: [webauthn] Deprecate AuthenticatorAttachment in favor of PublicKeyCredentialHints. (#2053)

> @MasterKale, order matters with hints; so to be clear, you were intentional in placing `"security-key"` before `"hybrid"`, right?

No, I was not intentionally ordering the hints in that comment. RP's should be free to order hints as they see fit.

> Perhaps it was an oversight, but [`PublicKeyCredential`](https://www.w3.org/TR/webauthn-3/#publickeycredential) only has a field for `authenticatorAttachment`. If `PublicKeyCredentialHints` is designed to be a replacement, then ideally `PublicKeyCredential` would be updated to contain a `hints` `attribute`.

`authenticatorAttachment` still has value as a signal of whether the user might need to be prompted to register their local access device. Hints don't control browser behavior in the same way that authenticatorAttachment does; it's possible that specifying `hints: ["security-key"]` leads to the user completing hybrid authentication anyway. What value might be returned for a hypothetical "`PublicKeyCredential.hints`" in the response in this scenario? `["security-key"]` wouldn't make sense, but the RP didn't specify `["hybrid"]` so it could be confusing...meanwhile returning `authenticatorAttachment: "cross-platform"` remains an accurate description of the general type of the authenticator that ultimately completed the ceremony, so I can't see the benefit of replacing `PublicKeyCredential.authenticatorAttachment` right now.

> According to [@MasterKale's comment](https://github.com/w3c/webauthn/issues/2053#issuecomment-2023398238), the inverse seems to be `"cross-platform"` → `["security-key", "hybrid"]` and `"platform"` → `["client-device"]`; however if that is the case, it should be mentioned in the spec.

Mapping in the opposite direction, from `hints` to `authenticatorAttachment`, isn't quite that easy. While `["hybrid", "security-key"]` and `["security-key", "hybrid"]` conveys slightly different desires by the RP about which type of authenticator they want the browser to start the user in. Naively mapping either combination to `"cross-platform"` prunes this desire. 

---

My ultimate goal with hints was to make it possible to break up registration into three separate flows. The introduction of passkeys jammed hybrid registration into previously-security-key-only flows. For RP's (like Duo Security) that want to be able to show the user instructions before the WebAuthn ceremony this made it incredibly difficult to pull this off. Especially when we wanted the user to use their security key but were shown this by their browser:

![Screenshot 2024-04-19 at 2 23 23 PM](https://github.com/w3c/webauthn/assets/5166470/f572cd92-676b-459c-8e98-07b40be3ef0d)

Hints enable registration to now be three options, as passing in `["security-key"]` can have the browser jump straight to security key interaction when `.create()` is called:

![Screenshot 2024-04-19 at 2 23 33 PM](https://github.com/w3c/webauthn/assets/5166470/0adac5d5-14fe-449f-b949-7e99bbfc68e0)

Sure, clients are free to allow the user to choose a different kind of authenticator than specified in the hint, but if users are just looking to click Next to get through the first thing shown to them this doesn't seem too bad a restriction over using `authenticatorAttachment`.

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


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

Received on Friday, 19 April 2024 21:43:24 UTC