00:59:38 jeff has joined #wpwg 02:36:03 kirkwood has joined #wpwg 13:44:39 RRSAgent has joined #wpwg 13:44:39 logging to https://www.w3.org/2021/10/28-wpwg-irc 13:44:47 Meeting: Web Payments Working Group 13:44:58 Agenda: https://github.com/w3c/webpayments/wiki/Agenda-TPAC2021 13:45:02 Chair: Nick 13:45:03 Scribe: Ian 13:45:14 agenda+ PING review of SPC 13:45:22 agenda+ Updates from the Privacy CG 13:45:29 agenda+ Privacy Sandbox and impact on payments 13:45:35 agenda+ More use recognition use cases 13:45:43 agenda+ Digital Goods API 13:45:45 agenda+ Next meeting 13:54:10 zakim, who's here? 13:54:10 Present: (no one) 13:54:12 On IRC I see RRSAgent, Zakim, bkardell_, j_pascoe, bdewater, jeff, pea13, canton, wseltzer, hober, dlehn, benoit, weiler, ljharb, rowan_m, manu, dlongley, slightlyoff, Travis, 13:54:12 ... hadleybeeman, falken_, tobie, nicktr, smcgruer_[EST], Joshue108, ntelford, mkwst, Ian, jeffh, AdrianHB 13:54:16 present+ 13:56:27 present+ Anne 13:56:31 present+ Rouslan 13:57:36 jeanLuc has joined #wpwg 13:57:56 present+ Wendy 13:58:19 present+ Uno_Veski 13:58:40 present+ Jean-Luc_di_Manno 13:59:21 present+ 13:59:43 present+ Bart_de_Water 13:59:45 present+ Sam_Weiler 13:59:52 present+ Clinton_Allen 13:59:59 AdrianHB_ has joined #wpwg 14:00:11 present+ Adrian_Hope-Bailie 14:00:23 clinton has joined #wpwg 14:02:11 Anne has joined #wpwg 14:02:23 nick_shearer has joined #wpwg 14:02:23 present+ Nick_Shearer 14:02:55 present+ Stephen_McGruer 14:03:02 present+ Ryan_Watkins 14:03:36 present+ Nick_Telford-Reed 14:04:03 present+ Manish 14:04:09 present+ Jordan 14:04:25 zakim, take up item 1 14:04:25 agendum 1 -- PING review of SPC -- taken up [from Ian] 14:04:42 present+ Julien_Rossi 14:05:09 present+ Pete 14:05:14 Gerhard has joined #wpwg 14:05:25 present+ Gerhard_Oosthuizen 14:06:09 Sam: We discussed SPC on a couple of PING calls (with Editors on the call). 14:06:18 kirkwood has joined #wpwg 14:06:26 ...I think the biggest comments are on security considerations, notably around merchants leaking customers 14:06:31 hemnath has joined #wpwg 14:06:42 ...there are some potential mitigations in the document that's we'd like to see as normative requirements for an implementation 14:06:44 s/leaking/linking/ 14:07:01 ...I want it to be possible to not have an identifying payment id provided by the user 14:07:15 ...I would like to allow for the possibility that the payment system supports it. 14:07:15 q+ 14:07:22 Sam: I've also filed some editorial. 14:07:30 scribenick: nicktr 14:07:35 present+ Arno 14:07:47 q+ 14:08:08 ...that's the flow we anticipate 14:08:28 ...when you say "the user not provide an identifier", do you mean prior to using SPC? 14:08:45 smcgruer_[EST]: Sam is referring a world where the issuer is using tokenized card 14:08:46 ack Ian 14:08:54 scribenick: ian 14:09:25 smcgruer_[EST]: In such a situation, the user might give two separate card numbers. A naive implementation of SPC has to return the same credential list for the two identifiers. 14:09:49 ...our main suggestion for this (and implementation would be needed) would be to salt the credential IDs. 14:10:19 ...this salt needs to go down into the authenticator level; this might not be palatable tot hem 14:10:37 rouslan has joined #wpwg 14:10:38 (See issue 77 -> https://github.com/w3c/secure-payment-confirmation/issues/77) 14:10:44 present+ Rouslan 14:10:59 Sam: ApplePay does not expose card ID to the user at all 14:11:20 smcgruer_[EST]: ApplePay, GooglePay, and other wallets do a good job of protecting the user from the merchant 14:11:32 Manish has joined #wpwg 14:11:37 q+ 14:11:39 ...user logs into wallet, wallet talks to backend 14:11:45 ack smcgruer_[EST] 14:11:56 smcgruer_[EST]: ApplePay and GooglePay are not all payments on the web, however 14:12:03 present+ John_Bradley 14:12:05 present+ Manish 14:12:09 present+ Max 14:12:15 q? 14:12:15 ack Sam 14:12:17 ack weil 14:12:24 present+ Michael_Knowles 14:12:38 q+ to ask if this is mitigated by PH 14:12:43 q- 14:12:55 q+ 14:13:05 ack nick 14:13:13 Ian: We saw payment handlers as a way to do this. 14:13:14 ian: we have Payment Handlers but these have not had wide adoption 14:13:42 Nick: We expose a device identifier to the user and merchant. It's not regenerated on a regular basis. Merchants could, if they really wanted to, do cross-merchant tracking. 14:13:48 ...we don't offer that level of privacy at this stage. 14:13:56 q+ 14:14:01 ...it is more private than a regular credit card, but it does not mitigate cross merchant tracking completely. 14:14:01 q- 14:14:32 weiler: The proposed salt mechanism depends on the cooperation of the bank. I would rather see a scheme that does not depend on the bank cooperating with the user to protect the user. 14:14:43 ...I'd rather see something that just protects the user even with a malicious bank. 14:14:56 Rouslan: Is this tracking the only/main issue PING has found? 14:15:29 pete: The second issue ... this is unpartitioned storage. I want to hide my identity from the RP as well. 14:16:33 pete: I have one identity with each RP 14:16:46 bryanluo has joined #wpwg 14:16:55 rouslan: Yes, just like WebAuthn, but if we mandate the salt then ideally that would mean that the credential identifiers sent to each merchant would be different. 14:17:12 ...it's even possible that the same merchant could get different credential ideas per transaction 14:17:33 pete: My concern is not that one; it's rather me wanting to have multiple identities with the RP 14:18:25 present+ 14:18:29 q? 14:18:43 q++ 14:19:03 q-+ 14:19:26 takashi has joined #wpwg 14:19:34 q+ 14:19:43 ack Gerhard 14:19:48 Ian: Problem statement is bank linking 2 identities (when they would otherwise be possible to keep separate) 14:19:48 q+ re: roaming authenticators 14:20:09 Gerhard: There are 2 ways for card associations to tokenize: 14:20:19 a) Wallets can issue a token that lives across multiple merchants 14:20:33 b) E-commerce tokenization; one token per merchant 14:20:58 Gerhard: in the second case, the industry works hard to keep consistency even if card changes (e.g., lost card) 14:21:29 Gerhard: SPC doesn't really deal with these 2 identifiers. SPC assumes credentials have been released on the backend. 14:21:36 qq+ 14:21:37 pete has joined #wpwg 14:21:40 q- 14:22:34 Gerhard: Idea: during transaction, browser could generate a key pair. The public key is sent to the issuer. The issuer (RP) encrypts the SPC credentials using the public key. Then the browser can decrypt them. 14:23:19 weiler: Seems like a reasonable approach. I think salting is flawed. I'd rather have a mitigation that doesn't require cooperation. 14:23:27 +q 14:23:36 qq- 14:23:38 +1 to that idea 14:23:43 ack weiler 14:23:43 weiler, you wanted to discuss roaming authenticators 14:23:45 I don't know if it is relevant here, but the PAR (Payment Account reference) allow merchant ot identify the consumer account whatever the Tokan/PAN for loyalties reasons. The RP then can identify the consulmer account anyway. no? 14:24:00 weiler: There's a security issue as well we've noted; please support roaming authenticators. 14:24:03 q? 14:24:04 ack pete 14:24:22 q+ to ask Gerhard to write up his proposal on GitHub 14:24:37 pete: I appreciate the point about per-merchant encryption, but it's still not addressing partitioning with the RP 14:24:46 q? 14:24:50 q+ 14:25:04 q+ 14:25:31 ian: are we assuming that in a world without SPC the user still initiates identifying themselves with the RP 14:25:44 q- 14:26:34 q+ to clarify who we are trying to prevent from doing the tracking 14:26:45 jrossi has joined #wpwg 14:27:05 q+ 14:27:10 ack rouslan 14:27:10 rouslan, you wanted to ask Gerhard to write up his proposal on GitHub 14:27:11 ack rouslan 14:27:11 q- 14:27:19 rouslan: Gerhard, please write up your propose on GitHub. 14:27:30 q+ to comment that the encryption proposal will probably break our 3DS v2.3 integration :( 14:27:38 ack nicktr 14:27:44 q- 14:28:09 qq+ 14:28:14 nickTR: A merchant requirement is that they know who there customers are. In a non guest-checkout scenario they already do. So we're talking about non-guest checkout. 14:28:45 q+ 14:29:10 weiler: I appreciate that. I appreciate most merchants are in that boat. But I can imagine merchants that don't need to know. 14:29:21 ..I don't want to build systems that make them HAVE to know 14:29:23 ack weiler 14:29:23 weiler, you wanted to react to nicktr 14:29:31 qq- 14:29:36 ack smcgruer_[EST] 14:29:36 smcgruer_[EST], you wanted to comment that the encryption proposal will probably break our 3DS v2.3 integration :( 14:30:00 smcgruer_[EST]: Just a heads-up that if we adopt something like Gerhard's suggestion, it will break our 3DS 2.3 integration. 14:30:12 ...2.4 will not be out for 24-36 months 14:30:24 ack nick_shearer 14:30:27 present+ Joshua_Ssengonzi 14:30:47 Nick_shearer: I think that when you choose to check out with a merchant, you can provide whatever contact information you want. 14:31:03 ...so you can prevent cross-merchant tracking if you want for guest checkout (except around the instrument) 14:31:16 ...but we have to accept the harsh reality of the ecosystem is that 16-digit instruments are not going away 14:31:32 ..it will be hard to create something that will prevent cross-merchant tracking and get adoption 14:31:35 q+ 14:31:35 John_Bradley_ has joined #wpwg 14:31:38 present+ Hemnath 14:31:42 ack AdrianHB_ 14:31:43 present+ Haribalu 14:31:47 present+ Eilm 14:31:51 present+ Bryan_Luo 14:31:53 ack AdrianHB 14:31:57 AdrianHB: Do payment handlers! 14:32:03 adrianhb++ 14:32:04 present+ John_Bradley 14:32:14 present+ Rufus 14:32:16 present+ Takashi 14:32:27 +q 14:32:32 present+ Erik_Anderson 14:32:43 ErikAnderson has joined #wpwg 14:33:14 present+ Gargi 14:33:24 q? 14:33:32 ack paste 14:33:33 ack p 14:33:48 pete: Regarding payment handler and 1p context; cf discussion a couple of years ago 14:34:46 present+ Doug_Fisher 14:35:01 RRSAGENT, make minutes 14:35:01 I have made the request to generate https://www.w3.org/2021/10/28-wpwg-minutes.html Ian 14:35:27 scribenick: nicktr 14:35:34 ian: to summarise: 14:35:54 ...1) Reducing cross-merchant tracking (Gerhard's proposal is a good starting point) 14:36:07 ...2) unintentional linking on the RP side 14:36:31 ...3) security issue on roaming authenticators 14:37:28 present+ Susan_Pandy 14:37:34 smcgruer_[EST]: that sounds like a product issue (roaming authenticators are not supported for SPC) 14:37:43 John_Bradley: Are you saying "lack of roaming" is a security issue? 14:38:00 weiler: I want to see roaming authenticators supported. 14:38:30 John_Bradley: There are some technical issues we'd need to sort about whether some credentials are usable in a 3p context 14:38:39 scribenick: ian 14:38:42 ...we'd need to add metadata, or segment RP IDs, etc. 14:38:52 ...we'd have to dig into this before we enable roaming authenticators to work with SPC 14:39:11 +1 to what John_Bradley_ is describing - we're supportive of roaming authenticator support but there are technical challenges 14:39:11 -> https://github.com/w3c/secure-payment-confirmation/issues/12 Issue 12 14:39:58 zakim, close item 1 14:39:58 agendum 1, PING review of SPC, closed 14:40:00 I see 5 items remaining on the agenda; the next one is 14:40:01 2. Updates from the Privacy CG [from Ian] 14:40:01 zakim, take up item 2 14:40:01 agendum 2 -- Updates from the Privacy CG -- taken up [from Ian] 14:40:42 Yes invoking SPC from inside a paymenthandeler would eliminate the third party context issue. I cant say how practical that is however. 14:40:49 ErikA: Privacy CG spun up to work on harmonizing some implementations differing across browsers 14:41:06 ...Storage Access is in Chromium but not Chrome 14:41:11 ...(and implemented elsewhere) 14:41:30 ...so discussions are still ongoing about whether movement will happen in more bespoke APIs or general APIs 14:41:42 ...I think Storage Access may transition outside of the CG soon 14:41:58 invoking it in a iframe could solve it but people want to invoke SPC directly on a third party and that creates the third party issue 14:42:05 ErikA: More areas are in flux; we are in the stage of "writing down reality" 14:42:24 ...client-side storage 14:42:53 -> https://github.com/privacycg/storage-partitioning Client-Side Storage Partitioning 14:42:57 ...we are writing down "all the ways" 14:43:11 ErikA: Another one that might be of interesting to this group: First Party Sets 14:43:23 -> https://github.com/privacycg/first-party-sets First-Party Sets 14:43:39 ErikA: Interesting discussions on that, whether user will understand, etc. 14:43:45 ...but we have a good forum for these discussions. 14:44:06 ...it's worth calling out that we take new proposals 14:44:12 q? 14:44:18 ...we're spinning off a new group as well @@name@@ 14:44:47 ...mostly for ad use cases 14:45:06 present+ Solai 14:45:09 q+ 14:45:22 ack Ian 14:45:44 ian: yesterday we reopened a topic 14:45:55 ...there's a spectrum of authentication needs 14:46:03 ...SPC is at the "strong" end 14:46:20 ...but there are weaker signals for authentication for lower friction 14:47:19 ...we would like to give stronger hints that the browser was "trustable" for a payment instrument 14:47:34 ian: trust tokens don't have a payment instrument binding 14:48:01 ..."has this browser made a legitimate payment with this instrument before? " 14:48:03 q+ 14:48:12 ack Gerhard 14:48:53 Gerhard: What constitutes informed consent? Is one "ok" enough? Or do you have to randomly check from time to time? 14:48:57 ...would love some guidance here. 14:49:10 ...we don't want to do this secretly/silently 14:49:17 ...but we need to manage friction (and abandonment) 14:49:33 q? 14:49:57 ErikA: It's worth calling out, trust tokens, blinded signatures 14:50:09 ...did people attend the anti-fraud use cases session? 14:51:00 ...first party sets work suggests there will be vigorous debate about user understanding of terms and conditions 14:51:23 ....don't want to force users to make a choice that leads to tracking 14:51:39 ...the conversations will be difficult. +1 to writing down use cases and requirements. 14:52:10 q? 14:52:12 q+ 14:52:19 ack AdrianHB 14:52:21 ack AdrianHB_ 14:53:01 AdrianHB: My observation about this debate is that there's a tension between user choice and creating features for purpose that are maliciously reused 14:53:21 ...even if you are getting user consent, how confident are you that the user understands the consent, and can the user be tricked in a way that leads to tracking. 14:54:44 q? 14:55:09 q+ 14:55:12 ack weiler 14:55:51 weiler: When the user is presented the option of creating an SPC credential, can they "downgrade" it to a login credential? 14:56:09 q? 14:56:23 q+ 14:56:40 q? 14:56:44 smcgruer_[EST]: That's a worthwhile discussion. Two things to think about for later. 14:57:10 ...some parts of the WebAuthn don't want a payments bit. 14:57:28 ...the other part of the UX that comes to mind: what happens when a bank tries to enroll the user for payment and the user unticks the payment checkbox? 14:59:17 If browsers supported payments and login natively so they were pluggable features (like search) this would be a solved problem. Users would always know when a website was trying to initiate a login or a payment because they could build a UX to do that 14:59:20 zakim, close this item 14:59:20 I see a speaker queue remaining and respectfully decline to close this agendum, Ian 14:59:26 NickTR: Thanks to our guests!! 14:59:38 ...we appreciate the input. 14:59:42 zakim, take up item 3 14:59:43 agendum 3 -- Privacy Sandbox and impact on payments -- taken up [from Ian] 15:00:19 q? 15:00:22 ack me 15:00:31 [TAKE 3] 15:04:48 jonathan has joined #wpwg 15:05:56 zakim, close item 3 15:05:56 agendum 3, Privacy Sandbox and impact on payments, closed 15:05:57 I see 4 items remaining on the agenda; the next one is 15:05:57 2. Updates from the Privacy CG [from Ian] 15:06:01 zakim, close item 2 15:06:01 agendum 2, Updates from the Privacy CG, closed 15:06:03 I see 3 items remaining on the agenda; the next one is 15:06:03 4. More use recognition use cases [from Ian] 15:06:05 zakim, take up item 5 15:06:05 agendum 5 -- Digital Goods API -- taken up [from Ian] 15:07:19 -> http://www.w3.org/2021/Talks/rouslan-dgapi-20211028.pdf Rouslan Digital Goods API slides 15:08:02 rouslan: Progressive Web Apps that are wrapped can be distributed in app stores. 15:08:37 ...trusted web app is PWA wrapped by Android wrapper 15:08:53 ...the "trusted" bit comes from published signature information 15:09:10 q? 15:09:13 ...some app stores provide seamless purchase flows 15:09:53 -> https://github.com/WICG/digital-goods/blob/main/explainer.md Digital Goods API explainer 15:10:26 ...digital goods API provides access to more seamless purchase flows 15:12:06 [Rouslan shows code and flow on slide 8] 15:12:56 rouslan: You can use DG API in your Web App to call into the Store (e.g., using an SKU) 15:13:13 ...the API supports access to stores via a URL 15:13:34 present+ Jonathan_Grossar 15:13:44 present+ Solai 15:14:25 rouslan: In this code, the Payment Request API is used in tandem with the DG API; the API is used to get the details provided to PR API 15:14:55 ...so you can purchase goods from the store via browser instead of your app 15:15:33 present+ Kaustbha_Govind 15:15:33 q+ 15:15:49 present+ Brian_Lefler 15:16:13 rouslan: The developer creates one application that can be used in a variety of mobile and browser contexts. 15:16:24 ...so lower development investment 15:16:35 ...from user perspective, and be used either in a wrapped app or on the Web 15:16:36 q? 15:16:38 ack nick 15:16:45 ack nick_shearer 15:17:14 nick_shearer: This covers the purchase flow. One common use case for these sorts of apps is subscription. Do you anticipate a purchase restoration flow? Or would developers have to integrate with payment providers? 15:17:41 rouslan: We anticipate supporting the features of a native app store API. We do envision subscriptions, and changing subscription prices, and discounted subscriptions. 15:17:50 ...I'm not familiar with purchase restoration flow (as such) 15:18:06 ...we are interested in hearing from developers and what features are missing from their perspective 15:19:11 nick_shearer: Merchant wants to know whether user already has a subscription (via another device) with a service 15:19:32 rouslan: Digital Goods is currently in an origin trial 15:19:46 ...looking to publish a draft spec in the WICG 15:20:09 Rouslan: We've not asked to include this in the charter for the WPWG at this time; we'll continue to iterate on the API 15:20:35 ...we'd love to collaborate with other app stores, game apps, user agent vendors on this 15:20:44 q+ 15:20:59 rouslan: We'd love to build this together with you! 15:21:25 michel_cc has joined #wpwg 15:21:32 q+ 15:21:41 Ian: When you say "WICG" do you mean "Too soon for a WG"? 15:21:52 ack Ian 15:21:55 ack AdrianHB_ 15:21:55 Rouslan: Yes; lots of rapid iteration currently. 15:22:17 AdrianHB: What's the motivation for standardizing this API if it's not really available "on the Web" but rather "in a special context" 15:22:29 q+ 15:22:33 q+ 15:23:04 rouslan: It would be available in Web technology, even if that includes other distribution channels. Let the user choose their preferred venue. But keep using open web technology. 15:23:15 AdrianHB: Cf also the MiniApp discussions 15:23:38 ...I appreciate reusing the technology in different platforms, but when it comes time to think about formal standardization, there may be more pushback. 15:24:02 rouslan: We'd love to see this on the Open Web as well, it's just not yet feasible 15:24:06 q? 15:24:20 AdrianHB: Would be interesting to know what happens if this happens in a browser on the Web. 15:24:25 Rufus has joined #wpwg 15:24:26 zaki, close the queue 15:24:30 zakim, close the queue 15:24:30 ok, nicktr, the speaker queue is closed 15:24:31 Rouslan: I don't have an answer to that today, but we'd like to explore that. 15:24:45 AdrianHB: Why not call the DG API over the Web? 15:24:52 ...why go via the browser? 15:25:09 Rouslan: That's a design choice; seamless auth is probably an important reason. 15:25:22 ..in the case of Google, the play store Identifies the application via its signature 15:25:28 ...that's not readily available on the Open Web 15:26:19 ack nick 15:27:18 Nick_Shearer: This is a super interesting API. It constraints the proposal to treat it as platform-specific. I think it could also be useful on the Open Web 15:27:38 ...you could imagine a site that wants to offer subscriptions and where different subscription providers are available in different countries. 15:27:48 ...I think it's an interesting extension to payment request 15:28:41 ErikA: Microsoft app store supports PWAs natively; that might suggest still integration into store rather than open web 15:29:10 zakim, close this item 15:29:10 I see a speaker queue remaining and respectfully decline to close this agendum, Ian 15:29:14 q- 15:29:16 ack Er 15:29:18 zakim, close this item 15:29:18 agendum 5 closed 15:29:18 ack ErikAnderson 15:29:19 I see 2 items remaining on the agenda; the next one is 15:29:19 4. More use recognition use cases [from Ian] 15:29:23 zakim, take up item 4 15:29:23 agendum 4 -- More use recognition use cases -- taken up [from Ian] 15:29:45 Thanks everyone, super interesting. 15:30:12 I'm not objecting to the specific rearrangement, but I observe that it is very challenging during this TPAC, with so many meetings scheduled 1400-1600 UTC - I've been scheduling in much finer grained blocks during these hours to facilitate darting between meetings. 15:31:02 Jonathan: I'd like to take a few minutes to talk about user recognition (already on this week's agenda) 15:31:14 ...we've been talking about authentication of the consumer (the 3DS risk use case) 15:31:46 Jonathan: ...it's great to see the progress on securing payment transactions. Also great to see FIDO progress as the standard for authenticating consumers. 15:31:59 ...more and more players are considering FIDO as a good standard for this. 15:32:18 [SRC = Secure Remote Commerce, and EMVCo technology] 15:32:58 Jonathan: There are other environments that may wish to leverage SPC (e.g., wallets, Secure remote commerce) 15:32:59 Also called ClickToPay 15:33:37 Jonathan: One note on SPC super powers and a possible extension: for a party to create a credential on behalf of a RP. 15:34:10 Jonathan: But the more important topic for today is to understand who the user is. 15:34:42 ...with new privacy controls in browsers (e.g., no 3p cookies) what can be done? 15:34:57 ...a few minutes ago rouslan pointed out that login is sticky in apps 15:35:24 ...that's not the case on the Web, but there is a desire to for the user to be able to say "remember me" 15:35:50 ...what can we do to consistently recognize the user when the user says "I want to be remembered" 15:36:20 ...it's not my objective today to propose a solution, just want to highlight the user recognition topics 15:36:50 ...yesterday we were discussing enabling banks to know "this is the same device" for risk assessment. 15:37:03 ...something similar might be useful for user recognition, potentially using FIDO 15:37:36 ...there is a concept of "user presence" in FIDO; could we (with user consent) retrieve an identifier that would be stored together with FIDO credentials. 15:37:54 q? 15:38:26 Jonathan: How can we make progress collaborating to find a solution to this? 15:39:01 NickTR: To summarize the use case: consumers want to be remembered for a specific device across a broader swath of retail experiences. 15:39:04 q+ 15:39:27 Ian: what relationship could this have, if any, to isLoggedin? 15:41:46 ErikA: Don't know. Is logged in may be named something closer to "login state API" 15:42:01 ...not sure if it's applicable to this use case. 15:42:20 isLoggedIn -> https://github.com/privacycg/is-logged-in 15:42:24 Jonathan: Does the API require an input string? Or does the API give back an identifier that is tied to a particular entity? 15:42:32 q? 15:42:36 ack Ian 15:42:46 ..the payment facilitator doesn't know who the user is at transaction time. 15:43:10 ..if the user has accepted to be remembered for a particular origin, then the browser could give a hint 15:43:20 ErikA: I'm not familiar enough with how the apple folks are envisioning this. 15:44:13 ErikA: I think the isLoggedIn folks are interested in use cases. 15:44:29 ...suggest going to the repo to log use case 15:44:37 ..but I think there's not a lot of developer interest yet. 15:45:14 q? 15:45:30 ACTION: Ian to work with Jonathan on next steps around user recognition and its relationship to isLoggedIn 15:45:54 +1 am interested 15:46:24 John_Bradley: There's another CG that's discussing this from a federation perspective 15:46:51 https://www.w3.org/community/fed-id/ 15:47:14 John_Bradley: That might be a better form; I think your use case is sort of the opposite of what isLoggedIn wants to do. 15:47:22 ...so looking at WebID and isLoggedIn 15:47:46 Jonathan: Would be good to see about FIDO without user verification. 15:48:02 John_Bradley: CTAP doesn't require user verification. 15:48:09 ....that's under control of the platform. 15:48:19 ...CTAP does not require user presence, but WebAuthn enforces it 15:48:46 ...so you could get a silent authenticator (CTAP) . That's used in some use cases. You can find out if a credential is on a device at the CTAP layer. 15:49:39 ...some platform authenticators do not, unfortunately, speak CTAP 15:49:54 ...so in practice they may not respond without user verification. 15:50:38 Jonathan: One question is what constitutes "user presence" 15:50:53 John_Bradley: Generally there is a real user interaction (e.g., pressing a button) so that malware can't press the button 15:51:27 ...for a platform authenticator they could use practically anything, but I believe that the current design of platform authenticators requires access via user activation to unlock material for an authenticator to access. 15:51:41 Jonathan: I'm hearing that current landscape may not lend itself to a solution her. 15:51:51 s/her/here 15:52:06 q? 15:52:17 John_Bradley: That might change over time, especially if sync functionality is taken on 15:52:29 ... in which case credentials may no longer be stored in secure elements 15:52:34 I have made the request to generate https://www.w3.org/2021/10/28-wpwg-minutes.html Ian 15:52:57 zakim, close this item 15:52:57 agendum 4 closed 15:52:58 I see 1 item remaining on the agenda: 15:52:58 6. Next meeting [from Ian] 15:53:02 zakim, take up item 3 15:53:02 agendum 3 -- Privacy Sandbox and impact on payments -- taken up [from Ian] 15:53:30 q+ 15:53:43 NickTR: Can we postpone this? 15:53:47 Rouslan: Yes, next meeting please 15:53:52 ack smcgruer_[EST] 15:54:00 smcgruer_[EST]: This is important. 15:54:46 PROPOSED: 15:54:54 * Meet 4 Nov, 18 Nov, 9 Dec 15:54:59 * Cancel 11 Nov, 25 Nov 15:55:02 +1 15:55:04 +1 15:55:15 +1 15:55:32 +1 15:55:51 +1 15:56:01 present+ Tomoya_Horiguchi 15:57:11 I have made the request to generate https://www.w3.org/2021/10/28-wpwg-minutes.html Ian 15:57:20 ACTION: Ian to schedule meetings on 4 Nov, 18 Nov 15:57:24 Topic: Wrap-up 15:57:46 NickTR: I want to thank AdrianHB as this is (we think) last meeting he will co-Chair. 15:57:50 +1 15:57:55 I have made the request to generate https://www.w3.org/2021/10/28-wpwg-minutes.html Ian 15:58:11 +1 15:58:11 AdrianHB: This has been great; I've enjoyed working with everyone. 15:58:45 Ian: Last 2 words? 15:58:47 AdrianHB: Guess :) 15:59:03 PAYMENT HANDLERS 15:59:31 I have made the request to generate https://www.w3.org/2021/10/28-wpwg-minutes.html Ian 16:00:46 RRSAGENT, set logs public 16:00:49 zakim, bye 16:00:49 leaving. As of this point the attendees have been Ian, Anne, Rouslan, Wendy, Uno_Veski, Jean-Luc_di_Manno, benoit, Bart_de_Water, Sam_Weiler, Clinton_Allen, Adrian_Hope-Bailie, 16:00:49 Zakim has left #wpwg 16:00:53 ... Nick_Shearer, Stephen_McGruer, Ryan_Watkins, Nick_Telford-Reed, Manish, Jordan, Julien_Rossi, Pete, Gerhard_Oosthuizen, Arno, John_Bradley, Max, Michael_Knowles, bryanluo, 16:00:53 ... Joshua_Ssengonzi, Hemnath, Haribalu, Eilm, Bryan_Luo, Rufus, Takashi, Erik_Anderson, Gargi, Doug_Fisher, Susan_Pandy, Solai, Jonathan_Grossar, Kaustbha_Govind, Brian_Lefler, 16:00:53 ... Tomoya_Horiguchi 16:05:37 RRSAGENT, bye 16:05:37 I see 2 open action items saved in https://www.w3.org/2021/10/28-wpwg-actions.rdf : 16:05:37 ACTION: Ian to work with Jonathan on next steps around user recognition and its relationship to isLoggedIn [1] 16:05:37 recorded in https://www.w3.org/2021/10/28-wpwg-irc#T15-45-30 16:05:37 ACTION: Ian to schedule meetings on 4 Nov, 18 Nov [2] 16:05:37 recorded in https://www.w3.org/2021/10/28-wpwg-irc#T15-57-20