Initial text for conditional create

[pascoej]

Fixes #1929

---

Preview | Diff

[agl]

Further up this change says:

prominent modal UI should not be shown unless the user has already consented to create a credential via the [=conditionalCreate|conditionalCreate extension=])

That suggests that a conditional create() shows a modal UI unless the user refused consent to create a credential during the previous conditional get(). It sounds like it's a way to avoid bothering the user with a modal creation UI if they didn't "opt-in" to being bothered during autofill. (Which is different from "the create() can resolve silently if the user consented previously".)

While user agents can ultimately implement any UI, how do you want sites thinking about how to use this extension?

[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.

[nsatragno]

Really excited for this! I'll summarize my thoughts I shared in the w3c call:

• As it's written, making a credential through conditional registration requires opting in to a conditional get assertion. We should relax this requirement: it should be acceptable for an RP to offer conditional registration after the user opts in (e.g., after they chose a previously saved password in a sign in form) without also requiring them to offer previously registered passkeys on the same form. An example use case would be to create a passkey from a password field during registration (see WebAuthn Autofill (Conditional UI) for credential registration #1862). I understand you are using the get assertion extension to collect consent, but I don't see why consent needs to be tied in to a get assertion call.
  If we go this route, perhaps we can do away with the assertion extension, and instead have a create request with mediation: conditional that handles obtaining consent. When it resolves, it could either run a callback or return a promise with a method to fill in the username, challenge, etc.

• CredentialCreationOptions needs to be updated to have a mediation parameter.

[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: w3c/webappsec-credential-management#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.

[timcappalli]

One small change from 2024-04-03 call

[timcappalli]

s/SHOULD/MUST

[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.

webauthn/index.bs

Line 5372 in 89f204f

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

[emlun]

This section is the client operation, but this is a requirement on the authenticator. This needs to go in section 6 (WebAuthn Authenticator Model) instead, or be rewritten in terms of how the client is to set the arguments to the authenticator operation.

[emlun]

The flow here is a bit convoluted, I would formulate it something more like this:

Suggested change

	:: If <code>|options|.{{CredentialCreationOptions/mediation}}</code> is set to
	<dl class="switch">
	: {{CredentialMediationRequirement/conditional}}
	:: throw a {{NotAllowedError}} {{DOMException}} unless it can be explicitly collected during the ceremony.
	: empty or another value
	:: Let |userVerification| be [TRUE].
	</dl>
	:: 1. If <code>|options|.{{CredentialCreationOptions/mediation}}</code> is set to {{CredentialMediationRequirement/conditional}}
	and [=user verification=] cannot be collected during the ceremony,
	throw a {{NotAllowedError}} {{DOMException}}.
	1. Let |userVerification| be [TRUE].

[emlun]

Also, is NotAllowedError the right behaviour here? The closest analogue currently in the spec is the "error code equivalent to ConstraintError" returned by the authenticator when UV is required but cannot be satisfied by that authenticator. Returning an error at all also differs from conditional mediation in get(), which simply hangs forever on most errors. Should conditional create do that too?

[pascoej]

The idea with conditional registration is that you invoke it right after logging in and get a result quickly. If the user didn't consent to this type of create, then they will quickly get an error, otherwise a credential.

I think ConstraintError does sound okay in this case. I've made the change.

[timcappalli]

LGTM

[MasterKale]

Note to self: this new case for ConstraintError will need to get documented in the same Registration API Exceptions being proposed in #2047.

Can be addressed in Emlun's followup.