14:00:46 RRSAgent has joined #wpwg 14:00:50 logging to https://www.w3.org/2025/03/27-wpwg-irc 14:00:50 Zakim has joined #wpwg 14:00:52 Meeting: WPWG meeting 14:00:53 Scribe: Ian 14:00:56 Chair: Ian 14:01:02 regrets+ Henna 14:01:17 agenda: https://github.com/w3c/webpayments/wiki/Agenda-20250327 14:01:20 present+ NickTR 14:01:29 present+ Stephen_McGruer 14:01:41 present+ Ioana 14:01:45 present+ Rogerio 14:01:48 presnet+ Rouslan 14:01:50 present+ Fahad 14:02:02 present+ Jeff_Owenson 14:02:03 present+ Bjorn_Hjelm 14:02:07 presnt+ Rene_Leveille 14:02:10 present+ Gustavo 14:02:14 present+ Slobodan_Pejic 14:02:32 agenda+ SPC matching BBKs 14:02:41 agenda+ FYI on pull request to add BBK to SPC 14:02:48 agenda+ Charter 14:02:50 agenda+ next meeting 14:02:58 present+ Jean-Luc 14:03:03 present+ Doug_Fisher 14:03:27 zakim, take up item 1 14:03:27 agendum 1 -- SPC matching BBKs -- taken up [from Ian] 14:03:28 JL has joined #WPWG 14:04:06 -> https://github.com/w3c/secure-payment-confirmation/issues/271#issuecomment-2748417300 14:04:33 Stephen: We've been working on browser-bound keys in BBK. We have a prototype behind a flag. We also now have a pull request for the specification 14:04:42 -> https://github.com/w3c/secure-payment-confirmation/pull/286 Pull request 286 to add BBK to SPC 14:05:01 ...we think this reflects what was in the issue (271) 14:05:16 Rene has joined #wpwg 14:05:17 ...one partner raised a topic -- they would like to be able to only trust a set of known BBKs 14:05:32 ...they will get a BBK on creation, and that's the one they want to trust 14:05:39 ...they want to avoid a double authentication problem. 14:05:48 present+ Sameer_Tare 14:06:05 ...when second BBK issued, there would likely be another step-up to start to trust the second BBK. 14:06:22 ...but then the question is: why do we need passkeys if we are just using single BBKs? 14:06:25 q+ 14:06:36 ack nicktr 14:06:44 q+ nicktr 14:07:48 present+ Praveena 14:08:01 present+ Laszlo_Gombos 14:09:15 Gustavo: The reason we wanted BBK is for device binding. There's no way to know which device it is until the user starts interaction. 14:09:41 ...I've talked to banks and I think they've said "if I can't prove to regulators that the user went through some device-binding that I trusted" it wouldn't work for them 14:09:54 present+ Sami_Tikkala 14:10:05 Gustavo: Banks are using their own banking apps in many cases (rather than OTP) 14:10:23 ...when the user does 3DS there's an out-of-band interaction; regulators trust the app approach. 14:10:57 Stephen: Understood. The statement here is -- for the second factor we need to have proof of possession of a *known* device (although it might not be the *current* device) 14:11:20 q+ 14:11:20 q? 14:11:45 Gustavo: The BBK binding process might need to go through a banking app they trust. 14:11:59 Stephen: we've heard that BBK at passkey creation is acceptable 14:12:06 benoit has joined #wpwg 14:12:12 ...it's recreation (at authentication) is the challenge 14:12:18 ack nick 14:12:33 present+ David_Benoit 14:12:58 queue=Fahad, Doug, Ian 14:13:35 stephen: You can avoid 2 authentications by having a BBK accept list...send user to fallback flow in this case but they won't be authenticated; they will be shunted back for a single step-up 14:13:56 ...downside of this is that it makes the passkey useless 14:14:39 ack Fahad 14:14:40 ack Doug 14:15:07 Doug: I want to point out in terms of the second authentication; not every country has SCA. There's value in the BBK when it's generated on a new device. 14:15:26 ..the trust that comes into the first BBK is variable. There are other signals that the RP might have including fingerprinting, checking SIM 14:15:42 ...if you get a new BBK but it fits into a situation where you've seen the device, you may not need to challenge 14:16:10 ...having a fallback ux when there is no match tests poorly 14:16:49 q? 14:16:55 ..not sure there's a need for the bbk accept list but if so, option 14:17:03 q+ to ask again about non-ynched passkeys 14:17:54 q+ 14:18:37 ack me 14:18:39 ack nick 14:18:39 nicktr, you wanted to ask again about non-ynched passkeys 14:18:56 Ian: See also DBSC, trust signals, and other ways to get trust 14:19:09 NickTR: Can you say "must use synched passkeys"? 14:19:29 Stephen: WebAuthn only allows hints, and platforms are generally synching 14:20:16 slobodan has joined #wpwg 14:20:26 ack Rene 14:20:29 q+ 14:20:44 q+ gustavo 14:20:45 Rene: I think DBSC would not work in the case of SPC because the cookie is bound to the session of the merchant. 14:20:58 q+ JL 14:21:38 Rene: Extensions for either webAuthn or CTAP can be used by any authenticator 14:21:55 ...there might be interest in an extension to hint to authenticators to not have a syncable key 14:22:37 ...I was going to bring up RPK (relations public key)...finding a signal that would be device-binding-ish where the key is transferred through a proximity signal or it gets signed 14:23:21 ...I have a question -- has there been input from platforms here about implementing BBK 14:23:46 q? 14:23:49 ack JL 14:23:52 ack JL 14:24:20 Jean-Luc: There's a WebAuthn L3 flag on backup-eligibility. 14:24:36 ...this flag could send a strong signal whether the RP wants this credential to be synched or not 14:25:10 Stephen: I think that's an output property; the authenticator decides the value but there's no way to request a particular value 14:25:55 JL: We think DBSC + CHIPS would be useful here; combining SPC with this 14:26:28 JL: Regarding the proposal of "BBK accept list" to avoid double authentication; that seems to be the equivalent of registering a new device. 14:27:06 ...there's an opportunity to request BBK after step-up 14:27:09 q? 14:27:12 ack gu 14:27:13 q+ 14:27:14 TallTed has joined #wpwg 14:27:23 q+ 14:27:51 Gustavo: Could a key be created after a 3DS step-up? 14:27:57 q+ 14:28:27 gustavo: What would experience look like for user when they engage again? Would they have multiple passkeys? How would they know which device is which? 14:29:56 Ian: Can we add key after step-up? Or fallback authentication? 14:31:11 Stephen: Likely privacy issues ("ah, there was no bbk in this case!") 14:31:37 regrets+ Gerhard_Oosthuizen 14:32:22 [We discuss in more detail the UX of double SCA situation] 14:33:37 Gustavo: 2 SCA is a one-time thing (cf onboarding a card in a payment app and first doing faceid then doing OTP) 14:34:20 Fahad: In digital credentials discussions they are looking at this topic of "inline provisioning"; there haven't been privacy issues raised. 14:34:28 ...so you could give a provisioning URL if a key does not exist 14:34:47 ...and the user completes authentication within that URL and then processing continues depending on the outcome of the process. 14:34:55 ...so check out what DC folks are doing. 14:35:37 ...second topic - if we get an SPC error (fallback UX) and we do a 3DS call, would you then need to do a second SPC call? 14:35:54 Stephen: It feels like if we haven't authenticated the user we can't simply give you a new BBK. 14:36:15 ...if you want a passkey with a bbk that you trust, you need to do some sort of WebAuthn before or after you do the step-up authentication. That's the binding. 14:36:17 q? 14:36:20 ack me 14:36:21 ack smcgruer_[EST] 14:36:47 ack ni 14:39:25 [Nick walks through his understanding of the flow] 14:39:43 q? 14:40:07 Nick: Is the objection that there's never a second authentication, then it's broken. But if you can have a step-up once for a new device, then everything's ok. 14:40:44 Fahad: You're right that the concern is that on a new device, you'll see the payment sheet and the user will do biometric. Then after that because the device is new, there would be a step-up by the issuer. 14:42:08 q+ 14:43:09 q+ 14:43:13 ack Rene 14:43:39 Ian summarizes three things he heard: (1) not a problem at all (2) not likely a common problem (3) inline provisioning 14:43:49 q? 14:43:55 Rene: Question is what amount of user friction is acceptable when onboarding a new device? 14:44:33 ...do you want to require the user to log into a financial institution after an authentication failed, or do you want to do something with a synched passkey where you will end up doing the re-authentication inline which likely means less friction. 14:44:46 ...do you need the user to onboard the device in an app or a 1p context? 14:44:56 ..but I think there will be a second authentication regardless. 14:44:59 ack JL 14:45:12 JL: My understanding is that, to know there's a bbk, we need to go through SPC. 14:45:17 Stephen: Correct 14:46:18 JL: That means in this case, I would be concerned about whether same factor type (e.g., biometric) used twice; which might not satisfy regulation 14:47:07 JL: What about using DC API for second factor? 14:48:04 Stephen: relationship with DCI needs to be worked on more; lots of unknowns 14:49:16 zakim, take up item 3 14:49:16 agendum 3 -- Charter -- taken up [from Ian] 14:49:28 https://www.w3.org/Payments/WG/charter-2025.html 14:52:30 present+ Sue_Koomen 14:53:55 [Ian reviews changes in charter] 14:54:00 Ian: We need a plan to get PR API to Rec. 14:54:13 Stephen: We are still interested in the PR API and PH specs; supportive of that work 14:55:15 q+ 14:55:43 Ian: Please give feedback on charter within 2 weeks 14:55:43 ack nick 14:56:04 nicktr: Regarding PR API ... WebAuthn use L1, L2, L3 language for versioning 14:56:16 ...should we use similar language to provide greater clarity? 14:57:29 NickTR: Payments industry may want revision numbers. 14:57:44 Stephen: -1 to versioning info 14:57:58 ...for WebAuthn, the levels are not really observed by implementers 14:58:04 Rene: Levels are additive 14:59:16 zakim, next item 14:59:16 agendum 1 -- SPC matching BBKs -- taken up [from Ian] 14:59:22 zakim, close item 1 14:59:22 agendum 1, SPC matching BBKs, closed 14:59:23 zakim, close item 2 14:59:24 I see 2 items remaining on the agenda; the next one is 14:59:24 2. FYI on pull request to add BBK to SPC [from Ian] 14:59:24 agendum 2, FYI on pull request to add BBK to SPC, closed 14:59:24 I see 1 item remaining on the agenda: 14:59:24 4. next meeting [from Ian] 14:59:24 zakim, close item 3 14:59:25 agendum 3, Charter, closed 14:59:25 I see 1 item remaining on the agenda: 14:59:25 4. next meeting [from Ian] 14:59:35 zakim, take up item 4 14:59:35 agendum 4 -- next meeting -- taken up [from Ian] 14:59:41 Next meeting: 24 April 14:59:47 rrsagent, make minutes 14:59:48 I have made the request to generate https://www.w3.org/2025/03/27-wpwg-minutes.html Ian 14:59:51 rrsagent, set logs public 15:02:44 rrsagent, make minutes 15:02:45 I have made the request to generate https://www.w3.org/2025/03/27-wpwg-minutes.html Ian 15:07:30 rrsagent, set logs public