Web Payment Security IG

Introduction to OWF and GDC

(Daniel Goldscheider introduction on OWF and Global Digital Collaboration (GDC))

DG: OWF is about 2.5 years old, with a goal to bring developers together to create open source code for digital wallets and credentials.
… the second idea was to bring together stakeholders around wallets and credentials, including developers, governments, civil society
… on the first point, we were one of the very few Linux Foundation projects that started without code
… we took a risk of creating a neutral venue. Today we have 32 code projects.
… they vary greatly in number of developers
… goal for the future is to nudge developers to work together
… we have only carrots
… we're going to have a maintainer summit before the end of the year
… my personal take is that it's unlikely you'll have a large number of wallet engines; more likely there will be a few

DG: This project started with a government-led advisory council.
… a year later 12 governments had joined the council
… but we got feedback that the (private sector) Linux Foundation was probably not going to be a place for governments to meet
… we also heard that some governments don't like the word "Advisory" in "Advisory Council"
… so in year two, we started a sister project called the Open Wallet Forum
… it's hosted at ITU
… which is the only specialized tech agency at the UN
… now we have 45 government members on the council
… we also got some feedback that that model did not solve all problems.
… we also wanted to convene SDOs in this activity (including ISO, IETF, FIDO, W3C, EMVCo)
… we needed another structure to convene various SDOs
… there are also different credential issuing orgs that we will want to convene and there are similar issues.
… in year three, our iteration is the Global Digital Collaboration (GDC)
… 50 organizations worked together on GDC2025
… to foster discussion among a variety of types of stakeholders
… so the question is what type of structure can house discussions that touch on a variety of standards, with a wide variety of stakeholders
… topics include, for example, secure key storage
… or biometric authentication on the device (so governments are comfortable relying on them)
… or post-quantum zero-knowledge proofs
… our first event was July 2025. Our next one will be September 2026
… we are likely to have about 100 organizations helping to organize
… we had about 1500 in Geneva this year; expect more next year
… there is not one organization creating the agenda; it's jointly built
… this is an opportunity for us as a group to help build the agenda (starting soon)
… W3C will be one of the organizations that will bring people in
… there is no registration fee, although you need to be invited by the organizing SDOs to attend

We Build Large Scale Pilot for Digital Wallets and Payments

(Gerhard Oosthuizen slides on We Build Consortium)

Gerhard: I wanted to give an overview of We Build. Entersekt is a Member of We Build. What I'm sharing I'm allowed to share.
… Europe led the way on open banking and are aggressively leading the way on digital identity.
… EIDAS2 regulation entered into force in May 2024
… there's an Archicture and Reference Framework (ARF).... but it's evolving,
… goal of 80% of EU present by 2030
… fundamentally: if you are doing SCA under regulation, an EU citizen must have the *choice* to use a wallet
… I can use my banking app, but I will also need to be able to use my EU wallet
… EU merchants may be obliged to accept an EUDI wallet for login by end of 2027
… banks in practice will need to accept this form of authentication for onboarding, opening an account, KYC, logging into bank account, probably for issuing tokens into wallet, and also digital / physical payments
… there were LSPs; a number of them finished with production pilots
… two new consortia pilots were approved, and We Build started in Amsterdam in Sep (following the https://github.com/EWC-consortium)
… Aptitude started in October
… both of these projects started in Oct.

ACTION: Ian to reach out to WeBuild and Aptitude to provide updates to WPSIG

(Daniel to Ian: I know them well; I can help with outreach)

Gerhard: WeBuild has a large number of participating partners, countries, and business registers
… there is both government and industry leadership

[We see a slide on the structure of the consortium]
… the payments domain includes consumer banking, consumer payments, corporate banking, and corporate payments
… the first phase has no been concluded; we have supplied a list of "must have" and "nice to have" use cases

Gerhard: the following is my interpretation about the LSP; my own observations
… user experience is critical (but was clunky in initial trials)
… the bank (ASPSP - Account Servicing Payment Service Provider; broadly "issuer of payment credential") remains liable and should be able to decline
… fraud signals and reporting are critical and must be considered
… some regulatory uncertainty remains between EIDAS and PSD2/3 and PSR
… and then, it's important to keep authentication as a separate step with rich signals (distinct from money movement flow)
… and opportunity to perform SCA
… they are thinking about two main use cases:

1. Account to account (push payments) and card payments
2. Standard SCA replacement by ASPSP; wallet initiated payments (you might start from a wallet) where:
   • Merchant does SCA and says to the bank
   • Merchant starts transaction and bank does SCA
   • From the wallet you kick off the payment

Gerhard: There are three main proposals

• Single payment
• Payment with a credential (e.g., age verification, or citizen verification)
• Recurring payments. (recurring is in the "nice to have list")

smcg: You put "wallet initiated payment" in the same list; how is that different from SCA?

Gerhard: Bank-led SCA...transaction goes over 3DS rails
… the network will initiate an event to the consumer (or their device)
… the consumer will reach into the wallet, where consent will happen
… consent will be passed to the bank
… the bank will verify it
… to ensure payment instruments are valid for this authentication
… the other flow that is one that more sophisticated merchants will want:
… merchant reaches out to the wallet for consent
… merchant submits proof to the issuer
… issuer can look at risk signals and proof (to connect to identity) and decide whether to step up

Gerhard: We will need to work on clarifying these flows moving forward

Arman: Will output be published on GitHub?

Gerhard: Yes.

tomasz: In WeBuild there is a horizontal workstream about standardization
… there is an ARF that is moving a lot
… attestation formats, etc.

SameerT: The notion of merchant initiated is pushing towards iframe-less solution
… we don't yet know what issuers will expect from merchants

tomasz: See the SCA spec (work in progress).

Wallet certification activities at FIDO

Lee: FIDO has been looking at digital credentials for a little while.
… we started looking at digital credentials as a proof of possession for passkeys
… we also started looking at how to present digital credentials cross-device
… passkeys rely on CTAP for cross-device, and it's the same problem for digital credentials.
… a bunch of work happened to improve CTAP for digital credentials.
… shipping on Android, iOS. Chrome and Safari, support it (see more on Digital Credentials API ecosytem support)
… you can make a request for a credential and present it over hybrid

Lee: and it became clear we needed a new work stream within FIDO to look at blockers to adoption to digital credentials
… and where FIDO might be uniquely positioned to help
… based on our assessment we concluded that there's a big gap about wallet certification.
… we also need a baseline FIDO profile specification
… each nation is putting together its own certification program either formally (as in Europe) or informally (e.g., in the US)
… RPs want to know security properties of the wallets
… instead of every nation state creating its own certification program, we wanted to create one...FIDO has approved work to create a wallet certification program
… we are working with major credential issuers (governments) to use the FIDO baseline profile as the basis of their certification scheme.
… it's suppose to be a common baseline that can be globally applicable, and different govs can add on what they want
… do the FIDO certification is likely to get you "90% of the way there"
… will include protocol conformance testing, credential format support, encryption and algos support, transaction data support
… will include dynamic linking (relevant to this group)
… secure environment and key management
… biometric and holder binding
… ux requirements
… business processes
… around Q1 we'll have more to share about what these requirements will be. Signs suggest people are very interested in this

Gerhard: One of the challenges on the payments side with FIDO is a sometime misalignment (e.g., device binding)
… is the intent here to more closely monitor government requirements and "keep to it"?
… what is the commitment from FIDO to stick closer to regulatory requirements (to increase adoption)

Lee: Yes, that's a strong focus here.
… the EU is the acid test here.
… passkeys is a different thing (consumer login)

Lee: Are there any payment requirements?
… if so, through the payments group at FIDO?

Ian: Could some conversations start in WPSIG?

Henna: Yes.

New in Digital Credentials API

timcappalli: We are working through issues. One is whether there is a registry (Editor's Note: See outcome of TPAC discussion about the registry.). The Digital Credentials API specification is implemented in webkit and chromium.
… hoping to go to Candidate Rec soon.
… we are seeing good ecosystem support (presentation)
… next priority is issuance (save to wallet)
… it's useful to see where DC API plays in the ecosystem.
… DC API analogous to WebAuthn (browser API)
… agnostic to protocols today; most usage today is OpenID4VP
… and ISO for Apple Platforms
… CTAP 2.2 is how we bridge devices. See more on layers.

Ian: What's the registry discussion?

timcappalli: Registries at W3C are interesting. A goal is to avoid identifier collisions in protocols.
… but registries have another meaning in other contexts like "you have to be in the list to be usable"
… when you have a normative registry, what would W3C's role be?
… there are a lot of parties involved.
… tomorrow we will consider 4 or 5 options on how to make progress.
… this is a big blocker for us.

Ian: Any most relevant for payments?

timcappalli: Registry not likely super relevant for that

stephen_mcgruer: If a spec is in CR but one of the major engines only allows a narrow subset of underlying protocols or capabilities, we will have recreated an issue we encountered in PR API

Gerhard: In the digital credential discussions there's a piece that sits outside of that: there are certain "trusted parties"

Gerhard: As implementers, how should we think about verifying trust relationships

Lee: At the DC API level, it doesn't matter much. DC API just a pipe.
… DC API punts the fancy logic to a higher level protocol (OpenID4VP, ISO today are the big two). They basically do the same thing; a lot of the logic lives there.
… the request signing part happens at this protocol layer.
… the wallet is then required to verify signatures.
… the OS doesn't do anything; just passes through to the wallet who does the check

Gerhard: Suppose I'm naive and I want to open a bank account. I might see a random wallet pop up .... will the consumer have to know which wallets will work?

Lee: OpenID4VP has a query language that allows the request say what they want (e.g., DL, in which format, form which issuers)
… the user only sees credentials that match the query
… the query language is very expressive

timcappalli: Most of the logic is in the credential manager (wallet or app)
… including holder consent, holder verification presentation and issuance protocols, key management

Lee: We talk about priority of wallet display. Likely based on last viewed

PLH: What I found interesting on Tuesday was that DC API does not have bidirectional communication
… that is why logic pushed to a query language

timcappalli: The developer knows very little when calling the API

fahad: We heard from Nick_S an interest in using PR API to connect to DC API

Gerhard: There are all sorts of cross-border use cases in the WeBuild Consortium discussion

FIDO Payments WG introduction

Henna: We started the FIDO Payments WG out of a general need to see what payment authentication options can be used (e.g., passkeys, SPC, passkeys with high assurance credentials)
… we didn't have a payment authentication forum
… we want to document what we need globally (including regulated markets) and find the optimal solutions
… we are currently talking about digital payment credentials (DPCs) and exploring how that could work
… we are trying to figure out: if used in a regulated market, how would it work?
… what needs to happen in the underlying protocols?
… it's mostly been Q&A about how it works and what is need for payment authentication use cases
… we are now reviewing a DPC schema. EMVCo is holding the pen on this, specifically for card payments.
… but the credential will not be just for cards (though we are starting there)

Henna: We are trying to figure out what needs to happen at OpenID, at ISO, and in other groups
… outside of DPCs, this group would eventually discuss passkey implementations, SPC implementations, etc. We hope there will be case studies and deployment reports

Henna: Later Fahad will talk about our subgroup focused on agentic payments
… DPCs is a topic for agentic as well.
… the agentic group started a month ago
… this group will also be looking at UX (how to present DPCs to wallet, presented to user, etc.)
… will also provide input on certification
… if there is specific input on what wallets need to do, the FIDO payments WG can provide that feedback
… we need to find a way to bring some of the outcomes of DPC to the WPWG to connect to PR API
… the way I see this working is that we bring DPC into PR API via a payment method, with data model from EMVCo work.

tomasz: A DPC schema would be for the credential itself (starting with card payments)
… the second part of the DPC schema will be transactional data that goes into the wallet to present in the payment sheet. This is close to what PR API could handle
… support for payments through DC API would require the wallet to behave slightly differently ... what we are looking for is the presentation of the transaction data (to consent and authenticate)

Gerhard: There are two proposals on the table -- separating things into smaller pieces (my identity at the bank, my consent, a DPC credential)
… the alternative approach is to combine some of these pieces
… has the FIDO group ascertained that the 3-layer separation should be the final approach?

Henna: We started DPC conversation as an authentication construct but it could become (also) an initiation construct
… we are talking the SCA aspect first
… this is meant for payment authentication only

Gerhard: the discussion we need to have is about relationship among different types of credentials

timcappalli: There's a reasonable world where you can interact with the Payment Request API for simple use case and the DC API for more complex use cases

stephen_mcgruer: It's important to distinguish credential from schema
… I was going to say DC API for the simple request and PR API for complex (for more interaction)

Digital identity and Payments TF at EMVCo

Sami: I chair this, our latest EMVCo group (created in May 2025). We are chartered to collaborate with industry groups, including around Europen Digital Wallet initiatives, FIDO, W3C, OpenID Foundation, OWF, and others (e.g., ISO)
… we will provide advisory insights within EMVCo on e-commerce payments use cases, authentication, etc.
… there will be presentation in the TF from our different groups (including 3DS, SRC, Token, EU, BoM, SWG). Activities include:

Arman: We'll bring that to WPSIG for discussion at some point
… it'll be a "Framework" document

Sami: EMVCo also looking at Agentic and getting an understanding about what agentic topics are touching our agenda.
… e.g., data handling, interactions models, transaction flows
… in this area we need to understand the scope of our work; although some things will happen outside our domain. Our biggest concern is whether we have enough placeholders for data for these new use cases (agentic)

Henna: We've had feedback on getting contributions for non-card schemas.
… we think FIDO could hold the bigger structure; card schema from EMVCo

Tomasz: We see this as a collection of schemas; not a single "one true schema."

How it all fits together

Henna: There was a point made on Tuesday about how Payment Request API could work with DPC.
… do we need to do that? Should we do that?
… where should work happen?

<nicktr> I would argue card payments are a subset of payments. We can debate the ontology but it would be a mistake in my opinion to derive the payments schema from one special case subset

Gerhard: One decision we need to make is in terms of user consent and regulatory approval.
… whether passkeys is an interim step, or whether passkeys and DPCs will co-exist
… I think it's premature to say passkeys will be the only things
… I expect a world of 4 ways to authenticate:

• Passkeys
• DPCs
• Existing authentication mechanisms (e.g., out of band)
• Frictionless (no challenge)

Gerhard: The last being the demand of most of the world.
… it would be great to have a world where the OS helps achieve a good UX. It would be great for PR API and SPC to help facilitate

tomasz: I'm not convinced that OS or UA is the best place to make the decision. I would favor that the requestor be able to specify what they need.
… whether to use PR API -- I think there is a nice fit
… there is an important bit of data that is relevant across credential schema...and that's transaction data..and PR API already handles that well

<SameerT> +1 to requestor being able to define it

rbyers: Two reasons why wrapping PR API around DCI. One reason is that you can call PR API within 3DS already.
… we don't have an attribute that says "ok to do DPC but only for payments use cases"
… so this would allow use of iframes to give permissions for payments, and DC API could be used within PR API

<tomasz> +1

rbyers: We are exploring a lot mixed flows; we've talked about NASCAR screen problem.

<Gerhard> If requestor is merchant, how would they know what's possible / trusted by the SCA?

rbyers: Digital credentials is trying to reduce NASCAR effects

(Ian: Just as payment request sought to do, but failed for a variety of reasons including different parties not wanting to cede the user experience to the browser or other parties.)

rbyers: I think PR API might help get to market sooner, as well. And it would be good for the WPWG to be working on that. There are two options for the allow attribute today ("payment is one)
… we can support DPCs within PR API

Henna: We want to support DC APIs in 3DS.

rbyers: Everywhere?

Henna: We need to support it for the identity + payment use case

rbyers: That requires merchant work anyway

tomasz: Another scenario is to support credentials in mobile applications

Henna: As we figure out how to use PR API for this...the model we are testing in We Build is to show that DC API can get a DPC. We are not talking about PR API in the We Build setup?
… do we need to do so?

Henna: What do we lose by bringing that as an option?

Lee: WeBuild is focused on an EUDI wallet
… if you introduce other concepts, you need to change the ARFs

stephen_mcgruer: But we are talking about a front end

Lee: Don't think we need to do this in We Build setup

stephen_mcgruer: But developer ergonomics matter

tomasz: 3DS is in scope but not limited to 3DS. EUDI wallet is not just about DC API.

stephen_mcgruer: I see benefit through rick's comments

Ian: What does frictionless mean exactly? Is having the user push a confirm button frictionless?

Gerhard: Anything that the merchant doesn't control is friction.

<dom> [rather than friction-less, this is about who controls the amount of friction from what I understand]

DP: You've done a good job of calling out frictionless. A goal I've heard from issuers and merchants is to kill the iframe.

stephen_mcgruer: What's the main problem? Reliability or debuggability?

gkok: All of the above.
… but reliability is primordial

Gerhard: Predictability

<jcayzac> +1 for allowing but decoupling

Ian: Could define a payment method in WPWG (e.g., identifier 'dpc') and webifiy the data models from FIDO and EMVCo

stephen_mcgruer: the WPWG also has people in it that should be thinking about the DPC schemas that come out

rbyers: And writing Web platform tests.

Gerhard: I've spoken to a number of people who have said "if the merchant initiates the DPC and goes through the flow, it will be awesome. Regarding the issuer flow, it will be "eh".'
… from a merchant perspective, they want success.
… we are going to be bootstrapping an ecosystem ... for an international merchant...the challenge with a merchant-initiated flow is that ability that it "could be frictionless" but since I am going through this flow there will always be friction
… whereas...if we could just ask the bank do they want friction
… in most markets they don't...and they know this better than the merchant
… if the merchant says "issuer, can I do this without a challenge" and the issuer says "you must do with a challenge" it will lead to more success.
… the argument that a merchant should "just try and hope" will be low chance of success, unless the merchant asks the issuer first

sami: And the issuer needs to know how to authenticate

Gerhard: So the SPC integration into 3DS is an important integration
… that's where SPC, in the cross-domain world has a role to play with the DPC API
… SPC could come back, and give DPC to issuer

stephen_mcgruer: I think we should have made the "double areq flow" more general than just being for SPC

sami: +1 to generalizing the "double areq flow" in a future 3DS version

DanielG: You want to know "canMakePayment?" for wallet.

tomasz: In DC API today we can check only a couple of things...for payments, it would be good to do "canMakePayment?"

stephen_mcgruer: But this might be better because less specific than PR API

Fahad: When we talk about bringing up PR API at We Build....it becomes important if other platforms are talking about other approaches to doing things

(Discussion of whether Nick_S was thinking about more complex back and forth for PR API)

Lee: I agree that the back and forth nature of PR is where a benefit would be in doing PR API.

(Discussion of multi-shot over hybrid)

<nicktr> Payment request is not a commerce API

Lee: However we implement it, there are use cases (e.g., loyalty cards)

Henna: I think we should still do a pros and cons exercise on the relationship between the PR API and DPC within the WPWG.

ACTION: Ian to talk to Nick_S to have him articulate the use cases he has in mind for connecting PR API to DPC

ACTION: Henna and Stephen to initiate the exercise of gathering pros and cons about connecting PR API to DPCs to gather input from the participants.

Agentic AI landscape

(Dan Pelegero slides on Agentic Payments)

DanP: Jean-Luc di Manno helped put together slides; many thanks.

DanP: merchants want AI identification
… depending on merchant site, AI generated traffic is now between .5% and 15% of all traffic
… this is screwing up fraud models, and informing how the web site is presenting due to two types of "users"

(DanP summarizes regulatory context and constraints)

DanP: Consent logs will be legal artifacts, not just UX

<dom> i|[slide 60]|<dom> Related issues: w3c/webrtc-encoded-transform#214 w3c/webrtc-encoded-transform#283 w3c/webrtc-encoded-transform#259

DanP: in india, there is a "reserve pay" block. That block doesn't necessarily mean you will automatically have payment be deducted; but user still needs to give consent
… this needs to be auditable under NPCI
… agent delegation signature will be legal artifact

Protocol example 1: Agentic Commerce Protocol (ACP)
… there's advantages where everything happening in the closed ecosystem means "know your agent" is already a trusted channel.
… so that handles discoverability (even though there are commercial implications)

Protocol example 2: AP2
… the mandates (intent, cart, and payment)
… are chained together. All three mandates are verifiable digital credentials.
… question is: if agent hallucinates, where does liability sit?
… the protocol acknowledges that there's a gap
… there's a responsibility gap here.
… with an agent in the flow, and because it's not technically fraud, what is it?

Example 3: Merchant-controlled open agentic commerce API
… this model is trying to solve the problem of product discoverability
… if the agent can interact with a well-known URL, the agent can go straight to it.
… the agent has a means of reading a product catalog without messing with consumer traffic.

DanP: If each MCP produces different results the same variables, how can we derive predictable outcomes?
… gaps exist here, too

(DanP has a slide on where there are gaps)
… consistent product semantics
… reduce screen-scraping practices
… shifting disputes from "i didn't buy that" to "your agent exceeded my mandate"
… payment schemes need to update arbitration hierarchies to account for the agentic use case with hallucination
… more predictability from MCP execution
… good regulatory contexts

(Slide on potential roles for W3C and other SDOs)

DanP: Three big questions for discussion today:

- should an agentic purchase on the web require human consent?

- what should be the role of the browser?

- what journeys would we (first) standardize?

DanP: Not looking for an answer here on liability

stephen_mcgruer: We should not over-index on hallucination being the only mismatch here. We are in a probabilistic world.

Fahad: On the question of "is it fraud"? there are some specific cases.

AP2 Demo

(Nick Steele slides on AP2)

NickSteele: A goal of AP2 is to make layer for payments to be more transparent and interoperable
… this can be used with MCP and other transport layers
… gives clearer demarcations where liability (might) lie
… the user must provide intent and authorization
… there are six parties involved:

- Shopping agent talks to merchant endpoint or agent

(merchant using MCP)

- Payment processor for merchant

- bank /issuer

- credential provider

- user

NickSteele: The flow we will demo is the "Real time purchasing" flow
… agent begins a task for the user and creates an intent mandate
… the agent communicates with the merchant and eventually a checkout cart is built
… once the cart is finalized by the merchant, agent, and user, the agent makes a cart mandate the reflects the final purchase intent to the user
… that goes to the user for verification

NickSteele: But there is also a future/delegated purchasing use case (in development)

<nicktr> This is a really excellent European Parliament study into liability in a world of autonomous AI

<nicktr> And this is another well-argued discussion with a more US-centred view

<nicktr> And we all need to become familiar with the "juridical person"

(Slide on "things that are grey")

NickSteele: Mandates should be short-lived

<Sharanya> What are the entities which are authorized as validate credential providers?

Gehard: Does cart include more terms and conditions? Or is that in the payment mandate?

NickSteele: We can have all the info in the cart. When the credential holder signs it, we can store the final transaction amount in their wallet.

Gerhard: In some cases things are added later (e.g., tip) and that won't be in the cart.

stephen_mcgruer: Is the cart mandate structured?

NickSteele: Yes

Sami: One intent may lead to multiple purchases (the "cowboy outfit" use case)

DanP: India is clear on this

NickSteele: Recurrence would be a next step. Regarding the cowboy outfit use case (where an intent mandate leads to cart mandates from multiple merchants), that could be structured in the cart mandate.

DanielWyckoff: Beyond the mandates...how would agents share discovery about available payment methods:

NickSteele: TBD

NickSteele: This is meant to meant to work with A2A, MCP, embedded and proprietary flows
… could be extended as well

see also ACP, x402, ChatGTP Apps and Google MCP Toolbox
… interesting early developments

[Demo shows cart mandate in a secure modal window]
… it's presented through the Digital Credentials API
… it's controlled by the OS and the Wallet at the same time
… in this case, the 1password wallet
… we're going to sign over this with the DPC given a biometric prompt
… agent sends result to the merchant and you have your confirmation.

stephen_mcgruer: So there's no deterministic receipt in that demo?

Lee: No

Rene: The receipt is the card mandate.

stephen_mcgruer: Do you have a receipt from the *result*?

Rene: Yes, it's possible, but not part of this demo

Agent Commerce Protocol (ACP) Demo

Cip Blujdea slides on ACP

Cip: 700+ AI agent startups launched on Stripe in 2024
… consumers are embracing LLMs ... younger generations keen to use them for everything

(We see a demo for a cowboy outfit purchase)
… we see some chatGPT results (web search results)
… you can interact and specify more specific
… e.g., "I like the hat but want red hat with more bling that's leather"
… the chatGPT interface lets you select size, for example.
… there is a "buy now" option to execute a purchase within the ChatGPT interface.
… the merchant does not need to use Stripe as the acquirer
… that's the advantage of having this be a protocol
… you can see that it has prefilled my card (based on what I have used to pay for my chatGTP subscription)
… same with shipping address, though I can change both card and shipping address.
… we see the UX to change payment methods (card form, apple pay, google pay, etc.)

stephen_mcgruer: We just saw a beautiful payment handler experience

Cip: One option is with "Link" the Stripe wallet

(We see a flow diagram)

Cip: Agent creates a "shared payment token" with the business, and the business goes to their acquirer (e.g., Stripe, Adyen, etc.). Some of the ACP principles:

• to be interoperable
• to allow merchants to have one integration
• for agents to get a revenue share and be more useful to their users
• processor agnostic
• payment method agnostic (ideally)

<Sharanya> How do we satisfy the mandates with credentials in Human Not Present usecases?

Cip: It's also important that the shared payment token be scope to merchant, date, amount...and also be revokable. It's important to have a distinction between discovery process (where hallucination might happen) and then the cart mandate where the user can see what they are going to purchase.
… note that raw card data is not shared with merchant
… only the token is shared (with is tightly scoped to this transaction)

Sami: When consumer enters card, where does that go?

Cip: Depends on the agent integration with Stripe (e.g., ChatGPT). They could have it if they are PCI-compliant.
… but typically the agent doesn't want to touch the card number, so they rely on Stripe to do it for them
… the payment sheet is controlled by Stripe

gkok: So Esty in this example won't see user credential. Will it be a prepaid card?

Cip: there will be different approaches depending on situation

gkok: As a merchant, I'm not controlling whose coming in.

Cip: the merchant has to sign off on this (a 1-time integration)

gkok: Ok, so the merchant has to agree.

NickTR: Marketplaces are super problematic

DanP: With the shared payment token, who's coding into whom?

<nicktr> I see KYC obligations being very problematic in this model.

Cip: It's early right now. The first implementation we launched is bounded in what we can do (e.g., US-only for now; limited number of agents and merchants)
… we don't have all the answers yet.

DanP: Is buy-now-pay-later part of this?

Cip: Can't speak to that.

Sharanya: How does this work when user not present?

Cip: We don't support consumer-not-present yet. These tokens do have an expiration date, so they will be usable in those situations.
… you will consent in advance
… the agent will complete the purchase at a later time

<vasilii> Rene, can you share bottom sheet on the screen again, want to ask the question about it

(Vasilli has a question about the AP2 sheet)

Vasilli: Who controls that sheet?

Rene: In this case we are going through the DC API
… this sheet specifically is a platform-level sheet
… the contents are populated by the wallet
… that enables us to make it non-repudiable
… this is all outside the agent's context

vasilli: So the cart info is in the DC API call?

tomasz: The wallet doesn't have any UI in this demo.

Lee: The wallet does get to show its consent UX

<vasilii> Thanks Rene!

Gerhard: The flow after the red hat was purchased and shipped
… is that a normal flow?

Cip: Merchant owns the relationship.
… merchant gets some PII in the transaction

Rene: DC API can have an encrypted response; that's an advantage
… so PII is only seen by the merchant.

Discussion about Agentic AI and payments

stephen_mcgruer: We are interested to understand what the web platform needs to provide
… I look at protocols and don't see super necessity for the web to ship other than DC API

Lee: If you are in chatGPT in a site, you are staying in the chat context.

NickSteele: When it comes to authenticating and using pages, it would be interesting to give agent access to specific tool.
… the site could say in the page "visit the server and this is the tool and yes you can do it" to push into an MCP flow and get off the page
… we don't want the agent acting as the user in the page

Sami: Question based on Cip's demo -- what is provided to the user? Why should they trust the transaction?

Cip: The model that we are working towards is "agentic tokens"
… they are bound for 1-time usage.
… these are network tokens
… that would reuse existing framework

Sami: Is there any information about the intent that is shared?

Fahad: It depends on the protocol.
… ACP depends on merchant integration
… and when it comes to the payment, there's a dedicated payment step
… a shared payment token becomes part of a delegated flow.
… but there could be a model where one could deliver payloads directly to the merchant
… none of this is standardized
… merchant could provide an endpoint or could point to a PSP endpoint

Fahad: When you talk about intent, it's the same thing. You need a communications protocol to transfer the intent. It's not standardized how the mandates are exchanged

Gkok: In regulated markets, how would this model work?
… who is the end merchant (E.g., Etsy). Who will process the payment? Who is the 3DS requestor at this point?
… there are identity mismatches

Cip: We are not spending a lot of time on that yet, but will in early 2026

<SameerT> In regulated markets, the flow becomes even more complicated when exemptions come into picture

gkok: When you go to regulated market they require dynamic linking and you need to be precise about the merchant and the amount of
… the transaction

Fahad: AP2, the end result is the mandate with all the merchant details.
… all that info is in the mandate

gkok: Should I think of this like the "travel" model where someone is coming in but the transaction itself might be happening on behalf of another party

Fahad: Let's take that example (travel). I book a trip to Tokyo and there's a flight and hotel. The basic intent will capture that. Two mandates can be used separately (one for each merchant).

Cip: 3DS construct can be used to authenticate a payment and then reuse cryptogram and pass on to different merchants, based on the initial authentication.

stephen_mcgruer: Agents are going to browse the web as humans. Question for the group -- when an agent doesn't "get off the web". Do we as a group need to do anything to help protect, or empower, etc etc merchants and users?

Lee: I think you have two modes (1) browserless; that has problems but they should be solvable (2) browser use cases. But today most merchants go out of their way to block the browser activation flows.
… do we see those use cases getting unblocked?
… my guess is that it won't get unblocked
… how much energy do we put into these flows if they are going to die

Lee: What about tools to block?
… we see that the browserless cases will be the place for most of our energy

<Zakim> Gerhard, you wanted to talk about the MCP auth flow (how will that be triggered for the browser) and to talk about payment handler applicability

Gerhard: Unless there's a different model, they're just going to block it.
… we haven't spoken yet about fraud. A lot of banks have fraud systems built on the authorization layer. If I see 15 transactions come in in the span of 2 seconds, the bank will decline.
… I don't know that 3RI is the answer. We will want it to appear as "one purchase"; and the purchaser will be ChatGPT as a company
… ChatGPT would then have a relationship with the merchants
… we should focus on that model...

Gerhard: There is an opportunity for payment handlers here as mediation layers
… we have this payment handler construct which is in a 1p context.
… could facilitate handover

stephen_mcgruer: It depends where you are triggering from. There was no Web in the demo.
… if you are on ChatGPT.com you're not really on the web.

Gerhard: If more and more sites are putting out agents as part of their sites....suppose wedding gift store

<SameerT> 3RI Split Payment feature today supports split payment, split shipment

Gerhard: would the facilitation between the merchant and an aggregator of purchases be do-able in a payment handler?

NickSteele: Realistic use case is agent in a web view, for example on a site

Lee: We have a demo where you can add to cart, but when you view cart it's just ordinary checkout. The purchase flow is ordinary.
… for that we don't need to do anything special.
… if the user agent is not a typical browser, and the basket has been created agentically, that's where it becomes interesting.

David_Benoit: Refunds are going to be messy

Gerhard: I agree.

David_Benoit: What if we end up in a situation where there are many agents vying for the same products. Are we going to be able to tip agents to be "first in line"?

Fahad: Might be a case for micropayments. In general I agree that we want to drive to agentic interface, but merchants may wish to continue to use traditional interfaces
… I think there will continue to be interest in using existing resources.

gkok: Regarding "what we can actually do", it may be necessary to identify that an agent is coming in through "the normal path"
… that's not necessarily a payments thing

stephen_mcgruer: People are starting to work on this

NickSteele: Some discussions did not go well at IETF last week on this.

stephen_mcgruer: There are other conversations about representing the web to agents. Is it ARIA? Something else?

(Ian: I am hearing a first point for us to have sustained discussion: the question of agent identity on the Web.)

Lee: this is the crux of the debate...
… IIW asked this question
… there are different views like: (1) list of trusted agents [but that's not realistic] (2)
… AP2's reason to exist is to enable dispute resolution without needing the agent to worry about it.
… ACP similarly goes to a trusted ChatGPT UX. You don't care about the agentic part.
… if you think along those lines you don't need agentic identification

gkok: but we need rules of engagement.

NickSteele: If people are going to do this anyway, we need to make it possible for them to do it safely
… before WebBotAuth was vaporized last week, the question was "how do we identify them"?
… 70% of Web traffic is bots.
… is this anything more than workload?

vasilii: Regarding agent identity -- what's important to identify is whether the agent is authorized to act on my behalf.

NickSteele: "What have I authorized the agent to do on my behalf" that's the key
… everything the agent does before that doesn't matter.

vasilii: Agree that it only makes sense when human is in the loop

Lee: Scraping is a bit different. There are two types of agents. E.g., hosting flows. There's also when agents train
… that's different. there's a business problem.
… if the agents can identify themselves when doing training, that's a different problem space.

Vasilli: Your agent will look through a catalog. As a business owner, I still want to know who is looking at my site, in a privacy preserving manner.

NickSteele: Possible to bind at a particular moment.

(Ian: I am hearing a second point for potentially sustained discussion: How to understand as a merchant who is browsing my site?)

vasilii: Yes, like google analytics but for agents. We care about people at the end of the day, but agent identity is a proxy for that

NickSteele: I'm also interested in context where agent is acting on behalf of an organization (not a user)
… when a user goes to do something autonomously with that agent, that agent is acting as a service within a boundary of the enterprise. But it's operating with privileges granted by the user.

NickTR: LLMs that are acting as agents are "just new browsers" displaying info in a new way
… In the context of transactions / payments, there is no doubt that where there is genuine autonomy, then the agents must be identifiable due to liability related to decision making
… there will be a whole new class of legal identities

NickTR: We'll need to be able to identify whether a decision was made fully on behalf of a user.

Lee: I agree with that point. When you have user not present flows, what you sign is fuzzy intent mandates

NickTR: We have the concept in payments of trusted display in the world of physical terminals. Booleans for authentication in AI no longer work.

Lee: That entity is tricky. It's probably not the agent or the merchant. We call this "intent resolution" where you compare precise thing to fuzzy things, and some decision is taken.
… one argument is that the merchant should make the decision.
… you could also make the case that the merchant should not get the fuzzy intents (e.g., that express "max") so you might need trusted parties.

NickTR: Right -- who has the user's best interests at heart?

NickTR: If you are not paying for the agent, it's not on your side.

Gerhard: Should we have a Payment Handler type for AP2?
… it would take in (as input) a cart mandate
… and it returns a payment mandate.
… it takes in what the client has agreed to and returns the customer's consent

stephen_mcgruer: What's the user journey?

Gerhard: This could be a vehicle to mediate digital credentials....mapping an AP2 format to a digital credential format

gkok: So you'd sign the payment mandate (e.g., via SPC)?

Gerhard: AP2 defines a handoff between a cart and a handoff. What if we could be part of the handoff to make the journey present.

gkok: When you say "we should be thinking about this" are we restricted to building things limited to the web?
… ideally we would want to have consistency across platforms.

Nishant: A lot of browsing and shopping and getting prices is not done anonymously (to see discounts, to user points, etc.)
… that doesn't seem to be accounted for in this conversation.
… so the merchant does care that it's agent with the user's credentials.

Vasilli: Another use case - MCP monetization is another topic. How can someone in control of an agent get payment for services provided by MCP

DanP: I am hearing "consent should be required" but it's currently happening that way.

Ian: +1 to use cases

NickSteele: If an agentic client were to visit a page for payment, what information would you want from it. What additional data would you need to trust that payment in that client?
… we can factor that into AP2

(Ian: I am hearing a third point: Ensuring data shared in a privacy protecting way to help payment processors trust these payments

Lee: DPCs have the advantage of having wallet attestations (as opposed to passkeys and SPC)
… we did AP2 with DPCs for this reason

vasilii: I want to make a point about frictionless flows. For both agentic and non-agentic payments is there a way to use BBKs ?

David: Is my mandate bypassing SCA?

Lee: The mandate can be signed in a way to make it SCA-compatible
… so you know it's me, but not necessarily my commitment to buy something

<nicktr> Headline in the New York Times today: "Who Pays When AI is Wrong?" [gift article]

<stephen_mcgruer> [My second point that I forgot before was: on the agentic browsing usecase - sorry Nick. It is worthwhile in my opinion for this group to consider: If an agent acting on behalf of a user in a pure HTML/CSS/JS use-case with the users cookie jar turns up at a merchant site and is going to buy something. Do we have thoughts on if we want to shape that purchase to use any particular mechanism (maybe including jumping to AP2... so maybe

<stephen_mcgruer> this is the same thing as Nick wants...)]

<stephen_mcgruer> Also, you know, if somehow you haven't seen it - https://www.theguardian.com/technology/2025/nov/05/amazon-perplexity-ai-lawsuit

Joint meeting with Antifraud CG

Philipp: I'm a member of the Anti-Fraud CG; work on Chrome. We are focusing here on fraud and payments, but there are more topics in the CG. Some concerns we have in this space:

• Should the UA snitch on the user?
• False positives are inevitable
• Browser choice and evasion; fraudsters will move to least strong UA and so not good to raise the bar unilaterally
• Misuse of payment-specific signals; people may use data maliciously

Philipp: Also some practical matters:

• Cross-site identifiers are not great; they enable tracking
• Same thing with non-resettable identifiers (e.g., bought a used device)
• Proof of browser identity ... Web Environment Integrity proposal ... we learned a lot of lessons; once you introduce "proof of this browser" or "proof of hardware" you break the one web expectation

Philipp: There's also the mobile app gap
… why? device attestation for single-platform apps is less controversial?
… how do we enable end-to-end commerce on the open web?

Philipp: Would these things be useful?

- Opt-in paths. What is the carrot for benign users and merchants?
… what prevents merchants from requiring opt-in path?

Ian: Basically, if a signal is available, it will be abused.

stephen_mcgruer: Given that the landscape of anti-fraud on the web has changed (wrt 3p cookies) does that change the discussion?

Philipp: Cookies have benefits, but can be lifted from one venue to another.

Martin: The fact that there's a large portion of the population that don't have those cookies...I imagine companies want to do with those people as well (5% of chrome users turn off cookies)

Eric: People were relieved when Chrome decided to decided to no longer pursue IP protection

Vinod: We need to keep in mind the different kinds of threat actors.

Vasilli: Can you say a bit more about the fraud scenarios connected to the browser that you look at?
… one scenario we are interested in is ecommerce fraud.

PhlippP: Some of the work areas I'm familiar with include identity; bulk account creation; account takeover

Sam: If a user is putting 1000 cards in one after the other, there aren't many uses to that, but it's difficult to find solutions for that there are non-discriminatory

<SameerT> +1 to it being challenging

stephen_mcgruer: I think there is a lot of potential here for people who know about fraud and privacy protection to chat with people who know about payment threat models. Historically a big challenge in my eyes has been understanding how to APPLY the various clever privacy-preserving APIs that came out of e.g. Privacy Sandbox to payment challenges.

gkok: I want to prevent fraud, so I'm frustrated when we lose tools that would help users; but I understand the point of view.

Sameer: We'd of course like to get as much data as possible. Device fingerprinting considered bad. If a merchant app initiates a transaction v. merchant web site, the app has a lot more information. A few years back we talked about the browser detecting a payment scenario and increasing signals in that moment

Sam: There's been discussion about bringing people to a more trusted forum to be able to share threat scenarios.

gkok: As a merchant that relies on the web to takes payments, it's tough.

David: In practice there are actors in 3p context to fingerprint my browser and track my activity. What are we preventing against?

stephen_mcgruer: Wouldn't fraud also be gone?

gkok: Some bad traffic looks like new users; so we don't prevent fraud completely.

<stephen_mcgruer> Ian: I recall a conversation last year where we said maybe its useful to add a small bit of entropy that might still be very valuable

<stephen_mcgruer> ... Such as "this browser is not where it usually is"

<AramZS> (^ specifically about geolocation)

Sam: If you are relying on the OS you rely on device attestation. There might be another way to get it, but it's not clear to implement it that satisfies guardrails. I could see the value of privacy protecting geo info for , e.g., stolen laptop scenario. Regarding privacy and fraud; we want to come up with solutions that are more robust than "losing all your privacy"

Eric: A lot of the privacy sandbox was about removing signals and removing some entropy. We got some feedback that some features were helpful in aggregate.
… we are really focused on allowing people to share their own signals across context; but we want to find ways to add signal...but need to figure out what would be useful.

stephen_mcgruer: You said you got good feedback...which community did you hear from?

Eric: Some antifraud vendors in the ad fraud ecosystem.
… they could use signals in aggregate

Sam: Regarding the mobile app gap...we have all these thoughts and ideals about how to protect users on the web. But if we can't keep users on the web....
… is this a problem for you all?
… are there other solutions people want to volunteer?

Matt (sysrqb): I want to go back to the argument that the use of APIs is a misuse of the Web platform itself. Preventing fraud is an important objectives, but understanding how the signals are being used is important.

<AramZS> Will add: yes this mobile app gap question is a problem because it pushes people from our website into our app where the transactions are easier to execute through an app-authenticated flow.

Sam: I think one major thing I took away was that signals were about going from one site to another. We should not be relying on the inaccessibility of hardware.
… there are a variety of equity ideas if the mitigation is an expensive device.

rbyers: On the question of how to know something is in a payment context...we have SPC.

stephen_mcgruer: I would argue credit card autofill as well

rbyers: More signals could be available in the SPC context. But I don't think PH does it. But DC API will be when a request is for payment credential. If you are buying something an providing your shipping address, your privacy concern is different than when you're not providing your address.

AramZS: If it would be helpful, knowing that a page is in a payment context could be useful.
… the problem we have not is like captchas. That's not a good user experience. I'd love to have an option other than lots of captchas.

philipp: David mentioned that fingerprinting is happening already. The browser could do a lot of cool things, but the browser only knows that because it has a privileged vantage point. Another dimension one could think about is: is there any info in aggregate that could be computed that individual parties don't have access to?
… is there anything that would be useful that would not step on toes.

John_Wilander: Back to the location question...that sounded like assuming a desktop browser.

<stephen_mcgruer> [If I understand philipp's point, its sort of discovering new fraud signals? But then isn't it also available to fraudsters to learn from as well and change their own behavior?]

<mt_hates_irc> Keep in mind that bad actors don't use honest browsers

Gerhard: I think the main point was more to "pick up change"

<stephen_mcgruer> [Presumably any sort of signal here would - yikes - have to be attested in some fashion...]

Gerhard: it could also be useful to know whether my device is near my browser.

<stephen_mcgruer> [I have vague memories - MAYBE INCORRECT! - that Apple Pay give some sort of attested 'high/low trust' signal ?]

John_Wilander: That takes me to the next point - that assumes that we are going to have browsers remember where we usually are, which sounds shady

<mt_hates_irc> we didn't have a great experience the last time attestations were proposed (some more than others)

<vasilii> If it is inside browser, and not shared with the 3rd party - it might be okay

<stephen_mcgruer> [Really? I am so surprised to hear that ;)]

John_Wilander: We often think about the forensic case.

gkok: What if the "odd behavior" is only available within a limited time frame like "can't be in two continents in 5 minute period."

Sam: The main difference I'm hearing here today is implicit device attestation

nick_s: There's a lot of focus here on the signals at the point of payment, which makes sense if the payment method is broken. If you do the risk assessment at enrollment, I think users will be willing to do. SPC does that (though I'm not a fan of SPC).
… we do fraud signals with Apple Pay on the Web, but it's done out of band.
… we turn signals into an opaque assessment. That assessment does include what people are asking for here (e.g., account age, location). It's opaque and goes to the issuer
… if there's a discussion to be had about opaque fraud scoring.
… the opaque signals is attested by Apple.
… it goes to server and is sent to the payment network.

stephen_mcgruer: Attestation is tough to do...close enough to WEI that some people might be unhappy

<Zakim> stephen_mcgruer, you wanted to note that we have heard that mobile <> app flows can cause drop-off, albeit unclear if we should instead just make that linking more stable rather than keeping people on the web...

(Ian had asked if we could have a thing like Apple Pay's opaque signal in browsers)

stephen_mcgruer: On the question of the mobile gap...yes, it does lead to drop-off
… in a variety of ways, like user walking away, or browser dies or phone not available

<mt_hates_irc> if an attestation is part of the payment, the privacy story is more interesting. we'd have to discuss what information is source from where, how it is passed, and who gets it.

stephen_mcgruer: there is still an interesting question about whether we should make the web-to-native jump more stable

<mt_hates_irc> wei was completely disconnected from anything else, so it could be used for many other things than payments

<AramZS> Would love to make the app payment flow better

Ian: Could we do signal through SPC?

stephen_mcgruer: If it's a payments context, we could be more open to the idea of attestation of opaque signal

rbyers: This is coming with DPCs. They are going to use mobile wallets with attestation.

<nicktr> I wanted to say the same thing - we heard that DPC could do attestation earlier, I think, and I would like to understand why that's possible but SPC cannot.

<mt_hates_irc> as a casual observer, the acronyms are a pretty annoying barrier to comprehension

<stephen_mcgruer> [sorry mt_hates_irc , that's totally reasonable to note!]

<stephen_mcgruer> [DPC = Digital Payment Credentials, a ~theoretical schema for Digital Credentials relating to payment authentication]

<stephen_mcgruer> [SPC = Secure Payment Confirmation, a W3C editors draft for approximately using passkeys for payments cases]

<stephen_mcgruer> [FIDO=... I actually don't know what it stands for. Just the name of the association that does authentication standards... where passkeys and CTAP are defined on the non web side]

<nicktr> FIDO is Fast Identity Online

<stephen_mcgruer> [mDL = mobile Drivers License - basically put your physical drivers license into a digital wallet and be able to use it online for verification of various things]

<stephen_mcgruer> [RP = Relying Party, in the passkey world thats the origin who registers/owns the credential]

FIDO trust signals update

Lee: Passkey trust signals. FIDO has had a group for about a year...using a passkey as a single factor. You can mostly use passkeys as a single factor (replacing password). But it doesn't work for every web site
… there are high assurance use cases
...the reason has to do with passkeys being synched.
… you get your passkey by logging into your passkey provider account.
… they need to support potentially phishable login flows...so the provider account could be phishable...and then you can steal all my passkeys
… the trust group wants to solve that problem and came up with two recommendations. If you need a proof of possession, then they can request one via the DC API. Examples include mDL, passport, verified telephone number.

Lee: the solution of this problem is a strong possession factor. But there are a few issues with this (1) privacy
… e.g., giving away phone number

Lee: it adds friction to the flow
… and some cost money (e.g., verified telephone number)
… we think there are some RPs will use this but it's not a great answer.
… you could argue that if you are going to use DPCs, why use passkeys at all?
… so another idea we are calling "Credential provider trust groups"
… we've been working on this for a year... the high level goal is to tell the RP that the passkey provider performed a strong phishing resistant sign-in

Lee: this way that don't need to request the Digital Credential themselves.
… that enables a 1-tap passkey only flow

Lee: here's how it works:

- it's a new key
… the RP creates a passkey on a device (after, say ID&V)
… the new proposal gives you a second key (the CPTG key) which you can trust as well
… now the user gets a new phone. The passkey is synched.
… if the signing was done in a way that the provider believes was strongly phishing resistant, you get the second key as well.
… you don't know what the provider exactly did, but since you trust the provider, you can trust the new device.
… so suppose an attacker phishes your account and gets your password and signs in.
… in this case, the passkey is synched, but there's a different CPTG key
… so the RP can decide what to do at that point (e.g., step up the user)
… and you might end up trusting the device (or not).
… and then there might be a fourth device
… and you end up with a couple of groups

Lee: Group one is "blue keys" which reflects that all logins have been phishing resistant. Group two is "red keys", the group that is all the devices connected to the first untrusted login.
… how do you know which group to add a new device to? You need a signal to link them.

Lee: At launch Google will use proximity to determine groups, and also Same T43 verified phone number.
… many others could be used in the future: ID Pass, eID. In the future providers could look at other signals as well, and a provider could use their own signals as well. So in the future could use DPCs as strong signals
… as strong possession signals. Signals are good but not perfect (e.g., not attested)

Gustavo: When you were talking about two groups...can a red key turn into a blue key?

Lee: Groups can come together, yes.