- From: philomathic_life via GitHub <sysbot+gh@w3.org>
- Date: Fri, 19 Apr 2024 23:35:29 +0000
- To: public-webauthn@w3.org
> No, I was not intentionally ordering the hints in that comment. RP's should be free to order hints as they see fit. Is this true? The spec says "if two hints are contradictory, the first one controls" which seems to imply that something like `["security-key", "client-device"]` is equivalent to `["security-device"]` due to the two contradicting each other and `"security-key"` appearing first. Additionally the spec states, "Hints may also overlap: if a more-specific hint is defined a [Relying Party](https://www.w3.org/TR/webauthn-3/#relying-party) may still wish to send less specific ones for user-agents that may not recognise the more specific one. In this case the _most specific hint should be sent before the less-specific ones_" (emphasis added). This seems to imply that something like `["hybrid", "security-key"]` is wrong since the latter is more specific and thus "should be sent before". > `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. So then I don't understand [your comment](https://github.com/w3c/webauthn/issues/2053#issuecomment-2023382632) that `AuthenticatorAttachement` should be deprecated. You seem to be arguing now that there is use in `AuthenticatorAttachment` that is not filled by `PublicKeyCredentialHints`. Were you stating that it should be deprecated only within `PublicKeyCredentialCreationOptions` but elsewhere (e.g., `PublicKeyCredential` and `PublicKeyCredentialRequestOptions`) still exist? Additionally nothing in the spec states or implies that the `AuthenticatorAttachement` that is sent as part of `PublicKeyCredential` SHOULD or MUST match the one that was sent in `PublicKeyCredentialCreationOptions`; therefore I don't see why a mismatch would be confusing. > 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. As stated already, the spec seems to indicate that `["hybrid", "security-key"]` shouldn't exist since the former is less specific than the latter. Also the spec _does_ attempt to map from `hints` to `authenticatorAttachment`, but unfortunately is does so in an incomplete way. For example it states `["security-key"]` SHOULD be mapped to `"cross-platform"`, but it doesn't state anything about `["security-key", "hybrid"]`. Additionally as stated in my previous comment, it suggests mapping `["hybrid"]` to `"cross-platform"` despite it appearing to be better to map that to nothing since a lack of `authenticatorAttachment` field means "any attachment modality is acceptable". > 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: > >  > > 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: > >  > > 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`. Thanks for the explanation. I understand the intent of `PublicKeyCredentialHints` a little better now; however to @timcappalli's point, there seems to be use cases for `AuthenticatorAttachement` (which you seem to agree based on your response). Additionally there seems to be missing/contradictory information in the spec as it relates to `PublicKeyCredentialHints` and `AuthenticatorAttachment`. -- GitHub Notification of comment by zacknewman Please view or discuss this issue at https://github.com/w3c/webauthn/issues/2053#issuecomment-2067393913 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 23:35:29 UTC