W3C

Web Payments Working Group

25 May 2023

Attendees

Present
Anne Pouillard (Worldline), Bastien (EMVCo), Clinton Allen (American Express), David Benoit, Fahad Saleem (Mastercard), Frank Delache (Shopify), Gerhard Oosthuizen (Entersekt), Ian Jacobs (W3C), Jean-Luc di Manno (FIME), Nick Burris (Google), Nick Telford-Reed, Rolf Lindemann (Nok Nok Labs), Rouslan Solomakhin (Google), Stephen McGruer (Google), Steve Cole (MAG)
Regrets
-
Chair
Nick
Scribe
Ian

Meeting minutes

WPWG charter revision update

Ian: The W3C Membership is currently reviewing the draft charter; review period until 19 June. Please ask your AC reps to reply to the call for review.

SPC to CR update

Ian: Our target publication date is 8 June. We are communicating with Advisory Committee representatives to solicit testimonials to accompany a press release. Please discuss testimonials in your organization; communications with AC reps will include a draft of the press release.

Nick: We get more traction of course with testimonials

Recap of joint discussion with WebAuthn WG

See the summary of discussion with WPWG from early May.

Ian: Regarding issue 220, I've initiated discussion with the IANA WebAuthn registry at owners about the 'payment' extension.

NickTR: As an aside, Google authenticator allows for backup to the cloud...what does this mean for us?
… you appear to be able to back up to google drive

Gerhard: I think it was announced at international password day

<Gerhard> Article announcing this: https://security.googleblog.com/2023/04/google-authenticator-now-supports.html

w3c/secure-payment-confirmation#174

Next steps on fallback UX and roaming authenticators?

[Stephen presents slides]

smcgruer_[EST]: I want to step back and look at the big picture
… there are 2 relevant properties:

1) Privacy - no credential probing!

2) Relying Party Security - 'cross-origin' authentication ceremony only with the RP's permission
… that is: the RP has to be cool with SPC cross-origin usage

[Regarding credential probing]
… the site requires user consent to know if a user does or does not have a matching credential available.
… SPC dialog + Webauthn dialog are both used to get consent when credential available.
… but when credential not available...ability of user to consent that they do not have a credential does not exist today.
… the reason is that users don't know what it means to say "I don't have a credential"
… so SPC and WebAuthn combine two output states to make it impossible for the site to know "no credential available"
… those two flows leading to the same state are "user declines" and "user has no credential"
… but this opens up a timing attack
… to avoid that, both WebAuthn and SPC show *some sort of UI* when there are no matching credentials
… in the WebAuthn case, there is a choice of other authentication mechanisms.
… why is the probing topic relevant to authenticators?
… to show the right UX, the browser has to know what credentials are available.
… this is achieved through credential listing API of some sort
… credential listing APIs exist on Android and Windows
… but change is afoot in Android...see credMan
… this will change how Chrome works
… on Windows 11 there is a credential listing API
… there is no API for this yet on MacOS.
… on MacOS, by the way, Chrome uses its own credential store
… on iOS there is no credential listing API

Rolf: ConditionalUI relates to this (and does exist)

smcgruer_[EST]: The credential listing API underlies both ConditionalUI and SPC's choice of which UX to show

smcgruer_[EST]: It is technically impossible to have a credential listing API for arbitrary roaming authenticators because you don't know if they exist.
… if roaming authenticators are plugged in, there are APIs via FIDO
… so what do we do with SPC when the credential listing API is not available? Today we cache the existence of the credential in the browser.
… this is problematic, because we lose cross-browser support
… also we are only caching SPC credentials, and not general WebAuthn credentials
… also cache can go bad if underlying state changes

[Moving to the second requirement for cross-origin opt-in]

smcgruer_[EST]: the third-party payment bit is not specified in FIDO.
… the browser needs to check two things (1) is a credential available? (2) is the cross-origin bit set?
… today only Android supports the third-party bit
… so on other platforms Chrome is caching information, which has the same problems.

[The path forward]

* Need to work with platform authenticators to support a listing credentials API.

smcgruer_[EST]: I think we will see positive movement over the next 6 months
… that's how the winds are blowing

* Need to work with platform authenticators to support the thirdPartyPayment bit

* Need Android folks to address potential upcoming regressions for both of the above

* Figure out a story for remote authenticators, for users to say "hey, I have a remote authenticator but it's not plugged in yet"

* Fallback UX
… examples => http://www.w3.org/2023/03/spc-fallback.pdf

Fahad: The whole reason for credential listing, was that to replicate ConditionalUI but with a button?

smcgruer_[EST]: I think that's why WebAuthn added the ability

Rolf: Why wouldn't you add the credential selection part to the transaction dialog?

smcgruer_[EST]: That's something we might need to do

Rolf: Add roaming support for "use another way"
… that's what WebAuthn does today

smcgruer_[EST]: That gets messy because people also want to use the phrase "user another way" to mean "don't use a passkey"
… Ian's deck shows moving from SPC 2-state exist (pass/fail) to 3-state exist (pass/cancel/doesnt-or-cant use passkey)
… to have roaming authenticators show up in the third bucket is non-trivial

IJ: So how do we make progress?

smcgruer_[EST]: See above last slide

nicktr: Where is best place to have discussion with platform authenticator providers?

Rolf: regarding list credentials, suggest WebAuthn WG
… for the extra bit, likely more a FIDO discussion
… question is whether platform authenticators will implement that CTAP feature

Ian: Maybe we write up deployment needs and share broadly, including TPAC

Returning user recognition

https://github.com/w3c/webpayments/wiki/Agenda-20230525#returning-user-recognition

smcgruer_[EST]: We have publicly stated that in Q1 of 2024 Chrome, 1% of stable users will not have 3p cookies
… we are moving towards no 3p cookies later in 2024
… 1% of stable users is a lot of people,
… suggest testing sites with Chrome settings where there are no 3p cookies and see what breaks

nicktr: How are 3ds implementations looking with 3p cookie deprecation?

Franck: This is something we'll have to test
… how can I easily test?

<smcgruer_[EST]> https://privacysandbox.com/news/the-next-stages-of-privacy-sandbox-general-availability

<smcgruer_[EST]> chrome://settings/cookies

smcgruer_[EST]: You can test with your own cookie settings in your browser.
… we will also in Q4 of this year, we will have a mechanism to test on your domain

Franck: Any way to roll this out incrementally?

smcgruer_[EST]: Normally the way this works is via origin trials. It's up to the domain to decide whether to enable something on a given visit

[Regarding storage access]

<smcgruer_[EST]> cfredric/chrome-storage-access-api

smcgruer_[EST]: Chrome is planning to ship Request Storage Access
… you can get back 3p cookie access with user consent
… this is an ack that there are no good solutions yet for some use cases and we need this for now
… still want to find better solutions

<smcgruer_[EST]> https://groups.google.com/a/chromium.org/g/blink-dev/c/vyXWn1W1daA/m/tL3f1_WbAwAJ?utm_medium=email&utm_source=footer&pli=1

smcgruer_[EST]: Also, bounce tracking update
… we've announced public plans to address this
… if a user has visited a tracker themselves, we are basically saying "that's fine"
… but if you are an entity where the user has not interacted with your site, these changes will create issues

Next meeting

8 June

Minutes manually created (not a transcript), formatted by scribe.perl version 210 (Wed Jan 11 19:21:32 2023 UTC).