Meeting minutes
SPC and frictionless flows
[Gerhard Oosthuizen presentation and Possession Credential Proposal]
Gerhard: Ecommerce growing significantly. With COVID even more
… 65% of customers that abandon a checkout transaction challenge, does so because of friction.
… that translates to 100s of billions of USD
... $146B in card-not-present purchases are declined per year without a customer challenge
… 52% of orders declined for fraud were good orders to fulfill
… 62% of cardholders will abandon a declined card
… so it's very important to get the challenge flow right.
… Microsoft as a merchant posts data on a monthly basis (see, e.g., SCA Performance - February 2021).
… they have breakdowns per country per type of authentication.
... Authentication success rates are too low. Browser based is 75% compared to 45% for app-based
… abandonment is too high (browser: 13%; app: 18%)
… challenge rates are much too high (browser: 81%; app-based: 75%)
… Microsoft quote: "Payments ecosystem must find ways to lower the challenge rate.". But it's also important to note that approval rates improve when a challenge succeeds.
Bastien: looking at the MS figures, do you have any clue which system was used to create this data?
Gerhard: Data from 3DS2 in Europe
… it is improving every month
… some countries have had issues in rollouts, or ACS have had issues, and they are working through the issues
… this is not a critique of 3DS2 directly, just about the state of deployment
[On 3DS in the slides]
Gerhard: 3DS 2.2 is the latest deployed version; 2.3 is in review.
… quick reminder: frictionless flow then challenge flow (optional). Goal is challenge no more than 20% of transactions.
… 3DS2 big additions were (1) app support (2) frictionless flow.
… the frictionless flow runs in a hidden iframe (methodURL)
… here we are having discussions about FIDO. And there are two flavors: user validation (presence check) and user verification (multifactor)
… noting two types of authenticators: platform, roaming
… SPC is a great move forward.
… first, gives predictability to merchant. Merchant controls the experience, whereas the issuer controls the identity [management]
… (delegated auth requires the merchant to take control of both...)
… second, there is a "payment focused display"
… better customer experience, especially since many authenticators don't have a built-in display
… closer to the regulatory intent (of, e.g., PSD2)
… a challenge for SPC is that both the merchant and issuer need to support it.
… even if the merchant does not do SPC, ultimately we as providers to issuers will still use SPC from the issuer domain, because of the transaction confirmation dialog and the signature over the transaction data.
… what interests Entersekt is to create a bridge.
… any extra click increases (by something like 10%) abandonment rates
… we want to avoid the extremes: too much friction v. no challenges as all (which can lead to higher false declines)
… what can we do?
... Two suggestions here (1) SPC with one-click (1) Silent challenge
… a silent challenge is where the user does not participate, but we have uplift on the approval rate
… with the latter the issuer is more likely to approve the transaction, reducing false declines.
nicktr: Another topic - need explicit consumer consent.
… that's lost in the debate about invisible payments
Gerhard: Predictability is really important as well
[Gerhard on PSD2]
Gerhard: Number of rules around challenges. When challenge occurs, requirement is 2 factors
... But outside of Europe there are other authentication requirements, e.g., single possession factor (e.g., SMS, App-based OTP, push to mobile)
… provable possession is a very strong signal for risk based authentication
… a core driver behind the browser data collection requirements of EMV 3DS
[Gerhard on requirements for a solution]
Gerhard: Needs to be privacy-friendly and secure.
… more specifically:
...Domain bound (only visible to issuing party). Accessible using identifier only known to issuer. Get user consent before issued to that user. Resettable by the user.
... Security reqs: generated by the browser
... Lots can be learned from WebAuthn, SPC experiment, Credential Management API, and Web Crypto
... WebCrypto lets you generate key pairs with protected private key in the browser; enables signing a challenge.
… with these technologies we can generate a signature
[Gerhard on what would NOT work well]
Gerhard: (1) cookies ...no user consent...nothing signed....always provides for full domain, i.e., not linked to a specific credential ID
… (2) WebID does not solve for complete user challenge
… (3) Trust tokens....anonymity is not what's needed here
mhofman: In the use case of payments, we already have an idea of who the customer is. We want to authenticate that the browser has been used by a person we already know.
… I think that there is a lack of web platform primitives to do this today.
Gerhard Proposal:
* Possession only factor issued by the browser
… user specific (credential ID) and domain-bound
… only generated after explicit consent
* Stored with credential management API
[Architectural slide]
Gerhard: From a consent perspective, during enrollment the user consents first, then credential provisioned in the RP's domain
… the consumer needs to be able to manage (including delete) the credential at any stage; similar to password management in the browser
… for authentication, signature created only after a user action
… allow the RP (issuer or bank) to choose the required level of trust.
… that might be, for example, full strong customer authentication, or for some transactions, possession only could suffice
… this could be implemented with a checkbox, for example, on the transaction confirmation dialog: "Don't ask me again for 30 days" or "Don't ask me again for transactions less than $10" etc.
... this might only show up after a full consent auth for example
… question: would the issuer be able to also indicate if a user challenge is NOT needed (enabling a frictionless flow) without user consent?
SameerT: Great presentation. What is your vision for the checkbox? Does consent go to the issuer or is stored locally?
Gerhard: What we've considered (because we want to maintain the current SPC flow) is that the consent is stored in the browser.
… but we could imagine that the issuer provides a hint like "It's ok if the user doesn't want to see the dialog for this transaction."
SameerT: From a 3DS perspective, it looks like there are 2 different consents: (1) creation of the initial ID and (2) adding the browser to a sort of "trusted list"
Danyao: You mentioned a few options for consent (e.g., 30 days or low transaction amounts). Who in this model would control which options would be presented to the user?
Gerhard: That's a topic for discussion. Our initial view was that browsers could differentiate themselves through different features.
... Merchant also needs to be able to provide hints like "I need an SCA here."
<Deepu> Does the vision also include provision to withdraw consent?
Danyao: Assuming user gives consent, when browser does frictionless flow, would the issuer and merchant have data what happened?
Gerhard: Yes, the signature should include that information.
gkok: Regarding this specific flow. Would there be cryptographic proof?
Gerhard: For me there would be cryptographic proof. The browser would say "I issued this based on prior customer consent"
… I do have a flow diagram for this
ChristianA: Yes, would be good to see more about "how the issuer knows what happened"
[Flow illustrations follow]
Gerhard: Suppose in a 3DS flow that frictionless flow does not lead to satisfaction.
... so challenge flow initiated, and ACS says in AReq "Let's challenge with possession"
... So the PSP gets back a set of credential IDs. If the merchant does not use SPC, fallback flows possible.
… but if merchant does use SPC, the transaction dialog is opened.
… but due to the way that the keys have been generated, the browser knows it can, for example, not require the user presence check.
… an alternative is that if the user has consented previously, the merchant could make the same call (without knowledge of the user's stored consent) and they would get the same result back (with information available to issuer that it was silent)
… CReq with signature can be returned to the ACS
… the signature can include information about which authentication flow happened
… this is not as strong as WebAuthn, but it's not as bad as data collection as it is done today
… so we have a bit better on the one hand, and not as good as SCA, but has minimal friction.
ChristianA: I am hearing that it's the same rails as WebAuthn, with just possession check.
Gerhard: When SPC was originally proposed we imagined one solution where the methodURL provides a hint
… but we didn't want to stretch too far, so this proposal leverages SPC as it's been proposed
Gerhard: The proposal is basically about how the various perspectives (merchant, user, issuer) as melded for a UX
ChristianA: The issuer needs to know what the consumer has consented to.
Gerhard: I agree, and the signature in SPC will say how consent was given and what was consented to
Deepu: Thanks for the explanation. Assuming a user gives consent (e.g., 30 days). Is there a provision for the user to revoke it?
Gerhard: Yes. User will manage that information in the browser, like passwords.
Deepu: This mechanism does not rely on Web authentication
Gerhard: Correct.
<SameerT> Comment: Perhaps there is a potential for collaboration to make sure the key EMV 3DS principles (Issuer making the final decision) is included in a broad concept where implementers can choose SPC as a bundle or parts of it for challenge
<AdrianHB> My understanding is this would use the same APIs as SPC but using credential IDs that are for software-stored credentials (vs hardware-based credentials as used for WebAuthn)
Ian: I am hearing that you'd like to enable the issuer to decide (with input from merchant) the UX, and the issuer (RP) has different credential ids for different experiences. And that WebCrypto is a fall back encryption mechanism when WebAuthn not available AND
Gerhard: The question is that some behaviors may not depend on external authenticators, and so we might be able to use Web Crypto. But if Web Authentication with no presence check can be used, that's good too
[On 3DS impact]
Gerhard: (1) proposal aligns with SPC as initially hatched (2) proposed SPC solution does require merchant integration
... This proposal is not specific to 3DS.
... Let me speak a bit about a second proposal...using the browser as a silent possession factor
<AdrianHB> Danyao: On Android, FIDO authenticator coverage is closer to 2/3rds and growing
Gerhard: 3DS2 caters to frictionless authentication. Risk-based auth leverages data from three sources (browser, user, transaction)
… a unique ID will also help here.
… if we use the same possession factor concept and can use it silently in an iframe to sign
… the challenge could bind browser + user + transaction details without the need of data collection
[Gerhard slides on this second proposal]
Gerhard: The ACS gets possession keys from the browser and ask the browser to sign transaction data in the method URL
… the 3DS transaction ID is the same, and the ACS can say "I've already verified this credential; I'm satisfied with other data; I can choose to not do step-up"
... I think this proposal aligns full with standard 3DS methodURL. Does not require any extensions. No merchant integration/modification required.
… but iframe permissions would need to support this
… if a possession credential is not available , you could fall back to SPC
... For me, I think this gets close to satisfying the browser ID requirements we discussed previously (and touched on yesterday).
… but it might not be "SPC" if the essence of SPC is the transaction confirmation dialog (since there isn't one)
gkok: To clarify - when you mention frictionless flow. Are you still using the PR API?
Gerhard: There are three scenarios (1) with user presence check (2) without presence check (3) no dialog
… but data is signed in all cases
SameerT: In the silent challenge flow, is the browser notifying the ACS of a credential or is the issuer sending credentials to the PSP?
Gerhard: ACS sends list of credentials to the browser
SameerT: So 3DS method allows silent challenge, and silent challenge data goes through AReq?
Gerhard: Maybe, but that would require the merchant. So we think there might be a way to do this simply in the method URL, which means the merchant does not need to be aware of that data.
SameerT: let's collaborate on the "id requirements" to make sure that it meets our requirements
Gerhard: +1. I want to ensure meets requirements, meets privacy requirements, has good UX
<Zakim> Ian, you wanted to ask about big picture ordering of approaches
<AdrianHB> ian: there seems to be a growing space of solutions that are within scope of SPC and not. What order would you approach these solutions?
<AdrianHB> ... this helps us know how these might map to different payment flows
Gehrard: Here's my list in order:
1) Issuer issues possession credentials (enrollment)
2) Issuer / ACS silent challenge without merchant knowledge
3) If the merchant wants control, then you move on to SPC
… if the issuer has done step 1 and that supports lower friction, then the merchant and issuer can take advantage
<AdrianHB> +1 to single-click SPC as priority (likely same API but with different credential IDs)
mhofman: I want to focus on the prompt-less authentication. Might be useful outside of payments use cases, especially if the browser is not showing specific UI.
… perhaps this should be discussed in the Web Authentication WG
… somehow you can use browser credential to sign some data in an iframe context
… that's where we need to figure out with privacy folks if that's ok
… maybe because it's tied to browser alone might be ok
Gerhard: That's an astute observation. The important thing is what is the user consenting to?
… our use case allows us to scope the consent.
… but we are interested in chatting with Web App Sec
… we can also discuss with the WebAuthn WG.
… to reiterate: the privacy side is important to us
… but due to progress on the payment side (via SPC), and because the user knows this is an important activity (payment), this could help prevent abuse.
mhofman: Since the authentication is silent, user approval will have to happen at enrollment. Even if you tie it to a payment request object, somebody could build such an object to use this; so I don't see how you can lock it down to the payments use case.
Gerhard: I hear that point.
Danyao: Picking up one point about implementation in the methodURL..is the proposal that you want to be able to invoke SPC directly from the methodURL iframe?
Gerhard: Yes, at a high level
… and to be able to say "Only do SPC if you can do it silently"
Danyao: For the second version of the SPC origin trial we now allow the creation of SPC credentials from inside a cross-origin iframe. So that should allow some prototyping.
Gerhard: Suppose I got to merchant 1. I can create credential in bank domain, then use in merchant 2's domain?
<arno_> @danyao would that 3rd party use of SPC be with feature policy such as with WebAuthn
Danyao: Merchant 1 still needs to embed the bank domain in the iframe, but does not need to redirect to the bank domain or use a secure modal window
Gerhard: Any specific iframe settings required?
Danyao: Allow_payments
SPC and open banking
Slides from Chris Wood and Chris' Full write-up on SPC and open banking
Chris: I am relatively new to the group. Have worked on open banking standards in Europe. Today we'll talk about open banking and SPC
… at a high level, I think that open banking and SPC mesh nicely.
… [slide on benefits of SPC]
... I think that open banking would benefit greatly from a standardized, ubiquitous authentication mechanism.
… an inconsistent user experience may make open banking less compelling
… various approaches have been tried like QR codes, but I see SPC having great potential for bringing consistency to the UX
… review of acronyms: payment services user (PSU), payment initiation services provider (PSIP), bank with PSU is the ASPSP
… the PSU wants to make a payment and has a SPC credential.
… the merchant or their PISP initiates the payment (calls Payment Request / SPC)
… the RP here is the ASPSP
… so the bank plays an important role (RP) even though they are not part of the legal agreements.
... Good idea to allow enrolled WebAuthn credentials to be "upgraded" to SPC credentials
… this will promote efficiencies
[Chris reviews steps]
Chris: Enrollment happens (typically) out of band with ASPSP
… during transaction, with many open banking standards, the customer and PISP make an agreement
… they agree to what is being paid, which authentication mechanism is being used
… that's built into the standards.
[Chris shows some UX associated with UK open banking]
Chris: In UK open banking, there are prescriptions for the UX
… the information about what is consented to ("the consent object" in UK open banking, or "the payment initiation request" in Berlin Group approach) is sent by the PISP to the bank.
… the PISP invokes SPC (via PR API)
… there could be a payment handler in the background that orchestrates the result of authentication, or the assertion is returned immediately to the PISP
… the PISP sends the assertion to the ASPSP
… the ASPSP verifies the cryptogram and lets the PISP know
… the PISP executes the payment initiation request at the ASPSP.
[Sequence diagram walk-through]
Chris: In the flow diagram, the bank sends a consent identifier back to the PISP. My suggestion is that data is used in the SPC challenge.
... Interesting open question on whether merchant needs to hold public key as well as the RP (yesterday Benjamin suggested this is a good thing to enable Merchants to do some validation; I agree)
... I think SPC fits nicely with the consent flows
… but there might be some further discussion on discoverable client-side credentials
ian: in SPC there are two things that need providing: the list of the credential IDs and the random number
… where in the seq diagram is that done?
<Ian> Chris: In this proposal, the merchant knows the credential ID (and they bind it to the consent they send in).
<AdrianHB> I think the consent id is sufficient randomness to prevent a replay
<Ian> ...the ASPSP sends the random number back in the "provide consent identifier" line
[Chris: Example UK - payment initiation consent]
[Second flow diagram]
Chris: second flow diagram shows same flow with more specific example data in it
… includes SPC, OpenID, FAPI pieces as well
[Example: Berlin Group - Payment Initiation Request]
Chris: In Berlin Group, similar: payment initiation request goes to target bank.
… suggestion I have is to send the credential id in the X-SPC-Credential-ID header (but could be done in other ways)
… the process overall is very similar to the UK flow
[Conclusions]
Chris: SPC can fit in open banking use cases effectively. Limited need to change initial vision of SPC to make this work.
... salient open banking standards would need little change to support this
… ASPSPs need to see the value of this.
[Open questions]
Chris: What should the role of payment handler be?
<AdrianHB> +1 to using the term "assertion" and following WebAuthn conventions
<btidor> Makes sense, the term "cryptogram" has already been a little confusing with 3D Secure
Ian: Is sharing of key done out of band?
<AdrianHB> ian: interested tin the desire to share public key with PISP
Chris: Merchant invokes PR API. Giving them access to the public key is very sensible
… they can make sure that responses are sent on the back end
… can help reduce risk of failure
<Zakim> danyao, you wanted to ask about sharing public key with PISP
Danyao: Thanks for the great presentation. Also regarding the last point (access to public key).
… in the FIDO world, usually only the RP has access to the public key
... do you see security concerns that ASPSPs might have?
Chris: I don't think so, but I'm not a security expert
… to me it feels like it's an ok thing to do. Whether it's part of the spec is another question.
SameerT: To me it sounds liked the PISPs would have access to the public key. That sounds like a delegated auth scenario.
… in 3DS use cases, even with merchants having keys, issuers may still choose to step up
SameerT: Merchant validating the user and sending that data to issuers is part of 3DS
… whether issuers trust the data is distinct question
John_Bradley: the UK flow that's being talked about is based on FAPI.
… adopted in other places as well (AU, CA, Brazil, NZ, others)
… the biggest issue I see in this is the merchant being able to specify an RPID for a credential issued by the bank
… I think origin scoping of credentials could be a big part of this work.
… so within WebAuthn we may need to enable banks to make credentials for merchants, or alternatively changing the flow where the WebAuthn can happen in an iframe in the bank's origin
… I would be interested in working on this, but there will be some WebAuthn issues to sort out
… I don't see the public key being shared with the merchant not necessarily a security risk.
… using the request id as the challenge would be fine IMO
Chris: Do you think that FAPI would see this as something they could create a profile for?
… would there be merit in that? "This is the expected behavior"
John_Bradley: I can't speak for the whole FAPI WG. There is interested in that group participating in this group and increasing the interaction.
… to get it to work smoothly probably requires some optimizations of some FAPI flows
… would have to figure out how some of the origin constraints can be dealt with on the WebAuthn side.
… but getting it to work would be a great thing
<Deepu> Thanks everyone
<benoit> thanks!
<Chris_Wood> ciao!