13:45:18 RRSAgent has joined #wpwg 13:45:22 logging to https://www.w3.org/2025/05/08-wpwg-irc 13:45:22 Meeting: Web Payments Working Group 13:45:33 Agenda: https://github.com/w3c/webpayments/wiki/Agenda-20250508 13:45:35 Chair: Ian 13:45:37 Scribe: Ian 13:45:40 agenda+ SPC updates 13:45:50 agenda+ Rechartering update 13:45:53 agenda+ TPAC 2025 13:45:57 agenda+ Next call 13:59:33 jpm-block has joined #wpwg 14:01:05 present+ Rogerio_Matsui 14:01:08 present+ Ian_Jacobs 14:01:18 present+ Takashi_Minamii 14:01:25 present+ Stephen_McGruer 14:01:27 present+ Ben_Kelly 14:01:40 present+ Rouslan_Solomakhin 14:01:40 present+ Slobodan_Pejic 14:01:42 present+ Juan-Pablo_Maretti 14:01:47 present+ Juan-Pablo_Marzetti 14:01:49 present+ Darwin_Yang 14:01:52 present- Juan-Pablo_Maretti 14:01:56 present+ David_Benoit 14:02:02 present+ Kenneth_Diaz 14:02:07 present+ Fahad_Saleem 14:02:11 present+ Albert_Schibani 14:02:14 present+ Doug_Fisher 14:03:04 present+ Ryan_Watkins 14:03:19 present+ Ben_Kelly 14:03:50 rwatkinsma has joined #wpwg 14:04:03 tminamii has joined #wpwg 14:04:22 kenneth_entersekt has joined #wpwg 14:04:25 Albert has joined #wpwg 14:04:31 Roger has joined #wpwg 14:04:43 present+ Sue_Koomen 14:04:55 present+ Gerhard_Oosthuizen 14:05:06 -> https://github.com/w3c/webpayments/wiki/Agenda-20250508 Agenda 14:05:53 present+ 14:05:56 present+ Henna_Kapur 14:06:01 present+ Ravi_Shekhar 14:06:04 zakim, take up item 1 14:06:06 agendum 1 -- SPC updates -- taken up [from Ian] 14:06:18 present+ Vasilii_Trofimchuk 14:06:27 Henna: We've reviewed the requirements to see if they are met by the BBK functionality. 14:06:33 ...we have some general comments and some clarifications. 14:06:42 vasilii has joined #wpwg 14:06:55 ...suggest we add an editorial comment why the term "browser-bound key" is used even if it's device-bound 14:07:02 present+ Michael_Horne 14:07:19 Henna: Is BBK supposed to be an optional extension, or that all SPC implementations will implement it? 14:08:01 smcgruer_[EST]: I would lean towards making this part of SPC. 14:08:07 Henna: My thinking, too. 14:08:22 smcgruer_[EST]: Is this a must as written? 14:08:56 slobodan: Is failure to create a BBK taken into account? 14:09:19 smcgruer_[EST]: I think from requirements we've heard, this is a "must" 14:10:37 Ian: We might need to strike a balance between "must" and "some cases where it won't happen" 14:10:55 present+ Praveena_Subrahmanyam 14:11:10 Gerhard: +1 to "must" but want to be mindful of interop 14:11:13 present+ Sharanya 14:12:19 Ian: I am hearing "Must" but with some variation possible depending on implementation and environment. 14:12:31 Henna: Reviewing the requirements more specifically.... 14:12:49 ...I have a question: how do we test for user profiles? 14:13:00 ravis has joined #wpwg 14:13:05 ...what is a 'user profile' here? 14:13:13 q+ 14:13:19 ack smcgruer_[EST] 14:13:47 slobodan: As far as Chrome is concerned, on desktop you can have separate user profiles. But on Android the passkey is available at the system level. 14:13:54 q+ 14:14:01 Henna: I'm trying to understand what behavior to expect. 14:14:04 q+ 14:14:14 ...suppose I have a passkey in Chrome. 14:14:20 q+ 14:14:27 present+ Sami_Tikkala 14:14:31 ack me 14:15:46 ack wan 14:16:11 wanderview: Regarding incognito mode ... how does it interact per profile? 14:16:19 ack smcgruer_[EST] 14:17:20 smcgruer_[EST]: To Ben's point, for creation we have the same behavior as passkeys. For authentication, existing BBK would be available in incognito mode. 14:17:46 https://github.com/w3c/secure-payment-confirmation/blob/main/bbk-requirements.md 14:18:39 q? 14:18:50 slobodan has joined #wpwg 14:19:00 smcgruer_[EST]: Regarding the user profile question, we can start to sort out as a WG now that we have some implementation experience. 14:19:13 ...maybe this is an unnecessary level of requirement. 14:19:32 ...we could say "doesn't leave the device" and then leave there rest unspecified. 14:19:37 Henna: How does it work in the current implementation? 14:19:53 ...if I move to another profile, what happens when I try to get a signature? 14:20:06 ...another use case is "if I am in incognito mode, what happens then?" 14:20:22 slobodan: Current behaviors on Android: 14:20:28 s/Android/Chrome on Android 14:20:44 ...one profile per browser...passkey is associated with user A (and BBK associated with it) 14:21:03 ..if I go to Chrome Beta that's a different browser, so it would generate a different key 14:21:22 ...in incognito mode will reuse a BBK from "parent" profile, but can't create a new one in incognito mode. 14:21:35 smcgruer_[EST]: Android supports multiple logins.... 14:22:08 ...when you create a passkey, you choose the Android account to associate with it. 14:22:25 ...BBKs on Chrome on Android use "Strongbox" which is "per-app" storage. 14:22:57 (And Chrome Beta is a different app than Chrome) 14:23:36 q+ 14:24:26 Ian: Should we remove any requirements related to accounts, or just provide hints? 14:24:26 ack smcgruer_[EST] 14:24:28 smcgruer_[EST]: Let's look at the ideal world. Is the following a reasonable statement? 14:24:45 ...a BBK would be persistent and available on the same physical device for a given passkey but would not leave the device. 14:25:07 ...in theory, multiple browsers might have access to the key 14:25:10 Doug: +1 14:25:11 Henna: +1 14:25:26 Henna: Concept of user profile is complicated, especially if inconsistent across device. 14:26:26 Gerhard: On mobile phones, app isolation suggests that we should not blur boundaries 14:26:46 ...I would perhaps restate the requirement that the BBK should be "within that browser instance only on that device" 14:27:14 ...I think that aligns with paradigm about how other things work. 14:27:19 ack smcgruer_[EST] 14:28:13 smcgruer_[EST]: On desktop, it's not obvious to me that we will go beyond user profile. 14:29:01 ACTION: Ian to work with Henna and Gerhard on update expectation about scope of BBK and "not leaving the device" 14:29:47 Henna: How is a BBK deleted? 14:29:54 ...can it be deleted independent of the passkey? 14:30:16 Slobodan: If you delete the app, you'll still have the passkey but we delete the BBK (which is associated with the app) 14:30:42 ...additionally there might be some amount of privacy concerns 14:30:57 ...there are other times it might be deleted independent of the passkey 14:31:07 smcgruer_[EST]: We are planning to delete BBKs that are unused. 14:31:46 Ian: I am hearing "When passkey is deleted BBK will be deleted but may also be deleted at other times" 14:32:01 smcgruer_[EST]: Note "best effort" around deletion of BBK when passkey deleted 14:32:33 Henna: Regarding device binding requirements, the one that's still pending is a signal about the nature of storage. 14:33:15 smcgruer_[EST]: I confirm that this has not yet been implemented (intentionally). There are open questions about whether this is needed, and that it's hard to define software and hardware. 14:34:05 rwatkinsma has left #wpwg 14:35:58 q+ to clarify current implementation as well 14:36:05 ack smcgruer_[EST] 14:36:05 smcgruer_[EST], you wanted to clarify current implementation as well 14:36:31 smcgruer_[EST]: The current implementation -- we only have hardware BBKs today (Chrome on Android). We are using Strongbox where available, and not doing BBKs where not available. 14:36:44 ...we might change that in the future, but today's implementation looks like that. 14:37:24 Henna: From my perspective, that's ok. Again, we could just clarify not solve for everything. 14:38:37 q? 14:39:00 Henna: I think the clarification that, for browsers on devices that have a TPM, a BBK is created. 14:39:09 ...and if there's no access to that, it's not created. 14:39:36 Gerhard: My preference would be for more signals but the offset is that you don't have an easy way to get validation that it's hardware bound. 14:39:51 ...but I'd like the signal even when hardware is unavailable. 14:40:04 q+ 14:40:09 ...it's still valuable regarding device takeover signal 14:40:35 smcgruer_[EST]: In the requirements doc we can make the diff clear. 14:40:53 ....the spec has no signal but also does not constraint to hardware. 14:41:02 ...the implementation constraints to hardware. 14:41:19 ...the tactical approach might be to update the requirements doc with "current status" 14:42:40 (We'll add this to our action to look at the requirements.) 14:42:57 Ian: Thank you for the review! 14:43:13 smcgruer_[EST]: Yes, thank you very much, Henna! 14:43:18 https://github.com/w3c/secure-payment-confirmation/issues/197 14:43:35 (Regarding icon management) 14:44:23 smcgruer_[EST]: We'd like to implement this pretty quickly so this is available soon 14:45:02 ...want to make this forward compatible 14:45:09 ...want to scale across payment methods 14:45:13 ...want to prevent against abuse 14:45:42 ...we are focused here on the facilitating entity logos (e.g., network and issuer icons) 14:46:22 doug: If we did look at the 3DS use case, is there any issue with rendering what's provided in the 3DS support for SPC? 14:46:31 ...in the 3DS spec we've specified the format for logos 14:47:19 smcgruer_[EST]: For SPC and 3DS we specify how to encode the payment instrument icon. Did we additionally specify how to encode the issuer/network logo? 14:47:19 Doug: yes 14:47:28 smcgruer_[EST]: I will have a look at the 3DS spec! 14:49:04 Ian: Does the browser know the payment systems? 14:49:34 smcgruer_[EST]: Practically speaking, no. 14:50:33 ...we should spec SPC so that it can work with the browser not knowing something, but perhaps the browser could catch up 14:52:31 Ian: I had pushed for "right/left or up/down" because that's closest to what the developer is thinking. 14:52:40 smcgruer_[EST]: We could also punt this in v1. 14:54:21 Ian: Could we minimally specify "order of icons" is significant 14:55:04 is it more of a "precedence" rather than "order"? 14:55:11 smcgruer_[EST]: That's what I had been planning for, so can work with that 14:55:28 Ian: We would just want to say that explicitly and include a Note that it's not fully specified. 14:55:44 smcgruer_[EST]: In my draft spec, I say that the UA can remove icons, but removes from the end of the list. 14:55:55 TallTed has joined #wpwg 14:56:44 smcgruer_[EST]: the other big question is what to do with aspect ratios 14:56:53 s/ratios/ratios and resolution 14:57:01 s/resolution/pixel density 14:57:51 zakim, close item 1 14:57:51 I see a speaker queue remaining and respectfully decline to close this agendum, Ian 14:58:06 q? 14:58:10 q- 14:58:27 smcgruer_[EST]: Please have a look at -> https://github.com/w3c/secure-payment-confirmation/issues/275 14:58:36 and -> https://github.com/w3c/secure-payment-confirmation/pull/292 14:58:54 zakim, take up item 2 14:58:54 agendum 2 -- Rechartering update -- taken up [from Ian] 14:59:21 -> https://lists.w3.org/Archives/Public/public-payments-wg/2025May/0000.html WG decision 14:59:58 zakim, take up item 3 14:59:58 agendum 3 -- TPAC 2025 -- taken up [from Ian] 15:00:04 Propose that the WPWG meet on 10-11 November. 15:00:44 Ian: I plan to ask for meetings on those dates 15:01:03 zakim, close item 3 15:01:03 agendum 3, TPAC 2025, closed 15:01:04 I see 3 items remaining on the agenda; the next one is 15:01:04 1. SPC updates [from Ian] 15:01:06 zakim, take up item 4 15:01:06 agendum 4 -- Next call -- taken up [from Ian] 15:01:12 22 May 15:01:27 Ian: We'll take spillover items and 3DS WG feedback 15:01:35 RRSAGENT, make minutes 15:01:36 I have made the request to generate https://www.w3.org/2025/05/08-wpwg-minutes.html Ian 15:01:42 RRSAGENT, set logs public