-
Notifications
You must be signed in to change notification settings - Fork 166
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deprecate AuthenticatorAttachment in favor of PublicKeyCredentialHints. #2053
Comments
We discussed this on a WG call a few weeks back, and I think there was loose agreement to do this as part of Level 4 (e.g. replacement added in L3, deprecate old way in L4). But I think we need to address RPs who still want to specify local vs remote, without having to worry about all the options. This could be addressed by just adding an additional option to hints to cover the equivalent of |
We attempted to hedge this by establishing in L3 that hints override attachment:
Deprecating in L4 definitely makes sense.
@timcappalli Are you thinking about auth here? Because |
I updated my comment. We talked about adding something equivalent to |
Hmm, what's the current gap with specifying |
Simplicity for developers and future proofing. The other thing we need to think about is the difference between authenticatorAttachment today vs hints. Hints are just a hint. It is expected that clients will use this to prioritize, but not limit other options. Whereas attachment limits the options available to users. authenticatorAttachment = very predictable experience today Something to consider as they are arguably serving slightly different use cases. |
As far as I recall, even in older version authenticatorAttachment has always been a "hint" as well. It just so happens it predictably works today, but it's still a hint. So changing this from platform/cross-platform to more specific transports / factors like "security-key" or "hybrid" is a good change. |
Perhaps it was an oversight, but Consequently a client can only inform what kind of credential was created via Edit According to @MasterKale's comment, the inverse seems to be |
As I write my WebAuthn RP library, I do find it somewhat bizarre that Also for clarification, the spec says "Hints are provided in order of decreasing preference so, if two hints are contradictory, the first one controls. Hints may also overlap: if a more-specific hint is defined a 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". This means that the countably infinite
Here I am assuming that a missing |
No, I was not intentionally ordering the hints in that comment. RP's should be free to order hints as they see fit.
Mapping in the opposite direction, from 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 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 |
I would suggest that most RP's either A) use hints one-at-a-time to offer pre-registration guidance for the general category of authenticator they want the user to register, or B) group hints along the current
IMO number 2 could just as easily put
Not necessarily. |
Is this true? The spec says "if two hints are contradictory, the first one controls" which seems to imply that something like
So then I don't understand your comment that Additionally nothing in the spec states or implies that the
As stated already, the spec seems to indicate that
With
Again, according to the |
Ah, so it seems to be the case that
which in turn means that if the spec intends to map |
I'd suggest that providing two places is nice because it gives priority on the first, but also provides browsers with direction if the first method isn't available. For example, a browser could receive I'll have to respond to your other points later, I'm heading back home from today's WAWG F2F ✌️ |
From WAWG meeting @ 5/1: there's potential value in keeping |
No, the You may be thinking of the use case for
Immediately preceding that, the spec says:
so no, your two examples are not equivalent - the former expresses a fallback preference of For the purposes of mapping to a suitable value of |
@emlun, that makes sense. Thanks for the clarification. |
Background
We have introduced PublicKeyCredentialHints for RP to better convey intention of which transport is preferred for both credential creation and authentication. Previously, AuthenticatorAttachment was used to convey similar intention.
However, AuthenticatorAttachment has a side affect during credential creation. It excludes certain authenticators and the definition of platform vs cross-platform has been murky for some time since the introduction of hybrid transport. It leads to market fragmentation and UI differences between platforms.
Proposed Change
Deprecate AuthenticatorAttachment in favor of PublicKeyCredentialHints in the spec. For backwards compatibilty when only attachment is provided, we can map those values to corresponding PublicKeyCredentialHints.
The text was updated successfully, but these errors were encountered: