Discussing mechanisms for enterprise RP's to enforce bound properties of credentials

[MasterKale]

This week at WWDC Apple demonstrated the ability of one iCloud user with a registered passkey to share that passkey with another individual on a separate iCloud account. The implications of this in the enterprise space are dire as it means that RP's like Duo can no longer ensure that a platform authenticator response matching a stored public key corresponds 1:1 to the user we originally associated that credential with.

The current state of the spec lacks much configurability to support enterprise RP use cases. Shareable credentials threaten to make it untenable for RP's to continue to leverage WebAuthn as platform vendors evolve authenticator capabilities more quickly than the API evolves.

We should start collecting additional RP concerns and discussing how WebAuthn might evolve to address enterprise RP concerns now that many of the consumer use cases are being addressed with Apple's, Google's, and Microsoft's upcoming passkey support.

[MasterKale]

To help clear things up, I'm referring to Apple's demonstration of shareable passkeys in this WWDC session: https://developer.apple.com/videos/play/wwdc2022/10092/

[sbweeden]

I believe this is closely related to #1688

[emlun]

See also discussion in #1714

[sbweeden]

Perhaps wild suggestion. If an RP requests direct attestation, why wouldn't the platforms offer a device-bound credential in this case?

[MasterKale]

Particular asks for supporting use of WebAuthn by enterprise RP's:

• Ability to request a device-bound credential and always get back direct attestation (@sbweeden)
• Ability to request a credential be permanently associated to the registering user (@master_kale) (opens the door to too many "bad" outcomes)
• <conversation goes way off the rails>

[sbweeden]

I'll try articulate in my own words the requirement I raised in the F2F:

As an enterprise RP, I would like a way to signal to the browser during a registration ceremony, that a device-bound key is required. This offers the client browser an opportunity to tailor the UX around this requirement. I'm explicitly avoiding saying "how" this is signalled (although it has to be some property(s) of the registration request), but ultimately my RP policy is that I wish to know that a credential is bound to a device, and then be able to ensure this remains true for subsequent authentications.

[emlun]

Perhaps wild suggestion. If an RP requests direct attestation, why wouldn't the platforms offer a device-bound credential in this case?

There's the use case where an RP wants to collect attestation for future use, but doesn't care whether it's device-bound, UV capable, cross-platform, or whatever. For example, to warn users if a security issue is discovered in a particular authenticator model. I don't think we should impose a device-bound-ness preference on that use case.

[Firstyear]

Here is a collection of use cases I submitted, as an RP that might help communicate what is desired as an RP, and might help you to design something appropriate. (right now most of them aren't possible due to some issue or another)

#1720 (comment)

[dwaite]

As an enterprise RP, I would like a way to signal to the browser during a registration ceremony, that a device-bound key is required.

Perhaps refine this to "hint to the client to guide UX during the registration ceremony, that non-device-bound keys would ultimately be rejected by the relying party"?

We could potentially define a registry of hints here, with the idea as well that not all clients will understand all hints at the time of registration (e.g. some browsers understand how to check an authenticator for a minimum certification level by a third party vendor).

[Firstyear]

Perhaps refine this to "hint to the client to guide UX during the registration ceremony, that non-device-bound keys would ultimately be rejected by the relying party"?

Any hint we add should have a direct relation to a flag in the registration process, such as the backup bits. A historical pain point for example is requesting resident keys, where there is no verifiable signal in response that an RK was actually created. So it would be good if we paired both the hint to the UX, with what the signed and attested response fields are so the RP can verify that the hint was followed and respected.

[rlin1]

Wouldn't DPK support (PR#1663) be sufficient? Essentially not preventing the multi-device key, but ensuring an additional single-device key being established per device.

[sbweeden]

Wouldn't DPK support (PR#1663) be sufficient? Essentially not preventing the multi-device key, but ensuring an additional single-device key being established per device.

I think so however it would have to include DPK attestation.

[Firstyear]

Wouldn't DPK support (PR#1663) be sufficient? Essentially not preventing the multi-device key, but ensuring an additional single-device key being established per device.

DPK is only known after the authentication and would be rejected by the RP during that process. And it relies on the authenticator providing DPK. DPK also isn't about creating a "per device key", it's still a key that is shared between multiple devices, but it allows the attestation to "follow" and roam with the multi-device key so that the RP knows when a new device has been used on the account allowing them to respond to that specific device now being a holder of that key material.

Imagine the workflow here as:

• RP sends challenge
• Client browser presents a UI for what authenticators are viable
• Authenticator is chosen and interacted with
• Browser sends response to RP
• RP either accepts or rejects the registration
• Client browser renders success or error.

Right now, we have to do this full process, and then render and error at the end. That then means the error has the burden to communicate to the user why their authenticator was not allowed to be used in this context. But this isn't nice for the user.

We have a step here near the start - the browser presents a UI for what authenticators are viable. If at that point we imposed a constraint, then we never need to error and communicate that to the user. They have a subset of their authenticators that are "more likely" to succeed in the ceremony. This is a better user experience, it's a lot easier to communicate to users, and RP's can produce a better workflow.

DPK would again, be sending is back to that full-error process, the same as "check the backup bits". What is being asked for here is the ability to guide that UX in a way that we have constraints available.

For more of a summary about this https://www.sachinrekhi.com/don-norman-principles-of-interaction-design

[rlin1]

I wouldn't do the last two steps that you proposed, i.e. "RP rejects registration" and "browser renders error".
In the ideal case, the RP receives a DPK extension signed with a (single-device) key that is already known. Essentially the trust level is equivalent to FIDO assertions today (i.e. before Passkeys).

Alternatively, the DPK extension could include a new (single-device) key (i.e. first time use of a device). In this case the RP might (or might not if password-only security level is sufficient today) trigger some kind of additional verification. This process is similar to what RPs would do today (i.e. before Passkeys): there is a new device, verify the user through some other method (=not using FIDO platform authenticator on this device) and then trigger registration of a new FIDO credential). The difference is that you do it in the inverse order with Passkeys, i.e. first get the new key through the DPK extension, and then (potentially) trigger additional verification.

The case without DPK is not as good, as the RP couldn't distinguish first-time use of the credential on a device from subsequent credential usage on a device - losing the ability to detect strong (in the sense of FIDO before Passkeys) device binding.

--> back to my previous opinion that DPK support would be sufficient for Enterprise RPs.

[rlin1]

... and: supporting attestation for the DPK is the only way to distinguish maliciously generated keys from keys generated by trusted authenticators.

Ideally, there would be attestation for the multi-device keys as well, so that the RP gets a strong prove of what kind of "sync fabric" is being used.

[Firstyear]

The case without DPK is not as good, as the RP couldn't distinguish first-time use of the credential on a device from subsequent credential usage on a device - losing the ability to detect strong (in the sense of FIDO before Passkeys) device binding.

There is difference in how DPK works for registration vs authentication. We want to block keys at registration so the features of DPK which are around attesting via authentication flows isn't relevant.

--> back to my previous opinion that DPK support would be sufficient for Enterprise RPs.

It's not.

Erroring "after" registration and trying to communicate why that error occurred is a terrible process. It will frustrate users. This is basic elements of human interaction psychology that we need to introduce a constraint before the process to prevent the user making the error in the first place.

PS: I'm a developer of an enterprise RP, and a generally RP library, so please don't try to prescribe what we need :)

[timcappalli]

DPK also isn't about creating a "per device key", it's still a key that is shared between multiple devices, but it allows the attestation to "follow"

This is not correct @Firstyear. The DPK is bound to a single device.

[timcappalli]

Erroring "after" registration and trying to communicate why that error occurred is a terrible process.

While I generally agree that this results in a poor user experience, this is not new and existed prior to multi-device credentials.

[emlun]

We understand that RPs want this and how it would help prevent frustrating user interactions. The debate (or at least a significant part of it) is whether this is a power we want to give to RPs. The TAG recommends that user needs come before the needs of web page authors. We don't want to end up with users needing to carry several different authenticators because RPs can't agree which are acceptable. Therefore, so far there has not been consensus in favour of supporting more powerful authenticator discrimination. Some is already possible using attestation, of course, but the additional work required from RPs to use it (as opposed to simply setting a parameter) has been deemed enough deterrent against abuse.

All that said, though, an argument in favour of something like #1744 is that a feature toggle could enable users to use an authenticator that would otherwise be rejected. For example if an authenticator uses cloud backup by default and would be rejected by an RP, disabling cloud backup for a particular credential might enable the user to use that authenticator for that RP. But on the other hand that makes it harder for the user to keep track of which credentials are backed up and not, which again is an argument against adding the parameter.

I think the devicePubKey extension (#1663) is an appropriate compromise. It's an up-front signal that the RP wants something hardware bound, but doesn't impose any restrictions on the primary credential.

[sbweeden]

The debate (or at least a significant part of it) is whether this is a power we want to give to RPs.

Yes please.

The TAG recommends that user needs come before the needs of web page authors. We don't want to end up with users needing to carry several different authenticators because RPs can't agree which are acceptable.

It can be argued this is putting users first, but delivering them the user experience required by the RP's policy.

Therefore, so far there has not been consensus in favour of supporting more powerful authenticator discrimination. Some is already possible using attestation, of course, but the additional work required from RPs to use it (as opposed to simply setting a parameter) has been deemed enough deterrent against abuse.

The consensus or lack thereof is from the platform vendors vs the enterprise RP camp. The settings that are already possible using attestation are again all POST-ceremony error handling, and not the orchestration of a ceremony that matches the RP's requirements.

I think the devicePubKey extension (#1663) is an appropriate compromise.

I'm not convinced it is, because:

• This is technically very difficult to adopt;
• Requires attestation itself to be trusted (which nobody has committed to delivering)
• Also requires for account sovereignty requirements an additional non-FIDO second factor or other identity proofing mechanism remain in place so that conditional application of it can be applied on new device registration (ie. when a passkey is used from a new device for the first time).

What the enterprise RP stakeholders are asking for is different. Give me a device bound credential assurance, and don't complete a registration ceremony unless that's what is going to happen. I'm not certain such an ask is entirely possible, since the device-boundedness cannot always be determined for "attached" authenticators, however that doesn't mean the RP should not be allowed to express their policy.

[Firstyear]

While I generally agree that this results in a poor user experience, this is not new and existed prior to multi-device credentials.

That isn't a valid excuse or reason that we can't fix this experience now.

The debate (or at least a significant part of it) is whether this is a power we want to give to RPs.

I feel like this WG has consistently only acted in the interest of device manufacturers and browsers, and leaves RP's to deal with a hot mess, that we need to somehow implement inside of all the other regulations and requirements that RP's have, and that it's up to RP's to try to create a somehow good user experience inside of a very poor canvas.

Which goes completely against the intent of trying to enable and create a seamless user experience, when instead we are creating a scenario for many tiny bad ones that will frustrate users.

All that said, though, an argument in favour of something like #1744 is that a feature toggle could enable users to use an authenticator that would otherwise be rejected.

There is already precedent to this, because google chrome would only show you a security key prompt even when touchid and other sources were available, and made the toggle to find other credentials basically invisible. It was only in self-interest when android caBLE was being released that they changed it to force that caBLE and android was always an option. For all the comments about trying to create a good user experience where users can use whatever device they want, this immediately collides with reality where chrome has disallowed that in the past. The irony is further not lost on me, that google itself doesn't accept anything thats not a u2f key at the moment it seems (I've tried to enroll touchid and it doesn't work, google backend rejects it without prompting as to why.).

What is a problem here is that workplaces and enterprises exist and we have requirements and regulations that we need to up hold.

A toggle that allows the user to "yolo let me just wreck my experience" would be fine provided that we can guide that initial UI/UX, but we are then back to the hostage situation of then getting chrome to implement it.

What the enterprise RP stakeholders are asking for is different. Give me a device bound credential assurance, and don't complete a registration ceremony unless that's what is going to happen. I'm not certain such an ask is entirely possible, since the device-boundedness cannot always be determined for "attached" authenticators, however that doesn't mean the RP should not be allowed to express their policy.

Fully. Agreed.

To further this, when we know the make and model of the keys we issue, why both prompting for caBLE when only a usb-yubikey would work. That's why we want to have these flows.

If you want to read about this in excruciating detail, https://fy.blackhats.net.au/blog/html/2022/06/13/exploring_webauthn_use_cases.html

[sbweeden]

In the June 29 meeting the question was asked as to why the current DPK proposal is insufficient and why RPs are requesting the ability to indicate more stringent requirements to the client during credential registration. I offered to provide a perspective on this ( FYI - @timcappalli ), so have initially picked two things to further the discussion:

• Account sovereignty of multi-device credentials results in ongoing reliance on alternative (often phishable) second factors.

  • If multi-device credentials (more specifically those backed up to a user's platform-provider cloud account) are not able to be excluded by RP policy during credential creation, the spec is essentially dictating that all RPs must figure out a way to make them acceptable (otherwise you have the undesirable fail-after-register UX).
  • If DPK + a risk engine is the answer to accepting multi-device credentials, then what does the RP do when the risk engine sees first use on a new device? Sites that require control over account sovereignty will need to require some additional level of assurance, typically an existing phishable multi-factor capability. This is exactly what most adopters of WebAuthn want to move away from - and not just because it is phisable, but because it shouldn't be necessary to create and manage the lifecycle of such additional mechanisms in the first place.
  • WebAuthn with attestation and a guarantee of device-bound credentials offers a way to provide a single step login experience that covers requirements of both account sovereignty and strong phishing-resistant authentication. Multi-device credentials with account sovereignty controlled by the platform provider takes this use case backward, and will see (IMO) all these types of RPs having to maintain alternative 2nd-factor capabilities indefinitely.
  • The counter-argument is account recovery is too hard. Regulated industry and enterprise RPs understand the challenges of account recovery and are prepared to deal with this in other ways. They are unwilling or legislatively unable to accept that account sovereignty is governed by the account a user has with a platform provider.

• Extensions are optional in the spec, and DPK attestation is not mandatory.

  • There is already a public implementation of multi-device credentials that does not supply DPK. DPK can not be considered a trusted signal unless attested, and it has been made clear that there are plans for a DPK implementation on Android later in 2022 which will not include attestation.
  • Given this state in the real world (no DPK, or DPK without attestation), it is apparent that there is no way for an RP with device-bound requirements to actually express that to the client. One might argue that's a point-in-time statement, but unless the specification makes some of these optional things mandatory RPs with the aforementioned requirements will still find themselves unable to ask the client to: "please do what we will accept, or don't do anything at all".

[dwaite]

If multi-device credentials (more specifically those backed up to a user's platform-provider cloud account) are not able to be excluded by RP policy during credential creation, the spec is essentially dictating that all RPs must figure out a way to make them acceptable (otherwise you have the undesirable fail-after-register UX)

I think this is still an inevitability. At most, we can provide a UX to hint to the client to try to optimize this, but the client may not understand that hint (or have appropriate UX to represent it to the user)

"please do what we will accept, or don't do anything at all".

This may not be possible, as such a decision has user state behind it which may leak. The user may instead get a modal interface they try and fail within, rather than those failures being exposed to the relying party. I would not expect a silent, immediate failure if say no USB security keys are currently connected to the device.

IMHO that has been the impetus for a try-and-fail approach; the RP is both ceding some ability to control messaging on requirements and on failures to the user, and their ability to get metrics on user failures. Both of those are known reasons why prior browser-integrated authentication schemes have failed to get traction.

[Firstyear]

If multi-device credentials (more specifically those backed up to a user's platform-provider cloud account) are not able to be excluded by RP policy during credential creation, the spec is essentially dictating that all RPs must figure out a way to make them acceptable (otherwise you have the undesirable fail-after-register UX)

I think this is still an inevitability. At most, we can provide a UX to hint to the client to try to optimize this, but the client may not understand that hint (or have appropriate UX to represent it to the user)

By being able to send a UX hint, the credential shouldn't even be listed for the usere to select in the ceremony, meaning that they are guided to a valid credential that can be used.

The alternative is they perform the whole ceremony then are dropped to an error screen that tries to explain why it failed. Which is much harder to communicate.

[MasterKale]

I'm going through issues assigned to me and this one hasn't had any activity in over a year (aside from editing milestones.) I think we should consider closing this out because my gut's telling me, as of January 2024, that there's nothing in here not already captured in other issues created since June 2022.

[MasterKale]

It's time to close this out.

[arianvp]

FWIW Apple has made some improvements in this field:

Passkeys are now available for Managed Apple IDs https://developer.apple.com/videos/play/wwdc2023/10263/

• They can not be shared between users
• There is an attestation statement that proves the Passkey is stored in an iCloud Keychain of the managed Apple ID
• There is an optional attestation statement that the Passkey is only accessible on managed devices

This means an RP can enforce that Passkeys are only used from managed devices

https://developer.apple.com/documentation/devicemanagement/securitypasskeyattestation

This is not hardware attestation though. Hardware attestation only happens for devices (in MDM setting) not for users.