W3C

– DRAFT –
Payment Authentication on the Web: an Issuer’s Perspective

10 November 2025

Attendees

Present
-
Regrets
-
Chair
aschGHub
Scribe
Ian

Meeting minutes

Albert: I will share issuer perspectives on authentication in payments.

Albert: challenge is to balance user experience and security.
… we want to stop fraud and eliminate friction
… we need a diverse toolkit

Our primary considerations when looking at new authentication methods and patterns:

Adoption...how quickly can customers learn and how simple is the experience?

Eligibility: This is a huge aspect when we hear about web payments. We want as few false positives as possible.

Fraud rate: Want phishing-resistant tool, and weaknesses of each tool

Omnichannel: We want things to work across devices, channels, and OSs

Complementary: No one tool solves everything.
… how does a given tool complement others in the suite?

Effort: How feasible for me to build or buy?

Albert: Capital one offers app, card tap, OTP for authentication
… we try not to pigeonhole customers to one particular method
… customers pick the most familiar often (so OTP much more popular than app which is more popular than airy)
… customers prefer lower friction
… fraudsters also prefer lower friction

Gerhard: Is there differentiation among fraud?

Albert: We see social engineering on all channels; that appears to be the main threat vector

Gerhard: How about cross device?

Albert: Don't know offhand.

Tony_Nadalin: If people have multiple devices, does that affect choice of method?

Albert: Yes, will say more in a moment

Cip: Do you always present all options to cardholders?
… or for example, you might only present one approach given risk calculation?

Albert: We modulate tool offering by risk.

Albert: A lot of issuers will have problems removing OTP from the market due to broad coverage.
… we will allow users to attempt one method but then try another approach if that doesn't work.

Gustavo: Are you using these options for login as well?

Albert: All these are offered outside of Web Payments
… there might be slight differences between mobile and web

Albert: One of the biggest challenges we've seen is that iframes present issues
… in order to get a customer into the mobile app or airkey experience, there are digital gymnastics
… we do offer push in mobile context
… for airkey it's even more challenging since CORS restricted.
… so we either do SMS to airkey or the user does a manual copy or paste in a mobile context.
… we are interested in SPC for this
… for the AirKey experience in iOS we offer it as an app clip
… for chrome / android it's done via WebNFC

Albert: We see drop-off between first screen and app. We are not seeing falloff once they are in the app

Gustavo: Are you asking backend for information?

Albert: We run our own ACS
… once a card tap happens, we signal to the merchant and network that authentication has completed.

Gustavo: So if the user closes browser, you would still the server that authentication completed...but merchant might have some issues.

Sammer: If we can optimize the iframe experience, we think our conversion rate will go up significantly.

DanielWyckoff: Do you have instantaneous completion here?

Albert: We are very careful about how we are pushing frictionless experiences within our ecosystem because the rate at which fraud matures is very slow.
… we may not get a fraud signal along those time periods.
… if the user is transacting and authenticating within a time period, we might handle them in a frictionless way...

DanielW: Is there any state where you would open a modal and then immediately dismiss it (because recent session data is available and relevant)

Albert: I would say no, we are not doing that.
… it creates a poor customer experience ... don't want to disrupt the payment unless we are intending to challenge.

RickByers; Are you asking user to copy a URL?

Sameer: 3DS says you can't do popups.

Stephen: But payment handler can open. So your payment app could be a payment handler that could do an NFC scan.

RickByers: Yes, could be a Web-based payment handler.

Albert: We believe that if we can advance our authentication tooling we can give users better options

[On passkeys]

Albert: We see passkeys as the future of payment authentication.
… all the good properties that we like
… no app download is needed
… no cell service is needed
… no channel switching (required)

Albert: We are planning to offer a passkey solution as an auth method to our cardholders.
… we will evaluate this tool and how customers respond (eligibility rates, completion rates, etc)
… we just launched passkeys for login this year

Tony_Nadalin: Are there any problems with registration?

Albert: I have not heard resistance. We're still evaluating the adoption rate.

Tony: Do people know what passkeys are?

Albert: Our enterprise is doing a lot of education.

Gustavo: If I'm only on the app, would I get a chance to enroll?

Gerhard: Do you allow registration during payment journey?

Albert: We won't be doing registration on the iframe.

Gerhard: How do you choose to do registration?

Albert: Initially we won't know, but we'll be looking at whether the payment credential has been enrolled with a passkey in the past.

Tony: Would it help if you knew in front that there was a passkey

Albert: Yes, absolutely.

(We talk about immediate mediation)

stephen_mcgruer: But is that really a better experience?

(Some discussion about UX challenge around immediate mediation, especially when multiple family passkeys are on the device)

(On 3DS and setting permission policy on iframe)

Albert: SPC has made it possible for issuer to assert on pre-established FIDO credentials without presence
… I see this as an opportunity to optimize our authentication tools.

Tony: Do you care about certification aspects?
… do you need FIDO?

Stephen: Which authenticator types do you care about? E.g., roaming v. phone v. ....

Albert: We see the most benefits out of synched passkeys.

Stephen: Do you have use cases for roaming keys?

TimCappalli: Would you restrict a user from saving a passkey on a roaming authenticator?

Albert: I am neutral.

Albert: A lot of our web based payments will be in a mobile context.

Gustavo: Your user today has three options. You are ok with user having only one option with SPC?

Albert: I'm interested in not owning the iframe.
… there are advantages to not having to manage the iframe
… I have no problem working with the browsers to elevate the options to give my auth tools a better chance of conversion.

Gustavo: I don't like iframes; they are hard to debug when problems arise.

Albert: The benefits of SPC are clear
… the way we see it: fraud security, challenge time, future success.
… can this be extended to other authentication tools (e.g., card tap, payment linking, roaming authenticators)?
… can we extend SPC beyond passkeys?
… it would be good to meet issuers where they are.

Gerhard: It would also be good to be able to get from merchant site to capital one app and then get back.

Albert: Maybe not even directly in channel, but halfway there.
… so cf the facilitated payment link proposal, or payment handlers

Gerhard: Some of this is available already. In 3DS 2.3.1 there's an option to link to the app and get back to the shopping context.

Albert: is that in web or native app?

Gerhard: I think from web to app and back

Lee: DPC is the more general solution.
… all inline without redirects.
… works for both native and web

Gustavo: How much remains in the control of the issuer in that case?

Lee: You'd make the DPC call wherever you would make the SPC call.

Sharanya: What are the two factors that you are using?

Albert: We are in an unregulated market, so we don't need to satisfy SCA.

(Albert shows mockup of SPC used with WebNFC)

Albert: Some issuers may hesitate to use SPC so you need to lead them into it.
… this group can help bring issuers along
… I'd love to see:

* Blend my other auth tools with SPC. A lot of my issues could be resolved with help from browser

Gerhard: Would you still need an OTP fallback?

Albert: Yes, but we'd like to get rid of it

TimCappalli: Do you want to get rid of OTP complete? What about Android phone number verification?

Nick_S: If you had the customer's phone number in your system, and it was cryptographically verified, would that be more useful?

Gustavo: With the phone number verification you get more guarantees.

DavidBenoit: But that doesn't prevent against SIM cloning

Gustavo: But I am hearing the issue is more about phishing rather than SIM swap

(Discussion of SPC with other authentication tools)

(WebNFC, OOB app)

Albert: We are strategically building toward SPC.
… we plan to launch webauthn in early 2026

and we'll evaluate SPC later in 2026
… I would encourage the group to think about meeting issuers where they are at

and advancing browser capabilities to bring issuers along
… and allowing issuer to authenticate their own customers.

Minutes manually created (not a transcript), formatted by scribe.perl version 248 (Mon Oct 27 20:04:16 2025 UTC).

Diagnostics

Maybe present: Albert, Cip, Complementary, DanielW, DanielWyckoff, DavidBenoit, Effort, Eligibility, Gerhard, Gustavo, Lee, Nick_S, Omnichannel, RickByers, Sameer, Sammer, Sharanya, Stephen, stephen_mcgruer, TimCappalli, Tony, Tony_Nadalin

All speakers: Albert, Cip, Complementary, DanielW, DanielWyckoff, DavidBenoit, Effort, Eligibility, Gerhard, Gustavo, Lee, Nick_S, Omnichannel, RickByers, Sameer, Sammer, Sharanya, Stephen, stephen_mcgruer, TimCappalli, Tony, Tony_Nadalin

Active on IRC: Ian, Padmanabhan, tidoust