Presentation Binding for Human-Authorization Receipts: Proving the Human Approved What They Saw

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 4 January 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

The hard part of human authorization was never the signature. It is the question a relying party's counsel asks first: a receipt of WHAT? A named human 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. First, most presentation attacks are RENDERING attacks: the surface computed the display from something other than the signed action. That is defeatable, 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.¶

2. 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 surface that displayed "$1" for an action that says "$82,000" cannot produce a rendering that re-derives; the deviation is detected offline, by anyone, without trusting the surface. This turns "render from the exact hashed bytes, never a re-described copy" from an unverifiable interface rule into a verifiable property.¶

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.¶

3. 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 raises the cost and auditability of a presentation attack; it does not, by itself, make the client honest.¶

4. Composition with the Evidence Layers

Presentation binding is the missing precondition under the rest of the stack. An authorization receipt ([I-D.schrock-ep-authorization-receipts]) gains a rendering that a verifier can re-derive; a binding ([I-D.schrock-human-authorization-binding]) that carries such a receipt MAY additionally require the display attestation as part of its digest-grounding requirement; an evidence policy ([I-D.schrock-ep-action-evidence-graph]) MAY, for a high-stakes reliance purpose, treat a receipt without a verifying display attestation as insufficient. The property this document adds — the human approved what a verifier can prove they were shown, is the one every other layer silently assumed.¶

5. 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 at least one such path ships today: Android's Protected Confirmation renders a prompt in a TEE-isolated display path and signs the exact displayed text under a key restricted to user-confirmed content, with an attestation chain a relying party can grade. Profiling such mechanisms as display attestors for this document's attestation, with assurance graded by the attestation chain, is planned work for a future revision. What this document removes is the CHEAP, SCALABLE, UNDETECTABLE rendering attack — the software surface that simply computed the display from the wrong bytes — and it makes the remaining, expensive residue explicit so a relying party can price it rather than discover it in a dispute.¶

6. 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.¶

7. IANA Considerations

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

Appendix A. 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.¶

Author's Address