Web Payments Working Group

PR API Status

See Next Steps Payment Request API email to WPWG.

<Ian> [No questions]

<Ian> NickTR: The meeting last week was constructive; we wanted as chairs to create an opportunity to further resolve the objection, e.g., through an enumeration of reasons in the spec; we invited proposals through 28 January.

Review of Privacy Resources

<Ian> Privacy and Web Payments

<Ian> NickTR: First we wanted everyone to be aware of these resources.

<Ian> Use cases known to be impacted by changes to browsers

<Ian> Nick: Some user experiences likely to be affected, e.g., which bank you used (stored in a 3p cookie)

<Ian> Jean-Luc: We also observe impact on SRC (keeping track of user identity)

<Ian> ...that's not yet in the use cases

ACTION: Ian to add the SRC user recognition use case to the resources

<Ian> Gerhard: After the user recognition step, there's a challenge step.

<Ian> Jonathan: First there is user recognition (done today through cookie); we need to identify alternative solutions

<Ian> Jean-Luc: There is also a question of SRC SDK...to be sure how all the systems recognize the same user; federated ID issue.

<Ian> Jonathan: I think that is an aspect of the same recognition issue

<Ian> NickTR: We know that Safari and Firefox already have restricted cookie access; how does SRC work in those browsers?

<Ian> Clinton: In browsers with limited 3p cookie access, the consumer has to re-enter identifying information and possibly other information

<Ian> NickTR: Is there any data that suggests that friction is causing additional drop-off?

<Ian> Clinton: I don't think I have any data, but at least intuitively the friction creates challenges.

<Ian> ...and having a cookie or other mechanism for user recognition would be an improvement. Where confidence is low, you can do a 1-time challenge or email

<Ian> ...once card has been selected, you can go through a cardholder authentication.

<Ian> NickTR: Who would see in their analytics whether there was a statistically significant drop off? Would it be PSPs or SRC systems?

<Ian> Clinton: The SRC systems might be involved, but I think the SRC-I would be the most likely to detect this

<Ian> Gerhard: Just a thought in terms of making that journey easier: in a 3p environment, think of discoverable credentials.

<Ian> ...is there restricted access to discoverable credentials in a 3p context?

<Ian> smcgruer_[EST]: Web Authentication authentication is available in 3p iframes in Chrome. So what you are describing is roughly possible (where implemented)

<Ian> ...there is also a proposal by Google called "Conditional UI"

<Ian> ..it would fit well here: the page could allow the user to enter an identity, but also click on a button for FIDO authentication.

<Ian> ...it could be a fit, but would in any case be a world with more friction than cookies

<Ian> Jonathan: You could prompt for FIDO authentication, but you don't know credential IDs in this context.

<Ian> ...could the browser prompt the user to consent, and that could reveal the SRC identity

<Ian> smcgruer_[EST]: Discoverable credentials allows calls to find out what credentials are available. But there are origin (1p) limitations.

<Ian> ...if rp.com is in a cross-origin iframe, rp.com can ask for discoverable credentials for rp.com

<Ian> Jonathan: Does this exist today?

<Ian> smcgruer_[EST]: rp.com can initiate an authentication.

<Ian> clinton: for discoverable credentials, if all SRC systems used a common origin, would that be a simpler solution?

<Ian> smcgruer_[EST]: yes, in general having a single origin would make this easier.

<Ian> ...if there's a single origin, you can open a popup in a 1p context and you have your cookies

<Ian> Manjush: Is the current construct that it has to be based on a popup experience or initiated via a button?

<Ian> smcgruer_[EST]:How to get a 1p context: popup, redirect, payment handler, native browser integration

<Ian> manjush: We are also contemplating a model where the SRC experience is embedded in the merchant origin

Upcoming changes to User-Agent string

[Mike Taylor's slides]

<Ian> Mike: We plan to make changes to user agent string; want to understand potential impact of changes of payments flows.

<Ian> Mike: Strings are a hot mess. Can be used for covert tracking

<Ian> ...parsing is painful and fragile

<Ian> ...to address these we would like to (1) freeze some information in the string and (2) reduce some other information

<Ian> ...we could keep some information that would continue to change (e.g,. OS, browser name, major version number)

<Ian> ...we also want to provide a new API that provides hints about the user agent

<Ian> ..."UACH" is User Agent Client Hints

<Ian> ...UACH will provide some of the high entropy bits that are being removed from the UA String

<Ian> ...we also plan to reduce some of the JS APIs

<Ian> ...timelines: we launched an origin trial in October; a couple of months to go for testing

<Ian> ...we want people to test now to tell us if we are breaking things

<Ian> ...in M96 we created a mechanism to get hints on first request

<Ian> ...if you are doing content negotiation on the first request, it's problematic because you only get data on second request

<Ian> ...moving forward we would provide info on first request; cached for subsequent visits

<Ian> ...once we are past testing phase, we will roll this out in Chrome 101 on Desktop

<Ian> ...that's when we reduce the "minor version" information, which will turn to "0.0.0"

<Ian> ...during this period we want people to migrate to UACH

<Ian> ...we'll continue to reduce the string on mobile in phase 3

<Ian> ...there will be a deprecation path for some period of time

<Ian> ...up to approximately May 2023

<Ian> Mike: User Agent string is loosely defined in HTTP spec (at IETF)

<Ian> ...but it's very loosely defined

<Ian> NickTR: What are expectations about similar changes in other browsers?

<Ian> Mike: We are aware of similar actions. Safari has largely frozen UA string; only major and minor version update these days

<Ian> ...Firefox also capped version of MacOS and Windows and they are considering further ideas

<Ian> ...there's no coordinated plan among all the browsers, but there is general sentiment to reduce information in the string

<Ian> UACH specification

<Ian> ...being worked on in the WICG

<Ian> ...this is intended to work cross browser

<Ian> Mike: We don't yet have a formal position from Apple. Mozilla is interested in the JS API.

<Ian> Jean-Luc: You are removing the UA string to reduce tracking. But there are legitimate use cases (e.g. risk assessment).

<Ian> Mike: We don't plan to remove the UA string completely; we just plan to reduce it.

<Ian> Mike: UACH can be used to regain some entropy that we are removing from the string.

<Ian> ...we are moving this from a passive to an active surface

<Ian> Mike: This should help the browser support legitimate anti-fraud use cases

<Ian> ...see also trust tokens

<Ian> Ian: Could you add a user consent feature to give back more data?

<Ian> Mike: It's not part of our vision to add a permissions model. But there has been discussion about how the user could provide consent where the user says "I'm ok with this site asking for this."

<Ian> IJ: Is that conversation to happen in the Antifraud CG?

<Ian> smcgruer_[EST]: +1

<Ian> Ian: We've also looked at trust tokens; not quite all we need for determining "trust this browser WITH THIS INSTRUMENT."

<Ian> Gerhard: Clarifying question - some stuff is being taken away and some is given back. Is there any plan to stop sending information to some domains to prevent misuse?

<Ian> Mike: We are actively considering that; see the privacy budget discussion.

<Ian> ...it's an abstract idea that the browser can track how much entropy an origin is requesting. And the browser might be able to act on the user's behalf when a lot is being demanded.

<Ian> ...we need something to enforce the entropy collection if it's not valid or doesn't reflect user consent.

<Ian> Gerhard: Any thinking about bringing the user into the entropy discussion?

<Ian> Mike: These are conversations that are being had: what does privacy budget mean?

<Ian> Ian: Go see the privacy community group.

<Ian> clinton: In this context is "entropy" used commonly?

https://en.wikipedia.org/wiki/Entropy_(information_theory)

<Ian> Mike: This is an information theoretic use of the phrase. Bits of identifying information. I think 33 bits of information is all you need to identify every human on the planet.

<Ian> ...we are trying to prevent bad actors from being able to identify users individually

<Ian> Mike: You are welcome to send me questions (email in slides) and let me know whether you think this will break deployments (e.g., no more minor version in the strings)

Next meeting

<Ian> 3 February