Initial text for conditional create

[pascoej]

Fixes #1929

---

Preview | Diff

[MasterKale]

Would anything in this proposal potentially blow up if we ended up in a future state where passkey providers offered users an option, entirely outside of the browser, to not silently register passkeys? That is, we'd have something like this:

• User turns off "allow sites to silently create passkeys" in their passkey provider

[A few hours later]

• RP sets up conditional creation with conditionalCreate extension
• User logs in with username + password
• Browser attempts to silently register a passkey
• Passkey provider says "nope"
• ???

Just trying to think ahead a bit, about potential controls that passkey providers might offer users (outside the influence of ostensibly user-centric WebAuthn) that would potentially clash with RP-friendly features like this one.

[pascoej]

I still need to address the non-requirement of the extension and sort out a procedural issue in order to submit a PR against credential-management.

[MasterKale]

The thought occurred to me over the weekend: how can the browser know an auth is successful if A) the RP cannot use the conditionalCreate extension, and B) the user doesn't use the browser autofill to enter username + password (because we're assuming the user can't use WebAuthn hence the desire to conditionally register a credential, and maybe they use a browser extension for password autofill that suppresses the browser's default autofill.) If conditionalCreateLifetimeTimer can be started by the browser without the use of conditionalCreate, it's unclear to me right now what heuristics a client might use to know when to start the timer.

[pascoej]

Associated credential management PR: https://github.com/w3c/webappsec-credential-management/pull/224

[nsatragno]

I asked for a few changes on the CredMan PR, but I don't think they will affect the integration on webauthn -- thanks!

My question about the extension requirement still stands. We can gain a lot from decoupling conditional creation from conditional assertion at the spec level.

[pascoej]

I've addressed comments and added more clarification that the extension is not required.

[MasterKale]

There doesn't seem to be anything in here addressing users with multiple available providers. When a user has a security key inserted, has iCloud Keychain enabled, and a third-party provider integrating OS passkey provider APIs, which of these receives the silent registration response?

If this might be handled via client configuration, can we add verbiage in here requiring clients to offer users with such a configuration capability? I think the behavior of conditional creation could get very confusing very quickly if it's left up to the clients to figure out what to do here.

[timcappalli]

3 concerns I have from the 2024-03-27 meeting:

1. UP and UV are not occurring during the WebAuthn create ceremony
2. There is no binding between the autofill provider and authenticator
3. This doesn't seem realistically interoperable until there is a better client solution for extension-based passkey providers

[timcappalli]

Here's a proposal based on the discussion and concerns expressed yesterday:

• When conditional create is used, UV and UP MUST be 0/false unless UP or UV is performed as part of the WebAuthn ceremony.
• Conditional creation requests SHOULD use UV=preferred or UV=discouraged for a more predictable result.

As was mentioned during the discussion, since conditional creation is an opt in feature for RPs, so changes are required by the RP, and the RP's logic will need to match the use case and flow, which means accepting a response with UP=0 and UV=0.

This balances the concerns about redefining UP and UV with the usability enhancements that are brought by conditional create.

NOTE: there are CTAP changes that will need to be made, likely as part of CTAP 2.3, for this to be supported with security keys for feature/experience parity.

[timcappalli]

The verification step needs to be updated as well to add an if mediation=conditional check.

1. Verify that the [=UP=] bit of the <code>[=flags=]</code> in |authData| is set.

https://github.com/w3c/webauthn/blob/89f204f4b1b02a147dfcdee4fbd88319cab5e104/index.bs#L5372