FIDO2 assertion versus transaction submission

1. What the WebAuthn assertion signs

A WebAuthn assertion is a signature, produced by the authenticator, over the concatenation authenticatorData ‖ SHA-256(clientDataJSON) [1, §6.3.3]. authenticatorData carries the relying-party-id hash, flags, and signature counter. clientDataJSON is constructed by the client (the browser or platform WebAuthn binding) and contains three load-bearing fields: type (set to webauthn.get for an assertion), challenge (the server-issued nonce), and origin (the page or app origin presenting the prompt).

The assertion proves three things to the relying party: that the private key bound to a known public credential was available to the authenticator, that the user verification flag — if requested — was satisfied at the moment of signing, and that the signature was produced for the specific challenge the relying party issued. The WebAuthn specification calls this combination phishing-resistant authentication [1, §1.2]. It is exactly that, and it is well implemented across browsers and platforms.

2. What the assertion does not sign

clientDataJSON does not contain the transaction body. Amount, beneficiary, idempotency key, and all the other parameters that make a transaction a transaction are absent from the structure the authenticator signs. WebAuthn Level 1 [§10.3] defined a transaction confirmation extension family — txAuthSimple and txAuthGeneric — registered in the WebAuthn extensions registry at the time. The extensions were not retained in Level 2 and have negligible authenticator support. CTAP [2] defines the on-the-wire extension transport, but the canonical txAuth definitions are in WebAuthn. In current production deployments — across consumer banking, payments, and corporate single sign-on — these extensions are effectively unused.

A successor effort, W3C Secure Payment Confirmation (SPC), specifically targets transaction binding for payments — the relying party shows the user a payment instrument and amount on a browser-controlled surface, the authenticator signs an SPC-specific assertion bound to that displayed payload, and the issuer verifies. SPC is in early production deployment by some card schemes and is the standards-track successor for “WebAuthn does not bind the transaction body” in payment flows.

In the absence of the extension, the assertion is a proof of who and that they pressed; it is not a proof of what they pressed for. The transaction body is committed to elsewhere: in an authenticated session, in a co-signed JWT, in a backend-side state machine. None of those layers is FIDO2.

3. What runs in the gap

Between the moment the authenticator returns the assertion and the moment the settlement message reaches the acquirer or scheme, the device executes:

• Payload assembly. The application reads form fields, applies client-side validation, normalises currency or beneficiary identifiers, and serialises the payload.
• Final user confirmation. The application renders the values the user is about to send and waits for an explicit confirm. This is the rendered values, not the structurally-bound values: what the screen shows and what the network receives are the same only by application convention, not by cryptographic guarantee.
• Submission. The application places the payload on the wire, often via an authenticated session whose binding to the prior assertion is by cookie, header, or token — not by signature.

A class of mobile-runtime attacks operates inside exactly this window: parameter tampering after user confirmation, overlay-driven substitution of the rendered values, accessibility-service-driven input synthesis. None of these attacks defeats the FIDO2 assertion. They do not need to. They operate on the layer above, where FIDO2 no longer applies.

4. The PSD2 dynamic-linking parallel

European Banking Authority guidance on PSD2 SCA, codified in Commission Delegated Regulation (EU) 2018/389 Article 5 [3], requires the authentication code to be dynamically linked to the amount and the payee of the specific transaction. WebAuthn, without a transaction-confirmation mechanism, does not by itself satisfy dynamic linking — the EBA Single Rulebook Q&A on PSD2 clarifies repeatedly that the authentication mechanism must produce a code that changes if the amount or payee changes. Operators who deploy WebAuthn for SCA in the European context build the dynamic-linking guarantee in a layer above the assertion: server-side construction of a transaction-bound challenge, or co-signing the transaction body with a separate device-bound key.

The architectural point is the same one the FIDO Alliance and the EBA both make in different language: the assertion is not the transaction. The gap between them is where Execution Evidence Infrastructure (EEI) — the device-identity infrastructure layer for banking and payments — produces a signed account of payload assembly, user confirmation, and submission, bound by hash chain and hardware-backed key.

5. Cross-references

• Sibling articles in this theme: the-play-integrity-gap, the-emv-execution-gap, the-sca-settlement-gap
• Architecture: /architecture/runtime-coherence, /architecture/evidence-token
• Glossary: /glossary — Evidence Token, Runtime Coherence

6. External references

[1] W3C. Web Authentication: An API for accessing Public Key Credentials, Level 2. www.w3.org/TR/webauthn-2/. Cited 2025-09-23.

[2] FIDO Alliance. Client to Authenticator Protocol (CTAP) v2.1. fidoalliance.org/specs/fido-v2.1-ps-20210615/. Cited 2025-09-23.

[3] European Commission. Commission Delegated Regulation (EU) 2018/389 — Regulatory Technical Standards on Strong Customer Authentication and Common and Secure Open Standards of Communication, Article 5 (Dynamic Linking). eur-lex.europa.eu/eli/reg_del/2018/389/oj. Cited 2025-09-23.