13:44:22 RRSAgent has joined #wpwg 13:44:26 logging to https://www.w3.org/2025/05/22-wpwg-irc 13:44:39 Meeting: Web Payments Working Group 13:44:46 Agenda: https://github.com/w3c/webpayments/wiki/Agenda-20250522 13:44:49 Chair: Ian 13:44:56 Regrets+ Henna, NickTR 13:45:01 present+ Ian_Jacobs 13:45:04 agenda+ SPC updates 13:45:18 agenda+ Updates elsewhere at W3C 13:45:29 agenda+ Meeting time 13:45:31 agenda+ Next meeting 13:45:38 Scribe: Ian 13:48:39 RRSAGENT, make minutes 13:48:40 I have made the request to generate https://www.w3.org/2025/05/22-wpwg-minutes.html Ian 13:48:44 RRSAGENT, set logs public 13:58:06 present+ Ehsan_Toreini 13:59:43 present+ Jeff_Owenson 13:59:54 present+ Arman_Aygen 14:01:05 Ehsan has joined #wpwg 14:01:08 present+ Steve+Cole 14:01:25 present+ Ravi_Shekhar 14:01:50 present+ Sameer_Tare 14:01:57 present+ Sami_Tikkala 14:02:03 present+ Takash_Minamii 14:02:06 present+ Takashi_Minamii 14:02:07 Takashi has joined #wpwg 14:02:10 present- Takash_Minamii 14:02:37 present+ Slobodan 14:02:43 present+ Praveena_Subrahmanyam 14:02:48 RaviS has joined #wpwg 14:03:07 present+ Bjorn_Hjelm 14:03:31 present+ Sue_Koomen 14:04:05 present+ Rouslan 14:04:11 present+ Ben_Kelly 14:04:16 present+ Jean-Luc_di_Manno 14:04:25 present+ Stephen_McGruer 14:04:31 zakim, take up item 1 14:04:31 agendum 1 -- SPC updates -- taken up [from Ian] 14:04:49 SameerT has joined #wpwg 14:04:55 JL has joined #WPWG 14:05:04 Arman has joined #WPWG 14:05:17 [Expanding output states for SPC] 14:05:27 -> https://github.com/w3c/secure-payment-confirmation/pull/292 Pull Request 292 14:05:33 relates to https://github.com/w3c/secure-payment-confirmation/issues/275 14:06:23 smcgruer_[EST]: Goal is to distinguish more clearly "cancel this payment" from "cancel this means of authentication" 14:06:36 ...we introduce a new error state for canceling the payment. 14:06:51 ...there is corresponding UX 14:07:13 present+ 14:08:14 Ian: Is there anything about UX in the pull request or left to implementation? 14:08:29 smcgruer_[EST]: In the spec we slightly change wording to say "you always show the confirmation UX" 14:08:53 (No questions or comments) 14:08:58 smcgruer_[EST]: I will land the pull request. 14:09:29 present+ Doug_Fisher 14:09:39 [Feedback from 3DS WG on UX] 14:10:57 Sameer: 3DS WG happy with seeing logos for issuer, network. Our one comment is we'd like to see the logos edge-aligned. Not a deal breaker but users would see different UX, which isn't great. if it's possible, it could be better to have the logos edge aligned. But it's not a deal breaker. 14:11:15 ...any feedback from Chrome UX folks on that request? 14:12:08 smcgruer_[EST]: We've discussed centering v. edge-aligned; not feed back from designers. We can continue on some other issues (e.g., low res logo, weird sizes) 14:12:36 Sameer: Within the 3DS Spec we only have guidelines for display (but requirements for elements to be displayed) 14:12:45 ...we don't say what happens when logos are not provided. 14:12:53 ...we can continue to provide input on other questions. 14:13:28 https://github.com/w3c/secure-payment-confirmation/pull/294 14:13:33 Ian: Where are we on the payment system logo pull request? 14:14:00 smcgruer_[EST]: We added a label for accessibility 14:14:21 ...other than that, there's just small bits of feedback to be incorporated 14:15:20 ...we are taking the general stance that the output cryptogram will include the url of the logo if the browser showed it in some capacity. But in some error cases, there is not information about what happened (e.g., logo not provided at all, or logo had to be resized, or logo didn't download) 14:15:45 ...we consider it is "sufficient" to know via the cryptogram whether the logo was shown or not. 14:16:11 Ian: Is there error handling guidance in the 3DS spec? 14:16:30 Sameer: We do have some guidance, but I need to take a look to see if there's error handling related to logos. 14:16:51 Ian: How far is the implementation from the pull request? 14:17:12 Doug: I don't think we have error guidance in 3DS re: logos 14:17:45 Sameer: That makes sense. We treat logos differently in browsers and SDKs. 14:18:32 present+ Sharanya 14:19:09 -> https://github.com/w3c/secure-payment-confirmation/pull/297 Add the TAG security and privacy self-review questionnaire for BBKs 14:20:04 See also https://github.com/w3c/secure-payment-confirmation/pull/296 14:21:38 durkinza has joined #wpwg 14:21:46 -> https://github.com/w3c/secure-payment-confirmation/pull/293 14:22:30 Should BBKs be created on all passkeys even without the payment bit being set, so that RPs can use them in the future with SPC? 14:24:05 q+ 14:24:10 ack smcgruer_[EST] 14:24:31 smcgruer_[EST]: If we do BBK by default for all passkeys, are we encroaching on WebAuthn space? 14:24:36 Ian: But only available through SPC. 14:25:45 Sameer: It does make sense to have BBK on passkeys without payment bit set; we are hearing from issuers that they would want to use their passkeys for authentication. 14:25:57 ..if the issuers have passkeys for login, they do want to be able to use for SPC. 14:26:07 ..and they would want device binding in that case. 14:26:39 Ian: Any negative implementation implications? 14:26:58 Slobodan: From tech level, probably similar...the current restriction is that we check if the bit is set. 14:28:09 Bjorn: Fair question to ask ... suggest you check with the WebAuthn WG 14:28:27 q+ 14:28:31 ack Sam 14:28:44 Sameer: Is the bit only set at creation? 14:28:55 smcgruer_[EST]: Currently only at creation. Whether an update is possible is a good question. 14:30:28 Slobodan: Clarification - you get a BBK on authentication in all cases (even if bit is not set). The question is simply about creating a BBK at creation time if no payment bit set. 14:31:11 Sameer: If I have a passkey on the device and I use it with SPC, the BBK is created? 14:31:21 smcgruer_[EST]: Yes. 14:32:54 smcgruer_[EST]: If payment bit is not set at creation, then we don't have a way to get the BBK to the RP 14:33:21 ...the way to make this work consistently is to use the payment bit. 14:35:01 smcgruer_[EST]: If you are setting a BBK, maybe just set bit on creation 14:35:08 s/setting/expecting 14:35:13 Sameer: In practice, some issuers may support login before payments 14:35:25 present+ Kenneth_Diaz 14:35:42 Sameer: We can put guidance in the 3DS Spec 14:36:10 + 14:36:14 q+ 14:36:22 smcgruer_[EST]: We've not come to a clear conclusion in this group that "a passkey should always have a payment bit" and more strongly separate the concepts (auth for login, auth for payments) 14:37:25 JL: Are we looking at being able to create a BBK for other use cases for payments? 14:37:53 smcgruer_[EST]: Are you always thinking of passkey use cases? 14:37:57 JL: Yes. 14:38:15 ...e.g., accessing a bank account in EU requires multiple factor authentication. 14:38:23 ..it's a sensitive operation but not payments related 14:41:29 Ian: It would be similar friction either way: create a new passkey with bit set v. use passkey without bit but step up user when new bbk seen 14:41:57 smcgruer_[EST]: There's some implementation complexity that goes away if we assume "bit needs to be set at creation time" or if there's an "upgrade path" 14:42:23 ACTION: smcgruer_[EST] to look into whether a passkey can be upgraded to have the payment bit set. 14:43:50 q+ 14:43:57 ack JL 14:43:59 ack Sam 14:44:06 Ian: Would RPs like update path? 14:44:48 SameerT: I think that in a 3DS context, I think issuer using their own passkeys for authentication will be somewhat uncommon and ACS's are likely to be managing the passkeys. 14:45:28 ACTION: Ian to add an issue to the issues list about SPC passkeys always having the bit set, but with an update path. 14:48:12 Q Do we need to be more precise about the meaning of a "browser instance" or partitioning among user profiles? 14:48:30 Slobodan: We'd like the definition to include different profiles. 14:49:04 (No comments requesting more rigor in definition) 14:49:50 Ian: How do the change in requirements impact the Pull request to integrate BBKs in the spec? 14:50:16 Sloban: No changes needed if we don't add BBK back for non payment bit passkeys. 14:50:23 smcgruer_[EST]: I don't think the spec needs to change 14:51:12 smcgruer_[EST]: We hope to merge the PR for bbks-in-SPC some time next week 14:51:43 [SPC feasibility on Chrome iOS] 14:52:00 rouslan: We are often asked about SPC on other platforms (e.g., iOS). 14:52:13 ...payment request is available on iOS as is Web Authentication. 14:52:59 ...we have asked the WebKit team if it's possible to implement SPC in WebKit; we've not yet received responses. 14:53:13 https://lists.webkit.org/pipermail/webkit-dev/2025-March/032741.html 14:53:25 ...another idea is to explore the feasibility of implementing SPC in iOS 14:53:45 ...some options include a pull request on WebKit 14:54:12 ...another option is a Javascript shim that overrides the PR API implementation and looks for a payment bit for that payment method; this would only work in Chrome 14:54:21 ...an important topic would be how device binding is handled. 14:54:36 ...we don't want the keys to be synched for example. 14:54:59 ...we'd like to hear from the group how important they see this feasibility study, and any pitfalls people foresee 14:56:33 Ian: Many people tell me that they would like to see SPC on more systems. 14:56:43 +1 to Ian's comment 14:56:46 smcgruer_[EST]: At this point we would need to do some feasibility work first 14:56:58 Ian: This would also be a second implementation, which is important for our getting to Rec 14:57:14 zakim, close item 1 14:57:14 agendum 1, SPC updates, closed 14:57:15 I see 3 items remaining on the agenda; the next one is 14:57:15 2. Updates elsewhere at W3C [from Ian] 14:57:18 zakim, take up item 2 14:57:18 agendum 2 -- Updates elsewhere at W3C -- taken up [from Ian] 14:57:24 https://www.w3.org/TR/privacy-principles/ 14:58:25 https://www.w3.org/press-releases/2025/verifiable-credentials-2-0/ 14:58:47 zakim, take up item 4 14:58:47 agendum 4 -- Next meeting -- taken up [from Ian] 14:58:55 5 June 14:59:13 zakim, close item 4 14:59:13 agendum 4, Next meeting, closed 14:59:14 I see 2 items remaining on the agenda; the next one is 14:59:14 2. Updates elsewhere at W3C [from Ian] 15:00:02 zakim, close item 2 15:00:02 agendum 2, Updates elsewhere at W3C, closed 15:00:03 I see 1 item remaining on the agenda: 15:00:03 3. Meeting time [from Ian] 15:00:06 zakim, take up item 3 15:00:06 agendum 3 -- Meeting time -- taken up [from Ian] 15:00:20 Ian: We received a request to move this meeting 1 hour later to align with WPSIG meeting time. 15:00:32 ...please think about that possibility and we'll talk about it again at the next meeting 15:00:44 zakim, close item 3 15:00:44 agendum 3, Meeting time, closed 15:00:44 I see nothing remaining on the agenda 15:00:44 rrsagent, make minutes 15:00:45 I have made the request to generate https://www.w3.org/2025/05/22-wpwg-minutes.html Ian 15:00:51 rrsagent, set logs public 17:22:26 Zakim has left #wpwg