What You See Is What You Sign, on Mobile: The Two Halves of the Promise
What-you-see-is-what-you-sign sounds like one guarantee. It is two. The first half: the signature covers the real transaction, so what was signed is what was sent. The second half: the screen showed the human the same thing the signature covers. Conflating the two halves is how signing products overclaim.
Half one closes cryptographically
The action parameters, amount, recipient, action type, are hashed into the payload and signed in hardware on the enrolled device. A parameter mutated after approval breaks the proof. There is no opaque token in the middle: what is signed is the action itself. This half is closable in full, and Yuthent closes it.
PSD2's dynamic linking (RTS Art 5) encodes exactly this half for payments: the amount and payee are bound into the authorization, and a change invalidates it.
Half two has an owner
Display integrity asks a different question: did the pixels the human saw match the payload the device signed? That surface lives in the relying party's UI, by design. The rendering code is the app's code.
What the platform contributes at that boundary is signal: device attestation confirms an untampered app on untampered hardware, and the trust engine's detection surface reports the known attacks on the rendering path: overlays, screen mirroring, accessibility-service abuse, and remote-control tooling. Signal on this half, closure on the other. We state which is which.
Why mobile changes the equation
The previous generation of WYSIWYS lived on dedicated signing hardware with its own small screen, a separate trust domain for the display. Mobile trades that screen for something stronger and something weaker at once. Stronger: the key lives in the Secure Enclave or StrongBox, the biometric is OS-mediated, and attestation covers the whole stack. Weaker: the display is the same OS the rest of the app lives in. The honest architecture accepts the trade and names the boundary rather than papering over it.
What a trusted display would take
Full closure of half two would require a display path with its own trust root. The category answer exists. Android defines one in Protected Confirmation, a confirmation surface rendered from the trusted execution environment rather than by the app, but hardware adoption is marginal. iOS has no OS-level equivalent. Dedicated-screen signing hardware solves it by owning the display outright, at the cost of being dedicated hardware. Stated plainly: no vendor closes single-device WYSIWYS on stock mobile hardware today. The honest ceiling for a mobile SDK is the strongest attestation and detection posture underneath an app-owned display.
The claim ladder
Three claims, in descending strength. That the signature binds the exact action: full, cryptographic. That the untampered app on an untampered device received exactly those parameters: attested, overlay-checked. That the human read and understood them: no vendor can claim this, and we do not.
Common questions
What does the signature actually bind?
The canonical action payload: amount, recipient, action type, hashed and signed in hardware. A post-approval mutation invalidates the proof.
Can malware change what I see?
Overlays, screen mirroring, accessibility-service abuse, and remote-control tooling target the display surface, and the trust engine detects and reports them as signals. The rendering itself belongs to the relying party's UI, and we say so.
Why isn't the OS biometric prompt enough?
BiometricPrompt and LAContext gate the key. They prove a person passed the biometric check before the key signed. The OS does not attest the app-rendered parameters around the prompt: the screen above and below the biometric sheet belongs to the app. That gap is half two.