– DRAFT –
(MEETING TITLE)

Payment Request

Ian: Any Payment Request implementation or adoption updates

Ian: How has it been using PR API to get to ApplePay ?

Nick_S: Good! We have soft deprecated ApplePay.js. We are no longer adding new features to it.
… one example is that we now support disbursements. We are only adding support to PR API and not the proprietary API
… I expect over the next year we will start to further deprecate it.
… we support ApplePay on other browsers through a polypill.
… we like payment request and think it's good

smcgruer_[EST]: If I understand, the ApplePay experience onChrome on MacOS is a QR code. Any desire to use PH API?

nick_S: We are interested.

Nick_S: At least some of my colleagues. We may also have an opportunity with digital credentials to take a more generic approach.

Nick_S: Apple pay is also supported some some headless devices; we are interested in exploring handoff options.

smcgruer_[EST]: From our side, we shipped native payment handlers for web views. If a web view host opts in, to enable the user of payment handler API

Cathy (Meta): In the Facebook browser we can now support PR; experiment was wildly positive. Conversions increased a good amount.
… you click on a link in the Facebook app, and payment request can be used instead of a JS implementation
… seeing Google Pay without PR API took a minute to log in...it was not a good UX
… but with PR API, checkout happened within 20 seconds.

smcgruer_[EST]: This is using the open payment handler stack; this would work with any payment handler

Ian: Any PH API news?

smcgruer_[EST]: Shopify sought input PH API in interop 2026

smcgruer_[EST]: Interop 202X is an open submission where anyone can submit what they consider to be an interop issue on the Web
… this effort has been, IMO, amazingly successful
… we've seen interop scores go up across browsers.
… there is a proposal process.

NickTR: Who hosts this?

Martin_Thompson: This is under "Web Platform Tests" auspices.

<jcayzac> https://wpt.fyi/interop-2025

Martin_Thomson: The goal is to get close to 100% agreement across tests.
… if something like this (PH API) makes it, it will improve interoperability

Cathy: The original question was about "payment handlers": what we found for PR API, sometimes when a PH exists, sometimes it's blocked. We had to get on an allow list.
… if you are a payment handler and you're not on our allow list, talk to me.

smcgruer_[EST]: That's a choice of the app distributor

NickTR: Those are native apps.

Gerhard: I'm excited to hear about interop (2026). I've heard people say "Come back to me when browser X supports this"; it seems like a way to motivate interoperability.

<mt_hates_irc> https://wpt.fyi/interop-2025

<rbyers> https://web.dev/blog/interop-2026-proposals

Gerhard: Do we have timelines?

<rbyers> https://github.com/web-platform-tests/interop/blob/main/2026/selection-process.md

rbyers: This is not a mechanism to get someone to do something they don't want to do. It's a means to get signals; vendors make their own decisions.

smcgruer_[EST]: But it is a good venue to indicate interest.

rbyers: Look for news (blog post) later this year.

PLH: Mike Smith is our link to WPT and interop

<plh> [WPT finds its origin at TPAC 2009: https://www.w3.org/2009/11/TPAC/DevMeeting]

<mt_hates_irc> https://github.com/web-platform-tests/interop/issues lists the open proposals

Improved error codes

smcgruer_[EST]: The request for improved error codes (from PayPal)
… my recollection is that there might be some privacy concerns; I don't think so.
… but we need to make sure it does not break things in an implementation.

nickTR: There are two proposed directions (1) feature detection (2) specific error code
… my sense was that Marcos' suggestion had less potential to be a breaking change

smcgruer_[EST]: At first glance, I lean towards Marcos' approach.

Ian: Any TAG perspectives here?

Martin: Under normal circumstances, adding error codes is an ok thing to do; people should expect that understanding evolves.
… but also, software will typically break.
… respond to the screaming that you will hear

ACTION: smcgruer_[EST] to sync up with Marcos to try to sync up on 1040.

Ian: Any opportunity to connect PR API to new digital wallets?

Nick_S: Yes.
… as I mentioned yesterday, DC API will allow any credential manager to plug into it
… those implementations are shipping
… it seems like there's an opportunity to combine the many years of work we put into PR API to handle complex checkout flows (e.g., price negotiation based on contact info)
… with this extensible system for credentials.
… it would be very unfortunate if we ended up in a place where there was use of DC API for payments
… we should schedule some time in the future to see how we can bring these two APIs together in a combined flow.

Gerhard: Are we proposing that a Payment Request do its thing then invoke DC API?

nick_S: That's one option, but I am thinking that DC API might be a standardized payment method that can be used within PR API
… there may well be other things we want to do
… e..g., auxiliary claims could fit into that flow
… a good example might be phone number. PR API allows you to query phone number.
… so you may want to get a payment credential and a phone credentail; you may need an API that allows you to get multiple credentials.
… this would allow you to fall back gracefully.
… suppose a wallet supports digital credentials and can return a 3DS cryptogram
… if you are on an older browser, you could say "I also support these other payment methods" and have graceful fallback

tomasz: I think this is an interesting idea, especially since PR API has a lot of support for payment use cases.
… what DC API is lacking these days is to provide a structured context for payments, which we have (more or less) in PR API
… the way we think about digital credentials goes beyond web
… PR API is just for the web.
… the platforms have implemented their APIs natively

nick_S: The DC API is also a web standard. I'm not saying you wouldn't have native integrations, it's more that we want web sites to have access.

timcappalli: We need to chat sooner rather than later about what this would look like for developers.
… e.g., simple use case for PR API, more sophisticated UX with DC API
… the original idea with DC API was to have a type attached to the request; but that's been offloaded to the protocol

MartinT: One of the things that's interesting here is that there's pushback on use of DC API for privacy reasons. The TAG does not want to see people refusing to do business unless they get access to identity information
… the considerations that apply on the DC side will apply even more in payments.

nickTR: Nick_S made an interesting point about digital credentials as a payment method.
… but my instinct would be that PR API provides context, and DC API would be an extension point to respond to a payment request.

timcappalli: Think of DC as a format.

timcappalli: DC API is the entry point for the developer. After that there's plumbing that can hold credentials.

nickTR: I share the TAG's concerns generally about barriers that are presented by doing identity
… but age verification is often required in a regulatory environment.

rbyers: This is an interesting discussion discussion about PR API and DC API
… it was core to design of DC API that it be one-shot (not bi-directional)
… so we'd have to do some work to understand how they relate
… PR API does not require a user interaction in the same way DC API does

fahadMastercard: I think connecting these is a good idea. I think we need to solve for the .create use case for payments

tomasz: Regarding digital credential-as-payment method... I would think we'd need the type of credential as a payment method

nick_S: I think merchants often want all the buttons visible....

<smcgruer_[EST]> +1

nick_S: NickTR's Finland example is a good example of where we should be using DC API....selective disclosure should be done with DC API

<tomasz> +1

nick_S: I look forward to continuing the conversation

<nicktr> @tomasz that's the point that I was trying (inelegantly) to make - payment methods represent a more granular request for a specific kind of credential

Facilitated payment links

(smcgruer_[EST] presents slides)

smcgruer_[EST]: Browser can ignore the payment links flow; the merchant still needs a backup flow (e.g, QR code)

Shipping in Chrome since July 2025
… There are 7 wallets supported by chrome
… our page loads are increasing rapidly
… there's a lot of demand for this for non-EU / North Am markets

(We see demos)

Lee: Do we need (yet another) API to go from Web to native app?

smcgruer_[EST]: Why a new front end? We are hearing from merchants they won't build a JS integration. They are saying no to PR API. They are willing to drop an HTML link on their page.
… we cannot solve for generic payment protocols today ; nowhere to host manifest so we went with intents for the moment

Marcos: At a high level, the use case is interesting.
… but I question some of the design decisions.
… why do you need a link relationship to duplicate data (for the QR use case)
… why not just label the image?

smcgruer_[EST]: That makes sense.

Martin: I'm concerned about resolution of these URLs
… you have data URLs in there potentially loading UI which could be an attack vector
… in the DC API we wrote up why custom URI schemes is not a good idea

smcgruer_[EST]: Do you have a suggestion for doing this declaratively in a way that would be good?
… we heard one idea to use data URLs

Martin: The Web site uses a custom scheme that the browser recognizes, and the browser knows how to turn those things into a payment request (to a first approximation)
… that's a resolution process.
… you are not specifying a resolution process here.
… if these were HTTPs URLs, they would be interoperable

smcgruer_[EST]: For the ones that are entity-specific, yes, we should fix custom scheme issue
… but for a generic protocol that anyone can answer, how do you solve the decentralized use case?

<rbyers> The doc Marcos referenced: https://github.com/w3c-fedid/digital-credentials/blob/main/custom-schemes.md

Martin: Don't make the browser know how to handle proprietary schemes.
… different browsers might have different understandings, and we'd not get interop
… you'd get an inconsistent user experience

Idea: Map this to PR API if possible

Payments in Japan

Note: The first presentation from Morimori will remain Member visible upon his request.

Morimori: I want to cover three topics today - phishing resistant MFA in japan; selfi-matching only eKYC is being obsoleted
… Digital identity guidelines

[Scribe will cover discussion but not the slides]

Gustavo: You mentioned the focus is on financial services. Is there more strict guidance possible as well to providers?

Morimori: Countermeasures from the government is to implement DMARC with reject as well as phishing resistant MFA. It's not mandated, for all parties, but other parties are following suit.

Gustavo: Customers may not understand why it's important to use passkeys. What is happening to educate users?

Morimori: Good question; I will need to think more about that.

Cip: For payments authentication, is phishing resistant MFA going to happen?

Morimori: More on that in a moment

Morimori: Regarding identity proofing, ... there has been traditional eKYC (selfie matching only)
… but companies are seeing lots of attacks through fake ID cards.
… so the trend in Japan is to use IC Chip-equipped id cards
… so the goal is to obsolete sell-matching only eKYC

(in 2024-2025)

JPKI and its capabilities on a smartphone
… MyNumber Card on iPhone became available in June 2025

"d payment" application allows to do identity proofing

Morimomri: Digital Agency recently published the DS-511 digital identity guidelines
… is a normative requirement as of 30 September 2025
… there are three authentication levels
… the user must be able to choose phishing resistant MFA (with passkeys as an option)

Gerhard: Thank you for the presentation. In Europe we've seen definitions for SCA that may not align exactly with the implementation of passkeys.
… e.g., one example we've spoken about is device binding
… can you say more how Japan has defined MFA, and are there specifics (e.g., key lengths, device binding)

Morimori: DS-511 defines normative guidelines.
… but there will be supplemental guidelines that explain what phishing resistance means

Gerhard: Will it be device-bound?

Morimori: Synched passkeys were a controversial discussion
… personally I think synched passkeys really help

<TallTed> NickTR -- note that RRSAgent dropped at 21:54:46. (I've invited the bot back.) Some IRC loc and/or minutes patching will be needed. (I don't know who your staff contact is. They can help.)

Morimori: open banking in API

[11: 55] <Ian> Morimori: With my NTTDoCoMo hat on I am driving to implement passkeys with 3DS

[11: 55] <Ian> q?

[11: 55] * Zakim sees no one on the speaker queue

[11: 55] <Ian> Cip: As of April 2025 there are also other rules in Japan.

[11: 56] <Ian> [Takashi Minamii from JCB]

[11: 56] <Ian> TM: JCB covers Amex and Discover in Japan

[11: 57] <Ian> ...the Japan payment landscape is complex.

[11: 58] <Ian> ...JCB is trying to implement digital wallet with selective disclosure

[11: 59] <Ian> ...in Japan, Credit card remains the primary payment method

[11: 59] <Ian> ...QR code payments have grown significantly

[11: 59] * nina (~nina@6b13c2d6.publics.cloak) has joined #wpwg

[11: 59] <Ian> ...mostly for public transportation payments

[12: 00] <Ian> ...but combined share of e-money and QR code payments is approaching 50% on a transaction count basis

[12: 00] <Ian> ...heavily skewed to small-value payments

[12: 01] <Ian> [Slide on merchant discount rate]

[12: 01] <Ian> TM: There are no caps on MDR or IRF

[12: 01] * nick_s has quit ("My Mac has gone to sleep. ZZZzzz…")

[12: 02] * nick_s (~textual@6c65f1b9.public.cloak) has joined #wpwg

[12: 03] <Ian> ...in Japan, two companies handle card processing: CAFIS and CARDNET

[12: 03] * Albert (~Albert@6b13c2d6.publics.cloak) has joined #wpwg

[12: 05] * taki has quit ()

[12: 05] <Ian> ...IPR overlap: "Cotra" exists, but only for P2P remittance

[12: 06] <Ian> ...Confirmation of Payee is so ubiquitous that Japanese people don't even think about it

[12: 06] * RRSAgent (rrsagent@16081354.team.cloak) has joined #wpwg

[12: 06] <RRSAgent> logging to https://www.w3.org/2025/11/11-wpwg-irc

[12: 08] <TallTed> NickTR -- note that RRSAgent dropped at 21:54:46. (I've invited the bot back.) Some IRC loc and/or minutes patching will be needed. (I don't know who your staff contact is. They can help.)

[12: 08] <Ian> ...open banking in API

TM: Alternatives to write-access APIs - real time direct debiting service

TM: Stable coin and CBDC

TM: Situation similar to other countries; no decisions yet on CBDC's

NickTR: What is driving the proliferation of choice in payment methods in Japan?

TM: I think one initiative came from public transportation industry.
… Japanese authorities started a push towards cashless payments, using QR codes
… many service providers used QR codes as a prototype for new payment methods

Rogerio: There are even more options for online commerce
… companies like to push their products and, after a while, public consensus leads to convergence
… but there are often competing activities

[Rakuten on Ecommerce in Japan]

[Julien introduces Rakuten]

Julien: We have services on almost every continent.
… about 1/3 of the Japan population are customers
… we have internet services
… but expanded to travel
… now have a big fintech segment
… our loyalty program (common in Japan) is very important.
… rakuten points are important; it's not cash-back.1 point is worth 1 JPY
… the more services of ours you use, the more points you get when you do a transaction
… Japan is moving towards a cashless society
… Japan has set a goal of 80% of transactions by 2035
… in 2024, 40% were cashless
… "cash" here excludes bank transfers.
… checks never took off in Japan because bank transfers have been common for 50 years

[We see a diagram of what it means to pay with Rakuten Pay]
… we offer a POS device for in-person payments
… people can use a variety of payment apps; they show a QR code or NFC; it is scanned by POS device, goes to Rakuten Pay backend then on to processing
… for online transactions, for external merchants we have "Rakuten Pay Online" which is based on traditional web flows

(DanP asks a clarifying question about IPCs)

<Zakim> dp, you wanted to ask about settlement gateways

Julien: The JPQR standard is a registry of payment providers that can provide QR codes
… there's no fixed length in the QR code, but prefixes are standardsized
… I've seen similar ideas in other Asian countries.
… QR code helps indicate where processing should happen
… POS payment methods at a glance topics include: credit/debit, domestic QR codes, foreign payment apps, e-wallets
… QR code payments are not cross-border

Cip: Are these payment methods via Google Pay and Apple Pay?

Julien: In my experience they are not really used.

Cip: Is there a more common alternative?

Julien: no, no platform-specific thing
… but phone manufacturers can provide wallets

Cip: Do you know why this is?

Julien: Maybe low need to provide same thing through new mechanism.

[More discussion about complexity of card support for Apple Pay]

nick_S: Apple Pay and Google Pay work differently if you are a resident of Japan.
… we used to ship phones specifically for Japan.

Nick_S: transit agencies only accept domestic issued cards (similar in other asian countries)
… so you may not be able to top up

(We see some slides showing Rakuten pay experience)

Julien: We have a mini app ecosystem to extend Rakuten Pay. Right now, just for 1p apps, but we are opening up to 3p apps.
… we would love for our merchants to be able to use Payment Request, but we cannot be accepted ...
… when we embed merchants in our pay, we do so in WebView
… we are also doing some plumbing with fetch request to skip some screens when we are embedded in our own super app, but it's not ideal
… facilitated payment links might help us out
… what we really want to offer merchants is a unified experience between usage from a web, and the experience when they are embedded in our super app
… we have some user onboarding challenges
… eKYC has historically not been a good experience.e
… some consolidation is happening via MyNumber card
… but what about visitors traveling from another country?
… related to eKYC is "risk rating"
… we collect lots of signals
… we are also evaluating verifiable credentials

Morimori: Agree that visitors without My Number should have payment security.

NickTR: I get that payment handler not supported through webkit. You could use it with chrome, however.

Julien: But merchants will have to do things 2 ways

NickTR: You can do feature detection to fail gracefully

Julien: Yes, we can implement fallbacks

Gerhard: Is your main hurdle the API or lack of interoperability?

Julien: Lack of interopability

smcgruer_[EST]: Should Payment Request just have a fallback concept?

Julien: Our fallback is Web Navigation

smcgruer_[EST]: Google has a bundle...these bundles take care of a million things and run JS in your domain. You do this because merchants won't do the updates themselves.
… is there something we could be doing here?

Gerhard: We could build a polyfill for a Payment Handler

smcgruer_[EST]: Maybe there's a "standardized" polyfill with a predictable fallback.

<jcayzac> +1 to the idea of polyfill

Follow up on SPC from yesterday

DBSC Update

DanRubery: I work on Chrome on DBSC

DanRubery: We originally designed this to mitigate cookie-theft

(DanR walks through DBSC overview)

DanR: We designed this around a "log in" session but it doesn't have to be for login
… the configuration includes a set of bound cookies that must be included for in-scope requests.
… if the request misses one of the bound cookies ..... if the cookie is expired we do a refresh and sign a challenge from a server
… and the server replies with a fresh cookie.
… deferral ensures that most of the app doesn't have to think about what happens when proofs have expired.

Gerhard: An example would be a registration journey. You ask the customer to re-authenticate themselves
… can you retire a cookie before a registration session?

DanR: If 3p cookie is blocked, we don't do a refresh
… also, no support for partitioned cookies (yet?)
… we've received requests for DBSC-specific permissions prompts, for example.

DanR: Partitioned cookies would let you set a different value of the cookie for each top-level site.
… if your 3p content is within different top-level sites, you'd see different values in those contexts.
… good for privacy, but DBSC also needs to partition to not create privacy issues.

DanR: Chrome does not plan to provide TPM attestation.
… non-revocable identifiers are bad

DanR: We have some other discussions on extensions related to cross-site single sign on
… it's hard to transfer these security properties cross-site
… we have one solution right now which is sharing the key directly.
… webauthn has a related feature called "related origin requests"
… but this does not scale well.
… we have some proposals based on attestation keys
… those proposals are focused on enterprise use cases.
… Chrome is running an origin trial today on this
… we expect to ship in February 2026

Gerhard: Any way in which you can figure out when you might do partitions?

DanR: It's not planned today but if you file a bug on the spec, we can discuss

@@: What is the platform support for this?

DanR: Our current implementation is windows only
… Mac implementation is in-progress
… mobile is a pending topic...mobile OS have fewer issues that this would address.

DanR: The origin trial -- any 3p can register to try it out, but only .5% of page loads can use it

NickTR: Is there a way to provide access both to the merchant top-level origin and the iframe?

DanR: What does the merchant need to know?

NickTR: They don't need the key, just that the issuer has authenticated the user

DanR: Assuming the user has not blocked 3p cookies, the iframe can access its 1p state. And so the issuer could message to the top origin

SPC next steps

timcappalli: I have three quick slides on immediate mediation

timcappalli: This is not yet in WebAuthn (but hopefully close)

timcappalli: There are mobile flows (blocking dialog), conditional UI (autofill UI).
… this is a third mediation mode.
… the goal is to enable a seamless fallback when a passkey is not immediately available
… "immediately available" means "available on the device"
… the feedback we've received is that RPs prefer the user logging in quickly
… if no immediately available credentials, API fails with an error code and you can redirect the user to a fallback login
… it does require a user interaction (click a button)
… you cannot pass in a list of credential IDS. It's important to not be able to probe the device to see which credentials are available.

[We see a video of an immediate mediation flow]

[We see code for how to set the mediation mode]

timcappalli: We imagine a cascade of options (e.g., password, fedcm) before fallback

Lee: This is by far the most deployed mode.

Gerhard: If there were two passkeys, would I first see both?

timcappalli: If you have two accounts, there's a selector. If there are two passkeys for the same account, probably frecency

Gerhard: The question for SPC ... by the time SPC arrives, either the card on file or the person typing in a PAN has chosen their card and there's a passkey linked to it.
… how can we work around the idea of not allowing credentials.

timcappalli: SPC could be an exception; but a problem would be if there's no dialog

Gustavo: Suppose I am asking the issuer: "do you have credentials". Is there some way to have a time-bound way to probe those credentials for a domain.
… so that I can try to get a slightly better experience.
… would something like that be possible?

timcappalli: I can't think of a way to do that without opening avenues for abuse.

smcgruer_[EST]: I hear the use case is "you could have brought the issuer into the 3p but didn't"
… you want to delegate the RP's origin

Gustavo: This would only be with the issuer's permission

Nishant: Across multiple issuers?

Gustavo: No, just one issuer.
… is there something we could do to limit probing?

timcappalli: We want to prevent probing.
… you need the user's permission, not the RP's permission

smcgruer_[EST]: The RP is "the enemy" for this particular threat scenario.
… imagine the user has created a passkey and you (e.g., as a government) are trying to find this person
… and you start probing for that user among all users that visit your site.

Jason: Can you delegate activation?

timcappalli: By default, no.

Jason: Does the error say "no passkey found"?

<smcgruer_[EST]> WICG/capability-delegation for delegating user activation

timcappalli: No, it's a predefined WebAuthn error. It is very clear what the scenario is, however.

<rbyers> Capability delegation (passing a user activation down to an iframe): WICG/capability-delegation

nick_s: I don't think we can solve this and fix the privacy problem. The problem is that this information is valuable and so abuse is inevitable.

nick_s: There are merchants who are malicious ; we need to be careful about revealing information about the user.

DanP: Are errors aligned with signals API?

timcappalli: they are distinct

gkok: I understand that passing credential does not work. Is there a way to achieve cross-domain with no list?

JohnB: But that would be a worse privacy issue...I could see if a user has a credential from another origin.

Jason: Could the request be signed by the RP?

Lee: DCP!

Gerhard: I guess there are cases where you might want to use SPC in the RPs domain.
… so an issuer could use this

smcgruer_[EST]: We could do this in a 1P context
… we will not do immediate mediation with an allow list.

smcgruer_[EST]: This was one of the reasons we moved away from the credential-per-payment-instrument.

ACTION: Jason to write up an issue for SPC to do immediate mediation in a 1p context without an allowList

ACTION: Jason to write up an issue for SPC to do immediate mediation in a 3p context without an allowList

Henna: We identified some themes that SPC could do based on how it works today. Here's a list of ideas:

1) We discussed immediate mediation

2) Some sort of eligibility check -- is BBK supported in this browser?

smcgruer_[EST]: I suspect that should be fine. I need to check privacy position

ACTION: Stephen to look into viability of BBK support check

smcgruer_[EST]: Is user-verifying platform authenticator generally true if there's no strongbox?

timcappalli: Not related

3) We want two ways to do SPC -- with passkey authentication, and the confirmation only path (without user verification)
… a proposal is that if you want passkey it's the default, but if you don't you ask for uv = discouraged.
… and then you get two signed payloads, but no UX for the passkey

<tomasz> re: 2) check #315 w3c/secure-payment-confirmation#315

nick_s: User verification discouraged does not guarantee you won't get a UX
… the browser can ignore that.

Gerhard: there are two paths (1) we include a passkey (2) if the passkey isn't there, we still want the BBK and sign only with that.

<tomasz> +1

JohnB: That's a whole other kettle of fish.

Lee: that's a different feature request

Gerhard: But that would be attractive (no passkey registration)

Henna: So that's a third option.

JohnB: That's just DBC

Ian: No, there are other features of SPC beyond DBSC

nick_s: there are many non-payment use cases

Gerhard: But there's always a display in our use case.

smcgruer_[EST]: Are Apple doing DBSC?

nick_s: I defer to my colleagues.

Lee: the question is "can we do uv = discourage"? Yes, we can
… and that's the one implementation.
… so I think we can do it on the platform side.

smcgruer_[EST]: We use GPM on Android, but we use other authenticators on other platforms.

JohnB: If you support windows hello on windows, it can't release a credential without a user verification

Henna: We are going to separate the issue of "no passkey" option

Henna: We should collectively think about "SPC or DPC"

Henna: How do we do recurring transactions, multi-merchant, etc etc?

nick_s: We are not trying to rebuild the whole checkout flow...
… if you are required to display a payment, it may not be able to solve in SPC or PR API

nick_s: ...there's value to that, but need to be thinking about not taking on too much

smcgruer_[EST]: I agree with Nick. Do you feel the same with DPC?

nick_s: Yes.
… also, rules change. We can't build it into the standard.
… custom UI has problems
… I'm not seeking to replace the entire checkout flow

smcgruer_[EST]: I think it's not about replacing the checkout flow, it's about dynamic linking requirements

nickTR: This is not a requirement in PSD2

Henna: I think there's an expectation that the user see information when they are entering into a mandate.

SameerT: It's not letter of the law...regulators just asked that things be fixed.

Lee: We can consider new features on a case-by-case basis.

Henna: I heard from Nick_S we should not put things in standards

gkok: We also need to figure out the experience on the 3DS side
… it's a fine line...
… regulators want to impose a mandate on something that is not a mandate

Henna: We are going to try to come up with an MVP structure

smcgruer_[EST]: I am hearing a couple of asks
… DPC takes a JSON schema. Should SPC? Yes. let's just do that
… what's the chance of a browser or wallet handling all the UX...my guess is not much

Lee: What we want in DPC is a small number of schemas
… for DPC it may be a JSON schema and the browser can display like it likes
… in FIDO we want a transaction schema and it should be same

<tomasz> +1

ACTION: Tomasz to add to SPC repo the topic of structured (DPC-compatible) way to specify schema

nick_s: Apple has a proprietary request to PR API for recurring

irene: I am hearing a number of feature requests. What's MVP?

FIDO requirements for payments

<nick_s> An example recurring payment request for Apple Pay that uses PaymentRequest custom modifiers: https://gist.github.com/nickjshearer/bbf9c3f80e76a97ea0cc016b41b0f1c3

<nick_s> We would be happy to discuss upstreaming this into line items if there is enough interest.

Jean-Luc: I'd like to talk about the regulatory context in Europe around payments.
… as you can see, there's lots of regulation...some is strictly enforced, others less so
… beyond PSD2 there is, e.g., the accessibility act
… and others

Jean-Luc: An important topic for us is going to relate to onboarding
… topics include incident reporting and risk management
… digital identity wallets
… PSD3...(1) expands and tightens SCA requirements. (2) Strengthens anti-fraud controls (3) Creates frameworks for dispute resolution and chargeback management (4) Better monitoring and reporting (5) Strengthen outsourcing rules to improve risk management

<nicktr> If you are interested, here's a blog I wrote about PSD3 last year

Jean-Luc: I can summarize the requirements...if we require with them, we should be able to comply with (all the) regulation.
… most of them are implemented (with current proposals)
… but "proof of liveness" is interesting
… demonstrate "device environment compliance"
… accessibility
… how to provide information to the financial institution during an audit which auth mechanism was used, and whether it complied.
… I have a slide where I evaluate technologies and how they fulfill the requirements

Jean-Luc: As you can see, for passkeys there are requirements not addressed (e.g., device binding)
… whereas for DPC / wallets many requirements are met

Gerhard: Thank you for the useful presentation. There are two that I don't see on the list. One is DORA. The other one is "confirmation of payee"
… could we add that to the list "who is the other party"?

Jean-Luc: I had understood DORA to be more server-side.

smcgruer_[EST]: I am going to ask a controversial question - define "respects privacy"?
… I think it's a contradiction to say that "things must be traceable" and "must respect privacy"

Jean-Luc: I agree you are right to point this out.
… it will require time to figure out a balance between the two

NickTR: "AML 6" is now law. It has bits requiring financial institutions to have information to do forensics.

DavidBenoit: They don't even have to find fraud, merely suspect it.

nickTR: So financial institutions will have to not comply with privacy requirements.

smcgruer_[EST]: how?

smcgruer_[EST]: We already give too much information...but I don't think there are technical solutions that give the implied level of information.

nick_S: It's orthogonal to the business of standardization.
… we don't stop using encryption keys when countries ban them.

nick_S: Instruments can figure out what they need to do

smcgruer_[EST]: I don't think it's orthogonal, but I agree that we should not as a standards body stop pursuing principle-based designs

jean-Luc: We should not be bound to a particular regulatory context, but we should also do our best to make it possible to fulfill there regulation. Banks are looking for workarounds to meet their regulatory needs.
… it's better to do a thoughtful design

Jean-Luc: how can we provide a financial institution with information about authentication modality to allow them to fulfill their audit trail requirements.
… I understand that this is not on the table for passkeys
… is there anything else that we can offer for, eg DPC

SPC MVP

Henna: We should talk about one more issue that we are thinking about for MVP

Jason: The issue arises when a new BBK is created and not to have a double step up
… one idea was to add a BBK allow list
… if no BBK matches, then override the user verification parameter to be discouraged

smcgruer_[EST]: You'll never get a BBK in that situation.

Jason: You'd still get a new BBK

smcgruer_[EST]: Ok.
… but you still may get a double authentication.

smcgruer_[EST]: The question is what are the users of this API comfortable with. Is "less frequent" ok?

JohnB: That doesn't seem completely unreasonable
… it can be dealt with entirely by the browser as part of SPC
… if the browser manages the BBK and if it matches / or not set UV to this or that value
… the underlying WebAuthn is ambivalte

ambivalent
… if you want to put in the SPC API, why not?

smcgruer_[EST]: If you set "discouraged" and the user was verified, is that reported?

<smcgruer_[EST]> JohnB: Yes

IJ: Does this moot the issue about poison BBKs?

smcgruer_[EST]: I think so

Gerhard: If we say discouraged, currently it will always authenticate on Window Hello

JohnB: But that will change depending on integration with windows hello moving forward.
… integration changes based on DLL

Henna's list of things:

* Immediate mediation in 1p context
… with no allow list

* Immediate mediation in 3p context in with no allow list

* BBK support feature detection

* BBK with passkey + BBK with uv = discouraged option

* BBK without passkey

* Structured data so that it works with either SPC or DPC

* Trusted BBK with uv = discouraged to avoid double step-up

Irene: think about prioritization in the context of real-life pilots
… other things can be "things we can continue to think about"

Henna: I've not done a 1-by-1 ranking from my perspective. there were just "the top 5 things"
… I will need more time to rank them individually

Jonathan: If you need to look into pilot, removing UV may not be for MVP
… the first use case would likely be that the BBK is used properly and you don't have issues when you change device.

Gerhard: I think Trusted BBk with uv = discouraged is high priority

Ian: Are there user journeys that would help prioritize?

Henna: That's hard to do. I'd like to take an action to rank them (and ask others too do the same)

Tomasz: I want to bring back issue 287 (re-authentication upon creating new BBK)
… I'd like to consider the solution proposed there in addition to uv = discouraged
… I'd like us to keep open the idea for a solution in that space.

ACTION: Tomasz to add use case of SRC using passkey to get card list, then doing SPC without biometric

ACTION: Henna to create a prioiritzation of these topics

ACTION: Tomasz to create a prioritization of these topics

Passkeys and Agentic AI (from a FIDO perspective)

Fahad: As Nick Steele discussed yesterday, it's possible to authenticate users during some agentic flows.
… when it comes to authentication within agentic commerce, we need to authenticate cardholders and also intent mandates
… we use passkeys for cardholder authentication, but how do we validate the user's intent?
… how can we get to an assertion that has intent data.
… what we are working on in the FIDO Payments WG agentic group is to how to use VCs to communicate user intent
… what I mean by intent is: the instructions given by the user to their agent.
… the intent could range from general to very specific.
… and some transactions may be faster to carry out depending on specificity

Fahad: We need to include intent data in assertions to reduce chargebacks.

gkok: Google did great work trying to break down what this ecosystem could look like.

gkok: The user might have a request, the store might ask for clarification....there's back and forth....would that make the user experience clunky?
… the user in a sense is signing off multiple times
… how do you get "the final request" and assert only that one?

Fahad: The agent will need to distill
… if the condition is met immediately and the agent adds something to a cart, that
… should produce an intent mandate related to the items in the cart.
… the mandate might also include boundaries (e.g, "no more than $100")
… we want to understand what the (JSON) data would look like.

gkok: There are good reasons to capture intent mandate even if user is present.

Fahad: In the end, I the user is not clicking a button...I'm asking the agent..and the agent could still mess up when executing the intent.

Gerhard: I watched the AP2 video.
… Google has 2 categories (user present, user not present)
… I think it was also clever to distinguish the intent mandate from the payment mandate
… perhaps we attest only to the payment mandate (to simplify)
… we could extend SPC to sign the payment mandate.

Fahad: In AP2, there is a chain of mandates. While the data may not be present, there's a hash of data
… in the final payment mandate, it might not have all the disclosures disclosed, but in the future, the issuer can go back to the merchant and verify disclosures

vasilii: The reason why I opened the issue with SPC re: line items is that the SPC experience looks like what we want to confirm intent.

Fahad: We would do it with SPC.

Sami: EMVCo is looking into agentic transactions in the digital identity and payments TF
… our focus there is on EMV technologies and how could they live with agentic
… how do interactions and integrations work?

Sami: Regarding scoping intent...in your thinking, do you have multiple items in your intent?
… e.g., "buy me a cowboy outfit"
… with multiple merchants
… the cowboy mandate could lead to multiple transactions
… there's another point on selective disclosure to the merchant. If my ask was "I'm interested in N and M, but not O shoes"; this is probably not to be disclosed

Fahad: JWT allows us to do some selective disclosures
… we need to define this and are working on that in the payments wg at FIDO

Sami: from EMVCO work, we're not writing any specs at this time; just want to make sure our tech can carry info
… we also ack that the agentic landscape is moving quickly

Fahad: From a principle perspective, 3DS transferring data to the issuer...how to do that?

Sami: My third point is that we need to scope it down a bit (e.g., consumer present/ not present is one axis, another is agent-to-merchant integration, agent-to-merchant-agent integration)

benoit_: When you ask a human "go buy me shows" that's easy if the person knows a lot about you.
… is there a way to prevent agents acting in parallel to double purchase?
… for less specific requests (cowboy outfit), will agents always tend to max out budget?

Fahad: Your second question is implementation specific.

DanP: How is this going to proceed without a framework for dispute management? Historically, that's a network specific issue.
… where should a standards body be playing in that space?
… a framework may not be useful if data is not able to be used in dispute management.

Sami: EMVCo doesn't do dispute management. We just need to make sure that the data doesn't stop somewhere.

<nicktr> +1000

nick_s: It's useful to draw a distinction between payments for agentic commerce and user intent.
… there are plenty of use cases that don't involve payments
… regarding adoption...we'd need to have more players coming to these discussions would be great.

steele: On Thursday we'll show a demo
… for a digital payment credential being used with AP2
… it sounds like we're putting the cart before the horse

steele: We don't have the architecture in place yet for intent mandates. We can do cart mandates
… we've received requests for providing additional context going into user authorization / delegation
… there's room for merchants and payment processors to be provided addl context in some contexts where they can have more context behind the reasoning
… if you wanted to buy something today (with MCP but not AP2) you'd use URLs... client would say "go to this URL and complete this event"
… today you are going to want to push the user back into a flow for high assurance use cases.
… AP2 is early enough that we are still figuring out intent mandate

<Zakim> nicktr, you wanted to remind the audience of the salutary tale of VGIS

NickTR: Visa built a whole spec for line items
… it's a catastrophe passing line items
… trying to build a spec for a customer not present transaction in a context without liability framework will be very very difficult
… let's have an API for doing intent, but lets keep our payment API to the context of payments

ve7jtb: I largely agree with NickTR on the difficulty.
… you can use passkeys to talk to a service to create an intent, sure
… but you don't need SPC for this; it's most likely a direct relationship
… these intents are potentially a privacy nightmare

<smcgruer_[EST]> +1

ve7jtb: on the one hand they are protecting people but on the other you are giving out highly correlatable information that can be used to track you
… so disclosure issues need to be considered very carefully
… you don't want multiple merchants being able to correlate

<raginpirate> Totally agree on the privacy front. A merchant, issuer, etc. likely should not see what conversation I had with my agent unless its a necessity at dispute time, and assuming a dispute framework even exists to use that information.

JohnB: Hard work, important. Just want to make sure it's on the table.

What's the latest in WebAuthn?

Tony: We still haven't published L3 specification as we are awaiting for some horizontal reviews.

Ian: What's in L3 that we should be paying attention to?

timcappali:

- Related origins

NickSteele: You can define up to 5 related origins; they can all use a passkey.

<timcappalli> Conditional Create (Passkey Upgrades), Conditional Get (Autofill UI), Related Origin Requests

NickStelle: Conditional get and create....see Eiji's blog posts on those
… conditional get shows available passkeys in form fields
… Signals API will be where a lot of the L4 stuff goes
… a lot of work on allowing the authenticator and the RP to update each other on the state of credentials on the RP side
… that will help credential managers show the user's display name in an object in the vault, for example.
… if user changes name on site, should be updated in vault as well
… GetClientCapabilities will also be useful
… allows you to see what the current client is able to do (e.g., elements of the Signals API and other types of calls)
… quality of life features for e.g., debugging

<jcayzac> https://featuredetect.passkeys.dev/

Ian: What is the status of L4 requirements? Any where the payments folks may want to weigh in?

timC: In L4:

- Immediate mediation

- Error code work (more about developer ergonomics)
… giving slightly more context in some cases to help e.g., with debugging

- Credential manager trust groups (formerly "RPK")
… credential manager can generate a key and the key be transmitted ... suppose three related devices in proximity; may be enough to reduce need to step up

- some interesting question of "what an account looks like on the web"
… maybe "one API" that might resemble some APIs that are available on platforms.
… you could get privacy benefits

TimC: Some other work is happening on work force authenticators ...

Ian: What's that?

TimC: Employer gives you an authenticator.
… you can tell a user to download an app and sign in with a "workforce authenticator"
… this is a workforce oriented provisioning flow

JohnB: There are authenticators already that create credentials in a back channel
… I think Windows Hello does, and Google does
… so there's some precedent for authenticators doing this
… the question is: what are the rules for doing this in a workforce environment.

timcappalli: What else should we look at?

Ian: What's the latest on transaction confirmation?

timcappali: Issue was closed due to lack of folks turning up to the WG meetings to discuss it, but it's re-opened again
… there is still no expectation that unstructured fields will be displayed

timcappalli: Another topic is to provide a hint to show language (enum) in the authentication dialog
… there are some re-auth scenarios that are not exactly sign-in

timcappalli: Another one coming up - some payment cards may have authenticators in them.

JohnB: It's an NFC authenticator

TimCappalli: There is another L3 use case - "client hints" .. allow you to you nudge the user to start with a security key dialog

(e.g., for high transaction values)

NickSteele: What's missing?

Gerhard: For clarification for this group: there's been a lot of talk about DPC and digital credentials, and WebAuthn
… how do those interrelate.

JohnB: There is something that we're working on for digital credential wallets where passkeys and wallets overlap
… there's a raw signing extension
… when you talk about "signing other things" you can use a derived key from your passkey to sign arbitrary pieces of information
… the passkey credentials are pairwise between the two parties
… you use your passkey to log into your wallet. As part of that, the wallet can create key pairs that are stored securely in the passkey provider
… these can be used for ZKPs etc
… Yubico has created an extension and will be available later in the year.
… it describes how to use an extension to WebAuthn to do personal HSM activities for 3p applications
… so in theory you could have an app int he browser do webauthn and store keys in the authenticator to sign other things than VCs.
… people love signing stuff
… it is an intersection between passkeys and digital payment credentials.
… you use a derived key from your passkey to sign arbitrary objects

Fahad: Will those derived keys carry attestations?

JohnB: The spec will support it

NickTR: Thank you for your energy and passioin
… great to hear all the good ideas and reminder we are working to help users