What each standard proves, and what it cannot

This is not a page about deficient standards. Every specification named here answers a precise question correctly, and most of them answer it better than anything that came before. The problem is that the questions are different from one another, practitioners assume they overlap more than they do, and the fraud has moved into the space between them.

Why a reference page rather than a critique

Engineers who work on identity have a reasonable and well earned allergy to vendor content about standards. It is usually a thin argument that some widely deployed specification is broken, written by someone who has not read it, in service of a product that does less.

So the framing here matters. Nothing below argues that WebAuthn is weak, that 3-D Secure failed, or that Sigstore does not deliver. Each of those does what it says with real rigour, and in several cases the specification is explicit about the boundary of its claims in a way that practitioners then ignore. The FIDO specifications, for instance, are unusually careful about what an assertion means. The problem is rarely the document. It is the inference drawn from it three layers up, by someone integrating it into a system that needed a different guarantee.

What this page tries to be is the reference nobody has written: for each standard, the question it answers, the question it does not, and the failure that lives in the difference. If you are choosing controls, this is the page to argue with.

Three questions that are constantly confused

Almost every gap on this page reduces to conflating three questions that sound similar and are not.

Who is this principal? Authentication answers this. A credential is presented, a challenge is signed or a token is validated, and the system concludes it is talking to an account. WebAuthn does this exceptionally well. SAML and OpenID Connect do it at federation scale.

Is this principal permitted to do this? Authorisation answers this. Scopes, policies, roles and posture checks decide whether the request should proceed. OAuth answers it for delegated access, zero trust architectures answer it continuously and per request.

Did a human intend this specific act? Almost nothing answers this, and it is a different question from the first two rather than a stronger version of either. A stolen session belongs to a correctly authenticated principal who is fully authorised. Every check passes. The intent was never formed.

The Identity Failure Map calls the resulting failure IFM-01, Session-Inherited Authorization: every action after login carries the authority of the login, so an attacker who obtains the session obtains the authority over everything that follows. Reading the standards table below with that distinction in mind is what makes the pattern visible.

What a transaction binding actually looks like

Before the table, it is worth being concrete about the missing property, because "prove intent" is vague and the implementation is not.

In a conventional authentication ceremony the relying party generates a random challenge and the authenticator signs it. The signature proves possession of the key at a moment in time. It says nothing about what the session went on to do.

In a transaction bound ceremony the challenge is not random. It is derived from the operation itself.

# Conventional: the challenge carries no meaning
challenge = os.urandom(32)

# Transaction bound: the challenge IS the operation
payload = {
    "act":      "payment.release",
    "payee":    "GB29NWBK60161331926819",
    "amount":   "42000.00",
    "currency": "GBP",
    "ref":      "INV-2026-8841",
}
challenge = sha256(canonicalize(payload))     # RFC 8785 canonical form

# The resulting assertion is only valid for THIS payload.
# Replay it against a different beneficiary and verification fails.
assertion = authenticator.get(challenge, rp_id="bank.example")

That is the entire difference, and it is small. The same authenticator, the same protocol, the same user gesture. What changes is that the resulting artifact is bound to one operation instead of one session, so it survives as evidence and cannot be replayed against a substituted payload.

Hold that shape in mind. Most of the gaps below are the absence of exactly this, in a different domain.

The map: what each standard establishes

This is the table this page exists for. Read the third column as the question the standard was never asked, not as a criticism of it.

What do passkeys and WebAuthn actually prove?

WebAuthn is the best thing to happen to consumer authentication in twenty years, and saying so is not throat clearing before a critique. Origin binding kills credential phishing as a class, because a credential registered to one origin cannot be presented to another no matter how convincing the imitation. That is a genuine structural win, the kind that removes an entire attack rather than raising its cost, and it is worth celebrating properly before examining what it leaves open.

What it leaves open is everything after the ceremony. The assertion proves possession of a key at a moment. The relying party then issues a session, and every subsequent action inherits the authority of that session without any further cryptographic involvement from the authenticator. An attacker who obtains the session, by adversary in the middle relay or by stealing the cookie from an infected machine, is indistinguishable from the legitimate user for the remainder of its lifetime. Passkeys prove you logged in, who signed the wire works through the difference between signing a random challenge and signing a challenge derived from a payload, which is the whole of the fix.

The frustrating part of this story is that the FIDO community identified the problem early. Extensions for displaying and confirming a transaction were part of the conversation from the beginning. They did not survive into broad deployment, for reasons that were as much about authenticator diversity and user experience as about protocol design, and the result is that the mechanism exists in the literature and not in the field.

Federation sits one layer up and inherits the same property. SAML and OpenID Connect answer whether an identity provider authenticated a subject, which is exactly what a relying party needs to establish a session and exactly not what it needs to establish that a wire transfer was intended. The seven layers of human-agent trust lays out where each layer's responsibility begins and ends, which is a useful frame when someone insists their identity provider already solved this.

What do 3-D Secure and PSD2 dynamic linking prove?

Payments is the most instructive family on this page, because it contains both the clearest example of the gap and the clearest example of the gap being closed.

Where the gap is open

EMV 3-D Secure was designed to reduce card not present fraud and to allocate liability, and it does both. The low friction path lets an issuer approve without interrupting the cardholder based on device and transaction data, which is a risk decision. The challenge path asks for a factor, which authenticates a person to an account. Neither binds a human to this purchase at this price from this merchant in a way that produces durable evidence, which is why the dispute process still turns on merchant telemetry. 3-D Secure proves the device passed a check covers this, and notes that the agent case makes it acute, since when software completes the purchase the device and behavioural inputs the risk engine relies on are describing software.

Confirmation of Payee is a genuinely effective control that is routinely asked to do something it cannot. Checking the entered name against the account name catches misdirected payments and a category of impersonation, and it has reduced real losses. It cannot catch the case where the payer has been persuaded to name the wrong destination, because the check confirms the payer's stated belief rather than testing it. Confirmation of Payee checks the name on the account is careful about this, because overselling a name check is how a bank ends up believing a scam vector is closed when it is not.

Where the gap is closed

Then there is dynamic linking. Under the European regulatory technical standards implementing PSD2, strong customer authentication for a payment must be dynamically linked to the specific amount and the specific payee, so that the authentication code changes if either changes. That is precisely the transaction binding described at the top of this page, mandated by regulation, implemented across an entire continent's banking sector, and working.

Sit with that for a moment, because it is the most important observation on this page. The industry did not fail to build transaction binding because it is hard. It built it, at scale, in the one place a regulator required it.

What does STIR and SHAKEN prove about a caller?

STIR and SHAKEN authenticate the origination of a call. The originating carrier signs the calling number and asserts an attestation level, with full attestation meaning the carrier authenticated its customer and confirmed their right to use that number, and terminating carriers verify. Against illegal spoofing, which is what it targets, it works.

The two limits are worth stating precisely because they are so often blurred. First, attestation concerns the number, not the person: a fraudster who lawfully obtains a number from a compliant provider receives full attestation on every call. That is the framework behaving exactly as specified. Second, nothing in it concerns the content of the call, so a legitimately originated call carrying a cloned voice verifies perfectly. Caller ID authentication proves the carrier develops both, and the practical conclusion is that caller identification should be treated as evidence about routing rather than about identity.

What does OAuth prove about the user behind a token?

OAuth is the most successful authorisation framework ever deployed and it was designed for a world of coarse, long lived, application scoped access. Scopes describe categories, which was the right abstraction for letting a photo printing service read your album.

Rich Authorization Requests, RFC 9396, fixed the expressiveness problem properly. The authorization_details parameter carries typed, structured detail about exactly what is being authorised, which is what open banking needed and could not express with scope strings. It is careful, well specified work.

And it changed the expressiveness of the request without changing how the human's agreement is captured, which remains a consent screen rendered in a browser session. So the token can describe a payment to four decimal places while the evidence that a person approved it is a click subject to every session attack in this series. OAuth learned to describe the transaction proposes deriving the assertion challenge from a hash of the authorization_details object, which is a small change to an authorization server and closes the loop.

The device authorization grant, RFC 8628, deserves its own note because it is the most elegant illustration of consent without a display. The flow exists so that a television or a command line tool can obtain authorisation via a second device, and every step of it is legitimate. The attack is simply to initiate the flow on the attacker's device and persuade the victim to enter the attacker's code on the genuine provider page. There is no lookalike domain and nothing for a link scanner to catch, because the user really is on the real page authenticating to their real account. Device code phishing covers it, and the correct first response is to disable the flow where it is not needed, which costs nothing.

For the broader migration question, from OAuth to AgentAuth covers what changes when the client is an autonomous agent rather than an application a user installed.

What do Web Bot Auth and AP2 prove about an AI agent?

This family is the newest and the most rapidly moving, and the standards in it are being built by capable people under time pressure, which is worth remembering before criticising any of them.

Web Bot Auth, building on HTTP message signatures in RFC 9421, lets an agent cryptographically prove which software sent a request. This genuinely solves agent authentication and it solves it well. What it does not address, and does not claim to, is whether a human authorised the action the agent is attempting, so a correctly signed agent operated by an attacker who compromised the user's account produces flawless signatures. Web Bot Auth tells you which bot, not whose human draws the distinction, and anyone can claim to be your agent covers what the world looks like before adoption.

AP2 approaches the same territory from the payments side, defining signed Mandates that express what a user authorised an agent to do. A Mandate is a well formed, signed, verifiable statement of intent, and the signature proves it was issued by a particular party and not altered. The gap is narrow and important: nothing guarantees that a live, unique human was present and understood the mandate at the moment it was issued. If the consent step was a click in a session, the mandate faithfully records an intent that may never have been formed. AP2 proves the mandate, it does not prove the human works through the difference between authenticity of a document and authenticity of consent.

The Model Context Protocol authorization specification handles how a client authenticates to a tool server and deliberately leaves human authorisation of individual tool invocations to the implementer. That is a defensible separation of concerns rather than an oversight, and the consequence is nonetheless that every server author independently decides whether a tool that moves money needs a human, and most decide by not deciding. Know Your Agent is half a check makes the compliance argument, which is that verifying the agent identifies the instrument rather than the principal, and no financial crime programme would accept a customer check that verified the wire transfer software.

What do Sigstore and C2PA prove about an artifact?

Sigstore changed artifact signing by removing long lived key management, using short lived certificates bound to workload identity with a transparency log for public auditability. SLSA gives a framework of build integrity levels on top. Together they answer, rigorously, which build system produced this artifact from which source.

The gap is that keyless signing binds an artifact to a workload identity, which is a continuous integration job, and that job ran because something triggered it: a merge approved by a click, a tag pushed by a maintainer whose token was phished, a schedule, or an agent with repository access. The attestation is complete about the machine and silent about the human. Sigstore proves the pipeline, nothing proves the person proposes a human release attestation published alongside the provenance attestation, and is scrupulous about the counterargument, since a long trusted maintainer who goes bad produces a perfectly valid human attestation too.

C2PA occupies the analogous position for media. Content Credentials attach a signed manifest recording capture device, edits and tool chain, with adoption across camera manufacturers and major platforms. For most provenance purposes, binding an asset to a device and an edit history is correct and sufficient. It becomes insufficient exactly where accountability matters: a claim photograph, evidence before a court, a byline. Content Credentials prove the camera, not the photographer is deliberately respectful about this, and insists that any human layer must be optional and selective, because binding a human to published content is dangerous for anonymous sources and dissidents.

What do Verifiable Credentials and eIDAS prove about a person?

W3C Verifiable Credentials are the serious general framing for issuer, holder and verifier, and the Bitstring Status List handles revocation with a privacy preserving property that deserves more credit than it gets: the verifier fetches an aggregate list rather than asking the issuer about a specific subject, which avoids exactly the surveillance behaviour that made per query revocation checking untenable on the web. Our own comparison is in Manav and W3C Verifiable Credentials.

The honest observation about this family is that its remaining problem is not technical. Formats interoperate long before institutions agree whose attestations they will accept, so the binding constraint is trust registries and governance. Can you verify a credential without phoning the issuer traces the certificate revocation history that settled the same argument in the web public key infrastructure, and the licence was revoked in March covers what happens when status and signature drift apart.

ISO/IEC 18013-5 for mobile driving licences is the most instructive deployed example, because a roadside stop has no guaranteed connectivity and the standard therefore had to solve offline presentation honestly rather than assuming a callback. eIDAS 2.0 and the European Digital Identity Wallet put legal effect and cross border governance behind the same shape, and eIDAS 2.0 and Manav covers where a private receipt layer sits relative to a state backed wallet.

What do SCIM, SPF, DKIM and DMARC prove?

SCIM tells you an account exists with these attributes and has been provisioned or deprovisioned, which is genuinely useful and is the backbone of workforce identity lifecycle. It says nothing about authority granted outside the provisioning path, which is where most residual access lives. What is a non-human identity covers the population that provisioning systems were never designed to enumerate.

Email authentication is the most complete historical parallel available and rewards study. SPF, DKIM and DMARC together establish that a message was authorised by the sending domain and was not altered in transit. That is a real achievement that took two decades and materially reduced a category of abuse. It also establishes nothing about whether the human named in the message wrote it or approved its contents, which is why business email compromise remains a multi billion dollar category conducted entirely through messages that pass every authentication check. Verifiable humanity is the new verifiable email develops the analogy, and it is the single best argument that authenticating the channel and authenticating the intent are permanently different jobs.

What does a zero trust architecture prove about intent?

Zero trust, as formalised in NIST SP 800-207, corrected a genuine and consequential error: network location is not authorisation. The resulting architecture of continuous verification, least privilege and per request access decisions is a substantial improvement over the perimeter model, and organisations that implemented it are measurably better off.

The narrow critique is that a zero trust access decision evaluates identity, device posture, network context and policy, and answers whether this principal should be allowed to perform this operation now. That is an access question. An attacker with a compliant device and a valid session satisfies every input by construction, which means the architecture is working correctly and still cannot distinguish the legitimate request from the stolen one. Zero trust verifies the device, it never asks what you meant makes the case that the policy engine is the natural place to require a per action signature for a defined class of operations, which is composition rather than replacement.

The finding: the industry builds this when it is told to

Run back through the table and one pattern separates itself from the rest.

Transaction binding, the property this whole page describes as missing, is not missing everywhere. It exists in exactly two places at scale, and both of them are places where a regulator required it.

The first is European payments. The regulatory technical standards under PSD2 require that strong customer authentication for a payment be dynamically linked to the amount and the payee, such that the authentication code becomes invalid if either changes. That is transaction binding, specified in regulation, implemented across the payment industry of an entire continent, and functioning.

The second is controlled substance prescribing in the United States. The Drug Enforcement Administration's rules for electronic prescriptions require identity proofing of the prescriber and two factor authentication applied to the act of signing the prescription itself, rather than to a session that then permits signing. EPCS requires two factors examines what remains open in clinical practice, and the point here is narrower: the rule placed the authentication at the action, and the industry built it.

Two regulated domains, two mandates, two working implementations. Everywhere else the property was left optional, and everywhere else it was not built.

The conclusion is uncomfortable for everyone, including us. This is not a technology gap. It is not waiting on a cryptographic advance, a new authenticator form factor, or a standards body finding the right abstraction. The mechanism has been demonstrated twice in production at national scale. What is missing is the requirement, and where there is no requirement there is no product manager willing to add a step to a checkout flow in exchange for a benefit that accrues mostly to the dispute process eighteen months later.

If you take one thing from this page, take that. When someone says binding authentication to the transaction is impractical, the answer is that half a billion Europeans do it every time they pay online.

What this page does not claim

Several honest limits apply to the whole argument, not to any single row of the table.

A gap is not a defect. Every specification here is bounded, and being bounded is what makes a specification useful. Criticising WebAuthn for not proving transaction intent is like criticising a lock for not knowing who should have a key. The failure is in the inference drawn by integrators, not in the document.

Composition is harder than the diagrams suggest. Saying that two standards should compose is easy. Making an authorization server, a card network, a registry and a relying party agree on a shape is years of work involving parties with divergent incentives, and anyone who has sat in a working group knows the technical portion is the small part.

More proof is not free. Every binding adds a step for a human who did nothing wrong. The entire art is choosing the small set of actions where the cost is justified, and a proposal that gates everything will be switched off within a quarter, deservedly.

Our own drafts are drafts. We have filed specifications for receipts and delegation chains at the IETF and the OpenID Foundation. Filed is not ratified, it is not adopted, and it confers no authority whatsoever. Treat them as a proposal from an interested party, which is what they are, and hold them to the same standard as everything else in the table.

A signature does not fix persuasion. Where a human genuinely intended an action, binding the authentication to it changes nothing about the outcome. That is why the payments rows above distinguish carefully between unauthorised transactions, which this addresses, and authorised push payment scams, which it does not.

Reading paths

If you are an identity architect

Start with passkeys prove the login for the core distinction, then zero trust proves posture for how it appears inside the best available architecture, then rich authorization requests for the composition point in OAuth, and the seven layers of trust for the layering model.

If you build payments

Read 3-D Secure proves the device first for the dynamic linking contrast, then Confirmation of Payee for the limits of destination checking, then AP2 proves the mandate and the token proves the agent may pay for where agent commerce is heading.

If you work on supply chain security

Begin with Sigstore proves the pipeline, then who signed the decision to publish, then who approved this deploy for the change management evidence problem, and C2PA proves the camera for the same structure in a different domain.

If you participate in standards work

Read verify without calling the issuer for the revocation history, then credential zombies and conflicting attestations for two vocabulary gaps worth chartering work on, then trust across borders for why registries rather than formats are the constraint, and the Identity Failure Map for a taxonomy you are welcome to argue with.

How to use this table in a vendor evaluation

1. Ask which of the three questions the product answers: who is this principal, may they do this, or did a human intend this. Most answer one and market as though they answer all three.
2. Ask what artifact survives the interaction, and who can verify it without the vendor's cooperation.
3. If a vendor cites a standard, read the standard's own statement of scope before accepting the inference. The specifications are usually more honest than the datasheet.
4. Ask which failure from the taxonomy the product closes, by name. A vendor who cannot answer that has not thought about it.
5. Ask what the product does when the user's device is already compromised, and treat any answer other than "nothing" with suspicion.
6. For anything claiming offline verification, ask them to verify a sample artifact with the network disconnected, in front of you.

The developer documentation sets out our own answers to those questions, and the signing demo lets you run the offline verification test above against a real artifact rather than taking our word for it.

Frequently asked questions

Are you saying these standards are broken? No. Each answers its own question correctly, and several are among the best engineering the industry has produced. The argument is that practitioners assume the questions overlap more than they do, and the space between them is where the losses now occur. A bounded specification is a good specification.

What is transaction binding, in one sentence? Deriving the authentication challenge from a hash of the specific operation being authorised, so the resulting assertion is valid only for that exact payload and cannot be replayed against a substituted amount or payee.

Why did FIDO transaction confirmation never ship broadly? The mechanism was discussed early in the FIDO work and did not reach wide deployment, for reasons that appear to have involved authenticator diversity and user experience as much as protocol design. The practical consequence today is that the property exists in the literature rather than in the field, which is why regulation had to supply it in the two domains where it exists.

If PSD2 solved this, why is it not everywhere? Because dynamic linking applies to in scope payments under one regulatory regime. Nothing prevents a bank, exchange or platform outside that scope from implementing the same property, and the observation of this page is that almost none do, which suggests the constraint is incentive rather than difficulty.

Does Web Bot Auth solve agent identity? It solves agent authentication, which is a real and necessary piece. It establishes which software sent a request. It does not establish that a human authorised the action, so a legitimate signed agent under an attacker's control produces valid signatures. The two properties compose and neither substitutes for the other.

How does this relate to Verifiable Credentials? Verifiable Credentials describe attested attributes about a subject. A transaction receipt describes one human's commitment to one action's payload at one moment. They address different questions and compose cleanly, which is why we publish our formats openly rather than keeping them proprietary.

What should a standards body actually charter? Two things stand out from this page. A vocabulary for expressing conflict, provenance and confidence when issuers disagree, which does not exist today. And a profile for binding an authentication assertion to a canonical operation payload, which several communities keep reinventing incompatibly because there is no common shape to point at.

Is Manav proposing to replace any of these? No, and a proposal to replace them would not be credible. The contribution is narrow: an action receipt that composes onto existing authentication, payment and provenance standards. Our drafts are filed at the IETF and the OpenID Foundation, filed is not ratified, and they should be judged as a proposal from an interested party.

Sources

1. W3C, Web Authentication (WebAuthn) Level 3: w3.org/TR/webauthn-3
2. FIDO Alliance specifications index: fidoalliance.org/specifications
3. European Banking Authority, regulatory technical standards on strong customer authentication under PSD2: eba.europa.eu
4. IETF, RFC 9396, OAuth 2.0 Rich Authorization Requests: rfc-editor.org/rfc/rfc9396
5. IETF, RFC 8628, OAuth 2.0 Device Authorization Grant: rfc-editor.org/rfc/rfc8628
6. IETF, RFC 9421, HTTP Message Signatures: rfc-editor.org/rfc/rfc9421
7. IETF, RFC 8785, JSON Canonicalization Scheme: rfc-editor.org/rfc/rfc8785
8. US DEA, 21 CFR Part 1311, electronic prescriptions for controlled substances: ecfr.gov, 21 CFR Part 1311
9. NIST SP 800-63 Digital Identity Guidelines: pages.nist.gov/800-63-3
10. NIST SP 800-207 Zero Trust Architecture: csrc.nist.gov, SP 800-207
11. W3C, Verifiable Credentials Data Model 2.0: w3.org/TR/vc-data-model-2.0
12. C2PA specifications: c2pa.org/specifications
13. Sigstore documentation: docs.sigstore.dev
14. Regulation (EU) 2024/1183, European Digital Identity Framework: eur-lex.europa.eu/eli/reg/2024/1183/oj

When someone tells you that binding authentication to the transaction is impractical, the answer is that half a billion Europeans do it every time they pay online. The mechanism was never the obstacle.