13:50:22 RRSAgent has joined #wpwg 13:50:26 logging to https://www.w3.org/2026/03/12-wpwg-irc 13:50:26 Zakim has joined #wpwg 13:50:32 Meeting: Web Payments Working Group 13:51:05 Agenda: https://github.com/w3c/webpayments/wiki/Agenda-20260312 13:51:08 Chair: Ian 13:51:10 Scribe: Ian 13:58:50 agenda? 13:58:50 agenda+ SPC updates 13:58:57 agenda+ Payment Request updates 13:59:01 agenda+ Next meeting 13:59:07 I have made the request to generate https://www.w3.org/2026/03/12-wpwg-minutes.html Ian 13:59:24 present+ John_Earnshaw 13:59:25 present+ Ian_Jacobs 13:59:53 present+ 14:00:59 present+ Jean-Luc_di_Manno 14:01:47 present+ Darwin_Yang 14:02:10 present+ Henna_Kapur 14:02:10 darwin has joined #wpwg 14:02:17 present+ Stephen_McGruer 14:02:22 present+ Jorge 14:02:26 present+ Kenneth 14:02:40 present+ Bjorn Hjelm 14:03:05 JL has joined #WPWG 14:03:20 zakim, take up item 1 14:03:20 agendum 1 -- SPC updates -- taken up [from Ian] 14:03:30 subtopic: Checking in on actions from 26 Feb 14:03:41 present+ Ashwany_Rayu 14:03:51 present+Isaiah 14:04:10 kennethentersekt has joined #wpwg 14:04:11 iinuwa has joined #wpwg 14:05:07 subtopic: Feature detection updates 14:05:13 present+ Dan_Pelegero 14:05:32 Darwin: We are awaiting approval, should be in Chrome 147 or 148 at the latest. 14:05:49 Stephen: So if in 147 would be rolled out completely by mid-April. 14:05:53 present+ Gerhard 14:06:48 Ian: What about the spec? 14:07:09 Stephen: We landed the spec change last week in the editors draft. 14:07:17 present+ Vivian 14:07:35 Stephen: We were asked whether we talked to the TAG and are are suggestion we do an FYI to the TAG. 14:08:35 ...our argument is that this is a small addition to an existing API so an FYI is appropriate 14:09:18 present+ Ehsan_Toreini 14:10:03 subtopic: uv=discouraged update 14:10:38 Darwin: I have confirmed that uv=discourged for android they will ignore it. They don't imagine changing this in the foreseeable future. 14:10:41 Ehsan has joined #wpwg 14:11:09 stephen: Summary then is uv=discouraged is not respected on any platform. 14:11:27 ...so we need to continue our conversation with the Android folks on our detailed use cases. 14:13:36 Ian: Would it make sense to invite people to this call? 14:13:39 stephen: Not yet 14:14:12 ACTION: Stephen and Darwin to continue conversations with the Google password manager team on how we might address double step-up use cases. 14:14:32 subtopic: BBK requirements / spec gap 14:14:40 https://github.com/w3c/secure-payment-confirmation/issues/321 14:17:45 stephen: We struggled with how best to describe the situation. Some browsers support "profiles" differently on different platforms. E.g., there is only one profile per signed-in account for Chrome on Android. 14:18:11 ...the interesting question is what is the desired underlying guarantee. 14:18:56 Ian: The high-level requirement was "can't be removed from the device." And we narrowed in. 14:19:18 Stephen: Right, we narrowed in for clarity, but not for security properties. 14:19:37 ...in my head "not leave the device" is a security requirement but "not leave the user agent" is more of a practical requirement. 14:20:57 Stephen: On desktop, our implementation is per chrome profile. 14:21:07 ...each profile has its own storage. 14:22:51 Ian: What problem do we want to solve ? 14:23:08 John: Fraud risk management team wants to know about guarantees that the implementation provides 14:25:04 Ian: Could you ask what guarantees people would like? 14:25:08 John: Sure. 14:26:34 ACTION: John_Earnshaw to get more information from his fraud team to understand what guarantees are being sought. 14:27:30 ACTION: Stephen and Darwin to propose an editorial fix to the specification language regarding one passkey per BBK requirement. 14:28:22 subtopic: SPC issue review 14:28:31 https://github.com/w3c/secure-payment-confirmation/issues/65 14:29:52 Ian: THis is not viewed as part of V1 so propose to close 65 14:31:09 stephen: Agree to close. 14:31:42 ...but note that you can't call SPC in a Payment Request because you can't do recursive payment request calls. Nobody has asked for this use case to be addressed. 14:31:55 ACTION: Ian to close 65 14:34:17 https://github.com/w3c/secure-payment-confirmation/issues/34 14:34:28 present+ Steve_Cole 14:35:26 Ian: At TPAC we moved in the direction of supporting "low friction" flows so was ready to close. 14:36:30 ...and we heard it was important to stay close to passkeys. 14:37:12 Gerhard: My sense was the "confirm" button was low-enough friction 14:38:11 Ian: Let's leave this open based on what we heard today. We are aiming for low friction. 14:38:33 ACTION: Ian to update the issue with the latest info 14:39:18 zakim, close item 1 14:39:18 agendum 1, SPC updates, closed 14:39:19 I see 2 items remaining on the agenda; the next one is 14:39:19 2. Payment Request updates [from Ian] 14:39:21 zakim, take up item 2 14:39:21 agendum 2 -- Payment Request updates -- taken up [from Ian] 14:39:48 zakim, open item 1 14:39:48 agendum 1 -- SPC updates -- taken up [from Ian] 14:40:14 (Regarding issue 24) 14:40:39 Henna: We wanted a coupling with passkeys so that you could have a single enrollment that gives you both options (with or without SPC). 14:41:35 Gerhard: The original three superpowers of SPC were (1) secure display (2) running in a different domain than the RP (3) dynamic linking 14:42:48 q+ 14:43:49 ack me 14:44:01 Ian: What use case have we missed with DC API + SPC + DBSC? 14:44:23 Henna: I heard we want a signature cross-domain (with user interaction) 14:44:31 Gerhard: In a lot of domains, possession is good enough. 14:44:35 present+ iinuwa 14:44:50 ...the whole world is using OTP which creates phishing issues. 14:46:18 Henna; The other argument I heard at TPAC is that if you have a key that can work cross-domain (user is aware of what's happening but no authentication) 14:46:51 ...but I can't remember whether key unaffiliated with a passkey but user confirm was ok or not ok. 14:47:22 Henna: I agree that we should list use cases and how we address them. 14:47:40 ...I'd be happy to work with Gerhard to see if there's another use case and the topic of "how do we solve it"? 14:50:28 Ian: Please recall previous chats about this idea (e.g., man in the middle attacks) 14:51:32 Gerhard: A challenge with SPC is that it requires support for FIDO, and that's more than is needed for some use cases. 14:52:30 zakim, take up item 2 14:52:30 agendum 2 -- Payment Request updates -- taken up [from Ian] 14:53:38 Stephen: we received a request from PayPal regarding clearer error messages, to differentiate a failure due to user canceling during a flow and a failure due to some error happening in the payment app. 14:54:04 ...Marcos and I worked on this and landed the update to the Payment Request specification to allow this concept to exist for payment apps. 14:54:21 ...so next step is to land this for different payment app types, starting with Web-based payment handlers. 14:54:40 ...then after that we'll look at making this work in native (Android) apps 14:54:53 ...PayPal indicated this improvement would help their use case. 14:55:57 zakim, close item 2 14:55:57 agendum 2, Payment Request updates, closed 14:55:58 I see 1 item remaining on the agenda: 14:55:58 3. Next meeting [from Ian] 14:56:41 26 March 14:56:57 Bjorn: I'll be able to talk about roaming authenticators on 26 March 14:58:21 RRSAGENT, make minutes 14:58:22 I have made the request to generate https://www.w3.org/2026/03/12-wpwg-minutes.html Ian 14:58:28 RRSAGENT, set logs public 16:02:22 zakim, bye 16:02:22 leaving. As of this point the attendees have been John_Earnshaw, Ian_Jacobs, benoit, Jean-Luc_di_Manno, Darwin_Yang, Henna_Kapur, Stephen_McGruer, Jorge, Kenneth, Bjorn, Hjelm, 16:02:23 Zakim has left #wpwg 16:02:26 ... Ashwany_Rayu, Isaiah, Dan_Pelegero, Gerhard, Vivian, Ehsan_Toreini, Steve_Cole, iinuwa