Is Introspection a Bug or a Feature?

When we talk about introspection in digital identity, we’re not just talking about what happens in OAuth 2.0. Yes, there’s a token introspection spec, but this post is about something broader: the idea that platforms—especially browsers—can inspect and influence the identity data being exchanged.

Is that a good thing? Apple and Google disagree on just how much introspection is required. And, unfortunately for my piece of mind, I can definitely see both sides of the argument.

What Is Introspection in Web Identity?

In OAuth, introspection allows a system (typically a resource server) to ask a trusted party whether a token is valid and get details like the user, scope, and expiration time.

But the concept of introspection has grown. On the web, it now also means the ability of browsers or platforms to inspect credential requests and responses in order to enforce policy, mediate UX, or protect users.

When a platform introspects, that could mean:

• Checking the structure of the credential request
• Verifying the origin of the Verifier
• Filtering or transforming claims before they reach the user
• Blocking requests that don’t meet policy requirements
• Mediating consent UX on behalf of the user

The question is: how much of that should the browser do by default?

Some say introspection is essential to prevent misuse and protect people. Others argue it creates surveillance risks and makes systems harder to build and scale. Both arguments make valid points, and Apple and Google are not entirely aligned. If you’re expecting a consistent user experience across browsers and mobile platforms, this split is a problem.

A Quick Aside: Inspection vs. Introspection

(Because language matters and I needed to look this up myself.)

Inspection is about checking whether something is safe to process, typically by looking at its structure or syntax.
Introspection is about understanding what something means and making decisions based on its content.

In digital identity:

• Inspection might involve validating that a request is well-formed and doesn’t contain code injection attempts.
• Introspection would involve analyzing the claims being requested and deciding whether they’re appropriate to show to the user, or even whether the request should be blocked.

To put it another way:

Inspection asks, “Is this safe to handle?”
Introspection asks, “What is this trying to do?”

That distinction matters, especially when deciding how much power the browser (or any other entity in the system) should have.

Two Tech Giants, Two Opposing Philosophies

I don’t think you’ll find these positions formally documented anywhere, but based on conversations I’ve had and observed, it boils down to this:

• Apple enforces stricter policies that require any credential request passed from the browser to the OS to be syntactically valid and free from malicious content (which means they need to see that content).
• Google takes a different approach: validating format but delegating deeper inspection to the wallet itself. That’s similar to how they handle passkeys with external providers.

Both companies agree that the browser, as the user agent, has the right to intervene if it believes a request is actively malicious, but they differ in how proactive the browser should be by default.

These positions ultimately shape APIs, UX flows, and developer expectations across major identity protocols. They even impact regulatory discussions as lawmakers argue about what they most want to protect the user from: Big Tech or everyone else.

(For a closer look at how these differences are shaping actual standards work, including the emerging Digital Credentials API at the W3C, I covered some of the details in this earlier post.)

📩 Want to stay updated? I write about digital identity and related standards—because someone has to keep track of all this! Subscribe to get a notification when new blog posts go live. No spam, just announcements of new posts. [Subscribe here] 

Enter Alice: A Real-World Example of Identity in Action

We all love Alice; she is the subject of many a tech story! Let’s say Alice goes to vote in a local election. She’s asked to scan a QR code, which opens her phone’s browser. The verifier (e.g., the state election site) sends a request to her digital identity wallet asking for name, age, home address, and proof of citizenship.

The problem? That’s not a single request. It’s really four separate ones. And Alice has more than one credential that could answer each, e.g., a mobile driver’s license and a mobile passport. Who decides which credentials are shown to Alice? Who ensures that the request is legitimate and not asking for too much?

That’s where introspection—by the browser, wallet, or platform—becomes a question of control.

It’s worth pointing out that neither Apple nor Google has said they want the browser to inspect everything or nothing. What they’ve done is adopt different implementation strategies:

• Apple enforces stricter content validation between browser and OS.
• Google favors letting wallets handle most decision-making, as long as requests are well-structured.

Both reserve the right to step in if a request seems actively harmful. But their default assumptions about the browser’s role do differ, and that shapes how developers must design for each environment.

Should the Browser Mediate or Stand Back?

If the browser only performs inspection, Alice’s experience might depend entirely on the wallet. That could mean an inconsistent user experience, especially if she has multiple wallets or credentials from different issuers.

If the browser goes further—into introspection—it could help Alice choose appropriate credentials, warn her if a verifier is overreaching, or even block suspect requests.

But that also means the browser has access to more metadata about what’s being requested and how Alice is interacting with verifiers. That’s a privacy concern in itself and ultimately a trade-off each platform has to make.

What This Means for Digital Identity Developers

The lack of consensus means that digital identity wallets, verifiers, and browsers are often behaving differently depending on what platform you’re using or developing for. That leads to:

• Inconsistent user experiences
• Confusing or overly technical prompts
• Incompatibility between ecosystems

These differences are baked into major specs: OpenID for Verifiable Credentials (OpenID4VC) for digital credentials in general and ISO 18013-5 for mobile driver’s licenses all take a stance on who gets to inspect what.

These aren’t just product design differences—they affect how global standards get written. If the browser is deeply involved, specs like OpenID4VC or ISO 18013 need to account for that. If not, then the wallet has to take full responsibility for consent and UI, which introduces fragmentation risks across platforms.

Developers are caught in the middle, trying to build usable systems that work across platforms with different requirements.

TL;DR: What’s at Stake with Introspection?

• For users: Do you want the browser to protect you—or stay out of the way? The answer to that guides what platform provider you choose.
• For developers: Do you build for Apple-style control or Google-style neutrality? Unfortunately, the answer is probably “both.” You job is complicated.
• For standards folks: Do your APIs assume the browser mediates—or just observes? You’ll probably have to be more careful to build in feature detection (among other things).

The answers affect more than architecture; they shape the identity experience itself.

So, Is Introspection the Bug or the Feature?

In digital identity, introspection can be either.

• When done right, it helps prevent overreach, clarify consent, and improve trust.
• When done poorly, it increases complexity, leaks sensitive data, or just gets in the way.

What’s needed is nuance, which is insanely challenging. Right now, we’re stuck in a binary: inspect everything or inspect nothing.

What Comes Next?

Should browsers protect users from overly ambitious verifiers? Or is it time to let wallets and holders take full responsibility?

The question isn’t just technical. It’s political, ethical, and practical. And like so much in identity, it comes down to one thing:

Who do we trust to protect Alice?

I’d love to hear how others are thinking about this. Is there a better path forward? Should introspection evolve or be reined in?