WPWG Meeting

01 Apr 2020



Clinton Allen (American Express / EMVCo), Giulio Andreoli (Apple), Dirk Balfanz (Google), Andrey Bannikov (Facebook), David Benoit, Tomasz Blachowicz (Mastercard), Sofiane Boumedine (Canton), John Bradley (Yubico), Erhard Brand (Entersekt), Donovan Changfoot (Coil), Chris Dee (FIS Global), Jean-Luc di Manno (FIME), John Fontana (Yubico), Max Geerling (Dutch Payments Association), Jonathan Grossar (Mastercard), Liquan (Max) Gu (Google), Lauren Helt (American Express), Jeff Hodges (Google), Mathieu Hofman (Stripe), Adrian Hope-Bailie (Coil), Ian Jacobs (W3C), Joshua Karoly (Netflix), Mahesh Kulkarni (Samsung), Vincent Kuntz (ISO 20022 / SWIFT), Florent Lambert (Lyra Network), Mercia le Roux (Entersekt), Bryan Luo (Amazon), Ajay Maddukuri (American Express), Takashi Minamii (JCB), Fawad Nisar (Discover), Cairin Michie (Coil), Gerhard Oosthuizen (Entersekt), Jay Patel (American Express), Brian Piel (Mastercard), Jean-Yves Rossi (Canton), Sophie Rainford (American Express), Hervé Robache (STET), Simon Rodway (Entersekt), Peter Saint-Andre (Mozilla), Sahel Sharify (Google), Rouslan Solomakhin (Google), Sameer Tare (Mastercard), Nick Telford-Reed, Benjamin Tidor (Stripe), Justin Toupin (Google), Laura Townsend (MAG), Arno van der Merwe (Entersekt), Luke Walker (Yubico), Danyao Wang (Google), Clément Warnier de Wailly (Canton), Wanli Yang (Airbnb)


Payment handler proposals (continued)

Sahel's slides. See also written proposal details for delegation, skip the sheet and JIT installation.

Skip-the-Sheet Behavior

[Sahel summarizes changes between Chrome 79 and 80]

Tomasz: You have a requirement that "only one payment method is provided by the merchant"
... would you consider instead "N payment method identifiers, but only one payment handler"?

Sahel: We've changed the condition in M80 to behave as you describe.
... so it's based on the number of available payment handlers
... In Chrome 80 we added support for shipping delegation
... to the payment handler
... which means that chrome doesn't need to show the payment sheet, which offers more opportunities for skipping-the-sheet
... but we always showed the sheet if the merchant requested basic card. Now Chrome 80 behavior adds support for another skip-the-sheet scenario: single PH available and payment handler supports delegation of data requested by the m erchant

[Sahel shows images in slides that illustrate changes in behavior from 79 to 80]

benoit: In that situation there's no display of the total amount that's being billed. That was displayed on the sheet.

Sahel: That is correct. Any time we skip the sheet it's up to the payment handler to display the total. Questions for the group: Should we standardize skip-the-sheet behavior? Are there concerns about co-existence of payment handlers with different delegation capabilities? Does it make sense to favor payment handlers that do full delegation above others?

PROPOSAL: Define skip-the-sheet behavior in the payment handler API spec

<tomasz> +1

<ChrisD> +1

<MaheshK> +1

<bryanluo> +1

<nicktr> +1

<btidor> +1

<Jean-Yves_Rossi> +1

<benoit> +1

<AdrianHB> +1

<mhofman> +1

<vkuntz> +1

<ajay> +1

<florent> +1

[Editor: We observe strong support for the proposal, but later there is discussion about the limits of specifying htis behavior.]

<mhofman> Can we favor PH that have enrolled instruments? That would include preference for PH that are already installed over JIT

<Zakim> ChrisD, you wanted to ask whether payment handlers which don't support full delegation would be hidden from the consumer - second-class citizens?

ChrisD: I wanted to follow on with a potential implication on consumer -- as a consumer, if we are doing away with the sheet and favoring delegation to payment handlers. Does this mean that I will need to provide shipping address another time?

Danyao: This move does mean that we are de-emphasizing the role of the browser in supplying the shipping address.
... most of the browser shipping address comes from autofill
... the sense we have is that as more users have direct relationships with payment apps, and the data they provide to them may be higher quality than what is scraped by the browser.
... so our hypothesis is that people will keep their addresses more up-to-date in those payment handlers

ChrisD: So I am hearing that you think consumers will prefer to use addresses given to PayPal, ApplePay, etc.

Danyao: Yes, that's our hypothesis. We want to hear from payment handler distributors whether they agree with this hypothesis

ChrisD: Autofill doesn't always work well for me as a consumer (e.g., apostrophe in my address)

Danyao: Storing addresses in browser makes most sense if I have N payment handlers that I use interchangeably
... but if I only use a couple of them and I use them all the time, and these have my addresses already (e.g., they need my billing address) then the fact that I don't have to update my address in the browser is a plus.

[Some discussion of the previous request for browsers to share address information with payment handlers with permission]

AdrianHB_: We could say in a way that Safari also implements "JIT" and "skip-the-sheet" but only in a limited fashion
... I think we can go ahead with whatever we think is worth changing. Let's forge ahead to make sure that what we settle on we do soon so that other implementers can take advantage of it.

benoit: If I both a person and business credit card, the bank and payment provider are the only ones who care about the address. The difference is only needed by the bank.
... for other payment methods that don't need a billing address, you don't really need to enter that information at all at the browser level.
... it's only the payment method that cares about it.

<Zakim> Josh, you wanted to confirm we have seen evidence that the shipping address stored by the browser are not usually accurate? Or an address used regularly?

Josh: Regarding delegation of shipping address to PH API, do we have evidence that stored addresses in the browser are incorrect?

Danyao: I don't think we have gathered enough information directly from PR API metrics to tell whether the addresses are incorrect.
... we might be able to see how frequently the user edits the address in the checkout sheet (but we've not looked into that)
... the two reasons we think addresses may not be accurate are: (1) higher drop-off when merchant requests shipping via PR API (2) we have data from autofill team about how frequently users update addresses when they fill out a form

Josh: Could it also be that when shipping is involved there is more dropoff?

Danyao: Yes, that's possible.

Gerhard: I do think shipping address is sometimes a challenge, notably when the price changes.
... from my perspective as a representative of banks, banks are not focused on shipping they are focused on billing.
... I think that's where the heart of our thing should be. A second point is that the US and Brazil have address verification mechanisms (AVS).
... we should focus on payments (not shipping)
... I would not want to force a bank to be required to deal with shipping addresses in order to leverage PR API
... More and more stuff doesn't require shipping details because it's digital

<nicktr> uk has AVS too

jtoupin: We have considered two extremes: one is where we imagine a browser-mediated sheet that incorporates all the data from payment handlers. And the other extreme is no browser sheet (just a handler selector), and we delegate to payment handlers.
... I think we should be cautious about something in the middle as it may become overly complex
... some factors that influence which extreme we go toward is:

a) Number of payment handlers in the ecosystem

b) What are the potential payment handler requirements. In general they have asked for full delegation.

Justin: I hear Gerhard saying bank payment handlers are an interesting counter-example to that trend we've heard

mhofman: Another consideration - if the payment handler has no enrolled instruments, it's uselss

RESOLUTION: The group should work on specifying skip-the-sheet behavior

PROPOSED: Browser should skip the sheet to installed payment handler even when another can be installed JIT

<ChrisD> -1

<rouslan> +?

<tomasz> -1

<mhofman> ~0

<nicktr> -1 should be user preference

<benoit> -1 otherwise how would new payment handlers get traction?

<ajay> +1

<clintonallen> -1

<giulio_andreoli> +1

<AdrianHB> ~0

[Editor: We observe mixed views or even slightly negative views of this proposal.]

PROPOSED: Browser should skip the sheet to payment handlers that support delegation of all merchant requested data, even if another one is available that could be used

<tomasz> +1

<rouslan> +1

<bryanluo> +1

<benoit> ~0

<AdrianHB> +1

<ChrisD> ~0

<giulio_andreoli> +1

<MaheshK> ~0

<Gerhard> ~0 Rather have more 'basic' handlers. One for payment, one for shipping.

<clintonallen> +1

<nicktr> -1 should be offered a choice of payment methods irrespective of delegation

<Fawad> +1

[Editor: We observe slight support for this proposal. However, below there is stronger support for showing available payment handlers by default except when users have configured a preference.]

Just-In-Time Installation Behavior

[We move on to the "Just in time" proposal]

Sahel: Current behavior around JIT is that Chrome only does JIT when it would be impossible to complete a payment otherwise.
... current JIT install is 2-step: (1) Find JIT-installable ph (2) install when user selects
... The proposal here is to show JIT-installable payment handlers even when the user has a way to pay otherwise. Another question is whether to allow skip the sheet to JIT-installed payment handlers.

Ian: I propose the following guiding principle: by default maximize handlers available to the user (that is, favor choice) but allow configuration to optimize checkout

<AdrianHB> +1 to choice over simplicity with the option to pick defaults

<ChrisD> + to say that as a consumer I don't want payment methods to be hidden from me without any preference having been specified. Maybe a 'don't ask me again - always use this payment method if available' could allow the choice to be bypassed.

AdrianHB: Reminder that proposals elsewhere regarding user consent are likely to affect the question of disallowing skip the sheet for JIT installable PHs

mhofman: Is the question to allow or disallow? Right now I would like to maintain status quo that if there's a single payment handler requested by the merchant and it's not yet installed, that we can still do skip the sheet...until we resolve the permission prompts

<jtoupin> @AdrianHB: The proposal we reviewed had consent @ first use for JIT PHs. So it would be listed but there is a step before the PH launches

PROPOSED: Guiding principle for decisions regarding display of payment handlers is to maximize availability and then optimize with user configuration

<nicktr> +1

<ChrisD> +1

<Jean-Yves_Rossi> +1

<rouslan> +0.1

<mhofman> +1 if that means only one configured means skip the sheet, regardless of JIT

<btidor> +1

<benoit> +0

[Editor: We observe support for this guiding principle.]

stpeter: I have an underlying concern (though I have to read the proposals in detail) about telling browsers what the user consent model should be.

Ian: There are good discussions about whether to specify this behavior in detail, or as a recommendation. But this is not meant to describe exact user interface

btidor: From an implementer perspective, it's important to know who is showing what
... and so I think the question of whether the sheet is skipped or not is not just a UI detail but important to specify

nickTR: I am with you as well. I think we can talk about expected behavior

danyao: I want to clarify a point - we want to distinguish discovery v. installation
... I agree that browsers should have choice over consent model
... we are hoping that discovery to be a stateless operation that can be done in a standardized way
... so merchants can understand what the users will have

AdrianHB: Something that Danyao said that's important is that in most web standards we don't specify UI. We want to stick to that here. However, we know from research about adoption that merchants will only use the APIs if there is some predictability about user journey.
... it may not require standardization, but they need predictability

Gerhard: I do not want a previous shopping experience to limit a future shopping choice. Having chosen a payment handler for one merchant, I don't want to be prevented from using another payment handler (e.g., that allows me to use points, etc.) on another merchant.
... so +1 to the proposal to show available handlers

Ian: Many thanks to the Chrome team for the proposals and also to everyone's feedback!

NickTR: Thanks Sahel!

Web Authentication WG Update

Tony: The WebAuthn WG produced a Rec for WebAuthn level 1 last year
... we are still working on enhancements to WebAuthn Level 2, in lock step with changes in CTAP at the FIDO Alliance
... as we make changes and add features to CTAP, there are times when we have to reflect those changes (e.g., as options) in WebAuthn
... you can use FIDO without WebAuthn if the platform exposes a native API
... different platforms do so; not all
... but as far as WebAuthn is concerned, level 1 is now implemented in all major browsers
... good participation in the WG as well
... regarding enhancements in level 2
... I think some of them will have an impact on payments flows

WebAuthn from cross-origin iframes

Tony: The first involves the ability to call webauthn from a cross-origin iframe (see WebAuthn issue 1336)
... we've done some threat modeling (e.g., Mozilla has done some work on this) and they have come to the conclusion that they are not comfortable allowing certain things to happen within a cross-origin iframe. This includes creation of WebAuthn credentials (create()). We will explicitly prohibit this in level 2
... so far Mozilla and Apple and Google and the Edge team are all ok with doing this
... this may impact some aspects of payment flows

JeffH: Just to clarify Tony's point, in level 1, both create() and get() have been usable within iframes from the same origin as the parent. In level 2 we will allow the relying party to delegate to a cross-origin iframe the ability to use get(). This is done via feature policy.
... what is presently in our Working Draft for level 2 is a feature policy that allows BOTH create() and get(). However, due to the threat analysis we have decided to only allow get() assertion in cross-origin iframes.
... so we will update that specification accordingly
... We expect these changes to be manifest in two specifications
... the plan is to rename the public key credential feature policy to be "public key credential get"
... we won't define the create feature policy

nicktr: I'm trying to understand the practical implication of this (e.g., for credit transfer)
... if I think about cross-origin creation v. get
... does that mean that cross-origin auth will still be possible but won't allow the first usage in a cross origin iframe?

Jeffh: Yes. We are separating out the notion of delegated credential creation
... in fact that is not, at this point, yet an official work item in the WG
... we are also discussing Dirk Balfanz's proposal regarding delegated credential creation

Gerhard: It makes sense to distinguish create() from get(). Will generation of credentials in a payment handler in 1p context be allowed?

JohnBradley: I think that since the payment handler (currently) opens in a 1p context you could create credentials in that context.

IJ: We are discussing a proposal that payment handlers open in 3p context, but can request 1p access (e.g., via Storage Access API0. Would the Web Authentication level 2 capabilities still hold if 1p rights achieved through storage access API?

JeffH: Not been thought through yet

JohnBradley: Not been thought through yet

JeffH: WebAuthn WG is the right forum for that.

btidor: I had the same question as Ian about what storage access API gives you
... conversely, if a regular cross-orign iframe uses request storage access, should it have access to webauthn create()?

JeffH: No.

btidor: I want to argue that payment handlers SHOULD be able to do create()
... with user consent to have 1p access

JohnBradley: Do payment handlers want to create credentials for their own origins?

btidor: Yes

JohnBradley: Payment handler is different from an iframe
... the permissions that we are adding are for iframes. Payment handlers may have different rules. At the current time because payment handlers are 1p they are not affected by the delegation rules

<AdrianHB> PH will have different rules. They are rooted in a Worker

<scribe> ACTION: Btidor to add a request regarding access to WebAuthn create() after storage access API to Payment Handler API issue 351

btidor: interesting architectural discussion about powers of payment handlers leaning more 1p than 3p

Dynamic Linking

Gerhard: Regarding fields displayed: could the browser show beneficiary and total (to help with PSD2 dynamic linking)?

JohnBradley: Historically there was a relying party provided functionality to include displayed total as part of signed data.
... browser vendors have expressed concern about displaying information from relying parties in browser chrome (due to past experiences)

<AdrianHB> FIDO calls this "Transaction Data"

JohnBradley: To progress this topic we'd need to figure out what information needs to be displayed and how the browser would trust it.
... it's unlikely that browsers will display arbitrary information in the chrome

JeffH: JohnBradley speaks truth.

Gerhard: If the payload is used as an element together with other context data to sign the payload, obviously the parties can attest that that was signed

JohnBradley: there is a place in WebAuthn for "client data"
... it would be a matter of figuring out where the browser gets this information, how it displays the data, and then whether data (or hash of that data) used in that field.
... People today are putting that information in the challenge.
... there might be a structured format for the payment information in the challenge
... if we could come up with a way to display that as part of API so that the user understood what they are agreeing to, that would be good. but probably not arbitrary information.
... obviously if it were coming from a payment sheet, that might be considered more trustworthy

Tony: This is somewhat out of scope for Webauthn.

JohnBradley: it probably needs to be mentioned in webauthn for how to include in client data. but probably not as an extension from an arbitrary RP

JeffH: Might still involve a protocol extension

AdrianHB: Age-old problem in payments - e.g., strings displayed in terminals generally need to be certified along with the terminals.
... here, if we could come up with structures that are standardized...when invoking webauthn in a payment, could the challenge and display cover this? I think that would be hugely valuable.
... I think the WebAuthn/WPWG joint task force that meets every other Wednesday is the right place to start on this conversation

JeffH: +1

NickTR: The simple transaction auth extension goes towards this, but it's not in level 2
... could we have a narrower proposal perhaps instead
... e.g., (beneficiary . (amount . currency)) and that's it

JohnBradley: Neither the simple transaction confirmation nor the complete have been implemented
... hopefully what we can do is come up with a better way to do this that will actually get implemented

JeffH: +1

NickTR: The disconnect I'm struggling with is that I hear there are no implementations but I'm also hearing "this can be done another way"

JohnBradley: The biggest problem is that both simple and general transaction conf need to be done inside the authenticator, and there are only 2 (roughly) that could actually do it.

NickTR: Because platform authenticators don't provide trusted display.

JohnBradley: Some debate recently about whether phones could do trusted display
... so we need to come up with a way of doing this that is more broadly applicable
... until such time as lots of authenticators can conform, it is unlikely to gain traction.
... in the interim we have "including the amount and beneficiary in the challenge but is not displayed to the user"; uncertain whether that meets the regulatory requirement

JeffH: it comes down to the definition of "trusted display". How trusted is your platform?

JohnBradley: The FIDO definition of a trusted display is that it be entirely within the TEE of a device and phones aren't built that way
... it may be that there are other implementations that are possible (e.g., still not subject to malware)
... it may be that we can do a trusted display as trusted as the rest of a phone

ChrisD: If you make the challenge predictable, is there a danger of exposing to MITM attack?

JeffH: Yes. It's important, especially in the get() assertion operations that the challenge is unpredictable and unique to that particular operation
... so if people are putting data in the challenge that is predictable
... then the challenge might be predictable
... so one would need to specify how to construct the challenge to make it unpredictable even if predictable data is part of it

<Gerhard> Comment: We should consider splitting the WebAuthn from FIDO spec. WebAuthn could do this through the Browser Agent as the mediator.

<AdrianHB> +1 to Gerhard - at least we could define a mechanism where the assertion is guaranteed by the browser (as much as is possible) to contain a challenge that contains the amount and beneficiary as displayed to the user

<AdrianHB> ChrisD - the payment request ID is a UUID4 (random and unique per tx) so we'd want to include that in the structured data be use to construct the challenge if we did it in the browser

<ChrisD> Thank you AdrianHB

NickTR: Let's continue this discussion on dynamic linking in the joint task force:

WebAuthn next steps

Tony: We are on-target for a 3Q or 4Q Candidate Recommendation for Webauthn Level 2. Our charter is for another 2 years (so 1 year after level 2 Rec)
... Not sure there are many new features in Level 2 that would enhance payments
... but I will say that we are getting more ubiquitous in our deployment

<AdrianHB> +1 to leveraging WebAuthn for payments

FYI on WPSIG discussion about WebAuthn and 3DS

Ian: For WPSIG discussion on how technologies relate I have created two diagrams. These are still drafty, and I welcome feedback:

Ian: The purpose of the diagrams was to show the impact of the WebAuthn WG's decision. Namely: if during a flow (e.g., 3DS flow) a relying party wants to enroll an authenticator, that will have to happen in a 1p context. But if a payment handler embeds some ACS code during transaction time (in a cross-origin iframe), the decision of the WebAuthn WG means that the ACS can authenticate without redirecting the user. This may be a superior user experience. I have talked with Stripe team (thanks to them)
... and I have talked to teh Mastercard team (thanks also to them) - with more fixes to come. These could be wrong. PLease help me get them right!

Sameer: Just wanted to mention to Ian's point that even though we are looking at 3DS flows and help correct them, ultimately the 3DS working group would have the final word on how they would work together
... just an FYI here

NickTR: Thanks to Tony, John, JeffH!!

<AdrianHB> +1

Joint Task Force update

Ian: No time today. Also, we covered some of the topics in previous presentations. So let's use the deck I prepared as the basis for upcoming joint task force discussions.

STET Update (Open Banking)

Hervé Robache slides

Herve: Good to talk with you again. The previous WPWG meeting I attended was a couple of years ago in Lyon.
... I work at STET and will give you an update today on what's going on in France
... STET implementations are primarily in France but also a bit in Belgium and Luxembourg
... implementations when live in Q4 2019
... there was not much activity
... numerous misinterpretation from banks and fintech
... we fixed issues
... since start of 2020 activity has increased
... there were millions of requests in February; don't have March statistics yet, but I anticipate acceleration. SCA requirements presented issues
... the regulation does not specify technologies, but does rely on the Berlin group's models for authentication approaches: redirect, decoupled, embedded
... with STET mostly relying on redirect approaches
... these redirect approaches are the source of many debates
... especially in how to get a frictionless approach
... in-browser implementations not problematic
... most issues arise from phone context
... we also see some complex architecture mixing browsers and native apps
... regarding the decoupled approach, we are looking into the FAPI approach (profile of OpenID Connect)
... this specification is new
... We met with the FIDO team and am interested in web authentication approach
... related issue: OAUTH2 and session fixation attack...but this was fixed in STET 1.4.2
... other issues regarded scope of data. PSD2 mainly focused on payment accounts. There are other banking products that are not in scope for STET.
... you'll hear from Berlin Group tomorrow that has a larger scope.
... we also in STET had a debate about fallback solution (e.g., screen scraping bank information)
... would log into user account and scrape bank page
... regulation allows this fallback solution if the PSD2 API fails
... with the SCA addition, this creates major issues in implementing the fallback solution
... another issue: banks need some data for fraud detection, but this creates privacy issues (GDPR)
... so we have to be cautious in providing data
... lastly, there has been some confusion about transaction dates...there are lots of types of dates and so we are clarifying this issue in our specc.
... We hope to issue our next revision in Q4 of 2020
... we are working with ISO 20022 to harmonize APIs
... you'll hear more about that from Kris Ketels tomorrow
... we are also working with ETSI regarding a common signature standard for all the european PSD2 APIs
... our goal is to have version 1.5 by end of year

NickTR: Thanks, Hervé!
... when you get big regulatory changes like PSD2 there's inevitability a period to figure things out. Work STET and others are doing is really importnat.

<AdrianHB> +1 - thanks

NickTR: Our hope is to enable the open banking APIs, ISO 20022, FIDO, Web payments to improve payments!

Hervé: Thanks all!

Tomorrow's meeting

nick: Thanks to everyone who presented today. Tomorrow: merchant feedback on PR API and more on open banking


Summary of Action Items

[NEW] ACTION: Btidor to add a request regarding access to WebAuthn create() after storage access API to Payment Handler API issue 351

Summary of Resolutions

  1. The group should work on specifying skip-the-sheet behavior
[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2020/04/01 19:04:10 $