13:51:39 RRSAgent has joined #wpwg 13:51:43 logging to https://www.w3.org/2025/07/17-wpwg-irc 13:51:46 Meeting: Web Payments Working Group 13:51:56 Chair: Ian 13:51:59 Scribe: Ian 13:52:17 Agenda: https://github.com/w3c/webpayments/wiki/Agenda-20250717 13:59:36 regrets+ Praveena 13:59:38 Tomasz has joined #wpwg 13:59:40 regrets+ NickTR 13:59:44 present+ Ian 13:59:47 present+ 14:00:04 present+ Ben_Kelly 14:00:08 present+ Rogerio_Matsui 14:00:52 present+ Jeff_Owenson 14:01:04 present+ Steve_Cole 14:01:08 present+ Ryan_Watkins 14:01:37 present+ Fahad_Saleem 14:01:44 present+ Stephen 14:01:50 present+ Slobodan 14:01:53 present+ Bjorn_Hjelm 14:01:58 present+ Nakjo_Shiskov 14:02:04 present+ Henna_Kapur 14:02:10 present+ Gustavo_Kok 14:02:17 present+ Takashi_Minamii 14:02:20 slobodan has joined #wpwg 14:02:20 present+ Sameer_Tare 14:02:45 Takashi has joined #wpwg 14:02:52 present+ 14:03:01 present+ NickTR 14:03:48 present+ Sami_Tikkala 14:04:34 topic: State of Platform Authenticators for SPC in Chrome 14:04:44 -> https://lists.w3.org/Archives/Public/public-payments-wg/2025Jul/0001.html Documentation from Stephen 14:05:26 smcgruer_[EST]: A "platform authenticator" is one that is "generally available on the literal same device" 14:05:42 ...historically it was the one built into the device, but now there are third party options 14:05:47 present+ Rene_Leveille 14:05:53 Rene has joined #wpwg 14:05:56 present+ Katharine_Wright 14:05:59 present+ Rouslan 14:06:37 smcgruer_[EST]: On Windows, for example, there are three types of platform authenticators: Windows Hello (provided by MS), Google Password Manager (only available for Chrome on Windows) and 3p passkey providers 14:06:42 present+ Kenneth_Diaz 14:06:58 present+ Sharanya 14:07:05 present+ Sue_Koomen 14:08:05 smcgruer_[EST]: On MacOS you have iCloud Keychain (from Apple; default platform authenticator) (2) chrome internal profile credential store (legacy) (3) Google password manager (4) 3p passkey providers via ASPasskeyCredentialRequest 14:08:15 apologies for being late 14:08:17 ...SPC uses the internal profile credential store 14:08:23 present+ David_Benoit 14:08:34 TallTed has joined #wpwg 14:09:26 smcgruer_[EST]: On Android, there are only passkey provider apps: Google Password Manager (often but not always default; cf Samsung phones), 1password, bit warden, lastpass, etc. 14:09:50 smcgruer_[EST]: On iOS (1) iCloud keychain (2) passkey providers via ASPasskeyCredentialRequest 14:10:07 smcgruer_[EST]: On Linux and ChromeOS, Google Password Manager 14:10:26 present+ Albert_Schibani 14:10:52 smcgruer_[EST]: Authenticator capabilities relevant to SPC: 14:10:56 ...synched passkeys 14:11:55 ...ability to create a silent list of credentials. This enables the choice between authentication UX and fallback UX. This is one of the main APIs we thought would be a thing for other situations as well (e.g., immediate mediation). But in practice, the OS has the list and Chrome does not have access to ti. 14:12:05 ...ability to store the third party payment bit (CTAP) 14:12:33 ...but platform authenticators don't follow the CTAP spec necessarily, so they don't have to support that bit (and many don't yet) 14:12:56 ...in the absence of the third-party bit, Chrome stores it instead. So the info is not available through synching or across browsers on the same device. 14:13:10 present+ Ehsan_Toreini 14:13:14 SameerT has joined #wpwg 14:13:20 present+ 14:13:32 (Stephen walks through table of which authenticators are used in practice with SPC today) 14:15:08 smcgruer_[EST]: On Windows, it's not clear that we'll be able to access 3p passkey provider credentials through the list-credentials API 14:15:13 +q 14:15:22 ack Rene 14:15:43 Rene: The API is in the Windows nightly; but there is someone from Chrome working on this and you do have access to list the credentials. 14:16:25 smcgruer_[EST]: On MacOS, chrome uses legacy credential store. This store does not and won't sync credentials. 14:16:35 ...so passkeys on macOS are not syncable. 14:17:00 ....3p bit not stored (but not needed in this case) 14:17:24 ...list-credential API available on MacOS but not yet used by Chrome's SPC implementation 14:18:09 smcgruer_[EST]: On Android, we use Google Password Manager (called directly, not through the credential manager API, because doing it this way give us a list-credential API) 14:18:29 ..the credential management API does not enable a browser to get a list silently. 14:19:24 [Stephen looks at possible future changes for platform authenticators used by Chrome for SPC] 14:20:18 smcgruer_[EST]: Using Windows Hello list-credentials API would allow us to use webauthn credentials that don't have the payment bit set. This seems do-able and valuable. 14:20:44 smcgruer_[EST]: We could also store the 3p payment bit in windows hello, which would allow cross-browser usage on same device (or also synching if the bit is also synched) 14:21:04 ...question of impact on 3p passkey providers, who may or may not store the bit. 14:21:22 rwatkins_ma has joined #wpwg 14:21:24 ...we could take a fallback approach to test if 3p bit storable and if so, store it in that authenticator 14:21:48 smcgruer_[EST]: Support google password manager. 14:22:11 smcgruer_[EST]: Moving to MacOS, we could use internal profile credential store. But most passkeys are not stored there today 14:22:22 ...most passkeys are in GPM or iCloud keychain 14:22:40 ...we probably can support GPM but haven't done the analysis yet 14:23:10 ...for iCloud keychain, there is no 3p payment bit. It does support listing credentials but not silently (there's a prompt) 14:23:33 smcgruer_[EST]: there's a general question of support for 3p passkey providers. 14:24:35 (Stephen walks through 3p scenarios and changes) 14:25:02 ...on Android, could use CredMan but would lose list-credential API 14:25:17 Bjorn: Yubico would like SPC support for roaming authenticators. 14:26:06 Ian: Any new news from WebAuthn space? 14:27:09 Ian: What would be good triggers to realize any of the future directions? 14:27:34 smcgruer_[EST]: If we think about capabilities, we need to understand how important the 1p usage of a non-payment credential is? 14:27:58 ...on Windows the 3p bit is browser bound and we could use Windows Hello 14:28:08 ...so those are the two use cases that seem quickest to unlock 14:28:45 rene: For Windows, it's complicated. The SPC bit exists for the internal Windows Hello authenticator but it doesn't exist yet as an option for 3p providers. 14:29:05 ...so might need both internal and external support for that bit. 14:29:47 Ian: Do you know when you are dealing (as Chrome) with a 3p provider? Or is that opaque by design? 14:30:01 Rene: My understanding is you can know, but not clear to what extent 14:31:03 topic: Avoid double step-up 14:31:04 https://github.com/w3c/secure-payment-confirmation/issues/287#issuecomment-3045734622 14:32:11 smcgruer_[EST]: Recall that with BBKs, when the caller first sees a BBK (after FIDO authentication), there may be a second step-up to trust the new BBK. 14:32:23 ...some providers expressed concern about the double setp-up 14:32:38 ...we have a proposal that reduces double step-up, but it's a bit complex 14:33:07 ...at a high level, the caller always gets back a BBK, and when first seen the BBK is "not yet trusted" but "can be trusted in the future" 14:33:20 ...the caller passes in a list of trusted BBKs 14:34:25 ...the caller also passes in the most recent "not yet trusted BBK" and if the user successfully authenticates, it becomes associated (in the browser) with the passkey 14:37:59 +q 14:38:14 q+ 14:38:37 ack Rene 14:39:16 Rene: Is there anything with user consent that is protecting the website of the RP from creating those eventually trustworthy BBKs? 14:39:51 smcgruer_[EST]: You, you get different potential BBKs until you go through an SPC authentication. 14:40:18 Rene: If there's some form of user consent dialog, it might be ok. 14:40:29 smcgruer_[EST]: Agreed. 14:40:55 Fahad: What would be passed as input for the BBK? 14:41:00 Slobodan: Public keys 14:41:31 Fahad: Suppose there's a payment service provider calling SPC, so chrome shows sheet and "confirm" and chrome returns a new bbk. 14:41:58 ...suppose the merchant includes BBK (without doing ID&V) in next call 14:42:07 ...does that cause the BBK to be added to the trust list? 14:42:09 q- 14:43:02 smcgruer_[EST]: What makes a passkey trusted in the first place? Our understanding in the flow you just described is that the merchant need to ask some other party to step-up 14:43:23 q+ 14:44:05 Fahad: I understand the actual RP can say "we don't trust this BBK" 14:44:23 smcgruer_[EST]: the RP will not pass in the BBK because it's not trusted by the RP 14:44:51 ...what possibly should happen is that even if a credential has a BBK, it might need to be overwritten 14:45:17 slobodan: If we allows a BBK to be overwritten, malicious merchants could blow them away arbitrarily. 14:46:55 smcgruer_[EST]: You can't cause the BBK to be trusted. 14:50:33 smcgruer_[EST]: The problem is you can't replace the poisoned BBK 14:51:05 smcgruer_[EST]: You could fix it later? 14:51:17 ...to the issuer it looks like a new unbound BBK 14:51:33 Ryan: Does this change the response for "continue with other verification"? 14:51:50 smcgruer_[EST]: Yes, it would be a breaking change .... this is theoretical 14:51:57 Ryan: We are interested in this, even if complex. 14:52:04 ...this would be worthwhile. 14:52:45 present+ Arman_Aygen 14:52:58 Ian: Next steps? 14:53:15 smcgruer_[EST]: We'll try to fix the issue raised today "the poisoning attack" 14:53:55 topic: Issues to close 14:54:00 Propose to close issue 56. 14:54:00 Propose to close issue 98 (fallback UX) since progress has been made. If immediate mediation takes hold in WebAuthn we can revisit the topic including the need for any fallback UX. 14:54:00 Propose to close issue 174 now that we have added BBKs to SPC. 14:54:01 Propose to close issue 154 since cross-origin feature only used in SPC. 14:55:03 Roger has joined #wpwg 14:55:04 ------- 14:55:15 Ian: Propose to close issue 56 due to inactivity 14:55:31 Tomasz: Ok to close. 14:56:07 ----- 14:56:29 Propose to close issue 98 14:57:17 ---- 14:57:17 Propose to close issue 174 14:57:51 ---- 14:57:52 Propose to close issue 154 14:58:31 Ehsan has joined #wpwg 14:59:34 ===== 14:59:58 Henna: The complexity of the proposal for avoiding double step-up is a source of concern, but it's worth exploring. 15:00:10 ...we need to evaluate this against the cost and frequency of double step-ups 15:00:20 topic: next meeting 15:00:23 31 July 15:01:47 Topic: TPAC registration 15:02:18 present+ Sidd_Gothoskar 15:02:46 RRSAGENT, make minutes 15:02:47 I have made the request to generate https://www.w3.org/2025/07/17-wpwg-minutes.html Ian 15:02:49 RRSAGENT, set logs public 17:32:34 Zakim has left #wpwg