Deprecate AuthenticatorAttachment in favor of PublicKeyCredentialHints.

[akshayku]

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.

[timcappalli]

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 cross-platform (e.g. remote-authenticator).

[MasterKale]

We attempted to hedge this by establishing in L3 that hints override attachment:

Hints MAY contradict information contained in credential transports and authenticatorAttachment. When this occurs, the hints take precedence. (Note that transports values are not provided when using discoverable credentials, leaving hints as the only avenue for expressing some aspects of such a request.)

Deprecating in L4 definitely makes sense.

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 two additional options to hints (e.g. local-client, remote-authenticator).

@timcappalli Are you thinking about auth here? Because client-device and hybrid hints should solve this for registration...

[timcappalli]

@timcappalli Are you thinking about auth here? Because client-device and hybrid hints should solve this for registration...

I updated my comment. We talked about adding something equivalent to cross-device to cover both hybrid and security-keys and any other future non-local option.

[MasterKale]

I updated my comment. We talked about adding something equivalent to cross-device to cover both hybrid and security-keys and any other future non-local option.

Hmm, what's the current gap with specifying ["security-key", "hybrid"]? Is it the ergonomics of needing to know to specify both values to achieve equivalent support to authenticatorAttachment: "cross-platform"?

[timcappalli]

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
Hints = somewhat predictable experience

Something to consider as they are arguably serving slightly different use cases.

[Firstyear]

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.

[zacknewman]

Perhaps it was an oversight, but 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.

Consequently a client can only inform what kind of credential was created via AuthenticatorAttachment which then has to somehow be mapped to a [PublicKeyCredentialHints] during the authentication ceremony. Unfortunately the spec defines a non-invertible function mapping PublicKeyCredentialHints to AuthenticatorAttachment forcing RPs to either play it safe and only use the AuthenticatorAttachment that was sent during registration or "guess" what [PublicKeyCredentialHints] to use instead.

Edit

According to @MasterKale's comment, 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. I also think PublicKeyCredential still needs to be updated. @MasterKale, order matters with hints; so to be clear, you were intentional in placing "security-key" before "hybrid", right?

[zacknewman]

As I write my WebAuthn RP library, I do find it somewhat bizarre that ["hybrid"] gets mapped to "cross-platform" instead of mapping to a missing value. According to the authenticatorAttachment field, "If this member is absent, then any attachment modality is acceptable". Doesn't "hybrid" mean both "platform" and "cross-platform" are allowed without preference to either one? If so, that seems to align with "any attachment modality is acceptable" (i.e., a missing field).

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 [PublicKeyCredentialHints]? is partitioned into five equivalence classes, correct:

1. []
2. ["security-key"]
3. ["client-device"]
4. ["security-key", "hybrid"]
5. ["client-device", "hybrid"]

Here I am assuming that a missing hints field, ["hybrid"], and [] are the same.

[MasterKale]

@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 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, 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:

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.

[MasterKale]

This means that the countably infinite [PublicKeyCredentialHints]? is partitioned into five equivalence classes, correct:

1. []
2. ["security-key"]
3. ["client-device"]
4. ["security-key", "hybrid"]
5. ["client-device", "hybrid"]

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 authenticatorAttachment split:

1. ["client-device"]
2. ["security-key", "hybrid"]

IMO number 2 could just as easily put "hybrid" before "security-key" as the RP desires - nothing about hints forces any of them into buckets, that should be an opinion established by RP's (or library maintainers.)

Here I am assuming that a missing hints field, ["hybrid"], and [] are the same.

Not necessarily. ["hybrid"] is the RP communicating to browsers that support hints, "please start the user in your hybrid registration flow." [] carries no meaning and so the browser would be free to start the registration ceremony where it wants to (e.g. the curernt behavior of optimizing for platform authenticator registration.)

[zacknewman]

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 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 that AuthenticatorAttachment 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) still exist?

Additionally nothing in the spec states or implies that the AuthenticatorAttachment that is sent as part of PublicKeyCredential MAY/SHOULD/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.

With AuthenticatorAttachment there were three separate registration flows possible:

1. "platform" (e.g., mobile device)
2. "cross-platform" (e.g., security key)
3. missing field (mobile device or security key).

Again, according to the authenticatorAttachment field, "if this member is absent, then any attachment modality is acceptable".

[zacknewman]

IMO number 2 could just as easily put "hybrid" before "security-key" as the RP desires - nothing about hints forces any of them into buckets, that should be an opinion established by RP's (or library maintainers.)

Ah, so it seems to be the case that "hybrid" is not contradictory to "security-key"/"client-device" nor more/less specific. This seems to imply there are 8 partitions then:

1. []
2. ["security-key"]
3. ["client-device"]
4. ["hybrid"]
5. ["security-key", "hybrid"]
6. ["hybrid", "security-key"]
7. ["client-device", "hybrid"]
8. ["hybrid", "client-device"]

which in turn means that if the spec intends to map hints to authenticatorAttachment as it presently seems to, then there are five other values that need to get mapped (again ignoring my claim that ["hybrid"] seems to be better mapped to nothing (i.e., an AuthenticatorSelectionCriteria instance with no authenticatorAttachment field) than "cross-platform").

[MasterKale]

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.

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 ["client-device", "hybrid"], know that a platform is unavailable in its own way outside the scope of this discussion, and decide to pop up the hybrid QR code instead because the browser knew it had enough prerequisites satisfied to perform a hybrid ceremony. Without the inclusion of "hybrid" the browser might have otherwise shown both hybrid and security keys when the RP isn't as interested in exposing security keys to their users.

I'll have to respond to your other points later, I'm heading back home from today's WAWG F2F ✌️