Meeting minutes
See also: 27 March minutes, 28 March minutes
Agenda Bashing
Overflow candiate topics:
Frictionless payments
Relation to recurring payments use cases (e.g., is re-authentication necessary or avoidable?)
Recurring payments
More discussion needed?
API refactoring
Using CredentialsContainer.get() instead of Payment Request API (#56)
SPC integrations
PIX; how do issuers and merchants communicate?
Payment Request
Next features?
Payment Handlers
Next features?
Reminder of half-height modal window
=====
SRC WG input on SPC
Clinton: A good place to start is to provide clarity between "recognition" (entering identity) and "authentication" (proof)
… today we'll look at a few emerging technologies that are relevant to these topics
… if we don't have a browser capability to identify / remember the consumer, they will need to enter their identity
… so upcoming challenges: no cookie access
… but if we do have some form of recognition, we can streamline and get closer to frictionless (e.g., display candidate list of cards)
… we would store information about cardholder identity upon first checkout, and then be able to retrieve the identity for subsequent transactions.
… we've talked about cookies, also "domain recognition" (cf bounce tracking to a domain that is separate from the merchant's origin)
… FedCM is compelling for federated login
… merchant recognition is also an option (for storing information in the merchant domain that is forwarded to the src system)
… so those are the four main models we've identified as helping with recognition
… one vision for what the browser can do to help is help with "horizontal recognition"...that is, cross-origins
[Diagram of FedCM for recognition]
Clinton: Stephen's demo showed a card list (rather than merely identities); that may or may not be interesting
… one thing we note when using FedCM for our use case is that some language (e.g,. "logging in") may confuse users for this case
… another topic: de-dupe in some scenarios (multiple SRC systems)
[Diagram showing FedCM to get identity followed by card selection followed by SPC]
clinton: In Stephen's demo, the FedCM response included the card reference so the user could pick the card and immediately go to authentication
<Zakim> AdrianHB_, you wanted to ask Stephen (or anyone who knows FedCM) if there is room for a concept of recognition vs authentication? (can wait to end) and to ask if FedCM could return fedrated id token?
AdrianHB_: I understand the concept of the federated identity token for user recognition across SRC systems.
… would that be an appropriate response from FedCM if you query each SRC system?
… suppose instead of a card list you got a federated id token?
Clinton: I _think_ so. I don't yet understand the restrictions on what can be enrolled for credential management. We're open to all discussion.
Tomasz: Yes, I think it works in FedCM to return a federated id token
… question is "who is the id provider"?
… if SRC system, then could get back SRC-compliant token
… if a third-party id provider, then there could be a round trip between id provider and SRC system to get a federated id token
AdrianHB_: My understanding of FedCM: browser makes a 1p request to identity provider; the identity provider can recognize the user but there is no authentication. Is that the correct understanding?
Clinton: The thing that confuses me is "logged in" v "logged out" status. If you are logged in, then you are already authenticated in some capacity.
AdrianHB_: Maybe there is a distinction between "there is a valid session" v. not
Tomasz: From my perspective, Adrian's perspective is accurate -- identity returned but no assumptions about authentication
<Zakim> nicktr, you wanted to ask about possibility of a "clicktopay.com" unified domain/recognition service
NickTR: What is the latest on a consolidate recognition service (clicktopay.com)
Tomasz: We do have an idea for a solution using a recognition domain
… user can be remembered by individual SRC system or a common entity
… both models are supported in SRC
… the common entity could become the identity provider
Ian: Common entity could help with de-dupe (using cookie jars for SRC systems)
jeanLuc: If the flow is (1) user recognition (2) get card list (3) authenticate
Clinton: In a world where FedCM call returns candidate card list, it would short-circuit some of SRC functionality
JeanLuc: So fed cm gathers the card list (and bypasses SRCI-I)
Ian: I feel like it's still the same flow, just implemented differently (get identity, get card list is still happening)
Clinton: Right, set of capabilities are still there
Tomasz: I think the short-cut flow is very illustrative at this point
… for the future maybe
<Zakim> AdrianHB_, you wanted to ask if FedCM could replicate the SRC model
AdrianHB_: I think FedCM, if it returns a card list, will group cards by SRC system
… assuming each SRC system is an identity provider
… so the fully distributed version (not using common entity) would lead to a bucket display of cards (by SRC system)
… to get a consolidated list you might need new FedCM capabilities.
… e.g., adding de-duping
AdrianHB_: That might be helpful for FedCM to include
… it would be interesting to call FedCM with a list...I want an identity token from any or all of these, and please consolidate the data you get back from them; give back the data in one response.
… but I don't know how that gets presented to the user
Clinton: I agree; I think that is a good reason to think about this as future functionality.
… if FedCM is for recognition (today) perhaps we leave it as such for today
<Zakim> smcgruer_[EST], you wanted to note the logged-out problem
smcgruer_[EST]: Regarding card selection through FedCM, you would run the risk of not being logged into to some SRC system.
… regarding de-dupe, we've suggested that the SRC folks raise an issue on FedCM to ad de-duping (see the FedCM issues list)
Tomasz: The SRC-I would need to call FedCM with all participating SRC systems.
… so no SRC system is missed
… this would happen via a JS SDK
Clinton: If we are using the identity as the FedCM credential, all the logic for presenting the candidate list happens within the SRC-I.
… in the model where FedCM returns card list, that moves the logic of how the card information is presented into FedCM.
… and maybe the merchant does not accept all card types
… FedCM does not include card filtering mechanisms.
<AdrianHB_> +1 - Let's find a way to use FedCM for recognition of consumer (not card list)
[On Authentication]
Clinton: SCR 1.3 includes features for Authentication Facilitation Service
… similar to GNAP flow
… there's a request to a party to find out what authentication options are available.
… the response of authentication methods includes a set of options, including SPC and FIDO
… this allows the merchant to request authentication via one of the authentication methods.
… suppose the merchant selects SPC
[We see slides where user enters identity, selects card, then SPC transaction dialog]
[Flow diagrams]
Tomasz: We've mostly talked about SPC in the context of 3DS. But what we are showing here is authentication without 3DS
Tomasz: In the flow, there is an authentication methods lookup phase (which could return "SPC")
… a second request/response would involve data needed for SPC (e.g., credentials, nonce)
Tomasz: When merchant gets back the assertion, the merchant calls the authentication service again and provides assertion to the SRC system for validation
<Zakim> nicktr, you wanted to ask if account reference == PAR?
NickTR: Where you refer to "account reference" ... is that PAR?
Tomasz: It's rather an SRC identifier for the card...it's a digital card id (not a PAN or PAR)
Ian: Any additional requirements for SPC from the SRC WG?
Clinton: I think the answer is "no" at this time :)
Tomasz: We are discussing fallback UI as an improvement
Gerhard: Does the SRC have similar display requirements as 3DS, or is it less prescriptive in display?
Clinton: Regarding various payment scenarios (split payments, etc.). From an SRC perspective, I think the details of all the types could be presented prior to the SPC call...better separation of concerns
Tomasz: There are some UX guidelines for full checkout
Clinton: I am intrigued by GNAP for more formal management of transaction contexts
jeanLuc: Interesting to see all the SPC possibilities
… who has responsibility in the case of fraud if SRC performs authentication?
Clinton: I suspect the answer depends on the authentication methodology. So if it's 3DS it might be one answer, and another answer with a different authentication method
Tomasz: +1
… SRC facilitates the authentication, but doesn't imply the SRC is the RP or authenticating party
Ian: I updated my slides on fallback to add new mockups that take into account some of the feedback we received on Monday.
<Gerhard> I like these. Probably just say 'Passkey' rather than Touch ID.
Frictionless Payments
NickTR: There's a tension here of course between privacy and friction
… important to keep both topics in mind
SameerT: Bringing recurring payments into SPC does not force merchants to use SPC.
<AdrianHB_> +1
SameerT: SPC is low friction, but still friction (from a 3DS perspective)
… using SPC does not preclude frictionless uses of 3DS
<clinton> +1
NickTR: I guess what we are looking for is "low friction" rather than no friction. Or "lubricated payments"
SameerT: The need to know this is the same user on the same device hasn't gone away
Gerhard: I want to reflect on a few points. There seems to be two models on how this could be done
… one group says "we want to silently detect presence of a user"
… one group says "nick should be asked to be recognized, and consent to be recognized"
… it might be interesting to have another option: "I don't know exactly who this is, but this is a trusted device"
… i think we will get further with explicit consent.
… another question is "who should choose"...should the bank choose? Or the merchant? or the user agent? or the customer?
… the browser could have a flag whether the user is ok with frictionless
… I think it's important to maintain some control in the bank (whether frictionless ok or not)
… the last element is "what does friction look like during the transaction"
… you could use SPC earlier in the checkout flow than just for authentication.
… remember 2-factor not mandated in a lot of situations
… I think there is a place where, if a bank allows it, you can do SPC with just a "Pay" button (no FIDO)
… a cryptogram is still created (by the browser)
<Zakim> AdrianHB_, you wanted to ask if FedCM could help with frictionless if it has a "payment" mode (that would also work with SRC). This would just change the prompt from "login" to "pay" or something
<Gerhard> Two topics to consider • Silently detecting a recurring customer Vs • Consent to be detected as recurring customer (and getting a better experience) We have 3 options in my view • RP controlled, but with Customer Consent • Browser Agent Controlled, with customer saying ‘remember me’. • RP and Browser Agent controlled. Remember what Platform Authentication does – it requires • OS level breakout • Biometric or PIN as part of that.
AdrianHB_: Gerhard, when you talk about key material provided by the browser, is that a key that somehow ties to the browser vendor, or ties to the device?
Gerhard: I imagine a credential.get per-browser call to mind a key and the private key is stored in the browser
… and the public key is domain bound
<SameerT> this possibly goes along the old proposal of browser id tied to a payment instrument stored and protected by the browser
AdrianHB_: Ok, the bank could do both FIDO-based and Web crypto-based registration
Gerhard: Right, that would allow the bank to first try browser-based, and if not , then go to SPC
<clinton> I suggest "efficient" to replace "frictionless."
AdrianHB_: I see Gerhard's model as being layered in the way that risk evaluation is layered.
… at one extreme, just recognizing the customer might suffice (e.g., $1 purchase for something the user does every day)
… then at the other end of the spectrum your security model needs to be stricter.
… and there's space in the middle we've not yet explored
… I am wondering whether FedCM could be used at the "low" end of the spectrum,
… then SPC with browser credential is next level up
… then SPC with FIDO is next level up
… so in the case of SRC, the merchant could:
* Call FedCM
* Get back one or more tokens (resulting from the browser reaching out to one or more systems)
* Then there is a payment-specific dialog with a set of identities
… so could FedCM have a "payment mode" where the customer is identified rather than talking about login
* Then with token, I can go back to SRC system and find what authentication mechanisms are available including SPC-lite and SPC-FIDO
… all this would not require iframes or redirects.
jeanLuc: I think there are two big problems: abandonment, conversion
… from merchant perspective.
… studies indicate people abandon when it takes time, or is complex, or tech problems.
… meanwhile, in France, 44% of out-of-band 2-factor authentications were abandoned
… there's a lot of friction when the user leaves the merchant context, and when another device uses (and more opportunities for failure)
… so it is desirable to keep user near merchant context.
… merchants meanwhile are reluctant to use exemptions
… what's great about SPC is that the issuer doesn't need to trust another party
… any low-friction option should include a way for bank to validate the assertions
SameerT: +1 to Jean-Luc; we've been trying to resolve this tension between 'user-as-user-of card" v. "user-as-customer-of-merchant"
… SPC is a good compromise: some amount of friction, but less than other redirect approaches
… what would be interesting to add on top is some sort of device recognition
NickTR: Say more about what you'd like
SameerT: in the app world we have an SDK generated id that is sticky
… so issuers know the device until the user has removed the app or cleared the OS
… in browser world we rely on data we can gather from JS and browser context
… cf previous presentations on browser-protected ID
NicKTR: Note that merchant can set a 1p cookie (with user recognition)
SameerT: But SDK manages its own functions. The merchant app just communicates the information out
… so even if merchant has a 1p cookie, the issuer has no way to know; the merchant doesn't share merchant recognition of user
smcgruer_[EST]: As always, if you are running an SDK in a merchant app, the merchant can do whatever it wants to the SDK. The Web's iframe model is better, but hits 3p cookie issues.
<SameerT> +1
smcgruer_[EST]: on mobile you are solving a different problem (individual merchant apps) compared to cross-origin
… you can use CHIPS for "single merchant" problem
smcgruer_[EST]: There is also a fundamental difference between app model and Web model. Users install apps and app stores mitigate risks.
… on the Web, can't have same assurances
… so Web standards are designed for a higher bar
… we have no way to restrict identification technology to payments scenarios (except, e.g., with things like dedicated UX such as SPC)
Ian: I think FedCM has steam; may want to focus on "great low friction" rather than "Frictionless"
gkok: one issue with iframes is -- difficulty troubleshooting
… example -- we troubleshoot payment transactions all the time and transactions are logged on the backend.
gkok: ...where things in iframes beak, hard to troubleshoot.
NickTR: Interesting to hear about value of observability in these situations.
aka AdrianHB_
AdrianHB_: Ian said something that I want to pursue: there's been an idea of extensible web...general purpose APIs
<Zakim> AdrianHB_, you wanted to say I think "packing payments stuff in" actually solves some of the privacy/security issues even though it goes against the "extensible web" idea.
AdrianHB_: But a disadvantage of this approach is that powerful features can be used "maliciously"
… whereas, if we can build in payment-specific features, with understandable UI, that's a huge benefit
… such dialogs prevent some malicious behavior
AdrianHB_: So while it might be more work for browser vendors to do payment-specific features, there's value
SameerT: Regarding gustavo's comments, there have been some updates to 3DS to help with logging
… and debugging ; happy to provide more details
smcgruer_[EST]: To Adrian's point, I agree with you (even if not everyone in every browser would also agree)
… I think there is benefit to provide more full-fledged UX to meet privacy needs
… but still hard to do.
… another thing we are struggling with: where to invest to find a success story
<AdrianHB_> +1 - SPC is the start of something beautiful :)
NickTR: I think SPC is very successful (already); by the timeline of most payment developments, we are still at the beginning
… traction of SPC is as fast as I've seen any payments tech get traction
<SameerT> +1
clinton: one of the primary issues of payments on the web is inconsistent UX
<AdrianHB_> +1000 - SPC is ALREADY in the 3DS spec. That's like Flash Gordon fast
clinton: In tracking and making steps of authentication observable, that's one of the components of SRC
<AdrianHB_> We are balancing SO many stakeholders. My observation is that we continue to iterate but continue to get closer to a solution that gets everything right
clinton: I think we are getting the tools; just a matter of mashing them together efficiently.
gkok: It can be hard to know who to trust. Is there a way to reuse the Brazil central bank model of trusted entities, and indirect entities?
… with incentives (e.g., direct entities get income, and risk punishment)
<jeanLuc> Issuers would have to implement SPC and issuer have the most inertia. As we observed for PSD2, openbanking or EMV 3DS. Issuers don't have same capacity as merchant to implement new technologies :( I guess it will need some time for issuers to understand and implement SPC
NickTR: Trusted/less trusted models imply (typically) a certification regime. Web doesn't have same model
NickTR: Thanks everyone for coming these past three days
… I'm particularly excited by exploring in the group PIX,
(Ian: And more on low-friction!)
Next meeting
13 April
NickTR: Thanks to all the presenters this week!
See also: 27 March minutes, 28 March minutes