Meeting minutes
See also Minutes from 11 November.
Introduction and Welcome
Nick Telford-Reed intro slides
NickTR: Please ask questions and enjoy hallway conversations
[We do introductions around the table]
SPC pilots and experimentation
Visa on SPC
[Sami Tikkala slides (PENDING)]
Sami: We did an SPC study looking at the BBK and UX additions to SPC on Android.
Sami: This was a controlled study (not a large scale study)
Sami: our first focus was to look at BBKs.
… and see how the new UX works.
… it was too much of a hassle to do an A/B study
… just jumped to people's reactions with the new UX
… we did not look at the "authenticate another way" feature
… our study included 6 users from 4 countries
… the participants had 2 devices
Gerhard: Who was the RP?
Sami: In our experiment the RP was an issuing back, and communication happened over 3DS 2.3.1 rails
Sami: in our flow we ID&V the user, then ask if they want to enroll in SPC.
… then they used a second device (where passkey is synched but the BBK is per-device)
Gerhard: how did you detect that passkey synched on second device?
Sami: Try and fail
[Regarding synching to second device]
Sami: We struggled a bit with the participants on the second device.
… e.g., people had different accounts, a source of friction
Sami: On second device without BBK, we use an OTP to verify the user to trust the BBK.
… on the new device
Sami: the flow worked very well if you have all the bits and pieces in place
<junhui> does SPC work without google signin?
[Note: SPC does not require Google sign-in, but passkeys are synched through Google sign-in]
Gustavo: Did you provide instruction to users in the study on what SPC means?
Sami: no, we did not talk to them about what SPC means
Sami: We got very positive feedback on the user journey: the speed, understanding of the flow
… on a scale of 1-5 (5 being positive), most of the feedback was on the very positive end of the scale.
Gerhard: Was there any passkey messaging?
Sami: No, only ever payment context
Dan: Did you test unhappy path?
Sami: We encountered issues that did not enable users to proceed in some cases.
Gustavo: When you are rebinding the new device, does that need to follow the same two factors?
Sami: Not all participants understood the purpose of a passkey at enrollment
… lots of messaging and education is likely necessary
Sami: Most participants missed branding on the SPC passkey authentication screen
… light mode and dark mode ... we need to communicate to issuers
Sami: people trusted the UI
Sami: When you do the second device after synching the passkeys, almost all participants guessed the step-up was for security
… there was a little bit of uncertainty among the users
… but they guessed it was for security
… so despite confusion, response was overall positive
Gustavo: Do you think that there's a bias because users are recruited to doing a test? Is there an opportunity to refine the messaging like "First time you are paying with this device"
Sami: some surprising findings: disqualified participants had a few challenges that kept them from being able to create a passkey or key the passkey from synching to their second device
… e.g., didn't have same google account on second device
Sami: Another question is "how quickly do passkeys sync"? Some people did test before synching had happened.
… also, if you have privacy mode on, synching doesn't happen
Gerhard: The mechanism that we used for base authentication (e.g., OTP) was performed in both cases. The question that comes to mind for me: would the client had seen any difference if the trial had been done without synching? For example, if they simply got a new passkey
TimCappali: The passkey is not necessary here. The BBK sufficient on its own.
<smcgruer_[EST]> +1
TimC: I'm surprised to see that the passkey is still being used.
Gerhard: There are multiple contexts - need MFA (Europe) and other parts of the world (where you want to get rid of OTP)
Gerhard: You could just issue a new passkey on the second device, it would be the same UX
smcgruer_[EST]: We were going to propose exactly getting rid of passkeys
smcgruer_[EST]: Maybe we architect this where you can swap between passkeys or bbk only or nothing at all...
… if we get rid of passkeys, life gets simpler.
Sami: Quite a few participants had dark mode on.
Sami: Strengths to build on: passkeys preferred for security, speed, reliability
… recognizable branding reinforced trust
SamI: Recommendations
- strengthen standards for branding.
- develop issuer guidelines for enrollment
- provide issuer guidelines for cross-device and fallback messaging
- coordinate on bbk availability expectations
Sidd: Wondering whether passkey still necessary now that there are BBKs.
smcgruer_[EST]: Please note we have a pull request on UX guidelines for SPC....PLEASE REVIEW
w3c/
timcappalli: Was there any feedback from users on "now every passkey I have is for payments"?
Sami: No.
timcappalli: We are hearing some feedback in another context.
nick_S: In this test, these were all Android users. If you had a google pay button would they have used that instead?
… a lot of the issues that are coming up here ... it feels like users already have a digital wallet (since they are Android users)
… and they've already enrolled their credential.
… what do you do for users who already have that payment credential in their wallet.
… Google pay could bypass this flow entirely
smcgruer_[EST]: I think that conflates a few things. These users have Google accounts, but that's not the same as having a payment method enrolled in Google Pay.
… these users may or may not be using Google Pay
… in the flow you mentioned, NickS, I think you are referring to Secure Payment Authentication (SPA from Google)
JonathanG: You may have a card on file with a merchant and want to use the card on file
nick_S: Should there be a way to tell with SPC whether user has a credential enrolled in another wallet?
JonathanG: Do you mean "use the card in the wallet"?
nick_S: Use it with the existing binding
… if I've bound the credential, is it better for the user or the merchant to use what's bound? What's the benefit of going through another enrollment?
benoit: Google pay also limited by your bank signing up
… whereas SPC does not require that.
gkok: The merchant also has to accept Google pay, but not all merchants do
Gkok: ...as a merchant, I value having the card number and not just the token.
[We get into the PAR discussion]
nick_S: This enrollment is heavy; the findings are telling us that.
… if you have an opportunity to bypass an enrollment by reusing a credential, shouldn't we allow that option (via the standard)
DanP: PayPal has been addressing this with custom credentials API...if they already have something they can run the attestion against, then run it.
albert: As an issuer, I would be interested in reusing existing enrolled credential.
Gerhard: It's partly about choice, partly about the merchant.
… my assumption is that merchant would have presented a variety of options (including Google Pay or Apple Pay) and the user has chosen this path
… to redirect the user to a wallet they did not select is not good for the user.
<SameerT> +1 to Gerhard's comment
<raginpirate> To share my thoughts here since the queue was closed for our prior topic on wallets: I think there's something very interesting here. I believe it's very valuable for the merchant to consume the raw payment credentials when supplied, and give the buyer that choice about how they are sharing their payment credential.
<raginpirate> But it could be amazing to identify if the device does have a wallet already leveraging that credential, and to share with the issuer both the raw details (what the buyer has chosen to charge with) and just authentication context from the wallet (biometric approval of a pre-tokenized credential with that issuer), without uplifting to passkey
<raginpirate> generation if 3DS is required. So, focusing on solving the part of the problem about authentication, without coupling the payment credential being charged directly with it.
<raginpirate> I say this with very limited knowledge in this domain though, I have more to learn.
Mastercard on SPC
[Jonathan Grossar slides (PENDING)]
Jonathan: Stepping back, we are seeking secure and seamless authentication. Mastercard introduced payment passkeys in late 2024 to deliver seamless MFA
… we can link cards to a passkey after doing some ID&V
… we want to link card to device, but only after step-up
Jonathan: We see passkeys as useful for multiple use cases (e.g., card on file, guest checkout, agentic)
… needs to work on Web, native
… if you use click-to-pay, that's another use case (closer to login)
JonathanG: Mastercard enabled passkeys for transaction authentication at over 1000 merchants in 2025
… (we see a demo of a checkout experience on Carrefour)
… when a passkey is already enrolled conversion is high
… pain point is enrollment
… when we do A/B testing, we see improvements based on UI changes to communicate passkey info
… other challenges are that in the payment ecosystem, authentication often happening in a 3p context (Iframe)
… this creates challenges like pop-up blockers, native apps, webviews, etc....there are a lot of different merchant integration models
… we also realize that all devices are not eligible (e.g., user has not set up a device unlock)
gkok: Are you saying it's not worth onboarding during merchant flow?
JonathanG: User might say "not now" but it's not leading to checkout abandonment.
… putting more context in place is important (e.g., bank branding)
timcappalli: Are you using feature detection APIs?
JonathanG: Just using the API call
JonathanG: To understand whether the passkey is on this device, we have to gather (without BBK) some device info to know if this is the same device where we created the passkey
JonathanG: Now that we are looking into implementing SPC, we are looking into all the user journeys
… a big improvement is cross-origin authentication.
… that reduces the risk of technical errors and latency
… it's also possibile to use bank passkeys...they don't need to be actively involved in the authentication process on the front end
… it's a smoother process, and a strong argument for using SPC
… second big improvement is addition of BBK for device binding
… reduces the risk of additional identity verifications
Jonathan: You can see from the demo that there is no need to use the MC popup (since modal is managed by browser)
Jonathan: Open questions:
- What happens when bbk not found?
… it might be that the merchant already knows you are not on the right device.
Jonathan: The next issue to look up is how to avoid double step-up (SPC authentication followed by OTP the first time the RP sees a BBK)
JonathanG: The double authentication is giving us a lot of headaches
… the second issue is you have the same passkey challenges as before (signing in with passkeys, different passkey managers)
Jonathan: We still want one enrollment and usable across N merchants
… if biometrics already enrolled, good to reuse it (even if not passkey)
JonathanG: There might be multiple RPs in a flow (e.g., SPC credentials from network, issuer, or the merchant's PSP)
<smcgruer_[EST]> [We can also solve multiple RP easily if we divorce from passkeys, I believe]
Jonathan: You need to allow for different integration models.
… we will want to compare feedback between passkeys for payments and SPC
Jonathan: We will find out when we launch this experience.
DP: When you say "conversion not so great" what does that mean?
Jonathan: We will also be interested in additional use cases (e.g., recurring payments, Agentic)
Gerhard: In the case where BBK not found...I am assuming you mean "after calling SPC"
Tomasz: Yes
Gerhard: Ongoing challenge of knowing whether credential available on this device
Tomasz: You need access to cookies to recognize user, but it's in another context.
Tomasz: Remember, there are two "no BBK" use cases: passkey synched but no BBK yet, and second case is BBK won't be available since old device
sidd: There can be multiple layers of authentication (e.g., user authenticating to PayPal who has their own FIDO implementation)?
<smcgruer_[EST]> [So, not to keep going to a theme, but... if we don't use passkeys, we are also able to explore more this identification of returning users. Still within our privacy norms though! Just less requirement to align with WebAuthn, is all]
<Tomasz9> [+1 for Stephen's comment]
Sidd: There might be one passkey for login and another for payments.
NickTR: That's fundamentally what a wallet does
Sidd: There is a delegation issue
Stripe on SPC
(Cip Blujdea leads discussion; no slides)
Cip: I'm the product manager for payment authentication at Stripe. I want to give updates on our implementation of SPC, in the UK market since 2022
… Stripe is a PSP and there's a tradeoff that we think about: maximizing payments while minimizing fraud
… authentication is an important lever of how we do that
… SPC is of renewed interest to us, since it can improve conversion and reduce fraud
… we are thinking about it outside of a 3DS context.
… we also want to avoid OTPs (which are not phishing resistant)
… I've been looking more into SPC lately and we're exploring more.
… we did a pilot in 2022 with Wise.
… the user journey involved a 3DS ID&V and an option to register for SPC next time.
… we saw a 7% uplift (in conversion) through SPC compared to OTP
… and 4x faster checkout flow compared to traditional 3DS flow
… since then, we've increased the scale with Wise....conversion has still been higher than traditional flow but only 1% at scale compared to previously
… fraud has been slightly lower than similar transactions
… we expected fraud to be even lower but we think this is due to three factors
Cip: We were wondering why the results were not as good as the previous trials.
… one reason is that Wise already has very good stats
… we think that for other issuers there will be greater improvements.
… one reason fraud has not decreased more is due to friendly fraud. Another issue may be a fraudulent initial binding.
Cip: Some of the challenges and learnings:
… first, when it comes to scaling, the biggest blocker has been that the issuer has the responsibility to authenticate in a regulated market.
… that's made it more difficult to set this up with more issuers, because of onerous regulatory and compliance due diligence
… this is why today we are not doing this with more issuers.
… another challenge with scaling is that many merchants control their full UX and so it makes it more difficult for Stripe. Smaller merchants allow Stripe to control the experience.
… we can control both the enrollment and authentication.
… another challenge we've seen is with the branding: what is the cardholder going to see ? Stripe is not a cardholder facing brand.
… we've had this question come up from cardholders (rarely) but also some merchants.
… the cardholder may be confused about who the RP is
… it's not clear what the cardholder is signing up for when creating the passkey
… we've also had some merchants opt out of the flow because it does not match the UX they are trying to give their users.
… one technical limitation we've seen: we don't know whether the device has been previously provisioned with a passkey
… having said that, we are looking at further rollout because we have had good results.
… in the UK, another issuer reached out to us for a similar experience, where 3DS flows don't work well and where there's not a bank app experience.
… for example, a business bank account (user is doing corporate payment but doesn't have an app)
… in this case, the issuer sees an opportunity to let user use mobile phone with SPC.
Cip: We think it's worth it in light of performance uplift
… the other way we are thinking of expanding this is in markets where 3DS does not perform that well (e.g., US market)
… where 3DS adoption isn't as high as in Europe
… we'd like to run a pilot on this.
Gustavo: I'm curious about the 7% v 1% conversion. Did you dig into that?
Cip: Since 2022, Wise has improved their authentication, but I don't yet have the full analysis
nicktr: I'm a UK card holder...the Wise step-up experience is really good
NickTR: UK is a mature 3DS market; there is little drop-out generally
Cip: So there was not much room to improve with Wise
Tomasz: Some issuers in the UK have more room for improvement
gkok: If you dive deeper, would you see a difference among device types?
… can you break down performance by device?
Cip: This is running on desktop as well
gkok: You should check it out...you might see better performance relatively on mobile.
Sameer: Who is the RP in your scenario?
Cip: Stripe is the RP in this experiment.
NickTR: Delegated auth in this case
Cip: We are still using a 3DS flow...we are telling the issuer the user has been authenticated, but there is no liability shift
Sameer: EMVco has defined a data set.
Cip: In this case we have a separate flow and relationship with Wise
DanP: In unregulated markets, what are you thinking?
Cip: There would be no liability shift (since not a 3DS flow) and no mechanism to get liability shift
… this would just be about Stripe having more confidence, and we know we would accept liability
vasilii: Can you say more about SPC and business bank accounts?
Cip: It's less likely that user has bank app on phone even though they have a corporate card.
… in the UK 3DS auth is majority biometric through bank app
… when you are doing business banking flow, you might have to rely on SMS OTP and that's not as secure
… that's the opportunity we see
Vasilii: How will binding happen?
Cip: 3DS OTP first time; the bank can have more of an experience around it, and they can tell users to do more secure SPC
Albert: the merchants that ask to opt-out....was enrollment process holding up the transaction?
Cip: We do enrollment after successful transaction to avoid delaying transaction.
… it wasn't so much a concern from merchants about performance; more that merchants wanted full control. But it was a rare situation where they opted-out
Albert: You said fraud rate was about the same. Did the use of passkeys give Wise more confidence to doing things downstream (e.g., handling disputes)
Cip: I don't know
gkok: Provisioning fraud more concerning
Cathy: I'd like to let people know that Meta also looking at adopting SPC.
SPC implementation updates
Irene Chang: Developments in 2025
(1) Passkey synching led us to add BBKs
(2) Dated user experience led to improvements to UX
(3) Unclear unhappy path led to improvements to fallback UX
Irene: BBKs available on Android today, and we are actively porting to Desktop (Windows, MacOS)
Irene: we want a consistent UX across different platforms (to build user trust)
[Demo of BBKs on desktop]
(We thank Darwin Yang for his good work!)
Irene: You just heard some Visa and Mastercard reports; here's more on case studies
… key takeaways: there's an opportunity to romp on why a passkey is being created with an issuer
… another issue is how best to handle devices that are ineligible for PSC
Irene: We are looking for more input from you on features that are important to you. We've been looking at SPC on Chrome on iOS
smcgruer_[EST]: On the screen you can see Chrome on iOS (webkit under the hood)
… wkWebView hosts the content within a Chrome shell
… you have three components in play: an app, the wkWebView library (with hooks provided by Apple), iOS level APIs
… for payment request or navigator.credentials; that's built into wkWebView
… but you can't do SPC or payment handlers today
… but there is a solution
… wkWebView are able to inject javascript into the Web content. We (Google) do this a lot today (long list of polyfill examples)
… we could polyfill with JavaScript Feature
… to use this feature you write some JavaScript, and then you add your feature.
… and magically the javascript runs in any loaded page
… the way we could do this is to intercept calls to PR API for SPC (and allow the other PR API calls through)
… so, should we just ship this?
<jcayzac> (we do the same in Rakuten Pay, polyfilling stuff before documents are loaded and implementing everything on the native side. works very well but goodness all the plumbing required)
smcgruer_[EST]: it turns out that there's a lot of work that we would need to do.
… we would have to implement payment handler functionality, BBKs, UX, etc.
… there are open questions, particularly around passkeys
… and there are downsides to this approach....we'd rather not do script injection.
… and also, other browsers on iOS would not get SPC.
Gerhard: The obvious question for me is: how many people would this implementation on iOS benefit?
… what percentage would be lifted by doing this?
RickByers: It varies a lot by country
… in June 2025, Chrome was 15% of iOS users
… 81% is Safari in the US
… in Germany, 16% chrome
<rbyers> Public browser market share data from cloudflare: https://
smcgruer_[EST]: It's possible other chrome-based browsers would also get the feature on iOS
Rick: We proposed to contribute this feature to webkit but got no response, so we are assuming we cannot land it directly.
gkok: Is the JavaScript approach more brittle than native implementation in webkit?
RickByers: No; this is a common pattern for us
gkok: If for some reason, SPC is invoked from within an iframe, does it work the same way?
smcgruer_[EST]: You have choices where you inject the script...we should be able to inject it in any frame
RickByers: We've done a lot of this on Chrome already so have experience.
Gerhard: Do you think it would be easier to do payment handlers than just SPC?
smcgruer_[EST]: We've also thought about this for PH
DanP: PCI has a script preservation requirements
smcgruer_[EST]: Have not considered
SPC issues and discussion
smcgruer_[EST]: Some additional prospective topics:
- agentic powered checkouts with SPC
- SPC for subscriptions?
- passkey-less SPC?
Ian: Could we use the Webauthn endpoint API to talk to the RP?
(We discuss the proposals around reducing double step-up)
Fahad: There's some precedence for reaching out to the RP (e.g., FedCM does this)
smcgruer_[EST]: Yes, it's similar, but the call would be non-authenticated in this situation
Rick: FedCM does have an unauthenticated request.
(Privacy issues mentioned)
smcgruer_[EST]: As soon as I type my card number, merchant and issuer can talk to each other
gkok: Right, through 3DS method
smcgruer_[EST]: Our preference would be to get rid of passkeys before fixing BBKs again and again
Ian: Would would the flow look like without passkeys?
smcgruer_[EST]: Let's call BBKs "payment credentials" now
… imagine you have an api to register a payment credential
… the ability to create a credential would either be authenticated via a biometric or not
… you create the payment credential and it's fully browser bound
JohnB: You'd be recreating single-device passkeys
smcgruer_[EST]: This would be a browser-level concept not an authenticator level concept
Ian: Would single device passkeys be same functionality?
sidd: How do you differentiate the agent from the actual customer?
JohnB: WebAuthn / passkeys require user presence.
… if you make up a new credential you don't necessarily need to follow those rules
… it would be surprising to people there wasn't a user presence interaction over WebAuthn
… if you wanted to do this with an agent that wasn't present, it would potentially be easier to do without passkey.
NickSteele: Passkeys don't need to be involved in agentic discussions.
… we're trying to avoid scenarios where we an agent is acting on behalf of a user with their identity; that's not a way forward.
… when we are thinking about agentic payments, we are not trying to change passkeys
smcgruer_[EST]: There's no world in which we are proposing passkeys or SPC for the agent to authenticate themselves as the user.
smcgruer_[EST]: For SPC and agents, we are more thinking of this in the use cases of the user authenticating their mandate.
Lee: Regarding passkey-less. We started with this idea of using a passkey to authenticate a transaction.
… but we've had to lay on "improvements" until we ended up making passkeys more suitable for payments.
… it feels like we've gotten to the point where we should do something else.
… I agree that we should not have gone done the passkey path
… if we are going to create a new payment credential -- we should absolutely do that -- why not come up with something that works natively and in the web?
Tomasz9: I like the idea of non-passkey user verification. ... agree we should look at in more details
… SPC is a two-step process...there is a two step process (sheet then passkey sheet)...we can improve the UX without passkeys (one step only)
… one of our findings is that we inherit passkey artifacts such as "signing with passkey" in the dialog
… the other thing I wanted to mention as far as BBK issues
… in the case where the device does not support BBK or browser doesn't
… it would be good to know in advance "is bbk supported on this device?"
… that could be accomplished by expanding an enumeration
Tomasz9: Regarding subscriptions use cases, I think more generally it's about recurring transactions; we think it's valuable to enhance the sheet for recurring payments
… it's not just about the UX, it's about signing over the terms and conditions
NickSteele: there is some other work going on with MCP...there is currently a spec enhancement proposal that will be added to MCP that will allow for an SPC flow to be triggered during an agentic flow
… the assertion will be handed back to the MCP client
… there's a push to use the browser to handle a payment on the desktop
JohnB: I want to speak up in defense of passkeys (kind of). There is work going on towards a relationship public key so that someone could have a trusted group of devices.
… if we think that we can't take advantage of that so that someone doesn't have to do step up on each device may not be worth it.
… but the advantage of passkeys is to reduce step-ups cross device...if we are moving away from that, there is little reason to use passkeys
JohnB: It's ultimately a question of whether this is a stop-gap solution...en route to what we ultimately want
JohnB: Are we going to move in the direction of multiple passkey providers, trust between devices, multiple browser and platform architectures...if we're NOT going there then, sure it can be a thing in the browser.
Nick_S: On the topic of the core challenges for subscriptions...I think it's important to define what the core challenges are.
… there may be different schemes depending on different payment schemes.
… so where's the boundary between what is something you should standardize v. what is scheme-specific.
Tomasz9: See issue 185.
(Regarding multiple RP credentails as input; Issue 310)
smcgruer_[EST]: Doesn't really make sense for WebAuthn to have multiple RPs
Jonathan: the question is that the caller doesn't know which credentials are available on the device.
JohnB: WebAuthn credential is for one and only one RP
Fahad: For a given payment method, there could be multiple RPs (bank, network, PSP, etc.)
… I want to be able to pass all of them in the payment request to increase my chances of an authentication.
JohnB: That is possible; you'd just need to pass the RPID in with the credential ID
… the authenticator only knows one RP for a given credential.
JohnB: once you let other people ask for your RPID, there are potential MITM attacks.
Fahad: But I would see a UX in that situation
smcgruer_[EST]: The SPC implementation can iterate over the full set of credentials; the main "risk" is that it would be yet another step away from passkeys
… the future where more authenticators would support this gets narrower.
nick_s: Are there any payment schemes where this situation could occur?
Gerhard: There could be use cases in open banking
nick_S: If this happens in other payment methods then makes more sense to solve.
NickTR: Any place where there might be a merchant-stored credential
Gerhard: Another use case under EIDAS where the bank can have its own credential and where the gov credential must also be accepted
Jonathan: You can make a choice up front.
Gerhard: But you could not need this if you knew there was (not) a credential before the SPC call
IJ: What is the mood in the room about knowing silently there are no available credentials?
JohnB: It's not silent; there's still a user interaction with immediate mediation.
smcgruer_[EST]: I always had the feeling that the cross that SPC can be called even though not RP would also complicate our situation.
… I don't think we cannot do this
timcappalli: You could do immediate mediation with BBKs.
smcgruer_[EST]: Sniffing attack with WebAuthn...you could only get the negative, not the positive.
timcappalli: There's been recent talk about a switch to turn off immediate mediation
nick_s: Regarding the question of whether to silently know there are "no credentials" ... absolutely not.
… there will have to be a user intent.
… the PR API implementation in Safari today says "yes, something is available"; it lies to you
(The acknowledged difference is that with SPC, other parties can use an RP's credential)
(The recap of immediate mediation is: silent "no" if no credentials, otherwise it triggers a user interaction)
[Back to topic of multiple RPs' credentials as input]
smcgruer_[EST]: I think we can build that into SPC.
IJ: what can we do to encourage more experimentation?
smcgruer_[EST]: Chromium is open source
… this is about resourcing, not gatekeeping
… there are many ways to contribute
JohnB: What are the requirements to actually move this from a theory to something that's widely deployed
… is it the number of devices that support this?
… we probably need to figure out "what is on the critical path" to make this an MVP?
… if it's only on some devices ... I can understand why a bank would look skeptically at this.
nick_s: I hear Ian saying 2 slightly different things: (1) how to experiment with the API (2) how can you add things that can get adoption?
gkok: I don't think that "subscription" is a critical feature; the lack of additional information is not causing banks to hesitate.
… I think device binding was a much more important feature
vasilii: I agree it's more about adoption than experimentation. Some features will advance adoption.
Gerhard: The problem has been and remained lack of surety about what will happen when SPC is called.
… improving 25% of the population in a given market is worth it for large issuers.
… but the risk is all the challenges that were mentioned today.
… lack of continued / predictable UX is a blocker
… if you have to track a cookie in an iframe in order to try FIDO, those have been the challenges we face. They don't like OTP, but they know that it works.
… I've been campaigning for a less onerous registration process.
nick_s: That's true. These are payment instruments that are operating under rules. One way of getting adoption is to for people who set rules to force adoption. (I'm not saying that should happen, only that it could happen)
… you'll never get complete compliance, but when rules mandate compliance it can accelerate things
Gerhard: Some things have been regulated. By making things more complex you can achieve higher failure rates.
nick_s: This isn't a problem you need to solve in the US. Nobody is going through OTP codes in the US
Gerhard: Yes, there are. A number of issuers are.
Gerhard: In the US, merchants are taking a large percentage of risk calls. Because the US is less accustomed to challenges, when challenges happen they are over OTP
Cip: 1.5% of transactions go through 3DS, and OTPs are over half of them.
Nick_s: But my point is 98% of transactions in the US are frictionless.
Gerhard: That's why I want SPC without passkeys in the US
gkok: When I spoke to some of the issuers some said that their biggest problem in some cases is card provisioning in wallets
nick_s: I'm not saying it's not worth it, I'm just saying adoption will be hard if it's not mandated.
Gerhard: Issuers are using fingerprinting to track the user, which is not good for privacy
… that's how they are trying to reduce risk.
… isn't that also bad?
Nick_S: But issuers don't care about that.
@@: It would not be possible to force SPC on issuers if not interoperably deployed on all browsers.
gkok: France in a market where they don't want exemptions. Is this a good market to test for scale? Everything is going to be challenged there.
… it would be great to test out in a big market.
… I think that would allow us to solve for other markets
Henna: I think SPC today with BBK and the UX improvements is something we would use.
… but I take the point that if not available consistently across browsers it will be more challenging
timcappalli: We need to resolve the question of BBK only or BBK with passkeys while we're at TPAC.
… maybe you get BBKs on desktop and digital payment credentials (DPCs) on mobile
Henna: I think passkeys with BBKs are fine; don't need to separate the two (at least yet)
… my preferences would be keep passkeys + bbks and add enhancements.
timcappalli: In my opinion, passkey doesn't provide value
timcappalli: The BBK would be a webauthn credential with UV required.
smcgruer_[EST]: We'd have to define all the authentication type things
timcappalli: It would be a webauthn credential with UV enforced.
smcgruer_[EST]: It might work to define it that way
timcappalli: You get a lot of guarantees by making it a webauthn credential, just not a passkey
Lee: it has a different UX, has different properties, etc.
timcappalli: I do think that making it a profile of webauthn is much easier than making a brand new thing.
JohnB: Would the credential also be available through WebAuthn?
Albert: We will be using passkeys for login and payments.
gkok: I think that was my point - the basic use cases is cards (and mostly in Europe) where they are most concerned about the binding.
… I think that non-card payments will require something like SPC for authentication
timcappalli: I think we should explicitly separate login credential from payment credential
… it might be one high level name but different under the hood (e.g., BBK on desktop, DPC on mobile)
JohnB: I know it sounds like a nice idea to use the same credential for both, but practically right now, only a small percentage of passkey providers can do SPC.
… the vast majority of passkey providers are just different providers
… unless we get to the far more advanced stage of SPC cross device,
… I think from a login point of view you want flexibility to work across passkey providers
Jonathan: When you are a bank, could you do one enrollment and create both a passkey and a BBK?
Lee: I think there are good reasons to create payment credentials.
… e.g., google pay gives you nice one-touch checkout
… if you want to make these things successful, you want a checkout API on the way.
Lee: I'd like to see APIs for dedicated payment credentials. You can create 1-touch payment experiences with them.
smcgruer_[EST]: People typing credit card numbers into forms represents a lot of e-commerce
Lee: You need an incentive for adoption by merchants.
timcappalli: If we go the BBK path, we should just go the DPC path.
… your browser can store DPCs. We can just kill BBKs
… you get a lot of benefits
… we have to be ok with passkeys not being the best approach for high assurance banking situations
nick_s: I agree largely with Lee. I think one reason PR API did not get the adoption we wanted because there was prior art.
… I see SPC as a stop-gap.
… I feel like we should be more forward thinking
JohnB: That's the point I was trying to make. SPC is a stop-gap .. should we prune it back as a stop-gap to get it deployed in some useful fashion
… if we keep adding features to SPC we're not going to get it adopted
nick_s: Would we rather solve for one payment method or try to solve for more ?
Ian: We have statements from other payment systems that this would address their needs and be useful (e.g., UPI, PIX)
nick_S: the reason we are doing SPC is that there is resistance to changing checkout flows. Should we be standardizing that, or should we be standardizing for the future?
nick_S: I am not dissing SPC, I think we should invest in the future.
Henna: We are doing that.
… there are many people in the room working on that concept. But it will take time that works across OS, browser, wallets
… today we have SPC and it works.
… I'm not disagreeing with you, but it is available now.
JohnB: It works in a certain context.
… if we can narrow down what we are offering people as BBK / SPC..
… let's narrow to get adoption faster.
JohnB: We have a limited window for this solution.
@@: That is an argument for keeping it as passkeys.
DanP: Tim's question on picking a direction is the core question.
… Lee asked what merchants are interested in? merchants care about approval rates. Once we get to debit cards, we are outside EMVCo.
… in the merchants with large volumes, they are thinking about uplift through SPC
… 7% conversation rates is very compelling and driving merchants to do pilots
… the issuer wants to stay top of wallet, the merchant wants approval rates.
Gerhard: If we have a DPC, how would we track the biometric?
… if it's still the person, why not have a person credential, which authenticates me?
gkok: If we find use cases for non-card use cases, I think SPC can work even better.
… the reality is that we still a lot of edge cases where tokens don't perform as well as they should
… it's very hard to back off something like that
… I don't want my users to leave the browser to have to do something outside which is a less good experience.
… we'll talk about facilitated links proposal tomorrow
… could we still use SPC in that context?
… I don't think we should move away from what we know about
david: Real-time push payments is a big opportunity.
timcappalli: There's a lot of misconception about what a webauthn credential. A webauthn credential makes not claim to represent a person.
… DPCs are a fresh opportunity to say "this is a payment schema" I think it gives you want you want passkeys to be that passkeys will never be
timcappalli: The thing that has changed (unlike 10 years ago) ... we have credential managers in all the devices
… most users have these things and plumbing is shipping
nickTR: Great debate. I think good to aim high, but also important to get improvements in some markets for some people
(Discussion about "stop-gap" v "long term solution" for SPC)
John Bradley: E.g., can you have multiple RPs ... if we are limiting that to chrome then a pretty simple solution
....if we try to solve more broadly it gets more complicated.
...if we try to solve this for the much larger ecosystem, it's a much larger problem.
Henna: From a pure RP point of view, we'd like SPC to work. The way it works today ; we'd like some minor enhancements.
....from a DPC point of view, we are also invested in that.
...I see SPC as a solution we will use today
... I don't think we need to re-architect the whole thing
...in parallel we need to get DPCs to work. IF it works as expected, we'll use it.
John Bradley: I want to be clear. It's not the passkey or security key providers that don't want to do SPC. We don't yet have the ability to play in that ecosystem. We changed the CTAP spec so that security keys could support it.
...but other pieces are not in place.
NickTR:
I have a pragmatic view on this. Re short-term v. long-term. ... I am aware that we started SPC as a tactical
solution...it's basically PR API with some extra bits.
...we did the tactical answer and we have some traction
...I'm hearing that we're going to have a lot of cards and a lot of browsers, so let's do this for now.
Nick Shearer:
You may have a lot of cards, but no mandate to use it.
...What is holding SPC back? Is it missing features? Or is it an interop issue?
IanJ: We've heard many times that it's both features and interop.
Nick Shearer: There's no question passkeys are better than passwords. Is it as clear that SPC is a superior experience?
Sameer: I think interop across browsers would get us to the next stage of SPC adoption.
JonathanG: I do understand frustration that payments are not fast to implement new things. That's because there are billions of cards, millions of merchants, etc. You can't change the ecosystem overnight. Regulations change.
...e.g., in UAE OTP will be banned, in India biometrics will be allowed.
...passkeys were introduced with login in mind.
...in payments, the credential needs to be tied to a user (can't be synched)
...every integration problem will add conversion issues and merchants will say "worse than before"
...the pace can be frustrating, but we are making progress. SPC is an improvement. DPC is very promising.
Tim Cappalli: Regarding "why passkeys are successful": companies aligned and were not competing with an existing solution.
Gustavo: It's more of a chicken and egg problem with SPC. Issuers said to me that they needed device binding.
Nick Shearer: I will need to defer to my colleagues who do authentication.
JonathanG: Do you see a difference between DPC and SPC from a UX perspective?
Nick Shearer: Yes. With DPC you can ask for a payment credential and also an id credential.
JonathanG: This aside (since you can do this outside SPC), do you see a gap in UX and security that SPC doesn't have?
Nick Shearer: SPC today..you can enroll a credential that you've enrolled somewhere else.
....it doesn't matter what wallet it is
...I think it's a poor UX to enroll a second credential.
...I think you'll get this through DPC. The wallet and credential managers will return the requested credentials.
(Some discussion of linking FIDO credential to an identity)
NickTR: Chrome team, how complex would it be to allow various SPC options: passkey only ,passkey + BBK, BBK only (BBK only is "user activated experience")?
Stephen: The version of this where you just click a "confirm" button is technically very simple, but there are some privacy questions. ...the version where you click and get an OS biometric is more complex.
John Bradley: Another of looking at this: if credentials are made through SPC they would have the payment flag set, and those credentials would not be offered for normal webauthn.
...it would be a small change to chrome or chrome passkey providers to not provide credentials for generic webauthn.
(Discussion of engineering effort and various solutions either using OS biometric or passkeys)
Sharanya: Apart from card networks and infrastructure / platform, issuer adoption is still influencing this. Thoughts? Can other parties being the relying party drive more adoption?
Gerhard: Could we perhaps enumerate the list of 'enhancements' for everyone's reference (e.g., Agentic, including line items, recurring payments (issue 185)? This might also help as people think about SPC in light of emerging wallets and digital payment credentials (see wallet comparison)? SPC without passkeys (BBKs alone) for single-factor authentication / registrationless authentication / SMS replacement.
Adjourned for the day. Minutes from day two on 11 November.