EMILIA Protocol, Inc.

US team@emiliaprotocol.ai

sec human authorization WYSIWYS presentation attack AI agents A human-authorization receipt proves an enrolled key produced a user-verified signature over a digest that commits to an exact action. It does not prove the signing surface DISPLAYED that action honestly. If a signing interface shows a benign summary while committing a different action, the resulting receipt is laundered authority: cryptographically valid and semantically false, which is worse than no receipt at all. This is the presentation attack, and it is the deepest unsolved problem in authorization evidence, because a signature cannot attest to pixels. This document narrows the gap with two additive, offline-checkable pieces that touch no existing receipt format: a DETERMINISTIC RENDERER, a pure function from the canonical action to a byte-identical human-readable rendering, so a verifier RE-DERIVES the rendering from the signed bytes and rejects a claimed rendering that does not match; and a DISPLAY ATTESTATION, a signed claim by the signing client binding the rendering it showed to the action it committed. Neither eliminates the presentation attack (nothing purely digital can), but together they let a verifier check the claimed rendering against the signed action under relying-party-selected client trust inputs. They make the residual risk explicit rather than hidden.

Introduction Signature verification alone does not establish what an approver was shown. An enrolled key signed a digest; the digest commits to an action; but the human did not see the digest; they saw a screen, and the screen was drawn by software. If that software rendered "approve invoice, $1.00" while committing "wire $82,000 to account X", the receipt is perfect and the authority is fabricated. Every downstream layer — composition, sufficiency, recourse — inherits this weakness: they compose and grade a receipt whose meaning was set by an unattested rendering step. Two observations make the problem tractable without overclaiming. One presentation-attack pattern is a RENDERING mismatch: the surface computes the display from something other than the signed action. A verifier can detect that mismatch when the submitted rendering or attestation records it, because a rendering can be made a PURE FUNCTION of the signed action and re-derived by any verifier. Second, the residue (a compromised or malicious client that renders honestly to a verifier's re-derivation while showing the human something else out of band) cannot be closed by any digital artifact and MUST be stated as residual risk, not papered over. This document does the first and is scrupulous about the second.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

The Deterministic Renderer A conforming renderer is a PURE FUNCTION from a canonical action object to a rendering. For any two canonical actions that are deeply equal it MUST produce byte-identical output on every conformant runtime, in every locale, at any time; it MUST NOT read the clock, locale, environment, randomness, or any I/O. It reads a fixed, ordered, closed set of action fields (for example: action type, target, organization, initiator, policy, amount, currency, requested-at, risk signals), each with a fixed label, and produces an ordered list of label/value lines, a concatenated human-readable text, and a rendering digest over the canonical structure. Because the rendering is a pure function of the SIGNED action, a verifier re-derives it from the very bytes the receipt's action digest commits to and compares. A claimed rendering of "$1" for an action that says "$82,000" does not re-derive and is detected offline. This makes consistency between the deterministic rendering and the signed action verifiable; it does not establish what an untrusted surface actually displayed. Handling untrusted content is normative: values that can carry display-manipulating characters (bidirectional overrides, control characters, homoglyph-bearing runs, or excessive length) MUST be neutralized by a specified, deterministic transformation before rendering, and a value that cannot be safely rendered MUST cause the renderer to refuse rather than emit a misleading line. The neutralization is itself part of the pure function, so the verifier re-derives the same neutralized rendering.

The Display Attestation A display attestation (wire tag EP-DISPLAY-ATTESTATION-v1) is a signed claim by the signing client: "I rendered THIS rendering of THIS action." It binds the rendering digest to the action digest under the client's key and is stored ALONGSIDE the receipt (in an audit record, a provenance bundle, or an evidence-graph node), never inside the signed receipt body; verifiers that predate this profile continue to verify receipts unchanged; verifiers that implement it add the display check. For high-stakes action classes a relying party's policy MAY require a valid display attestation and fail closed when it is missing or does not verify. Verified versus accepted applies here too: verifying the attestation (its signature holds and its rendering re-derives from the action) is distinct from trusting the CLIENT that made it. A display attestation records a claim that can be checked and audited; it does not, by itself, make the client honest or make a false display expensive.

Composition with the Evidence Layers Presentation binding is the missing precondition under the rest of the stack. An authorization receipt () gains a rendering that a verifier can re-derive; a binding () that carries such a receipt MAY additionally require the display attestation as part of its digest-grounding requirement; an evidence policy () MAY, for a high-stakes reliance purpose, treat a receipt without a verifying display attestation as insufficient. This document adds a separately verifiable binding between the signed action and deterministic or attested display bytes under relying-party-selected trust inputs. It does not prove what the human perceived.

Residual Risk: WYSIWYS Is Not Solved This profile narrows the presentation-attack surface; it does not eliminate it, and implementers MUST NOT represent it as doing so. A compromised signing client can render honestly to the verifier's re-derivation while presenting a different artifact to the human through a channel the protocol cannot observe (a manipulated display driver, an overlaid window, a coerced approver). Defenses against that residue are operational and hardware-rooted (trusted display paths, out-of-band confirmation of material fields, secure enclaves) and are out of scope here, though supported devices running Android 9 and later can offer Android Protected Confirmation as one separately profiled mechanism. It renders the prompt text in a protected path; a relying party using it must verify the attestation's trusted-confirmation requirement and bind the exact prompt text, because extra data is not displayed. This document does not define that profile. This document makes a mismatch between the signed action and the submitted deterministic rendering detectable. A malicious client can still attest the expected bytes while displaying different content, so that attack can remain cheap and scalable. The relying party therefore has to evaluate the client and display-path trust inputs and account for the residual risk.

Security Considerations The entire document is a security consideration; the residual risk section states the boundary. One further point: the renderer MUST be conservative to the point of refusing. A renderer that guesses at an unmodeled field, truncates silently, or best-effort displays hostile content trades a detectable failure for an undetectable one. Refusal to render is a safe outcome; a misleading render is the attack.

Receipt and Presentation Evidence Remain Distinct Verification of an EP-AUTHORIZATION-RECEIPT-v1 receipt proves that the enrolled key signed the exact covered Authorization Context under that profile. It does not prove that the signing surface faithfully rendered that context to the approver. Presentation evidence narrows this gap only to the extent stated by its own profile: it can bind deterministic or attested display bytes to the same action, but it cannot prove that an uncompromised human perceived those bytes or that a compromised physical display path showed them faithfully. A relying party MUST evaluate receipt verification and presentation-evidence verification as separate results under independently selected trust inputs. A valid receipt MUST NOT be promoted to presentation-accepted merely because its signature verifies, and valid presentation evidence MUST NOT be promoted to authorization merely because its display binding verifies.

IANA Considerations This document has no IANA actions. Registration of the render profile and display-attestation identifiers is anticipated for a future revision.

References Normative References Informative References EMILIA Protocol, Inc. EMILIA Protocol, Inc. EMILIA Protocol, Inc.

Implementation Status A reference implementation (the deterministic renderer, the display attestation, and the offline re-derivation check) is published Apache-2.0 in the EMILIA Protocol repository (lib/wysiwys/render.js) with conformance vectors and a test suite, including negative vectors: a rendering that does not re-derive from its action is rejected, and hostile display content (bidirectional overrides, control characters, over-length values) is neutralized or refused rather than rendered misleadingly.