Transaction signing and dynamic linking

Authenticating a session is not approving an operation#

Conventional multi-factor authentication answers one question: is the person at the keyboard the account holder? A one-time code or a tap on a push notification establishes that, and the result is a session. Everything done within the session inherits it.

The attacks that cause the largest losses operate inside that session. A real-time phishing proxy relays the victim’s login to the genuine service, completes the second factor along with it, and then submits its own payment. Malware in the browser changes the payee of a transfer after the user has entered it and before it is sent. In both cases the authentication was valid. What was missing was any proof that the user agreed to the operation that was actually executed.

Transaction signing addresses that gap by authenticating the operation itself. The approval is a signature over the operation’s content, produced on a device the attacker does not control, after the content has been shown to the user there.

The property, stated precisely#

The objective is usually called what you see is what you sign. For an approval mechanism to have it, three conditions must hold:

1. Display and signature cover the same content. The text presented to the user on the approving device is the text over which the signature is computed, without a separate channel that could show one thing and sign another.
2. Any change invalidates the approval. If the content is altered after display — one digit of the amount, one character of the account number — the signature no longer verifies.
3. An approval is used once. A signature produced for one request cannot be presented again for the same or a different operation.

The second device matters as much as the cryptography. If the content is displayed by the same browser that an attacker controls, the user sees whatever the attacker renders. Moving display and signing to a separate phone, with the key held in that phone’s secure hardware, puts both outside the compromised environment.

PSD2 dynamic linking#

European payment regulation states the same requirement in its own terms. Article 5(1) of the regulatory technical standards on strong customer authentication, Commission Delegated Regulation (EU) 2018/389, requires for remote electronic payments that the payer is made aware of the amount and the payee; that the authentication code is specific to that amount and payee; that the code accepted corresponds to them; and that any change to the amount or the payee invalidates the code. This is known as dynamic linking.

The conditions map onto the property above. When the amount and the payee are part of the text a relying party sends for display, Ydentifi’s signature is specific to them, and a change to either produces a signature that does not verify. Whether a payment service provider’s strong customer authentication as a whole meets the standard depends on its full implementation, including the independence of the authentication elements and its own processes, and is assessed by that provider. Ydentifi supplies the signing mechanism; it does not certify compliance.

How Ydentifi signs an approval#

1. Issue. The relying party’s backend calls IssueAuthChallenge with the text to display, the minimum authentication strength the operation requires, and optionally number matching and a location condition. See Authorize an action.
2. Display. The challenge reaches the user’s enrolled phone over the stream the phone holds open to the deployment, with no third-party push in the path; see MFA without platform push. The authenticator shows the exact text the relying party sent.
3. Check. The user passes the check the operation requires: a device unlock, or a biometric with no passcode fallback. With number matching, the user also types the number shown on the relying party’s screen, which ties the approval to the screen where the operation started. See Factors & levels.
4. Sign. The phone signs a canonical payload: the challenge identifier, a SHA-256 digest of the displayed text, the verdict, and the strength actually achieved. The signing key is an ECDSA P-256 key generated in the phone’s secure hardware — the Secure Enclave on iOS, StrongBox or the TEE on Android — and never exported. A device enrolled for post-quantum signing adds an ML-DSA-65 signature over the same digest; see Post-quantum MFA.
5. Verify. The deployment verifies the signature against the public key recorded at enrollment, refuses an approval below the requested strength, and moves the challenge to exactly one terminal state. The relying party receives the verdict and the strength reached over AwaitChallenge.

Because the challenge identifier is inside the signed payload and a challenge resolves once, a signature cannot be replayed. Because the text is hashed into it, a signature cannot be moved to different content. The canonical payload is described in The ceremony.

What the relying party must supply#

The signature covers what the relying party sends for display, and only that. Two obligations follow.

• Every decision-relevant field belongs in the text. For a payment, that is at least the amount, the currency and an identifier of the payee that the user can recognise. For a configuration change, it is the system, the setting and the new value. A field left out of the text is a field the approval does not cover.
• The executed operation must be the approved one. The backend should keep the operation it intends to execute alongside the challenge identifier, and execute that record, unchanged, only after the challenge resolves as approved.

Strength is chosen per operation. A login may ask for a device unlock; a change of payee details, a biometric; a payment above a threshold, a biometric with number matching and a location condition. The decision belongs to the relying party’s backend, which is the only component that knows what an operation is worth.

What the signature does not cover#

• Content composed by a compromised backend. The signature proves that the user approved the text shown. If the relying party’s backend is itself compromised before it issues the challenge, the text can be wrong at the source, and the user will be asked to approve it as written.
• A login relayed unchanged. A look-alike site can pass a plain sign-in request through to the real service; the request on the phone then looks normal. Transaction signing protects the operations that follow, where the content differs from anything the attacker could have shown the user. A relaying proxy also shows the victim the number to match, so number matching does not help here either; for sign-in, an origin-bound login such as a passkey covers this case. See On passkeys.
• The user’s judgement. A signature records consent to the displayed text. It cannot establish that the user understood it, or that they were not deceived about why the payment was needed.

Pricing depends on the number of users, not on the number of operations signed; an organisation that signs every payment pays the same as one of the same size that signs only logins. See pricing, the product page, and the quickstart to run the ceremony locally.