Open ianbjacobs opened 2 years ago
Relates also to issue #98
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.
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).
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).
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!
Thinking about this some more, this flow seems sensible:
The possibility of opting out is not necessary, but can be a nice touch for some users.
The current state of the art in WebAuthn is to use a cookie to track registration status for a given user+device:
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:
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):
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?)
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.
Here's the challenge: