search

w3c / secure-payment-confirmation

Secure Payment Confirmation (SPC)
https://w3c.github.io/secure-payment-confirmation/
Other
111 stars 40 forks source link

Special UI for SPC credential enrollment #84

Closed Eric-Alvarez closed 3 years ago

Eric-Alvarez commented 3 years ago

On the topic of whether the enrollment of an SPC credential should have a special user interface different than a typical WebAuthn credential enrollment.

If the special SPC enrollment UI is removed then there are at least two major downsides.

  1. Implementors of SPC need to create their own user interface to prompt users to enroll an SPC credential whereas the existing API does not require this. With this comes the challenge of localization and maintaining different text for each country where the implementor wishes to use SPC- a significant amount of additional work.

  2. User familiarity. When prompted for SPC authentication for the first time the user has the ability to link the familiar browser modal they used during enrollment and understand and trust what they are being presented with. If this browser modal is not used during enrollment there is a chance the user is confused or does not trust the modal they are being presented as they have never seen it before.

Given these downsides it seems preferable to continue using the browser modal during the enrollment of an SPC credential.

stephenmcgruer commented 3 years ago

Thanks for filing this, Eric.

To give the other perspective, if the special SPC enrollment UI is kept then there are the following downsides:

  1. Increased friction and loss of control for Relying Parties (e.g. issuing bank, or PSP, etc) who already have or would present their own UX for enrollment. The user has to click through two dialogs and an authenticator interaction to enroll.
    • We also have ample evidence that browsers building UX that could instead be built by websites tends not to work very well (e.g. see basic-card).
  2. We (Chrome) are looking to a future where SPC uses vanilla WebAuthn credentials. At that point, enrollment for SPC shouldn't be anything special - and thus shouldn't involve a special UX.
  3. The UX in it's current form (as implemented in Chrome) does not make sense when a credential is not tied to a specific payment instrument. This could be fixed, but will require more UX work.

The user familiarity point does resonate with us; we'd be interested in thoughts from other folks who are experimenting with SPC currently.

ianbjacobs commented 3 years ago

@jcemer, thoughts on this?

jcemer-stripe commented 3 years ago

+1 on what @stephenmcgruer is saying.

I think that it is the best to not have the browser enrollment UX, removing it brings parity to SPC and WebAuthn.

Having a full control of the enrollment experience is a big help to iterate on the enrollment design and land the messaging that works best for each particular case.

ianbjacobs commented 3 years ago

I was wondering whether browser UX that displays the origin of the RP during enrollment would reduce the risk of fraudulent sites registering users (e.g., pretending to be the user's bank). However, it may not be a problem in practice because SPC authentication won't likely succeed unless the user has enrolled with the real RP.

stephenmcgruer commented 3 years ago

browser UX that displays the origin of the RP during enrollment

That information is already available in the WebAuthn dialog (may differ per platform, but all platforms I know of show something like 'verify your identity on bank.com')

stephenmcgruer commented 3 years ago

As per discussion in the SPC Task Force (https://www.w3.org/2021/08/23-wpwg-spc-minutes), we agreed that V1 of SPC will not include a enrollment-time UX as part of the spec (implementors are of course free to add their own, the spec allows for that). We're going to close this issue, and it can be reopened if we hear stronger need for it from more industry partners.