13:55:51 RRSAgent has joined #wpwg 13:55:55 logging to https://www.w3.org/2024/05/23-wpwg-irc 13:55:56 Meeting: Web Payments Working Group 13:55:58 Chair: NickTR 13:56:01 Scribe: Ian 13:56:24 Agenda: https://github.com/w3c/webpayments/wiki/Agenda-20240523 13:56:44 present+ Ian_Jacobs 13:58:15 agenda+ SPC and device bindin 13:58:19 s/bindin/binding 13:58:28 agenda+ Visa passkeys announcement 13:58:37 agenda+ Web Monetization topic 13:58:39 agenda+ Next meeting 13:58:46 present+ Rouslan_Solomakhin 13:59:08 present+ Kenneth_Diaz 13:59:40 present+ Fahad_Saleem 14:00:28 present+ Nakjo_Shiskov 14:00:29 yonpols has joined #wpwg 14:00:33 present+ Jean-Luc_di_Manno 14:00:42 present+ Anne_Pouillard 14:00:47 present+ Alex_Lakatos 14:00:55 present+ Steve_Cole 14:01:02 present+ Stephen_McGruer 14:01:12 present+ Juan-Pablo_Marzetti 14:01:18 Anne has joined #wpwg 14:01:22 Gregoire has joined #wpwg 14:01:29 present+ Eric_Groves 14:01:36 present+ Vasilii_Trofimchuk 14:01:47 present+ Grégoire_Leleux 14:01:54 present+ Jean-Michel_Girard 14:02:02 benoit has joined #wpwg 14:02:05 nsiskov has joined #wpwg 14:02:14 present+ Haribalu 14:02:30 gkok has joined #wpwg 14:02:32 present+ David_Benoit 14:02:43 present+ Gerhard_Oosthuizen 14:02:50 present+ Adrian_Hope-Bailie 14:03:00 present+ Nick_Telford-Reed 14:03:06 jmgirard has joined #wpwg 14:03:29 present+ Clinton_Allen 14:03:49 vasilii has joined #wpwg 14:03:54 present+ Vincent_Kuntz 14:03:57 JeanLuc has joined #WPWG 14:04:10 AdrianHB_ has joined #wpwg 14:04:14 zakim, take up item 1 14:04:14 agendum 1 -- SPC and device bindin -- taken up [from Ian] 14:04:18 Hari_PayPal has joined #wpwg 14:04:22 https://github.com/w3c/secure-payment-confirmation/issues/271 14:04:33 yonpols has joined #wpwg 14:04:53 vincent has joined #wpwg 14:05:00 Stephen: I plan to walk through what I just posted 14:05:26 stephen: This is a high-level proposal for adding device-binding to SPC without relying on WebAuthn SPK/DPK 14:05:55 ...we have heard many requests for device binding from the payments industry to meet regulatory requirements. 14:06:54 ...passkey synching does not on its own appear to satisfy requirements. There is a DPK/SPK extension but we don't have a sense of a timeline for support in platform authenticators. 14:07:10 q/. 14:07:11 ...so the proposal here is to do the device binding directly in SPC. 14:07:12 q? 14:07:13 yonpols has joined #wpwg 14:07:32 present+ Yannick 14:07:58 stephen: The generated SPC key would be signed by the WebAuthn key to avoid MITM attack. 14:08:25 ...expectation is that first time this device key appears, it would not be trusted. So there might be a step-up when it is first seen. 14:08:39 Yannick has joined #wpwg 14:08:40 ...however, on the same device for future authentications you would get back the same key. 14:09:17 ...an alternative would be to register something at webAuthn registration time (using payment extension) but it would not work for extant credentials or when a 1p uses a vanilla webauthn credential. 14:09:31 q+ to ask about browser profiles 14:09:33 ...note that the key would be (1) browser specific on a given device, (2) available cross-origin 14:09:48 stephen: We think per-browser is a feature rather than a limitation. 14:10:23 stephen: Where would keys be stored? There are software and hardware options; I think hardware is the right move here (to reduce risk of key exfiltration). 14:10:49 ...but there may not be a TPM available on all platforms. We would have to think about a other situations like roaming authenticators or hybrid. 14:10:54 Vincent has joined #wpwg 14:11:02 present+ Ravi_Shekhar 14:11:14 present+ 14:11:17 stephen: Regarding privacy sharing key cross-origin, there are two consent dialogs. 14:11:20 Gerhard has joined #wpwg 14:11:32 present+ 14:11:45 ...we will do a privacy review but the sense is that this is not adding issues beyond what has already been considered. 14:12:16 stephen: Some other topics are discussed in the FAQ (e.g., whether to offer a single-factor version of SPC where there is no biometric authentication and only the SPC key is used). 14:12:37 ...that's an interesting situation but I'm not proposing it here; one reason has to do with the use of the WebAuthn key to avoid MITM attack. 14:12:56 ...secondly and possibly more importantly, it simplifies the privacy store a lot if we keep close to WebAuthn's privacy bar. 14:13:52 q+ fahad 14:13:52 ...there's another topic: what if SPK/DPK does get wide interoperable adoption? If so, we have a few options including deprecation of the SPC feature. 14:13:59 q+ later 14:14:33 ...Ian also had an idea for defining the SPC key in such a way that it could be implemented in different ways (e.g., by browser or WebAuthn SPK). 14:15:29 Hari_PayPal has joined #wpwg 14:15:36 ...With respect to Device Bound Session Credentials, there are enough differences between the APIs that they are not really competing; and also their launch timeline would be much later. 14:15:36 q? 14:15:51 q+ 14:16:29 Stephen: Are we reinventing the wheel with this proposal? Yes, to a certain extent. WebAuthn already addresses a bunch of topics. Our approach here should be to stick close to WebAuthn's experience. We should use the same primitives that they do (e.g,. their signing algorithms and crypto) 14:17:19 Stephen: Regarding device attestation, we've heard requests from the industry (in WebAuthn space) for this. On the Web there are privacy implications revealing device information, and ecosystem issues (barriers to entry for new players due to whitelisting). 14:17:35 ...so at this time I am not proposing doing attestation with this proposal and hope that device binding alone will suffice. 14:17:56 ...please note that at time of writing, there are only two implementations, so attestation is of limited value at this point. 14:18:00 q? 14:18:03 ack nick 14:18:29 ack fahad 14:18:49 Fahad: When would key be created? And who is the relying party? 14:19:09 stephen: It's created at authentication time using SPC payment method. It's bound to the actual party of the WebAuthn credential. 14:19:14 present+ Juliana_Cafik 14:19:28 q+ 14:19:45 ...this means that it can be created by a party other than the RP, but only when the RP has said it's ok for 3p to use their credentials. 14:20:07 ...also, this key should not be used on its own, but only (in this proposal) in conjunction with the WebAuthn key. 14:20:15 ...the trust in the user is from the WebAuthn credential. 14:20:23 ..the trust in the device is from this newly minted identifier. 14:20:27 q+ 14:20:42 Fahad: In the 3DS context, the issuer would have to register the key the first time they see it. 14:21:02 q+ to ask about relationship to cookes (3p access, persistence) 14:21:12 Stephen: Yes. 14:21:24 s/cookes/cookies 14:21:47 q+ to ask whether 3DS would need to be modified for this 14:22:12 Hari_PayPal has joined #wpwg 14:22:35 q+ to suggest device key creation at creation time as well to identify current device 14:23:06 q+ to ask about regulatory satisfaction 14:23:14 ack nick 14:23:14 nicktr, you wanted to ask about browser profiles 14:23:39 nicktr: My question is specific to Chrome. You can have multiple profiles in a Chrome instance. Are these identifiers bound to the profile? 14:23:48 vasilii has joined #wpwg 14:24:07 Stephen: I suspect the answer would be one key per profile. 14:24:18 ...Rick points out that these would be clearable keys as well 14:24:26 ...site storage is tied to profile 14:24:58 ...not sure yet where we will handle private browsing mode, but might issue a dummy key 14:25:21 ack Gerh 14:25:30 Gerhard: I like the proposal. 14:25:55 ...I was in a call last week with a financial institution and they were worried about the attestation. 14:26:03 ...just to say that that may still be an issue. 14:26:48 ...what domain would the key be bound to? 14:26:59 +q 14:27:02 Stephen: The identifier would be tied to tuple of the relying party and (possibly) the credential id 14:27:05 q+ 14:27:31 Gerhard: So if I have two FIDO keys for an origin, I would get two device keys? 14:27:38 Stephen: Yes, at least to start. 14:27:44 Gerhard: That seems fine as a starting point. 14:29:39 Gerhard: Second topic (Gerhard shows a diagram) could we do the same device attestation and send it directly to the issuer? 14:29:52 ...that would take away a lot of the issue related to merchant MITM attack 14:30:33 Stephen: Yes, that is what FedCM is doing. Usually handled via a .well_known URL. But SPC doesn't do that because the initial proposal involved explicitly the RP not being actively involved in the flow. 14:30:48 ...if the ecosystem has changed, that may open new options. 14:31:47 q? 14:32:18 ack Nshiskov 14:32:43 ack nshiskov 14:33:18 Nakjo: I like the proposal. I'd also like to get a device key at the time of registration. 14:33:33 ..the issuer, while creating the passkey, could use the key and remember it for this device. 14:33:47 ..that would reduce step-ups not he same device 14:34:47 ...I like this proposal as, in some sense, a special cookie that can be exchanged via the merchant without having a direct issuer connection at authentication ime. 14:34:53 s/ime/time 14:34:56 q? 14:34:58 ack ns 14:35:06 ack me 14:35:06 Ian, you wanted to ask about relationship to cookes (3p access, persistence) and to ask whether 3DS would need to be modified for this and to suggest device key creation at 14:35:09 ... creation time as well to identify current device and to ask about regulatory satisfaction 14:35:21 ack ian 14:35:35 scribe: nicktr 14:35:55 ian: this would be available in a third party context so better than cookies 14:36:17 ...it would be good to be relatively long-lived (but still clearable) 14:36:38 ...if there is another key, do we have to modify 3DS? 14:37:01 ...I was also going to suggest device key creation at key creation time 14:37:19 ...do we have a sense of whether this would meet regulatory requirements? 14:37:24 scribe: ian 14:37:31 ack JeanLuc 14:37:37 zakim, close the queue 14:37:37 ok, Ian, the speaker queue is closed 14:38:06 ericgroves has joined #wpwg 14:38:10 JeanLuc: Thank you for this proposal. It's close to DBSC. Can we trigger the same key outside of SPC authentication? 14:38:23 ...there's a step where the issuer would like to identify the device (as is done with DBSC) 14:39:26 stephen: In the initial proposal, there would not be a way. But we could look at whether the key might be available via DBSC. 14:40:15 JeanLuc: DBSC+CHIPS in an iframe could work. If issuer could use the same SPC key to recognize the device and not trigger step-up that would be nice. 14:40:56 ..note that DBSC also involves a direct connection to a RP; we could imagine the issuer as an endpoint and the issuer could do device recognition. 14:41:44 Stephen: Both Ian and Rick thought DBSC should be characterized as distinct from this SPC proposal; not sure myself. 14:42:06 JeanLuc: One question is how to do key renewal 14:42:48 JeanLuc: The issuer might record a chain of device keys over time. Will the issuer have information about key renewal? 14:43:08 Stephen: I have not contemplated that. We get into concerns, however, about reinventing the wheel. 14:43:23 ...each API has its own way of doing key management. 14:44:26 JeanLuc: Would this work in a custom tab? 14:44:30 Stephen: yes 14:44:48 I have made the request to generate https://www.w3.org/2024/05/23-wpwg-minutes.html Ian 14:44:50 zakim, take up item 3 14:44:50 agendum 3 -- Web Monetization topic -- taken up [from Ian] 14:45:35 -> https://www.w3.org/2024/Talks/ahb-signed-http-20240523.pdf Adrian Hope-Bailie slides 14:46:52 AdrianHB_: This relates to Web Monetization, being incubated in a CG. 14:47:06 ..it's a declarative API for receiving payments at a Web site 14:47:26 ...an important use cases is very low value payments without user interactions 14:48:05 [Slide shows payment flow] 14:48:52 AdrianHB_: The browser authenticates with signed http requests. 14:49:09 [Current provisioning and transaction flow slide] 14:50:58 AdrianHB_: Key is more of a session key than an authentication key. 14:51:34 [We review different proposals for key management] 14:52:33 [Ian thinks AHB should check out https://github.com/WICG/dbsc/blob/main/README.md ] 14:52:59 Fahad has joined #wpwg 14:53:25 Looks like a good use-case fit for DBSC, no? 14:54:30 q+ 14:54:36 ack me 14:56:14 ack me 14:56:35 AdrianHB_: DBSC only gets us half way. We want the request signed; not just the challenge. 14:56:46 q? 14:56:53 q+ Are you using https://datatracker.ietf.org/doc/rfc9421/ 14:57:02 zakim, open the queue 14:57:02 ok, Ian, the speaker queue is open 14:57:06 q+, Are you using https://datatracker.ietf.org/doc/rfc9421/ 14:57:13 q+ Gerhard to ask about https://datatracker.ietf.org/doc/rfc9421/ 14:57:20 q+ to ask Are you using https://datatracker.ietf.org/doc/rfc9421/ 14:57:20 ack Gerhard 14:57:20 Gerhard, you wanted to ask about https://datatracker.ietf.org/doc/rfc9421/ and to ask Are you using https://datatracker.ietf.org/doc/rfc9421/ 14:58:03 AdrianHB_: We're proposing that, for Web Monetization, the browsers would use that to make calls to the wallet as a way for the browser to identify itself 14:58:30 ...GNAP has a bunch of ways for clients to authenticate themselves; this ties in nicely to the browser-as-client with keys 14:58:38 Gerhard; FedCM does some of this 14:58:47 s/Gerhard;/Gerhard: 14:58:56 I have made the request to generate https://www.w3.org/2024/05/23-wpwg-minutes.html Ian 14:59:03 zakim, close item 1 14:59:04 agendum 1, SPC and device bindin, closed 14:59:04 I see 3 items remaining on the agenda; the next one is 14:59:04 2. Visa passkeys announcement [from Ian] 15:00:15 Topic: next meeting 15:00:17 6 June 15:00:29 I have made the request to generate https://www.w3.org/2024/05/23-wpwg-minutes.html Ian 15:01:11 RRSAGENT, set logs public 15:01:13 RRSAGENT, bye 15:01:13 I see no action items