How do RPs determine when to enroll the user?

[ianbjacobs]

Here's the challenge:

• The RP keeps track of enrollments, and is aware of one enrollment for an instrument.
• But if, for a given transaction, suppose the user chooses to cancel.
• If that is indistinguishable from "no matching credentials" then the RP does not know whether to offer to enroll the user on this device (which might be a different authenticator than the one it already knows about).

[ianbjacobs]

Relates also to issue #98

[rsolomakhin]

the RP does not know whether to offer to enroll the user on this device

This should work:

Prompt: Would you like to check out faster next time by using Touch ID?
Buttons: [Confirm with Touch ID] [No Thank You]
Checkbox: [✔️] Opt out. You can also change this option on your bank website.

[stephenmcgruer]

This should work: [...]

I would consider that a poor experience for a user who is already enrolled on this device, but whom declined SPC authentication during the current transaction (for whatever reason, maybe they cut their finger and their fingerprint reader isn't working).

[stephenmcgruer]

The relevant section of the WebAuthn spec, which SPC (deliberately) inherits its behavior here from is Authentication Ceremony Privacy:

In order to protect users from being identified without consent, implementations of the [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) method need to take care to not leak information that could enable a malicious WebAuthn Relying Party to distinguish between these cases, where "named" means that the credential is listed by the Relying Party in allowCredentials:

• A named credential is not available.
• A named credential is available, but the user does not consent to use it.

Note that SPC makes the attack more serious, as it opens it up to any malicious site that has obtained credentials from the Relying Party (legitimately or otherwise).

[rsolomakhin]

I would consider that a poor experience

I just realized that I addressed Ian's 3rd bullet point while thinking about 1st time users without credentials on file with the RP. Please ignore my comment!

[rsolomakhin]

Thinking about this some more, this flow seems sensible:

1. User attempts a transaction.
2. RP does not approve and asks the merchant to perform SPC with credential A.
3. Merchants requests SPC authentication with credential A.
4. User either does not have the credential on file, has trouble with biometric device, or refuses to provide their identity to the merchant by clicking [No] in SPC.
5. Merchant does not know which of these is the case.
6. Merchant and the bank perform an SMS OTP verification of the user.
7. The transaction is approved and is processed.
8. Merchant embeds the bank iframe on the page, which prompts the user to enroll a credentia as per How do RPs determine when to enroll the user? #124 (comment).
9. User either enrolls a new RP credential, refuses to do it, or opts out of enrolling SPC credential on this device entirely, for now.

The possibility of opting out is not necessary, but can be a nice touch for some users.

[stephenmcgruer]

The current state of the art in WebAuthn is to use a cookie to track registration status for a given user+device:

1. During registration, drop a cookie on the device.
2. In a later visit to your website, check the cookie and use WebAuthn if its present.

This works 'ok' for WebAuthn, though developers have still complained that things like users clearing cookies breaks their WebAuthn flows.

For SPC, using a cookie works less well:

• Merchants cannot rely on such a cookie for auth-time detection, because they aren't the RP. So they just have to call SPC and hope. (See steps 3-5 of Rouslan's flow).
• If the Merchant escalates to the Relying Party (steps 6-8 of Rouslan's flow), the Relying Party in an iframe can still get at cookies... in some browsers... for now. (Aka this will be broken if/when browsers remove 3p cookies, I believe).

To combat the general issue of 'how do I know the user has a credential' at auth-time, WebAuthn have suggested a semi-passive model (Conditional UI):

1. The Relying Party website includes an autocomplete field with a special-known id (webauthn-complete or something)
2. The Relying Party website then makes a 'hanging' WebAuthn call, saying they support Conditional UI
3. The browser displays non-blocking UI to the user, offering them the option to use their credential if they have one.
4. If the user does so, the website gets an event fired at the autocomplete field with the result
5. Else, the website just never hears from the browser

Websites are meant to handle step 5 by having alternate ways for the user to sign in, e.g. username/password.

The Conditional UI approach is interesting but does not immediately apply to payments I think, nor to the enrollment question. (E.g. if the user logs in with username/password in the above example... do you offer to enroll them now?)

[ianbjacobs]

This was discussed at the joint meeting today at TPAC with WPWG, WPSIG, WebAuthn, and Antifraud CG. It seems that the Web Authentication Adoption CG intends to publish some materials to help RPs know when to enroll the user. I understand they will describe a number of enrollment opportunities (including, e.g., when the device could support enrollment and the user has just elected to log in with a password).

I'll keep this open for now, but we should monitor progress in the adoption CG.