Sahel's slides. See also written proposal details for delegation, skip the sheet and JIT installation.
[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.]
[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!
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
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
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:
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
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
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.
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!
nick: Thanks to everyone who presented today. Tomorrow: merchant feedback on PR API and more on open banking
ADJOURNED
