13:52:32 RRSAgent has joined #wpwg 13:52:32 logging to https://www.w3.org/2021/10/27-wpwg-irc 13:52:57 Zakim has joined #wpwg 13:53:03 Meeting: Web Payments Working Group 13:53:18 Agenda: https://github.com/w3c/webpayments/wiki/Agenda-TPAC2021 13:53:26 Chair: Nick 13:53:28 Scribe: Ian 13:55:28 clinton has joined #wpwg 13:57:26 Hemnath has joined #wpwg 13:58:48 present+ 13:59:02 takashi has joined #wpwg 13:59:14 present+ 14:00:04 Anne has joined #wpwg 14:00:09 present+ Anne 14:00:13 present+ AdrianHB 14:00:19 present+ Tony_Nadalin 14:00:24 Chris_Wood has joined #wpwg 14:00:24 present+ Bart_de_Water 14:00:25 present+ 14:00:28 present+ Chris_wood 14:00:33 present+ Jean-Luc_di_Manno 14:00:35 JeanLuc has joined #wpwg 14:00:37 present+ Erhard_Brand 14:00:40 present+ Rouslan 14:00:42 present+ 14:00:48 present+ John_Bradley 14:00:51 present+ Paul_Grenier 14:00:57 present+ Chris_Dee 14:01:14 present+ Akshay 14:01:22 present+ Arno_van_de_Merwe 14:01:31 present+ Hemnath_Dhananjayan 14:01:33 nick_s has joined #wpwg 14:01:34 present+ Ryan_Watkins 14:01:38 present+ Richard_Ledain 14:01:42 present+ Nick_Shearer 14:01:46 ChrisD_ has joined #wpwg 14:01:46 present+ Jayadevi 14:01:50 present+ Emil_Lundberg 14:01:51 present+ 14:01:52 PaulG has joined #wpwg 14:01:56 present+ Jordan_Harband 14:01:59 present+ Baribalu 14:02:04 present+ Sameer_Tare 14:02:23 present+ Michel_Weksler 14:02:39 present+ Clinton_Allen 14:02:40 mweksler has joined #wpwg 14:02:44 present+ Jonathan_Grossar 14:03:11 bkardell_ has joined #wpwg 14:03:24 present+ Davor 14:03:28 present+ David_Waite 14:03:37 present+ bkardell_ 14:03:46 present+ Uno_Veski 14:03:50 Rolf has joined #wpwg 14:03:52 present+ Takashi_Minamii 14:03:57 present+ Rolf_Lindemann 14:04:14 elundberg has joined #wpwg 14:04:15 present+ Alain_Martin 14:04:16 rouslan has joined #wpwg 14:04:24 present+ Rouslan 14:04:46 jonathan has joined #wpwg 14:04:54 Topic: Web Authentication / WPWG joint meeting 14:05:43 present+ Julien_Rossi 14:05:51 present+ John_Bradley 14:06:09 present+ John_Fontana 14:06:41 ian: SPC is built on WebAuthn 14:06:58 present+ Michel Weksler 14:07:07 ... there have been discussions at Google about the relationship btw the two and some have surfaced into the WebAuthn WG 14:07:31 ... let's start by hearing the "Where are you going" from WebAuthn 14:07:32 present+ Bryan_Luo 14:07:49 tony: [Pinky voice] TAKE OVER THE WORLD! 14:07:50 Tony: We are currently revising the WebAuthN WG charter 14:08:20 ..once our charter has been officially approved we will begin to work on next things 14:08:49 Tony: What we are thinking about for WebAuthn Level 3: 14:08:59 John_bradley has joined #Wpwg 14:09:06 a) Delegation. You want to use WebAuthn in a "lights out" situation where you want to log into a computer, on behalf of someone else. 14:09:18 ...we don't know what solution there is yet. 14:09:27 b) Non Modal UI 14:09:37 c) Reauthentication from he discretion of the RP 14:09:41 s/he/the 14:09:49 ..how does the RP signal a desire for re-authentication 14:09:52 d) Recovery 14:10:12 ...how do I do backups / recovery? 14:10:21 ...there have been some discussions 14:10:23 q+ to understand "non-modal UI". Does that mean the UI presented by the browser? What is the use case/requirement? 14:10:28 ...some things in crypto we might be able to use 14:10:30 present+ Stephen 14:10:44 ...e.g., storage of private keys or syncing of keys across boundaries 14:11:28 Tony: We expect to run another year or so 14:11:48 Tony: I have not heard rumblings that we would go beyond level 3 14:12:12 John_Fontana: Last week there was vigorous discussion about key sync 14:12:18 ...in the FIDO Alliance 14:12:25 q? 14:12:27 ack AdrianHB 14:12:27 AdrianHB_, you wanted to understand "non-modal UI". Does that mean the UI presented by the browser? What is the use case/requirement? 14:12:35 AdrianHB: What does non-Modal UI mean? 14:12:45 ...what's different? 14:13:18 Tony: There are some situations where usability is an issue. 14:13:24 ...non-modal UI comes into play there. 14:13:26 present+ 14:13:31 ...I think Google introduced this topic 14:14:06 bryanluo has joined #wpwg 14:14:20 John_Bradley: A problem that RP's have is not knowing whether the user has a credential. this integrates discoverable credentials into a password-manager type flow. 14:15:06 ...the RP fires off a Promise in JavaScript. The UI waits for the user to click on the username dialog box where the browser would get a list of discoverable credentials and would present them along with any stored passwords (for example) and at the bottom of the dialog box to use another authenticator (e.g., roaming) 14:15:14 Manish has joined #wpwg 14:15:19 ..the user would select options and the results returned to the RP 14:15:33 ...so the RP does not find itself in a situation where there is UX without any WebAuthn credentials. 14:15:49 ...this mechanism might be of interest to SPC 14:15:58 Gerhard has joined #wpwg 14:16:03 present+ Kaz_Hoya 14:16:06 q+ 14:16:07 present+ Manish_Garg 14:16:14 present+ Rufus 14:16:15 bryanluo_ has joined #wpwg 14:16:20 q- 14:16:41 present+ 14:16:48 John: There are technical considerations that would need to be worked through depending on the platform (whether browser is separate from authenticator) 14:17:03 ...making sure only appropriate applications get list of payment credentials would need to be "seriously looked at" 14:17:11 ...but at a high level it does sound like what you want 14:17:40 q+ 14:17:42 AdrianHB: Could you filter the results (e.g., if the RP wants the user to pick from a particular subset)? 14:17:50 John: No. Only filtering is by RP ID 14:17:54 q+ to mention that the key idea is not "the website does not know which cred was selected", but "the website does not know whether or not the user has an enrolled credential, until the user selects one of the credentials." 14:18:00 ..in principle you could filter on user ID or other piece of metadata. 14:18:18 ...we'd have to address the question of how to indicate whether a credential is useable cross-site, is used for payments, etc. 14:18:31 q? 14:18:38 ...when we figure out how / whether to store the info, the next question is how to filter on the information 14:18:40 ack sm 14:18:52 SameerT has joined #wpwg 14:19:04 smcgruer_[EST]: There are two reasons why SPC needs changes in WebAuthn in the near term: 14:19:29 a) The first is the bit in the credential to know it is related to Payments and can be used in a cross-origin ceremony. We need that to prevent usage of credentials not so enabled. 14:20:01 b) Ability to ask the authenticator for a list of credentials. The transaction dialog is only usefully shown if there are credentials. 14:20:21 Tony: You are looking basically to attach metadata on credential usage 14:20:37 smcgruer_[EST]: Yes. We discussed in WebAuthn a bit on this 14:20:42 q? 14:20:55 present+ Gerhard_Oosthuizen 14:20:57 ack Rouslan 14:20:57 rouslan, you wanted to mention that the key idea is not "the website does not know which cred was selected", but "the website does not know whether or not the user has an enrolled 14:21:00 ... credential, until the user selects one of the credentials." 14:21:35 rouslan: I think the privacy we are talking about comes from the site not knowing they have an enrolled credential until the user has selected one in a modal UI. 14:21:40 AdrianHB: yes, that's what I meant. 14:21:57 present+ Elint_Chu 14:22:21 I have made the request to generate https://www.w3.org/2021/10/27-wpwg-minutes.html Ian 14:22:43 q+ 14:22:43 q+ to ask whether non-modal UI is using "hanging promises" 14:22:57 qq+ to comment on that 14:23:44 AdrianHB: In Payment Request we are asking the user "how do you want to pay"? Then with SPC, we find credential IDs for that payment method. I was hoping we could combine them but maybe we cannot. 14:23:51 ack smcgruer_[EST] 14:23:51 smcgruer_[EST], you wanted to react to rouslan to comment on that 14:24:33 AdrianHB: Can we leverage new features of WebAuthn to in some sense replace what we are doing with PR API...but we've not solved instrument stuff yet. 14:24:36 ack Gerhard 14:25:06 Gerhard: Here's a use case: A RP may wish to enable the FIDO token for payments, but might not want it to be used cross-domain. 14:25:23 present+ 14:25:44 Gerhard: I can see some issuers saying "I want to use transaction confirmation UX, but don't want this credential to be used by other parties than me" 14:25:51 +1 - it's tempting to try and solve both problems with one bit but they are different 14:25:54 q+ 14:25:56 q+ 14:25:59 q+ 14:26:46 ACTION: Gerhard to raise issue on distinguishing Payment type from cross-origin support in SPC repo 14:27:23 Tony: I wonder whether that is too much policy that is dealt with by the browser. 14:27:26 mknowles has joined #wpwg 14:27:39 Gerhard: I may be wrong, but I think some issuers may wish to restrict users. I think we should explore this. 14:27:56 Tony: I get worried about management 14:28:01 Gerhard: Understood. 14:29:09 John: I agree that if we are opening can of worms to give back attribute we need to look at the granularity. I agree that "can be used for payment" and "can be used cross-origin" are distinct. 14:29:24 Gerhard: We also wonder about "can do payment and "can do login" 14:29:33 q? 14:29:42 Rolf: The RP can already figure out whether the credential was exercised cross-origin. 14:29:54 ...the question is whether one can TRIGGER the operation cross-origin. 14:29:57 Bastien has joined #WPWG 14:30:00 present+ 14:30:04 present+ Susan_Pandy 14:30:14 present+ Jeff_Hodges 14:30:23 present+ Doug_Fisher 14:30:36 I have made the request to generate https://www.w3.org/2021/10/27-wpwg-minutes.html Ian 14:30:52 kazho has joined #wpwg 14:31:07 That might be too late to allow the customer to perform the challenge but then the issuer may decline it, and the customer performed an invalid action (bad UX) 14:31:20 q? 14:31:22 ack Rouslan 14:31:23 rouslan, you wanted to ask whether non-modal UI is using "hanging promises" 14:31:39 q- 14:31:40 Rouslan: Is the non-modal UI used in a "hanging Promise" scenario? 14:31:55 q- 14:31:55 ...related to conditional UI? 14:32:05 John_Bradley: Yes, I believe that is the current proposal. 14:32:22 q+ 14:32:38 JeffH: Even if not yet a formal term "hanging Promise" good enough for now 14:32:41 ack Sameer 14:32:58 Sameer: +1 to Gerhard's use case for limiting cross-origin use of payment credentials 14:33:31 q+ 14:33:34 s/not yet a formal term/not the formal term (if any)/ 14:33:37 ...in terms of discoverable credentials, today in 3DS, issuers try to get data from users. 14:33:44 ack sm 14:34:13 smcgruer_[EST]: I think Sameer said "You'd prefer that the credential cannot be used across browsers?" 14:34:16 present+ 14:34:40 Sameer: I think that the requirement is "Credential tied to device" and when the user changes devices, it's seen as a new device. 14:34:56 Stephen: You mean "browser on a new device" 14:35:10 q+ 14:35:19 Sameer: Yes. We'd also consider "different browser on same device" to be a "different device" 14:35:23 q+ to talk about syncable creds 14:35:42 Stephen: WebAuthn ties two browsers together. SPC does not yet. 14:35:58 ...is that useful for you to have the two browsers tied ? 14:36:07 Sameer: That data might not be sufficient. 14:36:18 JeffH: Has the device public key been discussed yet? 14:36:19 q- 14:36:36 q- 14:37:08 JeffH: Google is proposing in WebAuthn that authenticators will generate on demand a guaranteed device-bound key pair 14:37:42 JeffH:..and the public key is shared with the RP consistently to give a strong signal to the RP 14:38:06 ...the way it would work: the RP would request this extension on all registrations and authentications and would be able to see if there's a new device at the user's end. 14:38:14 Gerhard: Is user gesture required? 14:38:26 q? 14:38:33 JeffH: This is an extension which would just be submitted as part of auth/reg operations; the usual caveats would apply. 14:38:38 q+ 14:39:02 ...if a response successfully returns to the RP, there will be a key and a signature included, and if the device is different or a different authenticator was used, the signature and key will be different. 14:39:11 ..there's a pull request on this already for Level 3 (as an EXTENSION) 14:39:18 ..it's up to the RP to utilize this 14:39:24 ...highly security conscious RPs may wish to utilize this. 14:39:53 John_Bradley: The default credential is bound to the "user". You need to include the extension to get the device-bound credential. 14:40:14 ..I expect for payments RPs will want both signals: "same person" and "same person on same device" or "same person on different devices" 14:40:32 JeffH: It's not appropriate for every RP and requires work to parse and understand the data, which is by design. 14:40:57 q? 14:41:15 AdrianHB: When we talk about "same device" do you mean "authenticator" or something else? 14:41:44 Jeffh: Short answer is "it's mapped to the authenticator". It's most appropriate for platform authenticators. But there's nothing in the protocol design that would restrict roaming authenticators from implementing it. 14:41:57 ..but those roaming authenticators may have constraints that make it infeasible for them to implement. 14:42:39 John_Bradley: Imagine remote authenticators WERE capable of doing this (and, e.g., if caBLE comes into existence), a person could be on a Mac laptop but the authenticator might be on an Android phone. 14:42:56 ...the authenticator credential would be the same as it is when they authenticate on their phone. 14:43:08 AdrianHB: What does this feature give you that you don't already get today? 14:43:25 JeffH: We are imagining that user credentials can be synched by platform providers in the future (and are thus not hardware bound) 14:43:34 ..this extension gives a more hardware bound continuity signal 14:43:48 q? 14:43:54 ack Gerhard 14:44:15 present+ Michael_Knowles 14:44:36 Gerhard: In 3DS, in step one data is passed to the ACS which then decides whether to challenge explicitly. 14:44:36 Overall vision issue: https://github.com/w3c/webauthn/issues/1637 14:44:48 device-bound key extension: https://github.com/w3c/webauthn/issues/1658 14:44:52 present+ Max 14:45:16 s/device/issue: device/ 14:45:36 q- 14:45:52 q+ to ask about caBLE 14:45:54 PR: device public key extension: https://github.com/w3c/webauthn/pull/1663 14:46:27 AdrianHB: I am hearing a question about the use of WebAuthn for risk assessment 14:46:53 Gerhard: I am still interested in the use of FIDO but with less user presence check 14:46:56 present+ Garage 14:47:18 q? 14:47:25 Ian: What is the status of caBLE? 14:47:40 Jeffh: caBLE v2 for 3p is pushed out into one of the channels. 14:47:47 ..that can be experimented with. 14:47:51 q+ to ask about status of cross-origin WebAuthn? 14:48:08 ...status is "Google experiment" 14:48:10 ack ian 14:48:10 Ian, you wanted to ask about caBLE 14:48:33 ...we would hope that down the road other platforms would take advantage of this such that it could even work cross-platform 14:48:47 present+ Mike_Pennisi 14:49:06 Tony: There is an issue open 14:49:06 q? 14:49:09 ack AdrianHB 14:49:09 AdrianHB_, you wanted to ask about status of cross-origin WebAuthn? 14:49:28 AdrianHB: Can you stay what the status of cross-origin WebAuthn is? 14:49:56 (Ian thinks this means "at creation time") 14:50:47 smcgruer_[EST]: We don't yet have a clear path forward. We did have a conversation with the WebAuthn WG and that led to an issue about cross-origin creation. 14:51:03 ...it's not clear to me yet on how to make SPC properly integrated cross browser 14:51:22 AdrianHB: Could you summarize the ask? 14:51:34 ...e.g., "We'd like to be able to mark a credential as usable cross-origin"? 14:51:40 smcgruer_[EST]: That's a pretty good ask. 14:52:10 q+ 14:52:30 s/cross-origin creation/cross-origin authentication 14:53:06 AdrianHB: The goal is to let the user register a credential and allow non-RP origins to initiate the auth ceremony for payments 14:56:08 Ian: Should we reactive the joint task force (e.g., put SPC TF on hold)? Or just go to GitHub? 14:56:28 JeffH: Opening issues as needed on WebAuthn GitHub is just fine. 14:57:22 JeanLuc_ has joined #wpwg 14:57:27 ACTION: Stephen to open N issues (as appropriate) on WebAuthn GitHub about which features from SPC would be "best part of WebAuthn" 14:57:33 q? 14:57:39 ack me 14:58:30 RRSAGENT, make minutes 14:58:30 I have made the request to generate https://www.w3.org/2021/10/27-wpwg-minutes.html Ian 15:03:48 agenda? 15:03:58 Topic: User Recognition Use Cases 15:06:39 [Sameer Tare presents] 15:06:54 Sameer: there are two parts to my presentation today (1) refresher and (2) some ideas 15:07:15 present+ Tim_Cappalli 15:07:38 Sameer: when we say "frictionless" we mean "no challenge to the user" 15:08:15 [Review of data that is used as part of frictionless flow part of 3DS: Browser/Device Data, User Data, Transaction Data] 15:09:55 Sameer: User checks on payment button and there is no challenge if the risk assessment is satisfied, and payment is authorized in the background 15:10:38 Sameer: Browser data is vital for issuer's Transaction Risk Assessment. Issuers collect different data via different methods. Risk assessment methods vary widely. 15:10:56 ...so there's no way to say "this particular data element in the browser suffices" 15:11:57 ...issuers rely on a combination of existing identifiers for device identification, even though some of these identifiers may not have been created for that purpose. 15:12:28 ...increased privacy controls can inadvertently affect browser data for risk assessment which can lead to more user challenges (read: more friction and higher risk of cart abandonment) 15:12:47 ...using cookies is not a viable approach (3p cookies being removed) 15:13:23 ...there is lack (today) of hardware based identifiers 15:13:25 q+ 15:13:53 Rouslan: Could you state in one sentence what is the guarantee that you'd like to get during a transaction? 15:14:05 ...e.g., I want to know that I have seen this device 15:14:10 ..or I want to know that I have seen this user 15:14:16 ...or I have seen this card with this device 15:14:26 ...or I have seen this user using this card on this device 15:14:30 q+ 15:14:36 Sameer: I think "I have seen this device" 15:14:54 ...we get some other data about card and user in the transaction data. 15:15:14 ...what we are interested in is "this is exactly the same device we've seen before" 15:15:25 I have thoughts but I would like to hear the proposal first. 15:15:25 Rouslan: What is the purpose of knowing you have seen the device? 15:15:43 q+ 15:15:50 Suggestion: I have seen this user on this device for this payment instrument, and they have consented to be identified with this device to make their payment checkout experience better. 15:15:58 q- question answered 15:16:10 Sameer: Goal is to reduce total number of challenges; want to know whether this device has been seen before 15:16:17 q- benoit 15:16:23 Rouslan: Is the concern with the new device "this could be stolen card"? 15:16:28 Sameer: Ultimately yes. 15:17:06 ...each issuer has secret sauce, but device change is an important element typically. 15:17:14 Rouslan: If it's the same device but different card or user, do you care? 15:17:24 Sameer: Yes, but that's part of the overall data that's provided to the issuer 15:17:43 present+ Steven_Cole 15:17:58 Rouslan: If a user says I"m ok with step-up, is that ok? 15:18:04 Sameer: Yes, we want to talk about that today 15:18:20 s/I"m/I don't want to share my identity and I'm/ 15:19:28 Rouslan: In apps like Google Pay or Apple Pay there is a device-specific card number. That gives you a guarantee about the device (where the bank has approved usage of the card) but doesn't share the identity of the device beforehand. 15:19:36 ...is this slightly weaker guarantee for your use case? 15:20:30 [Ian missed reply] 15:20:39 q? 15:21:33 Rouslan: If there is a step in the browser to say something like "Enroll this card on this device" that will tell the issuer that this card bound to this device in some way, but without necessarily sharing any more detail, would that suffice in follow-up transactions that "this card is enrolled on this device" 15:21:37 Sameer: Potentially, yes. 15:22:32 Weiler: Why don't cookies suffice? 15:22:43 Sameer: They sort of do, but 3p are going away. 15:22:58 ...in real world checkouts, parties act in 3p contexts 15:23:11 ...and some iframes may be sandboxed 15:23:38 Weiler: For knowing "same device" is it sufficient to know "this is the same FIDO authenticator token"? 15:23:55 Sameer: It falls into middle area between 'user' and 'device' 15:23:56 q? 15:24:26 Sameer: If identifier is same, then it could work 15:24:50 Weiler: I heard you say you want to build a capability for a particular purpose. It's hard to build a capability and at the same time stop it being used for nefarious purposes. 15:24:54 q+ 15:24:55 ack Weiler 15:25:13 Weiler: I want to know how the "for payments" part will happen 15:25:32 Sameer: Agree 15:25:37 q+ to comment that a WebAuthN authenticator may not be available in some use cases - user may not have registered a credential: 3DS operates in a wider context than SPC 15:25:43 Sameer: ...the idea is to understand a payments context 15:25:54 ...we do something similar where merchant sets "allow" attributes on iframe 15:26:18 q? 15:26:26 ack me 15:26:26 +1, I would like to see the proposal and then will probably have some questions 15:26:31 ack Gerh 15:26:40 q- 15:27:14 Gerhard: Some additional context - first, people are doing this to make a decision whether to (1) outright decline a transaction 15:27:30 (2) Outright approve a transaction 15:27:36 (3) Choose how to challenge 15:27:52 ...browser data collection serves three purposes: 15:27:56 1) New device 15:27:59 2) Bad device 15:28:02 3) Tampering 15:28:15 ..."not a real users" 15:28:21 4) Recurring good users 15:28:29 ...I think we'd like to solve for "recurring good users" 15:29:11 Gerhard: I think the problem statement is "I have seen this user on this device with this instrument, and they've consented to be identified with this device to make this payment experience better." 15:29:23 ...and make sure it's happening now. (Avoid replay attacks) 15:29:37 present+ Nick_Telford-Reed 15:29:40 q? 15:29:51 I have made the request to generate https://www.w3.org/2021/10/27-wpwg-minutes.html Ian 15:30:11 AdrianHB: A lot of this happens before there's any interaction with a hardware authenticator. 15:30:21 q+ to ask that sameer point to the github repo he just now mentioned 15:30:38 -> https://github.com/w3c/wpsig/blob/gh-pages/3ds-reqs.md 3DS requirements repo 15:31:09 Sameer: If a hardware-backed authentication has taken place, this is a good way to establish 'good user' 15:31:40 q- 15:31:58 [Sameer moves on to a proposal] 15:32:48 Sameer: In native platforms, there is more structured device data available 15:33:44 ....today on browsers, device data is collected via (1) 3DS Method ... URL from the issuer/ACS (2) Authentication Request (AReq) 15:34:08 ...we gather device data in a way that does not interrupt user flow 15:35:48 ...summarizing the need: "find a way to identify a browser in a unique, privacy aligned manner to be used exclusively for Transaction Risk Assessment in a payment context." 15:35:57 ...we don't want to create a super identifier 15:36:19 -> https://github.com/w3c/wpsig/blob/gh-pages/3ds-reqs.md 3DS requirements repo 15:36:22 q+ 15:36:29 present+ Christian_Aabye 15:37:04 zakim, who is here? 15:37:04 Present: Ian, benoit, Anne, AdrianHB, Tony_Nadalin, Bart_de_Water, AdrianHB_, Chris_wood, Jean-Luc_di_Manno, Erhard_Brand, Rouslan, j_pascoe_, John_Bradley, Paul_Grenier, 15:37:07 ... Chris_Dee, Akshay, Arno_van_de_Merwe, Hemnath_Dhananjayan, Ryan_Watkins, Richard_Ledain, Nick_Shearer, Jayadevi, Emil_Lundberg, ljharb, Jordan_Harband, Baribalu, Sameer_Tare, 15:37:07 ... Michel_Weksler, Clinton_Allen, Jonathan_Grossar, Davor, David_Waite, bkardell_, Uno_Veski, Takashi_Minamii, Rolf_Lindemann, Alain_Martin, Julien_Rossi, John_Fontana, Weksler, 15:37:11 ... Bryan_Luo, Stephen, wseltzer, Kaz_Hoya, Manish_Garg, Rufus, bryanluo_, Gerhard_Oosthuizen, Elint_Chu, weiler, Bastien, Susan_Pandy, Jeff_Hodges, Doug_Fisher, jeffh, 15:37:11 ... Michael_Knowles, Max, Garage, Mike_Pennisi, Tim_Cappalli, Steven_Cole, Nick_Telford-Reed, Christian_Aabye 15:37:11 On IRC I see JeanLuc_, kazho, Bastien, SameerT, bryanluo_, Gerhard, Manish, jonathan, rouslan, elundberg, Rolf, bkardell_, mweksler, ChrisD_, nick_s, Chris_Wood, Anne, takashi, 15:37:14 ... Hemnath, clinton, Zakim, RRSAgent, wseltzer, j_pascoe_, jeff, hober, dlehn, bdewater, benoit, pea13, canton, Uchi_Uchibeke, ChrisD, AdrianHB_, kirkwood, weiler, ljharb, 15:37:14 ... rowan_m, manu, dlongley, slightlyoff, Travis, hadleybeeman, falken_, tobie, nicktr, smcgruer_[EST], Joshue108, ntelford, mkwst, Ian, jeffh, AdrianHB 15:38:37 Nick_S: I think that the challenge here is that other use cases will come up outside of payments 15:39:00 ...there are fraud prevention use cases outside of payments 15:39:13 ...so that's a challenge 15:39:34 ...also, on iOS we don't allow persistent hardware IDs across apps 15:39:49 ...so there is not an analogous system in iOS and modern Android versions 15:39:52 q+ to ask whether a unique browser ID is necessary? As you're using this in a risk-based assessment wouldn't a generic ID work - say all browsers mapped to one of 1000 IDs. 15:39:53 q+ re privacy and use case design 15:40:03 ...I want to dig into the central assumption that the issuer is the central point 15:40:19 ..we strive beyond regulatory requirements for privacy 15:40:36 ...I wonder if our ways of coming to the platform is that the browser/platform is performing this for you. 15:40:47 ...where the credential is device-bound, you have your identifier 15:40:55 ...this need is only for cases where instruments are not device-bound 15:41:18 ...there's more dive into but I think it may be difficult to do a "payment specific play" here. 15:41:40 Sameer: We are focused on payments context and don't want to make problem harder by addressing even more use cases. 15:42:34 ...there was a question of cross-app recognition. In 3DS on native, there is an embedded SDK in apps; that SDK cannot reach beyond the parent app 15:42:39 q? 15:43:53 mknowles has joined #wpwg 15:43:55 Jonathan: Regarding Apple and device token, since it is tied to the device if you send "123455" to the issuer, how different is that from what you are trying to achieve? 15:44:05 q+ 15:44:09 Nick: I imagine for payment methods like Apple Pay this is not required. 15:44:20 Jonathan: It is still something that is being shared 15:44:36 AdrianHB: I think that the solution is not a device id, but rather a device-specific version of the instrument 15:44:47 Jonathan: It's a binding to a specific device. 15:45:03 AdrianHB: Rather than the browser sharing a device ID, it shares a binding that is unique to the instrument. 15:45:13 ..the user would have to explicitly select the instrument before the ID is shared with the browser 15:45:19 ...that's the case in the Apple Pay flow 15:45:25 q? 15:45:29 q- 15:46:06 ack Chr 15:46:06 ChrisD_, you wanted to ask whether a unique browser ID is necessary? As you're using this in a risk-based assessment wouldn't a generic ID work - say all browsers mapped to one of 15:46:09 ... 1000 IDs. 15:46:17 uno has joined #wpwg 15:46:21 ChrisD: I wanted to quickly challenge the requirement for a unique browser ID 15:46:45 ..given that we're in the business of doing risk-based authentication, wouldn't it be acceptable for a browser to have a "family ID" 15:46:54 (have to step AFK for a minute, will be back) 15:46:55 ..many people could have a browser with a family ID 15:47:07 ...e.g., 1000s 15:47:18 ...and that family ID could be provided to risk engine 15:48:08 Sameer: We still need to know "this browser has used THIS DEVICE" before 15:48:08 q? 15:48:23 Sameer: This may not help the issuer sufficiently. 15:48:31 q+ 15:48:48 mweksler has joined #wpwg 15:48:50 ChrisD: Just to clarify I mean there's a GUID for, say, 1000 instances of the browser 15:49:04 q+ to ask whether we have any estimates of drop off rates and volumes without browser identity to understand the impact of this issue. 15:49:11 ...yes, a fraudster could get lucky and use your instrument on a browser with that GUID, but the odds go down (e.g., 1/10,000 families) 15:49:47 Sameer: It would say "Same instance of a browser" so that would be useful 15:49:55 ack ws 15:49:55 wseltzer, you wanted to discuss privacy and use case design 15:50:19 wseltzer: I think that you're hearing from several people the concern with the browser or device identifier 15:50:33 ...I'd encourage thinking in the direction of abstracting the use case one level 15:50:49 ...to describe the derisking were done if a device identifier is not available 15:51:07 ...we are seeing greater privacy concerns across W3C with persistent identifiers and sharing them across contexts 15:51:19 q? 15:51:24 zakim, close the queue 15:51:24 ok, Ian, the speaker queue is closed 15:51:47 Sameer: I think that we want to align with that privacy roadmap 15:51:56 ...we don't want to create a tracking identifier 15:52:03 ...at the same time we don't want a lot of user friction 15:52:19 aleksei has joined #wpwg 15:53:02 ...e.g., user involved every few transactions 15:53:11 ...or every several days 15:53:23 q? 15:53:27 ack smcgruer_[EST] 15:53:42 mweksler2 has joined #wpwg 15:53:43 smcgruer_[EST]: Going back to the native app use case. You mentioned that there an app embeds a 3DS SDK. 15:53:56 ... is the identifier that you get specific to the app? 15:54:20 Sameer: there are both platform specific identifiers and the 3DS SDk app id 15:55:02 smcgruer_[EST]: 3DS risk assessment is tied to a merchant in Android now 15:55:08 q? 15:55:29 s/Android/iOS, then 15:55:44 ack AdrianHB 15:56:06 mweksler has joined #wpwg 15:56:06 AdrianHB: I think that as a WG we really need to take a step back and try to find a solution 15:56:28 AdrianHB: I appreciate that payments folks are coming to the table with requirements and problem statements 15:56:32 ...so thank you 15:56:56 ...let's focus on problem solving for the web here 15:57:07 ack rousl 15:57:07 rouslan, you wanted to ask whether we have any estimates of drop off rates and volumes without browser identity to understand the impact of this issue. 15:57:21 rouslan: A couple of questions: 15:57:33 1) If we share "true" or "false" like "Has this card been used on this device previously?" 15:57:52 Sameer: That assumes selection of storage in the browser. 15:58:26 [ could trust tokens provide that answer? ] 15:58:57 2) Do we have an estimate of drop off rates or volumes of transactions or anything 15:59:02 ...when you don't know browser identity? 15:59:09 ...I'd like to understand the scope of the problem. 15:59:32 Sameer: EMVCo doesn't have those numbers. A lot of risk assessments are based on proprietary models 16:00:03 Gerhard: We could look at challenges not being completed. 16:00:10 ...I have some data... 16:00:34 ...there are billions of dollars in transactions that fail because browser is unknown, or user doesn't have phone, etc. 16:00:45 ..it's a serious issue 16:01:34 q+ did Shamir have a solution to present which we have not let him get to? 16:02:09 -1 cannot come early, sorry 16:02:13 +1 16:02:27 Apologies Sameer - I mistyped his name 16:03:23 PROPOSED: Prioritize the user recognition use cases int he WG's agenda 16:03:36 +1 16:03:44 +1 for more around 'reducing friction', and framing the problem. 16:03:49 +1 16:03:50 +1 16:03:52 q+ to thank Sameer for sharing requirements and also double-check that his solution was presented fully. 16:03:53 +1 -(think we should phrase as user and device recognition) 16:04:14 I have made the request to generate https://www.w3.org/2021/10/27-wpwg-minutes.html Ian 16:26:01 RRSAGENT, bye 16:26:04 zakim, bye 16:26:04 leaving. As of this point the attendees have been Ian, benoit, Anne, AdrianHB, Tony_Nadalin, Bart_de_Water, AdrianHB_, Chris_wood, Jean-Luc_di_Manno, Erhard_Brand, Rouslan, 16:26:04 Zakim has left #wpwg 16:26:07 ... j_pascoe_, John_Bradley, Paul_Grenier, Chris_Dee, Akshay, Arno_van_de_Merwe, Hemnath_Dhananjayan, Ryan_Watkins, Richard_Ledain, Nick_Shearer, Jayadevi, Emil_Lundberg, ljharb, 16:26:07 ... Jordan_Harband, Baribalu, Sameer_Tare, Michel_Weksler, Clinton_Allen, Jonathan_Grossar, Davor, David_Waite, bkardell_, Uno_Veski, Takashi_Minamii, Rolf_Lindemann, Alain_Martin, 16:26:11 ... Julien_Rossi, John_Fontana, Weksler, Bryan_Luo, Stephen, wseltzer, Kaz_Hoya, Manish_Garg, Rufus, bryanluo_, Gerhard_Oosthuizen, Elint_Chu, weiler, Bastien, Susan_Pandy, 16:26:11 ... Jeff_Hodges, Doug_Fisher, jeffh, Michael_Knowles, Max, Garage, Mike_Pennisi, Tim_Cappalli, Steven_Cole, Nick_Telford-Reed, Christian_Aabye 16:26:14 RRSAGENT, set logs public 16:26:38 mweksler has joined #wpwg 16:37:10 mweksler has joined #wpwg 16:51:47 bdewater has joined #wpwg 16:59:53 bdewater has joined #wpwg 17:07:19 mweksler has joined #wpwg 19:21:50 jeff has joined #wpwg 23:03:53 jeff has joined #wpwg