What they saw is
what they signed.
An approval is only worth what the person was actually shown. Yuthent renders the approval surface outside the calling application's control and signs the rendered content itself, so the gap between what appeared on screen and what reached the server closes.
A signature over a request the user never saw proves nothing about consent.
The user approved a screen. The server executed something else.
Malware, a malicious overlay, a compromised web view, or a manipulated render changes what appears at the moment of approval. The person confirms a fifty-euro payment to a known payee. The request that reaches the server carries a different amount and a different destination. Every authentication control in the path passes, because the person really did approve, they approved a lie.
In-app confirmation screens
Drawn by the same process that constructs the request. If that process is compromised or manipulated, the screen and the request diverge and nothing detects it.
OTP and push notifications
The code confirms a channel, not a transaction. Most implementations show a generic prompt, and the ones that show detail still bind nothing cryptographically to it.
TLS and request signing
Protects the request in transit and proves it left the client intact. Says nothing about whether the client constructed the request the user intended.
Screenshot and audit-trail capture
Produces an image the same compromised process supplied. Evidence generated by the untrusted party is not evidence.
The approval surface is not yours to draw.
The screen the person approves is rendered from server-supplied content, in a context the calling application cannot compose over or read back.
The server composes the content
Your backend defines what the person must see: amount, counterparty, scope, consequence. Not the client, and not the agent making the request.
The device renders it protected
The SDK presents the content on a surface the calling app cannot overlay, screenshot or modify, using platform protections for secure display and overlay rejection.
The signature covers the render
The hardware-bound key signs a hash of the exact content displayed, together with the action parameters. Display and request are one object, not two.
The server checks both halves
Verification confirms the signature is valid and that the content hash matches what the server sent to be shown. A mismatch is a refused action, not a warning.
The record includes what was on screen.
display_hash
Hash of the exact content rendered to the person. Reconstructable and comparable against what your server intended to display.
action_hash
Hash of the action parameters. Bound into the same signature as the display, so the two cannot be separated after the fact.
overlay_state
Platform attestation that no foreign window was composited over the approval surface while it was presented.
render_context
Which secure display path was used, so a verifier knows the assurance level of the presentation, not just of the signature.
user_verification
Biometric verification performed on-device at the moment of the press, attested by the operating system.
Where the display is the control.
Payment confirmation
PSD2 Article 97 dynamic linking requires the payer to be shown the payee and amount, and the authentication code to be bound to both. This produces that binding.
Clinical and legal sign-off
Prescribing, ordering, releasing records. The record shows not only who signed but precisely what was in front of them.
Agent-initiated requests
When an agent composes the request, the person still needs to see the truth. The rendering path does not run through the agent.
Answered plainly.
Does this mean we cannot brand the approval screen?
You control the content and the presentation within the protected surface, including your branding. What you cannot do, and what the guarantee depends on, is have the calling application compose arbitrary layers over it or alter it after the server defines it.
What happens on a rooted or jailbroken device?
Device integrity is part of the attestation. Your policy decides: refuse, downgrade the tier, or accept with the compromised state recorded in the proof. The important property is that the verifier knows, rather than assuming a clean device.
Is this different from a trusted execution environment display?
It uses the platform's strongest available display protections and records which one was used. On hardware that offers a genuine protected display path it uses it. Where the platform offers less, the proof states that rather than overclaiming.
Does the user notice a different experience?
They see one clear screen stating exactly what they are approving, then a biometric press. Most people read it more carefully than an in-app dialog, which is the point.
Put it on one flow first.
Tell us the action you need proof for. We come back with a working integration proposal and a signed sample you can verify yourself. First call within five business days.