Meeting minutes
PING review of SPC
Weiler: We discussed SPC on a couple of PING calls (with SPC Editors on the calls).
… I think the biggest comments are on text currently in the security considerations section of the spec, notably around merchants linking customers
… there are some potential mitigations in the document that's we'd like to see as normative requirements for an implementation
… I want it to be possible to not have an identifying payment id provided by the user
… I would like to allow for the possibility that the payment system supports it.
... I've also filed some editorial comments.
Ian: Please describe the merchant linking scenario a bit more.
<Ian> smcgruer_[EST]: Sam is referring a world where the issuer is using tokenized card
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.
… our main suggestion for this (and implementation would be needed) would be to salt the credential IDs.
… this salt needs to go down into the authenticator level; this might not be palatable tot hem
Weiler: ApplePay does not expose card ID to the user at all
smcgruer_[EST]: ApplePay, GooglePay, and other wallets do a good job of protecting the user from the merchant
… user logs into wallet, wallet talks to backend
... ApplePay and GooglePay are not all payments on the web, however
Ian: We saw payment handlers as a way to do achieve these goals.
Nick_Shearer: In Apple Pay 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.
… we don't offer that level of privacy at this stage.
… it is more private than a regular credit card, but it does not mitigate cross merchant tracking completely.
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.
… I'd rather see something that just protects the user even with a malicious bank.
Rouslan: Is this tracking the only/main issue PING has found?
pete: The second issue ... this is unpartitioned storage. I want to hide my identity from the RP as well. I don't want to forced to have just one identity with each RP
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.
… it's even possible that the same merchant could get different credential ideas per transaction
pete: The concern I was referring to is not that one; it's rather me wanting to be able to have multiple identities with the RP
Ian: Problem statement is bank linking 2 identities (when they would otherwise be possible to keep separate)
Gerhard: There are 2 ways for card associations to tokenize:
a) Wallets can issue a token that lives across multiple merchants
b) E-commerce tokenization; one token per merchant
Gerhard: in the second case, the industry works hard to keep consistency even if card changes (e.g., lost card).
... SPC doesn't really deal with these 2 identifiers. SPC assumes credentials have been released on the backend.
...Here's an alternative to salting: 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.
weiler: Seems like a reasonable approach. I think salting is flawed. I'd rather have a mitigation that doesn't require cooperation.
rouslan: Gerhard, please write up your propose on GitHub.
<smcgruer_[EST]> +1 to that idea
<jeanLuc> 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?
weiler: Another issue: please support roaming authenticators with SPC.
Ian: That is our issue 12.
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.
weiler: I appreciate that. I appreciate most merchants are in that boat. But I can imagine merchants that don't need to know.
… I don't want to build systems that make them HAVE to know
<Zakim> weiler, you wanted to react to nicktr
smcgruer_[EST]: Just a heads-up that if we adopt something like Gerhard's suggestion, it will break our 3DS 2.3 integration.
… 2.4 will not be out for 24-36 months
Nick_Shearer: I think that when you choose to check out with a merchant, you can provide whatever contact information you want.
… so you can prevent cross-merchant tracking if you want for guest checkout (except around the instrument)
… but we have to accept the harsh reality of the ecosystem is that 16-digit instruments are not going away
… it will be hard to create something that will prevent cross-merchant tracking and get adoption
AdrianHB: Do payment handlers!
<weiler> adrianhb++
pete: Regarding payment handler and 1p context; cf discussion a couple of years ago
ian: To summarize the main issues from PING I heard today:
… 1) Reducing cross-merchant tracking (Gerhard's proposal is a good starting point)
… 2) Avoid unintentional linking on the RP side
… 3) SPC should support roaming authenticators
smcgruer_[EST]: Regarding roaming authenticators, that sounds like a product issue (roaming authenticators are not supported for SPC)
John_Bradley: There are some technical issues we'd need to sort about whether some credentials are usable in a 3p context.
...We'd need to add metadata, or segment RP IDs, etc.
… we'd have to dig into this before we enable roaming authenticators to work with SPC
<smcgruer_[EST]> +1 to what John_Bradley_ is describing - we're supportive of roaming authenticator support but there are technical challenges
<John_Bradley_> Yes invoking SPC from inside a payment handler would eliminate the third party context issue. I cant say how practical that is however. 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
Updates from the Privacy CG
ErikA: The Privacy CG spun up in January 2020 to work on harmonizing some implementations differing across browsers
… Storage Access is in Chromium but not Chrome
… (and implemented elsewhere)
… so discussions are still ongoing about whether movement will happen in more bespoke APIs or general APIs
… I think Storage Access may transition outside of the CG soon
... More areas are in flux; we are in the stage of "writing down reality"
...we are writing down "all the capabilities related to" Client-Side Storage Partitioning
... Another one that might be of interesting to this group: First Party Sets.
... Interesting discussions on that, whether user will understand, etc.
… but we have a good forum for these discussions.
… it's worth calling out that we take new proposals
… we're spinning off a new group as well that might be of interest, the Private Advertising Technology CG. That is mostly for ad ues cases but might be relevant.
Ian: Yesterday we reopened a topic related to user recognition
...there's a spectrum of authentication needs
...SPC is at the "strong" end
...but there are weaker signals for authentication for lower friction
...we would like to give stronger hints that the browser was "trustable" for a payment instrument
...trust tokens don't have a payment instrument binding
...the question is "has this browser made a legitimate payment with this instrument before? "
Gerhard: I have a general question: What constitutes informed consent? Is one "ok" button push enough? Or do you have to randomly check from time to time?
… would love some guidance here.
… we don't want to do this secretly/silently
… but we need to manage friction (and abandonment)
ErikA: It's worth calling out, trust tokens, blinded signatures
… did people attend the anti-fraud use cases breakout session last week?
… first party sets work suggests there will be vigorous debate about user understanding of terms and conditions
… don't want to force users to make a choice that leads to tracking
… the conversations will be difficult. +1 to writing down use cases and requirements.
AdrianHB: My observation about this debate is that there's a tension between user choice and creating features for purpose that are maliciously reused
… 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.
Weiler: When the user is presented the option of creating an SPC credential, can they "downgrade" it to a login credential?
smcgruer_[EST]: That's a worthwhile discussion. Two things to think about for later.
… some parts of the WebAuthn don't want a payments bit.
… 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?
<AdrianHB_> 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
NickTR: Thanks to our guests!!
… we appreciate the input.
Digital Goods API
Rouslan Digital Goods API slides and Digital Goods API explainer
rouslan: Progressive Web Apps that are wrapped can be distributed in app stores.
… trusted web app is PWA wrapped by Android wrapper
… the "trusted" bit comes from published signature information
… some app stores provide seamless purchase flows
...Digital goods API provides access to more seamless purchase flows
[Rouslan shows code and flow on slide 8]
rouslan: You can use DG API in your Web App to call into the Store (e.g., using an SKU)
… the API supports access to stores via a URL.
...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
… so you can purchase goods from the store via browser instead of your app.
...The developer creates one application that can be used in a variety of mobile and browser contexts.
… so this means a lower-cost development investment
… from user perspective, and be used either in a wrapped app or on the Web
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?
rouslan: We anticipate supporting the features of a native app store API. We do envision subscriptions, and changing subscription prices, and discounted subscriptions.
… I'm not familiar with purchase restoration flow (as such)
… we are interested in hearing from developers and what features are missing from their perspective
Nick_Shearer: Merchant wants to know whether user already has a subscription (via another device) with a service
rouslan: Digital Goods is currently in an origin trial
… looking to publish a draft spec in the WICG.
... We've not asked to include this in the charter for the WPWG at this time; we'll continue to iterate on the API
… we'd love to collaborate with other app stores, app developers, user agent vendors on this.
...We'd love to build this together with you!
Ian: When you say "WICG" do you mean "Too soon for a WG"?
Rouslan: Yes; lots of rapid iteration currently.
AdrianHB: What's the motivation for standardizing this API if it's not really available "on the Web" but rather "in a special context"
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.
AdrianHB: Cf also the MiniApp discussions
… I appreciate reusing the technology in different platforms, but when it comes time to think about formal standardization, there may be more pushback.
rouslan: We'd love to see this on the Open Web as well, it's just not yet feasible
AdrianHB: Would be interesting to know what happens if this were invoked in a browser on the Web.
Rouslan: I don't have an answer to that today, but we'd like to explore that.
AdrianHB: Why not call the DG API over the Web?
… why go via the browser?
Rouslan: That's a design choice; seamless auth is probably an important reason.
… in the case of Google, the play store Identifies the application via its signature
… that's not readily available on the Open Web
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
… you could imagine a site that wants to offer subscriptions and where different subscription providers are available in different countries.
… I think it's an interesting extension to payment request
ErikA: Microsoft app store supports PWAs natively; that might suggest still integration into store rather than open web
<Nick_Shearer> Thanks everyone, super interesting.
More use recognition use cases
<weiler> 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.
Jonathan: I'd like to take a few minutes to talk about user recognition (already on this week's agenda)
… we've been talking about authentication of the consumer (the 3DS risk use case).
...it's great to see the progress on securing payment transactions. Also great to see FIDO progress as the standard for authenticating consumers.
… more and more players are considering FIDO as a good standard for this.
...There are other environments that may wish to leverage SPC (e.g., wallets, Secure remote commerce)
[SRC = Secure Remote Commerce, and EMVCo technology; also called ClickToPay]
Jonathan: One note on SPC super powers and a possible extension: for a party to create a credential on behalf of an RP.
...But the more important topic for today is to understand who the user is.
… with new privacy controls in browsers (e.g., no 3p cookies) what can be done?
… a few minutes ago Rouslan pointed out that login is sticky in apps
… that's not the case on the Web, but there is a desire to for the user to be able to say "remember me"
… what can we do to consistently recognize the user when the user says "I want to be remembered"
… it's not my objective today to propose a solution, just want to highlight the user recognition topics
… yesterday we were discussing enabling banks to know "this is the same device" for risk assessment.
… something similar might be useful for user recognition, potentially using FIDO
… 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.
... How can we make progress collaborating to find a solution to this?
NickTR: To summarize the use case: consumers want to be remembered for a specific device across a broader swath of retail experiences.
Ian: I'd love to hear from the privacy folks if they think there is any relationship between this kind of user recognition use case and what is in scope for the isLoggedin API?
ErikA: Don't know. Is logged in may be named something closer to "login state API"
… not sure if it's applicable to this use case.
Jonathan: Does the API require an input string? Or does the API give back an identifier that is tied to a particular entity?
… the payment facilitator doesn't know who the user is at transaction time.
… if the user has accepted to be remembered for a particular origin, then the browser could give a hint
ErikA: I'm not familiar enough with how the apple folks are envisioning this.
...I think the isLoggedIn folks are interested in use cases.
… suggest going to the repo to log use case
… but I think there's not a lot of developer interest yet.
Action: Ian to work with Jonathan on next steps around user recognition and its relationship to isLoggedIn
<nicktr> +1 am interested
John_Bradley:
The Federated Identity Community Group is discussing this from a federation perspective. That might be a better form; I think your use case is sort of the opposite of what isLoggedIn wants to do.
… the Federated Identity CG is looking at WebID and isLoggedIn
Jonathan: Would be good to hear more about usage of FIDO without user verification.
John_Bradley: CTAP doesn't require user verification.
… that's under control of the platform.
… CTAP does not require user presence, but WebAuthn enforces it
… 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.
… some platform authenticators do not, unfortunately, speak CTAP
… so in practice they may not respond without user verification.
Jonathan: One question is what constitutes "user presence"
John_Bradley: Generally there is a real user interaction (e.g., pressing a button) so that malware can't press the button
… 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.
Jonathan: I'm hearing that current landscape may not lend itself to a solution here.
John_Bradley: That might change over time, especially if sync functionality is taken on
… in which case credentials may no longer be stored in secure elements
Wrap-up
NickTR: Can we postpone the Privacy Sandbox discussion?
Rouslan: Yes, next meeting please
smcgruer_[EST]: This is important.
PROPOSED:
* Meet 4 Nov, 18 Nov, 9 Dec
* Cancel 11 Nov, 25 Nov
<rouslan> +1
<Manish> +1
<smcgruer_[EST]> +1
<AdrianHB_> +1
<benoit> +1
Action: Ian to schedule meetings on 4 Nov, 18 Nov
NickTR: I want to thank AdrianHB as this is (we think) last meeting he will co-Chair.
<smcgruer_[EST]> +1
<benoit> +1
AdrianHB: This has been great; I've enjoyed working with everyone.
Ian: Last 2 words?
AdrianHB: Guess :)
<AdrianHB_> PAYMENT HANDLERS