Summary

  • Revision 01 of an individual Internet-Draft now says that deterministic rendering can detect a mismatch between signed action bytes and a claimed rendering, but cannot prove what an untrusted screen actually showed a human.
  • It requires relying parties to keep receipt verification and presentation-evidence verification separate, and forbids treating either successful check as automatic authorization.
  • Daniel Kade proposes a presentation-decision record that binds both evidence results to client trust, human mandate, residual risk and the organization’s own decision. This is editorial governance analysis, not an Internet-Draft requirement.

The revision removes an unsafe shortcut

The strongest news in draft-schrock-ep-presentation-binding-01 is a subtraction. The 00-to-01 comparison retreats from language suggesting that a verifier could prove what a person was shown. The new text says something narrower and more defensible: a verifier can determine whether a submitted deterministic rendering is consistent with the signed action. That still does not establish what appeared on a compromised display, beneath an overlay or through another channel the protocol cannot observe.

The revision makes a second precision edit. Where the first version described a named person producing a user-verified signature, revision 01 says an enrolled key did so. That is the cryptographic fact. Associating the key with a person, establishing that person’s organizational role and deciding whether the role covered this action all require other evidence and policy.

These changes matter because an approval system can return several green indicators while answering different questions. A receipt signature may prove that a key covered an exact action digest. A deterministic renderer may reproduce byte-identical human-readable output from that action. A display attestation may validly bind a client’s claim about the rendering to the action. None of those facts, alone, proves that the human perceived the content or held authority to approve it.

The Datatracker record lists revision 01 as an active individual Internet-Draft updated on 12 September 2026. It has no IETF stream, working-group status, responsible Area Director or recorded intended RFC status. Anyone may submit an Internet-Draft; this proposal has no IETF endorsement or formal standards standing.

Reproducible rendering is evidence, not perception

The draft defines the renderer as a pure function over a canonical action. Equal actions must yield byte-identical output on every conforming runtime, in every locale and at any time. The renderer cannot consult a clock, ambient locale, environment, randomness or external input. It consumes a fixed ordered set of fields—such as action type, target, organization, amount, currency, policy and risk signals—and produces both a human-readable representation and a digest.

That design can expose a useful class of attack. If the signed action commits to one amount but the claimed rendering carries another, re-derivation fails. RFC 8785 supplies the cited JSON canonicalization basis. Revision 01 also requires deterministic treatment of bidirectional controls, control characters, homoglyph-bearing sequences and excessive length; a value that cannot be safely rendered must be refused rather than silently shortened or guessed.

But reproducibility is not a camera. A malicious client could submit the exact rendering that a verifier expects and simultaneously put different pixels in front of the human. The draft now states this residual risk directly. Its display attestation is therefore only a signed client claim: “this rendering was shown for this action.” Verifying that claim proves its signature and linkage. Trusting the client and display path is a separate appraisal.

Revision 01 gives the boundary normative force. Receipt verification and presentation-evidence verification must be evaluated as separate results under independently selected trust inputs. A valid receipt must not be promoted to “presentation accepted” merely because its signature checks. Valid presentation evidence must not be promoted to authorization merely because its display binding checks.

Hardware can narrow the gap without eliminating governance

The draft points to Android Protected Confirmation as one possible separately profiled mechanism, while making clear that it does not define that profile. The official ConfirmationPrompt documentation describes a hardware-assisted path in which a relying party checks an attested public key, a fresh nonce and the exact prompt text returned after confirmation. It also says dedicated hardware is required and the facility may not always be available; even a device reporting support can fail to present a prompt in some conditions.

That example illustrates why a generic “hardware backed” badge is insufficient. A relying party needs to know which root it trusted, what the attestation asserted, which prompt bytes were bound, whether the nonce was fresh, what material fields were actually displayable and which fallback path ran when protected confirmation was unavailable. The Android documentation itself emphasizes checking the prompt text because that is the content the user approved.

The same discipline applies to the draft’s claimed public reference implementation. Code and negative test vectors can demonstrate that one renderer rejects a mismatched or unsafe input. They do not demonstrate deployment prevalence, independent review, an uncompromised display path or organizational authorization. Revision 01 requests no IANA action; identifier registration is left for future work.

Preserve the decision that evidence informed

Daniel Kade proposes a presentation-decision record owned by the relying organization. It should preserve the action digest, receipt profile and verification result; renderer profile, version, canonicalization rules, locale and exact material fields; rendering digest and display-attestation result; client identity, attestation chain, trusted root and display-path class; enrolled-key-to-person evidence; the person’s role, mandate and limits; residual-risk classification; independent authorization policy and outcome; reviewer; timestamp; expiry; fallback or refusal path; and triggers for re-evaluation.

The record is intentionally not another universal approval token. It is a visible join between evidence generated elsewhere and a decision made under local authority. A bank may require a hardware-protected prompt for a large transfer. A network operator may accept a deterministic rendering plus out-of-band confirmation for a reversible maintenance task. Another organization may refuse entirely when a required display path is unavailable. The shared evidence can be portable while the consequence remains local and explicit.

This follows Heng Lu’s Minimum Initial Specification: standardize the smallest auditable evidence surface without pretending to standardize every future decision. The Policy Mirror supplies the companion discipline—record what each authority actually asserted, not what a later system wished the assertion meant. Why BTW Media Exists keeps the reporting boundary clear: an individual draft’s correction is news; adoption, deployment and proof are separate events.

Sources

  1. Presentation Binding Datatracker record
  2. Presentation Binding revision history
  3. Datatracker metadata API
  4. Presentation Binding revision 01
  5. Presentation Binding revision 00
  6. Official revision diff
  7. Authorization Receipts record
  8. Authorization Receipts revision 13
  9. RFC 8785
  10. Android ConfirmationPrompt API
  11. Android Protected Confirmation
  12. Android key attestation
  13. The Policy Mirror
  14. Minimum Initial Specification
  15. Why BTW Media Exists