Meeting minutes
See also 12 September minutes.
Stripe SPC Update
evan_jacobs: Regulation is driving friction in payments
… particularly in EMV® 3-D Secure.
… we have been looking at biometric authentication
… we look to see if we have seen a device before
… if new, we enrol via 3DS
<Zakim> smcgruer_[EST], you wanted to offer to scribe when I'm not talking
<aidanfoley> Stephen is the expert here :-)
evan_jacobs: shows flow
… shows SPC "opt in"
Gerhard_: I see you are using "biometrics" not "passkey"
… does that cause issues when biometrics are not available?
aidanfoley: We will be revisiting all of the UX but we went with biometrics as the cue that would provoke users the most.
evan_jacobs: shows returning user case
… throughout the the user flow, opt out is available
… turning to results. We are seeing a 7% improvement in authentication success
… when returning users choose biometrics, success rates is >95%
… but only 50% of returning choose biometrics
… and latency is hugely improved from 30s to 12s
gkok: do you know whether the returning users are on the same device?
evan_jacobs: we are looking at improving that.
gkok: is the authentication improvement matched in authorisation rate?
evan_jacobs: no
aidanfoley: We have a pilot running with an issuer currently, where the authorisation rate is better
SameerT: This looks like delegated authentication. Do you have any analysis of comparisons between this authentication mode v authentication offered by the issuer? What happens if the enrolment fails? Does the merchant lose the transaction?
aidanfoley: The enrolment happens _after_ a successful transaction
nick_s: Is enrolment per psp?
… i.e. it's only for Stripe
aidanfoley: Yes
nick_s: I'm worried about this as a barrier for new PSPs
… it would be nice to see this shared across PSPs
fahad: Could you get better times via the issuer?
aidanfoley: We continue to look at this.
Gerhard_: Who has liability? are you sending the binding?
aidanfoley: Stripe are currently taking the liability with the delegated authentication flag set.
… and we continue to learn from it
evan_jacobs: We are getting less fraud with this than "vanilla" 3DS but we are cautious about that
aidanfoley: We are only 90 days in
evan_jacobs: We are also seeing higher success with WebAuthn rather than SPC, which we don't understand.
tomasz: Did you try to run this as SPC directly?
aidanfoley: We do have this. The drop off is happening on the "OS prompt".
tomasz: Are you running this across platforms?
aidanfoley: Yes, but when we launched on android then the drop off was big.
tomasz: Do you know why?
aidanfoley: No.
evan_jacobs: To conclude - we continue to experiment, with much more UX research, and how to get more issuers involved.
Zakim: nicktr: thanks aidanfoley, evan_jacobs
nicktr: I think new PSPs have plenty of challenges!
nick_s: Yes, but we should not put in improvements that clearly favour larger PSPs.
Visa SPC Update
doug_F: presents slides
… Visa has been focussing on the use case of merchant-initiated SPC where the issuer is the Relying Party.
… we have been conducting two pilots
… both have 3DS architectures
… phase 1 - friends and family
… phase 2 - limited BIN range
… the first pilot is using 3DS 2.3.1.1 (the very latest specification)
<shows flow with AReq and ARes>
… the SPC assertion is passed in via a second AReq
doug_F: The second pilot is using 2.2 with an extension with Modirum
… bringing both reassurance about backward compatibility and a check in the latest spec. We wanted to provide feedback on UI and to investigate SPC v other authentication
… we also wanted to to look at fallback to 3DS if the user hits cancel or other failure states
… we found that users need more context and explanation of the value proposition
… many participants struggled to understand what they were being asked to do and why
… and in particular didn't understand that the credentials were specific to the browser. We found that the passkey dialogue box caused confusion (we saw one user trying to write things down)
… we found that users tried to "touch" the fingerprint image on the SPC dialogue
… there was a lot of difference between OS
… with better results in MacOS than in Windows
… windows dialogues seemed to cause more problems. Cancel did not test well
… but sentiment towards biometrics was generally positive
… 3DS tested well - but European users in particular are very familiar
… inconsistency across OS and devices and browsers is a real challenge
… Visa recommends iterative content and interaction design work
doug_F: compares SPC v OTP
… SPC is faster!
doug_F: shows demo and points out additional browser screen to prevent timing attack but which adds friction
<Zakim> smcgruer_[EST], you wanted to ask about user.name/user.displayName as what looks like an id
smcgruer_[EST]: if might be easier to add card name in the display name fields
doug_F: behaviour is different between browsers
smcgruer_[EST]: on the no matching credentials dialogue, is this a different device issue?
doug_F: yes
Gerhard_: Chrome and Safari use different data fields in webauthn. 3DS tests better but users are more familiar - do you think it's this familiarity is driving the better result?
doug_F: I think it's both familiarity and maturity - we have done so much testing of 3DS
tomasz: points out Windows Hello uses the Relying Party ID
smcgruer_[EST]: webauthn community pushed back on using relying party name
… but might now be different
… it's very confusing for the user
… most users don't know who the PSP is (even Stripe)
aidanfoley: users just know where they are shopping - the merchant name
rbyers: did you test webauthn v SPC like Stripe?
doug_F: we looked at webauthn as a fallback
gkok: suggests improvement to flow (didn't catch detail)
dougF: we didn't try that
<gkok> suggests improvement to flow by replacing the "cancel" button by something like "verify through other means"
<Zakim> SameerT, you wanted to discuss Imran/Nakjo - how will the fallback work on merchant initiated flow when the intermittent user activation screen is removed
tomasz: have you compared SPC v mobile authentication for 3DS
dougF: yes, and we could demo that
imran: transient user activation is required - we have implemented a dual authentication option but this is removed in Chrome v118.
imran: Flow when a new device is present is two additional clicks
imran: User ID is tied to "name" field, tied to user not device
… windows shows on registration and authentication
… but Android and MacOS shows only on registration
… possibly alternatives: PAN, masked PAN, or user chosen name
… SPC credential is unique ID - user ID + RP ID _ device platform authenticator
… case 1: browsers not sharing SPC credentials (except Android)
… case 2: Windows11 passkey synching
… but SPC credentials are not shared
… registration on new device fails - platform authenticator reports credentials already exists
imran: future considerations - biometrics clearly very important in SPC
… would be good to see issuer and scheme logos on SPC UI
… would like to understand effect on public key extensions and also role of roaming authenticators
Gerhard_: points out difference between "trust this device" or "trust this browser"
smcgruer_[EST]: webauthn is "trust this platform"
Joint Meeting With Federated ID CG
The Web Payments WG sat in on the Federated ID CG meeting to see demos of FedCM. See the Federated ID CG minutes.
Mastercard Update on SPC with Passkeys
Jonathan Grossar Slides on passkeys
Objectives:
1) reduce fraud and false declines
2) reduce friction
3) improve conversion
jonathan: identifies use cases for passkey and cards:
(1) issuer is the relying party
(2) merchant/PSP/wallet is the relying party
… (authentication ultimately passed to issuer via scheme specific mechanism
(3) lastly, where mastercard is the relying party
… which has advantages in terms of consumer familiarity with the mastercard brand
jonathan: what does SPC bring over webauthn?
1) only prompt when there is an authentication credential on the device
2) x-origin authentication
3) dynamic linking
4) consistency and secure display
jonathan: secure display includes "sign what you see"
smcgruer_[EST]: with SPC there are additional fields in the challenge result (you could do it with webauthn but it's explicit in SPC)
nick_s: we need to stop SPC allowing discovery of whether biometry is enabled
smcgruer_[EST]: agreed - we need to improve the UX
jonathan: if there is no credential, is there no dialogue?
smcgruer_[EST]: no, there is always a dialogue, but the fallback UI is not good
… FedCM is trying to do this with a complicated timing screen which does not have consensus across the browser vendors
gkok: could issuers learn what kind of verification has occurred
smcgruer_[EST]: not at the moment - it would definitely be a topic for discussion with webauthn wg tomorrow
rakesh: what kind of support are we seeing from issuers?
SameerT_: login is an easy use case for issuers as it's a first party context. But enrolment is more difficult and payment another step beyond that
Gerhard: iframes lack permissions, fallback in web versus apps
… and the lack of consistency causes friction
jonathan: shows example flow with passkey
… (registration during checkout)
… (returning user)
… showing difference between vanilla webauthn and SPC
jonathan: introduction of passkeys brings two new challenges
… 1) passkeys don't have an attestation to allow validation
… 2) passkeys are synchronised across devices. some implementations don't allow the RP to work out which device the user is on
<Zakim> nicktr, you wanted to ask about attestation
nicktr: did we lose attestation when passkey was introduced?
jonathan: no, it's only option in webauthn
nick_s: can you say more about why it's difficult for SCA
jonathan: the lack of information about how the user possession is validated
gkok: understanding where the liability sits is critical
<Zakim> nicktr, you wanted to observe that the schemes have made the liability situations clear in the past (for example with the introduction of 3DS)
nicktr: the ecosystem works best when everyone understands where the risk is sitting so ideally we would "paint" the transaction with all the information that would be necessary
jonathan: (shows degraded UX)
smcgruer_[EST]: it sounds like in a 1P context, webauthn works
… in a 3P context, would an iframe suffice?
… in other words, should we just make webauthn work better in iframes?
jonathan: we would prefer not to have to open iframes
jonathan: (shows potential use case of using SPC to access their account e.g. click to pay)
… which would require changes to prompt and also removal of "total" field
nick_s: Don't cookies have the same problem? Cookies can be backed up
nick_s: It sounds like what we really want is a way of uniquely identifying that the device that was enrolled is the one presenting the credential
smcgruer_[EST]: is cookie theft in your threat model, payment folks?
rakesh: it certainly informs our thinking
nick_s: sounds like there is other data that we could use
Gerhard: may I remind you that there is a world outside Europe and we need to find that balance
Netcetera Demos
nakjo: Our demo ran on EMV® 3-D Secure v2.3.1.1, with a participating issuer and and participating merchant
(shows demo store in a preview environment)
(shows non-happy path, the requestor doesn't support SPC)
SameerT: In the merchant-initiated flow, there's no iframe - there's no issuer messaging
… but in the second flow, the issuer has rendered an iframe. Just wanted to highlight that
fahad: Who makes the "show credential" call?
nakjo: In the merchant-initiated flow, it's the merchant. In the non-SPC flow, it's the issuer.
nakjo: (shows the fail flow - hits cancel)
(defaults to out of band authentication)
nakjo: shows mismatch between 3DS and SPC spec (3DS spec has Relying party ID, credential pairs, SPC has one RP ID and multiple credentials)
… (shows unregister UI)
… I don't know whether there is a maximum number of credentials
smcgruer_[EST]: I think the 3DS/SPC mismatch fix is relatively fixable
… with regard to the opt out, the intent of the Chrome implementation, we suggest that the opt out link takes the user to somewhere where they can manage the credentials that the caller has issued
dougF: in the third-party model, the issuer needs to be able to invoke this
smcgruer_[EST]: I think we assumed the issuer and merchant would have to talk.
… the link is not a "weblink" - it causes the authentication to fail with an error conditions
… "opt out error"
smcgruer_[EST]: is this opt out still important?
nakjo: Yes, deregistration is still important
Gerhard: Would it be possible for a directory server to add its RPID ?
nakjo: Yes, technically you could do this, but I don't know what would happen on the ACS?
gerhard: What happens with multiple credentials?
smcgruer_[EST]: We would only show credentials that could be used?
Gkok: It's not clear how we would prioritise which one to use if there were more than one
… and I'd suggest that the opt out resulted in a signed request to remove the credential
nakjo: (demos flow when SPC is not supported by requestor or in iframe)
nakjo: Here we fall back to webauthn in a new window with access in a 1P context
nakjo: The sandbox attribute means that this doesn't work
<Zakim> rouslan, you wanted to talk about popups with WebAuthn and SPC
nakjo: We're talking about a backup of a backup here
gkok: Could we just default SPC on in iframes?
smcgruer_[EST]: No.
dougF: But SPC is now in the requirements of 3DS including the browser settings
nakjo: Many corporate managed computers and phones restrict platform authenticators including windows hello
… and platform authenticator is not available in private/incognito mode
Netcetera Demo of SPC on Android with Custom Tabs
Nakjo Shiskov Slides of SPC on Android via Custom Tabs
(shows passkey registration and authentication flows)
nakjo: purpose of this investigation was to see if we could do SPC from a native app - or at least as close to native as possible
… we had a native application that contained the checkout experience and moved the SPC challenge "next to" the native app via a web landing page
… we had several failed attempts - webview failed so we tried custom tabs
(shows demo app)
nakjo: shows it's possible to deliver SPC experience in a custom tabs
nick_s: what's the benefit of relying on SPC v the bank's app
Gerhard: not all banks have a native app
… and consumers get lost moving between apps
… 3DS 2.3.1 addresses some of that
Can you explain the communication between the custom tab and the native app?
nakjo: we use a specific redirect URL and a link listener in the native app (which then checks the status)
SameerT: Is this over 3DS?
nakjo: No, though it could be.
nakjo: We can use custom tabs, but session handling, landing authentication page is tricky
… error handling is also harder
… and redirection to native app doesn't always work
… also you may have to override the default browser
… ideas for improvement include message exchange or event listener
Gkok___: I would love to see this working better if SPC in general picks up in popularity
… is there a world where native apps could use SPC more easily?
smcgruer_[EST]: Yes. We would love to make the workarounds unnecessary but we need to get the priority to do this work
Gerhard: it would be great to get "do SPC" added to the 3DS spec in the merchant app API
SameerT: I could possibly see this working for bigger merchant apps, where they may already be doing biometric authentication
Gerhard: doing this for each merchant app is a deployment nightmare
Apple perspectives
nick_s: We are happy to be back. We support payment request in MacOS, iOS, iPad and VisionPro (sp?) with authentication via iris
… on SPC - we are potentially interested as a merchant and also in delegated authentication
… it would be interesting to see SPC on other payment methods
nick_s: (for clarity, I work on ApplePay not webkit)
nick_s: we would love to see shipping and billing address back in payment request
… we know there are challenges with I18n and privacy
nick_s: we are now supporting "advance fraud protection" for Visa cards which is a private connection between the device and ?scheme? (NickTR missed this endpoint)
… we are interested in the receipt use case
Gerhard: Could that involve additional information being provided to the issuer?
nick_s: I think we would be interested in investigating that as a standardised way of communicating it
gkok: What are the roadblocks for SPC?
… I think there are clearly user experience and privacy issues to resolve
<rbyers> WebKit/
nick_s: if there is interest in using SPC in native apps, I think it would be interesting to explore how we could make this more seamless
joyce: could I have better control over my physical payments like I have on web payments? For example, the payment confirmation
nick_s: I would be delighted to talk to you about that - one limitation is the information that's available via the NFC interface
… some of these payment standards are quite old
… we have also recently introduced taking payments contactlessly via iphones and have made some accessibility improvements there
<rbyers> FWIW Rick and Stephen had to jump for a meeting 4:00-4:30, but we're obviously very interested in this topic. Sorry for the conflict.
????: are we trying to define best practices for SPC implementations?
Gerhard: I think it would be great if we could come up with a framework for comparing SPC implementations
evan_jacobs: we have a lot of challenge talking to issuers because we often measure different metrics or see different results
????: we see lots of different approaches
Gkok: I can see both issuer and scheme implementations working depending on scale of the issuer. Let me give a merchant perspective
… we really need relying parties outside our PSPs
… and in particular more issuers
… there is interest from issuers but they're not getting consistent messaging and support and information
… mobile browser is giving us the biggest headache for conversion
… and diagnosis is really hard
… again, as a merchant, we need more "insurance". It's all about the value of the user - particular on the first transaction. I would give up liability shift on first transaction.
evan_jacobs: Is there interest in implementing SPC in non-SCA markets?
gkok: Yes, if the performance uptick is worthwhile. It all comes down to the experience
evan_jacobs: I do wonder if there is an opportunity to do more with delegate authentication in the US market
nick_s: The optimist thinks that would be great. the pessimist (realist) looks at how hard Chip and PIN was in the US
… I think you either need either regulation or a significant economic incentive
gkok: I agree. perhaps it also opens up new business models or payment methods - for example in open banking
evan_jacobs: some US issuers see authenticated transactions as inherently riskier than non-authenticated ones
Breakouts and future topics
Group 1: Expanded payment use cases
Two categories: Non Payment Use cases and complex use case
(Sami giving feedback)
Second one was a broad discussion
What should SPC have extra?
Use-cases:
* Accessing a wallet
ID&V / enroll passkey (SPC) after legacy ID&V
Can SPC fields be expanded for this?
Complex use-cases was more diverse.
Payments + ID Data (e.g. age / location)
* Make Autofill and SPC make smoother together (Can we trust this/ binding this on the browser)
* Recurring transactions (once a month/ initial + recurring, etc)
Conclusions:
* Bigger picture is important. SPC is being used is broader than the single part.
Merchant + Network + Issuer.
Payment & ID and Autofill was where a lot of time around this?
Non Payment Auth has a ticket on it.
Group 2: Increasing trust and reducing friction
* Take lessons from FedCM
They offer more context to the customer so dialog can show list or narrow it down.
Also had a silent login option.
Could we enrich the API so the relying party could share more information
Next one was how we could add more browser data to the flow - influence on how the passkey/SPC asks for fingerprint.
Potentially a risk score or additional signals that the browser could provide. Also potentially prompts to share consent
Also potentially share biometric usage context (Still the same user)
A notification that credentials are being used.
Also spoke about auto-enrollment? How could we do this, and what obstacles would be there. Create a credential without prompting? What would that take?
If you want to authenticate then use this.
Context of the transaction such as pay/subscribe
(nakjo for group 2)
Group 3: INcrease trust and reduce friction:
First ensure consistent experience for user accross all OS and Devices
A couple of hops in that journey.
Marketing and branding the payment brands and logos. Improve that.
Experience enables consistency.
Eliminating unneccessary steps due to failed authentication.
Familiarity to uses in pop-ups. User names or something more memorable.
Enrollment scope and cross-device scoping. Should not be repeating this across various devices.
Group 4 (Stephen)
Expanding use-cases to talk about SPC and non-payment flows and more complex payments.
Also spoke about alternate payment mechanisms.
Focused more on SPC UI.
Technically it's too restricture (Recurring, variable)
But you cannot do raw text in browsers? So how do you do that? FedCM has 4 enumerations.
Payments may be more complex? Did not come up with a clear answer.
How important is this to solve? Some are seeing issuers are not wanting to enable recurring payments - want to re-auth every time.
Alternative payment: UPI, Open Banking, PayNow,
(and PIX) Not all the same. Merchant is push payment. Open banking is submitting the context for them to charge.
Obvious flows here are browser to app and back. How would we enable that.
Did not really have a real solution here.
What about Intents? PIX folks did raise concern since unsure about who responds to intends. Also based on time available /speed.
Payment handler had ability to check signatures, so this can be solved.
Alex had a complex idea.
ACTION: is to explore something - explore with RBI and Brazilian regulator. Also if SPC fits in there. Could you do everything in the browser.
Comment: Would be great to jump back from app to browser page that redirected back to that.
You should be able to solve this.
(comments from gerhard)
Second point: Browser is trusted globally in the rest of the world. We can leverage that. Let the relying party indicate if he wants to trust the browser or not.