“Attending standards development meetings is not dissimilar in some ways to attending a more typical conference: there is always more to do than there is time to do it.”

In my case, I very much wanted to learn more about what’s going on in the web payments world. That world is increasingly overlapping with the tech world I’m more familiar with: digital identity. Identity verification has always been a thing, but web payments already had their own stack of processes and regulations for that. Now? It’s all verifiable digital credentials, digital wallets, and so much more.

Of course, just like with digital identity, I’ve yet to find decent 101-level material that helps someone know where to even start. Diving directly into meeting notes is a bit of going off the deep end and hoping for the best. Oh well!

Which brings me to this blog post. Since I need to spend some quality time with the meeting minutes from the Web Payments Working Group (WPWG) and the Web Payment Security Interest Group (WPSIG) sessions held at the W3C TPAC 2025, I’m going to share what I’m learning with you while noting that I’m not at all an expert in this space. This is how I learn about new communities and their work—by reading, listening, and asking, “why does it work that way?” until the picture comes together.

You can Subscribe and Listen to the Podcast on Apple Podcasts, or wherever you listen to Podcasts.

And be sure to leave me a Rating and Review!

Two groups, two charters, one very tangled problem space

Before diving into the fun bits, it helps to understand who’s doing what.

The Web Payments Working Group (WPWG)

This is the group that produces actual web standards. If you want to define or evolve a browser API related to payments—Payment Request API, Payment Handler API, Secure Payment Confirmation (SPC)—this is where that work happens. The conversations here tend to be grounded in:

• implementability in browsers,
• web developer ergonomics,
• interoperability across platforms, and
• the slow, steady march toward something usable by both merchants and consumers.

The Web Payments Security Interest Group (WPSIG)

This group, on the other hand, doesn’t produce standards. Its job is to bring together a much broader ecosystem—FIDO Alliance, EMVCo, OpenWallet Foundation, payment networks, browser vendors, and others—to talk about how everything fits together and where the sharp edges are. It’s where wallet experts, identity experts, payments experts, and regulatory watchers all try to make sense of each other.

When you’re in the thick of it, it’s difficult to really parse the difference, because if you’re interested in one, you’re probably interested in the other. That’s exactly why the boundaries blur and the song, “It’s a Small World,” starts running through people’s heads. Both groups touch on payments and identity. Both care about trust, fraud, user experience, and emerging wallet models. But the groups ultimately hold different levers.

WPWG: builds the browser plumbing.

WPSIG: coordinates the rest of the ecosystem so the plumbing leads somewhere safe.

Where the conversations converged: digital wallets, identity, and trust

So, let’s dive into the minutes. They are public, and you can read them here:

• Web Payments Working Group – TPAC Minutes from 9 (or 10, depending on where you stand in relation to the International Date Line) November 2025
• Web Payments Working Group –TPAC Minutes from 10 (or 11) November 2025
• Web Payments Security Interest Group – TPAC Minutes 12 November 2025

Reading through the minutes, you can see the overlapping concerns loud and clear. (As it should be; it would be weird if they talked about completely different things.) Payments may have their own decades-long history of risk controls, but the shift toward digital wallets and verifiable credentials is reshuffling assumptions across the board, and that definitely shows up in the conversations.

A few themes stood out.

1. Wallet interoperability is becoming unavoidable

This comes up in both groups. The wallet landscape is fragmented:

• OpenWallet Foundation is pushing for open, interoperable models.
• EMVCo is defining identity and payments task forces.
• FIDO Alliance is focusing on strong authentication and wallet certification.
• Browser vendors are building APIs like SPC, Payment Request API, and the Digital Credentials API.

Everyone is looking at everyone else. There’s a real sense that wallet experiences can’t stay siloed inside one organization’s worldview.

The WPSIG discussion even entertained the idea of a W3C Digital Wallets Interest Group, separate from the security IG, to coordinate wallet architecture and expectations across the many SDOs involved. I’m not sure if another group will improve things, but it’s an interesting idea.

2. Identity verification is no longer “outside scope” for payments

The old assumption that “identity is for identity people; payments already solved this” is breaking down. Japan shared updates showing a shift from selfie-matching eKYC to IC-chip-based national IDs. European regulators are tightening requirements through PSD3 and AML6.

And in many presentations—including Mastercard, Visa, Meta, Rakuten—participants kept coming back to variations of the same question:

How much identity should a wallet (or browser) present during a payment flow? And who decides?

That’s where the Digital Credentials API started appearing in conversation.

Where the DC API enters the story

If you’ve been following my writing on the W3C Digital Credentials API (DC API), you’ll know it’s designed to let websites request credentials—anything from age claims to verifiable IDs—through an interoperable browser API. I knew the web payments people were paying attention, but I didn’t really grasp just how closely they are watching this API.

Payments may become one of the earliest large-scale adopters of the DC API

A few highlights from the WPWG meeting:

• Implementers see a natural fit between the Payment Request API (checkout orchestration) and the DC API (structured credential exchange).
• One proposal suggested treating the DC API as a payment method within the Payment Request API. In this model, a merchant could initiate a payment flow where the DC API provides the necessary credentials, rather than relying exclusively on traditional authentication channels. Supporters of this idea saw it as a way to bring identity-based or credential-backed payments into a standardized browser framework. People who were less supportive were concerned about expanding the DC API into general payment use cases, particularly where it might increase the spread of identity requirements or blur regulatory boundaries. One person emphasized that the DC API was intentionally designed as a one-shot credential presentation mechanism with explicit user interaction; embedding it inside automated or merchant-driven payment flows could undermine those guardrails.
• There’s momentum around “credential bundles”—where a wallet might return both a payment credential and auxiliary credentials (e.g., phone number, email, proof of age) in a single flow.
• The DC API’s “one-shot” design (a specific request → a specific credential) fits some payment use cases surprisingly well.

But the big tension is privacy.

The TAG is very wary of the DC API being used as a stealth identity requirement in payments

TAG feedback, repeated in the meeting, was that the DC API must not become a way for merchants to refuse service unless a user hands over identity information. This is exactly the kind of privacy creep standards bodies want to avoid.

And the payment world is… complicated. Identity requirements often stem from regulation, not merchant preference. Age verification, for example, is generally required only when regulators turn that into law.

So payments may need the DC API for certain cases, but cannot rely on it for everything, and must stay within privacy-preserving guardrails.

This is the tension that will shape the DC API + payments integration over the next few years.

Secure Payment Confirmation (SPC) sits at the center of all of this

SPC appears in both groups’ discussions, and for good reason. It’s one of the few browser features explicitly designed for payment authentication, and everyone wants it to work well.

What’s working

• Users like SPC when it works—Visa shared some user research showing strong reactions to the UI.
• SPC is faster and smoother than traditional 3DS flows that use OTP.
• Chrome is shipping improvements steadily on Android and desktop.
• Bindings like browser-bound keys (BBKs) reduce fraud and reduce reliance on cross-device sync by providing a possession factor, something particularly important in regulated payment environments. 

What’s not working

• iOS has no SPC support. This came up repeatedly as a major barrier to adoption.
• Enrollment friction remains high—passkey flows still confuse users.
• Cross-device syncing is unreliable, especially when accounts differ across devices.
• Merchants are hesitant about flows they can’t customize, especially around branding. It’s not a major blocker when it comes to purely the authentication aspects, but handing over control to the browsers in other aspects of the payment request UX makes them itchy.

The mood in the room: maybe it’s time to stop centering passkeys for SPC

I love passkeys. The meeting notes suggested, however, that passkeys still have a ways to go when it comes to user understanding. That led some people to suggest a BBK-only SPC, where the browser stores a key tied to the device and payment instrument without any of the passkey synchronization challenges.

It’s not settled yet, but that’s why we have these discussions.

Agentic AI makes everything more interesting (and more complicated)

Both groups discussed agentic AI—systems that can autonomously initiate actions like purchases, bookings, or recurring transactions.

What stood out is how quickly AI is forcing these conversations:

• No one wants AI systems impersonating users through passkeys.
• There is interest in agent-initiated payments authorized by users, similar to mandate management.
• Stripe and AP2 demos showed early patterns for agent-initiated commerce.
• WPSIG is watching this closely and wants coordination with the forthcoming AI and Web IG.

This is one of those areas where identity and payments are going to collide repeatedly. Agents need to know enough about a user to make decisions, but not so much that they become a surveillance nightmare or fraud catalyst.

Fraud is the ever-present pressure point

Across both groups, the concerns repeat:

• Cross-device phishing
• Abuse of synced passkeys
• Lack of UI trust signals
• The need for better cryptographic binding
• How SPC, DPC, and DBSC change the risk landscape
• Whether wallets can meaningfully contribute to fraud detection without over-collecting data

The Anti-Fraud CG joined WPSIG for part of the meeting, and trust signals—especially for cross-device CTAP flows—were a major topic.

This is an area where identity and payments will need shared guidance. Fraudsters don’t care about charters.

So what’s the difference between WPWG and WPSIG again?

After reading two days of meeting minutes from each group, here’s the distinction in practical terms:

WPWG

• Defines browser APIs.
• Works through implementation details, developer ergonomics, and test suites.
• Debates things like error codes, mediation modes, and API integration.
• Thinks in terms of “can we ship this?”

WPSIG

• Pulls in the whole industry.
• Surfaces pain points across the payments ecosystem—wallet certification, regulatory impacts, agentic AI, fraud.
• Helps organizations see around corners.
• Thinks in terms of “will this fit into the world we actually live in?”

Both are essential and influence each other’s work. And, probably of course at this point, both are working toward a future where digital wallets, identity credentials, and payment mechanisms can coexist without breaking user expectations or regulatory sanity.

But they do different jobs. And in a space as tightly interconnected as payments and identity, it’s completely understandable that observers (and newcomers like me) blur them together.

Why I’m watching this area so closely

It’s rare to see two worlds—payments and digital identity—colliding this directly in standards bodies. Payments folks are realizing that credentials matter. Identity folks are realizing that wallets aren’t just for government IDs. Browser vendors are trying to build something usable without getting caught in regulatory crossfire.

And everyone is trying to figure out how to handle AI before AI handles them.

For me, digging into these minutes is a way of understanding how these communities think, where they’re cautious, where they’re bold, and where they need help. Even if I’m not an expert here, I can already see how this work will spill into everything from consumer wallets to enterprise authentication to the regulatory debates coming down the road. And, full disclosure, I may have interpreted some of what’s in the minutes incorrectly. These are a place to start, not a place to end.

I’ll share more as I keep learning. Your mileage may vary, but I find these intersections fascinating—and often a little chaotic. Which is exactly why I keep going back.

📩 If you’d rather track the blog than the podcast, I have an option for you! Subscribe to get a notification when new blog posts go live. No spam, just announcements of new posts. [Subscribe here] 

Transcript

Why Web Payments Suddenly Matter to Identity

00:00:30

When attending standards meetings, one reality always stands out: there is far more happening than any one person can reasonably track. That truth was especially apparent during W3C TPAC, the annual meeting of the World Wide Web Consortium.

Although payments are not my primary domain, I found myself drawn to the Web Payments discussions—not because I plan to reinvent myself as a payments expert, but because payments and digital identity are beginning to overlap in ways that are impossible to ignore.

Since I couldn’t attend those sessions directly, I did what many standards practitioners do: I read the meeting minutes carefully and looked for patterns beneath the surface.

---

Identity Has Always Been Part of Payments—But Something Has Changed

00:01:45

Identity verification in payments is not new. Risk models, regulatory frameworks, and authentication requirements have existed for decades.

What is new is how these requirements are increasingly expressed using the language of:

• Digital credentials
• Digital wallets
• Browser-based APIs

This post—and the accompanying audio—reflects a thinking-out-loud process about what those changes signal, especially for people working in digital identity.

---

The Two W3C Groups Shaping Web Payments

00:02:30

At the W3C, two groups consistently surface in web payments discussions, each with a distinct role.

Web Payments Working Group

This group builds browser standards, including:

• Payment Request API
• Payment Handler API
• Secure Payment Confirmation (SPC)

Their focus is concrete and implementation-driven. They ask:

• Can this ship across browsers?
• Will developers use it?
• Does it improve user experience without breaking the web?

Web Payment Security Interest Group

The Security Interest Group does not produce specifications. Instead, it serves as a coordination forum across:

• Browser vendors
• Payment networks
• Wallet initiatives
• Other standards organizations

This group compares notes, surfaces shared problems, and examines how different standards efforts intersect—or collide.

---

Wallet Fragmentation Is No Longer Optional

00:03:40

Across both groups, several themes appear repeatedly:

• Digital wallets
• Fraud prevention
• Regulation
• User trust
• Digital identity

One strong signal from the meetings was that wallet interoperability is no longer optional. The ecosystem is crowded, including:

• Payment wallets
• Identity wallets
• Government-issued wallets
• Browser-managed credentials
• Platform-specific solutions

Everyone agrees fragmentation is harmful, but no one has a single, clean solution.

---

Regulatory Pressure from Japan and Europe

00:04:20

Meeting minutes highlighted presentations from Japan and Europe that revealed similar pressure points despite very different regulatory environments.

Japan

Older approaches to identity proofing are being phased out. Specifically:

• Selfie-based eKYC is proving too easy to spoof
• Phishing-resistant authentication is becoming mandatory
• Passkeys are explicitly named in government guidance

There is also a shift toward:

• IC chip–based identity cards
• Device-bound authentication models

At the same time, Japan’s payments ecosystem remains highly diverse, relying on:

• QR codes
• Domestic payment networks
• Transit-driven adoption

This diversity does not align neatly with platform-centric wallets like Apple Pay or Google Pay.

Europe

Europe faces similar challenges under tightening regulations such as:

• PSD3
• AML6

These frameworks increase requirements around:

• Fraud prevention
• Auditability
• Accountability

As a result, institutions are being asked not just whether a user authenticated, but how—and whether that process can be demonstrated after the fact.

---

The Digital Credentials API Enters the Payments Conversation

00:06:20

This is where the Digital Credentials API (DCAPI) begins to surface in web payments discussions.

Originally, the DCAPI was designed as:

• Privacy-conscious
• User-mediated
• Intentionally scoped

It was never meant to be a generic data pipe.

However, what stood out in the Web Payments Working Group minutes was a sustained discussion about whether the DCAPI could play a role in payment flows.

Ideas raised included:

• Allowing payment flows to invoke the DCAPI directly
• Treating the DCAPI as a payment method within the Payment Request API

This represents a meaningful shift in thinking—and one not currently centered in DCAPI-focused working groups.

---

Credentials as Part of Checkout

00:07:10

In practical terms, participants discussed scenarios where a wallet might return a digital credential during checkout, such as:

• A credential containing a cryptographic proof
• Selective disclosure of attributes (e.g., a phone number for risk analysis)

The intent was not to replace existing payment rails, but to allow credentials to become part of how payments are authorized and confirmed.

At the same time, there was clear caution. The DCAPI was deliberately designed as a one-shot interaction with explicit user involvement.

Expanding it into routine payment flows risks embedding identity requirements that are difficult—or impossible—to roll back.

---

Secure Payment Confirmation at a Turning Point

00:08:05

Secure Payment Confirmation (SPC) is one of the few browser features designed explicitly for payments.

When it works well, SPC:

• Is faster than traditional 3DS flows
• Reduces phishing risk
• Clearly positions the browser as a trust mediator

However, discussions revealed growing tension around passkeys in payment contexts.

Challenges include:

• Unreliable cross-device syncing
• Confusing enrollment flows
• Difficult-to-explain failure modes
• Perceived redundancy in layered risk checks

---

The Rise of Browser-Bound Keys

00:09:00

An emerging concept discussed was “BBK-only SPC,” where BBK stands for browser-bound key.

In this model:

• The browser generates a device-bound cryptographic key
• The key is tied to a specific payment instrument
• No cross-device syncing is required

This approach offers several advantages:

• Reduced enrollment friction
• Simpler mental model for users
• Strong device binding for fraud prevention

Notably, participants openly questioned whether passkeys were ever the right abstraction for payment confirmation—a significant statement given their momentum elsewhere.

---

Agentic AI and Mandated Payments

00:10:30

Another fast-emerging area is agent-initiated payments driven by AI systems.

While everyone agreed agents should not impersonate users, there was alignment around a mandate-based model:

• Users authorize actions upfront
• Agents operate within defined boundaries

This immediately raises familiar identity questions:

• How is consent represented?
• How is it verified?
• How is it revoked?
• How is it audited?

These are longstanding identity challenges that are now becoming unavoidable in payments.

---

Fraud as the Constant Pressure

00:11:40

Underlying all of these discussions is fraud:

• Cross-device phishing
• Credential misuse
• Replay attacks

These threats do not respect working group boundaries. As a result, conversations about SPC, DCAPI, device-bound credentials, and wallet trust signals all circle the same question:

How do we reduce risk without creating systems that are brittle, invasive, or impossible to deploy globally?

---

Two Groups, One Set of Fault Lines

00:12:20

The Web Payments Working Group and the Web Payment Security Interest Group approach the same challenges from different angles.

• The Working Group focuses on what browsers can ship today
• The Interest Group examines regulatory pressure, industry alignment, and emerging risks

They were designed to be complementary—and the minutes suggest that collaboration is increasingly effective.

---

Final Reflections on Identity and the Future of Payments

00:12:50

Spending time with the meeting minutes was not about mastering payments. It was about noticing how quickly digital identity concepts are becoming foundational in domains that once believed identity was already solved.

Key takeaways include:

• Wallets are no longer just containers
• Credentials are not limited to government use cases
• Browsers are active trust mediators
• Payments are deeply intertwined with identity ecosystems

The overlap between payments and identity will only continue to grow. Watching that convergence closely is one of the best ways to understand where the web is headed next.

---

Closing and Call to Action

00:13:08

Thanks for spending time with this episode of the Digital Identity Digest. If it helped make things clearer—or simply more interesting—please share it with a colleague.

You can connect with me on LinkedIn and find the full written version at sphericalcowconsulting.com. Stay curious, stay engaged, and let’s keep these conversations going.