WPWG Virtual Meeting

20 Oct 2020



Ian Jacobs (W3C), Ciciley Nelson, Hervé Robache (STET), Gildas Le Louarn (Linxo), Tetsuya Kono (JCB), Danyao Wang (Google), Adrian Hope-Bailie (Coil), Anne Pouillard (Worldline), Jean-Michel Girard (Worldline), Manoj Kannembath (Visa), Jonathan Grossar (Mastercard), Fawad Nisar (Discover), David Benoit, Gerhard Oosthuizen (Entersekt), Frank Hoffmann (Klarna), Chris Dee (FIS Global), Gavin Shenker (Visa), Andy Estes (Apple), Olivier Maas (Worldline), Lawrence Cheng (Barclays), Myungho Han (INCA), Chris Wood, Bryan Luo (Amazon), Jonathan Vokes (FIS Global), Mathieu Hofman (Stripe), Jalpesh Chitalia (Visa), Takashi Minimii (JCB), Clinton Allen (American Express), Florent Lambert (Lyra Networks), Giulio Andreoli (Apple), Tomasz Blachowicz (Mastercard), Justin Toupin (Google), Dave Fortney (The Clearing House), Nick Telford-Reed, Benjamin Tidor (Stripe), Desigan Chinniah (Coil), Erhard Brand (Entersekt)


Web payments architecture

[Adrian Hope-Bailie slides on architecture]

Ian: Adrian and I have done some work in conversation with others to start thinking about architectural ideas that would build on v1 of PR API based on high value capabilities people have identified. We may find that we want to break PR API into smaller composable capabilities.

Adrian: There is no consensus on this proposal; just for discussion with the WG
... Goals: (1) lower friction (2) high security (3) Privacy protection
... want to reduce typing to lower friction, but also fewer clicks
... we want high security to meet various SCA requirements, risk-based requirements
... want user consent esp. for cross-origin data sharing
... Assumptions (1) origins security policy of the web (2) risk is evaluated based on data (3) data collection is bad for privacy (4) payment initiation often happens in 3p context (5) browsers are limiting 3p powers such as access to cookies

[Adrian shows 4-corner generic payments model]

Adrian: The browser sits in the "interop" domain, between user and merchant, and as a broker in various relationshiops
... Our original thought was that the browser could open a pipe between merchant and RP for data exchange (via the browser)
... but our newer thesis is that we want to provide more options
... we want to consider a wider variety of use cases directly, rather than simply relying on the presence of payment handlers
... we have endeavored to identify some primitives that can be mixed and matched in various flows
... the first of these is instrument/payment method selection
... the user decides how to pay and invokes (implicitly) a relying party.
... the RP may be invoked in a variety of ways
... some examples include entering card info in a form (and PSP speaks to server) or selecting a wallet button
... we'd like to also include "selecting browser-stored credential" to this list
... we are thinking about how to create a payment credential selection UX that does not rely on Payment Handlers (but without proposing to get rid of PHs)
... assume we have a credential stored in the browser that the user can select (without going into details about the shape of this credential).
... a couple of paths are possible: (1) responsible payment handler is invoked to handle the payment or (2) the merchant / PSP receives information about the selected credential and interacts with the RP using traditional rails
... so there are two main paths: through merchant channels, or through payment handlers
... today we'd like to talk about use cases for the non-payment-handler use cases
... and talk about what might happen (e.g., event fires in merchant environment when user selects an instrument)
... the merchant receives an identifier to contact the RP with info about the selected instrument.
... in the case where we have browser-stored credentials, what might the UI in the browser look like?
... could the UI vary based on the use case (e.g., minimal UI we have discussed would not suffice if we are also taking into account shipping addresses)
... A "payment credential" is an abstraction that could represent an instrument, or a user identity. From the user perspective, they see the same thing.
... But either a PH could be invoked, or the payment credential could be returned to the merchant

Gerhard: Do we know if there is interest from the merchant in getting a list back (that they can control)?

AdrianHB: I think we won't give the merchant a list for privacy reasons.
... We've also thought about the "add new X" use case, where the merchant can take the user down an enrollment flow
... we'll get to that shortly.
... Next assume that the RP has received the payment request event. The PH can open windows, authenticate the user, confirm the details
... and it would be great for the payment handler to be able to invoke SPC without showing its own UI
... so the RP could have an easier time shipping a payment handler if most of the time no UX is required
... the payment handler could get a list of credentials from a server and invoke SPC to authenticate the user
... meanwhile, in use cases without payment handlers, it could work as follows:
... the user has selected an instrument or a wallet...the merchant (or PSP) should be able to use SPC to authenticate the user based on the received payment credential information
... today merchants need to embed a RP in an iframe or, even more commonly to redirect the user to the RP. But the redirect is not a good UX and there's always the risk the user won't come back.
... so another core architectural component we've heard interest in is "in-context" display on the merchant side in a payment context (similar to what Payment Handlers can do)
... this would allow the PSP to create a non-redirect UX for enrollment flows and for "card-on-file" use cases.
... some questions: exposing the in-context display with a 1p context...is that safe?
... one potential way to increase the security is that we limit the origin of code that can run in the modal window to the same origin as the selected payment method.
... so for example, suppose google stores a Google Pay credential in my browser, and the user has selected to pay with Google Pay, then the merchant could leverage the in-context display, but only from the google pay origin
... Last piece: In the case of a payment handler, the payment handler gets a payload from the RP and returns details to the caller of PR API
... and that information is used for payment authorization
... Summary: We are thinking of breaking functionality into some component capabilities:

Adrian: A key idea here is to enable some powerful capabilities but only in a "payment context" after the browser has shown something to the user and there is confidence that the user has explicitly entered a payment context
... so, for example, the "instrument selected event" would only be emitted in a payment context
... and in that event handler, could enable some powerful features because user has chosen this path
... some examples might be:

[Reviewing primitives that are suggested by this architectural model]

[More on in-context display]

[More on SPC]

[More on stored credentials]

Adrian: We want something "like a cookie" that has a few properties:

Adrian: We need to figure out what the identifier would look like....don't want it to be used for tracking. But PSP needs to be able to route information to the relevant party.
... Controlling origins of payment credentials can enumerate, delete, add, update from 1p context
... but they are managed independently of cookies (and would be more long-lived)
... The architecture intends to support both flows: selected credential given to caller of PR API OR selected credential given to responsible payment handler
... Payment credentials as a class could be managed separately by the user in the browser (e.g., when to clear them or update them)

[Adrian describes a flow using components from this architecture: instrument selection + 3DS + SPC]

[Adrian describes a flow with a traditional digital wallet where the handler info is stored in browser, and the handler opens the modal window]

[Adrian describes a flow where the user selects a credential linked to a payment handler that does SRC. User selects Visa payment handler invokes SPC to authenticate the user and doesn't open a window itself]

tomasz: You describe use cases where stored credentials are returned to PSP/Merchant or to payment handler. Payment handlers have limited storage capabilities, so if we could have more storage opportunities for key payment information, that would be interesting

mhofman: Great to see interest into breaking PR API into smaller features that can be leveraged by PSPs/merchants
... you mentioned a selector for instruments
... there might be ways to give more UI control to merchants on how to present payment credentials
... e.g., opaque identifier and web components
... so the merchants could arrange things on the page without knowing what's there.

AdrianHB: that might also help to solve for the hasEnrolledIInstrument challenge

mhofman: I've had an idea for a while to get a list of credentials without knowing what they are, just the number of them.
... other topic - if you need to re-authenticate there are scenarios where (1) user has not selected instrument or (2) instrument is known to user but not stored in the current browser

AdrianHB: One idea for that is that the merchant provides credentials that could appear in the selector ("card on file integration")

mhofman: I am thinking of card-on-file but the card has no corresponding credentials in the browser. You'd have to go through 3DS enrollment.

AdrianHB: You can't be confident about the payment context, but still want the powerful features. Thanks for identifying that use case.

Danyao: Let's have a hallway chat on this!

IJ: How and in what forum should we continue discussions?

AdrianHB: My last slide shows important considerations. We'd love feedback. We can continue on the main WG agenda after people have reviewed the architecture proposal.

Mastercard and SRC

[Jonathan refers to objectives spelled out in the proposed architecture for SRC with PR API and specifically the value proposition for SRC through Payment Request]

JonathanG: Updates since previous meeting on SRC-through-PRAPI using payment handlers. We'll also look at potential benefits of SPC for these flows.
... Main objectives are (1) streamlined user experience (2) authentication (3) merchant choice
... Mastercard has been investigating use of payment handlers. In April we discussed the user of a "common payment handler" with limited functionality.
... the idea at the time was simply to redirect to an SRC-I
... we have been exploring an alternative approach since April, where there is one-card-per-payment handler.
... each SRC system would operate its own payment handlers. Payment handler speaks to SRC system. is installed whenever the user adds a new card.
... a benefit of this approach is that it leverages existing browser capabilities
... network DCFs can install payment handlers during an SRC checkout. Or, the bank can do push-provisioning. Or, the user can install a payment handler when visiting the SRC administration page.
... payment handlers can leverage indexDB to store information used to authenticate the user for subsequent transactions
... payment handlers can be invoked using network-specific PMIs
... payment handlers can already use issuer authentication or FIDO authentication (but this requires opening its own window).

[Slide showing benefits of using payment handlers ]

[Slide showing how SPC could further help]

JonathanG: We are excited by these new capabilities; they are complementary to SRC.
... we wanted to be sure that SPC could be used in other contexts, usable by merchants, payment handlers, etc.
... we can see two use cases:

  1. RP is the bank. The DCF can use the bank's FIDO credentials to authenticate the user
  2. RP is the SRC system.

JonathanG: in the second use case the card payment handler can authenticate the consumer with FIDO without the need of opening a new window (the browser manages the auth)
... the displayed data is very useful for transaction confirmation / dynamic linking use cases
... it's also good for payment handler to be able to return authentication assertion data to the merchant in the PR API response.
... Another topic of interest is the source of randomness as input to Web Authentication. We are interested in avoiding the roundtrip to a server and having the browser generate the source of randomness; we realize this is still under discussion

[JonathanG shows some user experience slides]

[JonathanG shows an example of how experience could be augmented through SPC authentication flow]

[Tomasz walks through flow diagrams]

<scribe> ACTION: Ian to ask Tomasz to add new flow diagrams to SRC flow page on GitHub

[UX question that appears on the slide: The browser will ask for consent to install the payment handler (at enrollment). Would it be possible to not prompt the user for consent given the context -- the user is either intentionally adding the card from browser settings or has already agreed to add the card to the browser.]

[Tomasz summary:]

Tomasz: Would be great to combine consent in a streamlined enrollment process

[Transaction flow]

Tomasz: The slide shows "index db" but in the future that could be one of the "payment credentials" that Adrian discussed
... it is also interesting in this flow that the authentication flow could be achieved through SPC without the payment handler opening a custom window

Chris_Wood: Why are you excluding roaming authenticates from the design?

Tomasz: The user experience with roaming authenticators is pretty poor today, so we are likely to skip webauthn in that case.
... We also plan for fallback authentication when built-in authenticators not available. We want to keep friction low

JonathanG: We could, of course, expand the design as the ecosystem evolves.

Chris_Wood: Cf also my comment about discoverable credentials.

JonathanG: SPC will also facilitate the selection

btidor: I want SPC to address this question. Part of the value proposition should be to extend visibility into world of remote authenticatos
... I think the seamless fallback should be preserved

Visa and SRC

[Visa slides on SRC and SPC]

Gavin: What we'll show here first in mockups is how we could use SPC with (basic) SRC
... here we are referring to SRC implemented on the user side (without a payment handler)
... we are sharing mockups here (independent of the demo)
... user experience starts in the issuer's app on a mobile device.
... the user can enroll a card for use in SRC flows.
... the user can check a box if the device supports a platform authenticator to be authenticated in future transactions.
... the user enrolls the authenticator. The SRC system is the RP in this flow.
... During the transaction flow, please note that the merchant retains full control over the UX
... during checkout the user selects a card from a list. Under the hood some stored data is used to store the user's SRC identity.
... if the user consumer chooses a card enrolled to use SPC, the user sees the SPC verification prompt, authenticates, and that completes the transaction

Tomasz: Enrollment happens on the issuer domain. So isn't the issuer the RP?

Gavin: We want the SRC system to be the relying party.

IJ: What is the origin of the RP?

Jalpesh: Visa.com

[Manoj Kannembath does a demo]

JonathanG: Can Visa.com prompt for SPC during enrollment as well?
... because the mocks show the bank's Web site. But the idea is to enroll a credential with the SRC origin

<btidor> I think Tomasz is right -- the entity that registers the credential is what we've been calling the "controlling party" -- they enroll the credential, and have permission to update the name/logo/etc. in the future. But one of the properties we've been thinking about for SPC is that we want the credentials to be "independently verifiable", so if the public key is shared between the issuer and the SRC System, both parties can verify future assertions.

<btidor> Would that be helpful?

JonathanG: ...SPC allows "get" from another origin. Is it also possible to do "create" on behalf of another origin?

Danyao: Right now that's not possible. We assume that enrollment requires the RP to verify the user in a 1p context
... Does the user have to be on the bank's web site, or could they do so on an SRC origin?

Tomasz: If visa is service provider for bank, then enrollment has to happen (today) on visa origin.

Manoj: When we register the credential, I am hearing that the user would have to see visa.com (instead of fdnb.com)

Tomasz: If you leverage SPC, you don't need the SRC system to be the RP
... the bank can be the RP

<AdrianHB> A redirect to the RP for enrolment that immediately redirects back to the bank after would work...

btidor: I like this flow; I think we should find a way to support it.
... I really like the "remember me" checkbox in the UX

JonathanG: Let's take this up in the card payment security task force

<AdrianHB> +1

[Demo shows user logging into issuing bank, seeing a list of cards that can be enrolled into SRC]

[During transaction, user pushes click-to-pay...merchant renders list of SRC cards available to the merchant through the SRC system]

[When the user selects the SPC-enabled card, the browser UX appears to allow the user to verify the transaction, then use biometric authentication]

IJ: How do you populate the list of cards across sites?

Manoj: The card is available across any merchant that is integrated across SRC

Jalpesh: The SRC system is using local storage.
... in this case visa.com is using local storage in the merchant site
... other origins can similar store cookies

<Zakim> Ian, you wanted to ask questions about what next for this in the real world?

<nicktr> ian: I am hearing mastercard has gained experience with a Payment Handler

<nicktr> ...that is a little different from the original architecture

<nicktr> ...Also, there is interest in the SPC features

<nicktr> ...So my question is "what would the schemes like us to do?"

Jalpesh: From a Visa perspective, we'd like to scale the proof of concept and test it out
... we'll continue to work with the Stripe/Google folks on this, and we'd like to get scale across more platforms
... we like the flexibility of the merchant having the choice to list cards themselves, or for the browser to display payment handlers

<nicktr> ian: what other features would make this even better?

JonathanG: I agree with Jalpesh's point on merchant choice to manage the UX as they want
... I also agree with the idea of setting up a proof of concept
... the common capability is SPC
... we can debate "what's missing" in the task force

tomasz: I would add to the list of desirable features: the ability of the payment handler to use SPC (specifically trigger webauthn without having to open a window). I would also like to see how we can leverage credential storage and have credential info pushed into the payment handler.

NickTR: Any comments from American Express, Discover, JCB?

Clinton: I think both proposals are interesting
... more analysis is needed from Amex perspective. Much appreciated for the overview!

NickTR: Thanks to all the contributors!

[Adjourned until tomorrow at the same time]

Summary of Action Items

[NEW] ACTION: Ian to ask Tomasz to add new flow diagrams to SRC flow page on GitHub

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version (CVS log)
$Date: 2020/10/21 03:07:40 $