Manav.id
Spec

Statement draft

The statement wire format, canonical form and rules R1–R6.

draft-manav-statement-00 — The Manav Statement (Internet-Draft, informational, work in progress)

Last updated 24 September 2026

Abstract. A Statement is a relying-party-signed description of an action that a human will be asked to confirm. It carries the action's machine-readable fields and the exact human-readable rows to be displayed, and it is valid only if the rows are a complete function of the fields (total rendering). This document specifies the wire format, canonicalisation (RFC 8785 with an integer-only restriction and Unicode safety rules), the relying-party signature, and the validity rules R1–R6. It is the input to the seen-and-signed ceremony described in draft-manav-receipt.

Status. Wire format frozen at manav-stmt/1. Changes are additive and versioned. Reference implementation: core/Statement.php, js/manav-crypto.js. Conformance vectors: tests/vectors/.

  1. Terminology — RFC 2119 key words. "Relying party" (RP): the system that will execute the action. "Issuer": the party that runs the ceremony and countersigns receipts. "Approver": the human.
  2. Object — see Statement reference for the member table. All times RFC 3339 UTC Z; all numbers integers; money as fixed-precision strings with ISO 4217 currency.
  3. Canonical form — RFC 8785 JCS over the object without rp_sig; key order by UTF-16 code unit; floats MUST be rejected; strings MUST be NFC and MUST NOT contain bidi controls, default-ignorable code points or mixed scripts (§3 of Canonical reference).
  4. Rules — R1 total rendering; R2 schema pinning (source.schema_hash = SHA-256 of the JCS form of a published schema; field names and types MUST match); R3 RP pre-signing (Ed25519 over the canonical form); R4 no lossy abbreviation (masked values carry full_hash); R5 frozen canonicalisation; R6 exp − nbf ≤ 300 s, one_shot: true, nonce consumed once.
  5. Type registry — money, string, flag, enum, uri, account, digest, int, datetime, list, scope, budgets, each with exactly one render function. Action types MAY define their own render function for the whole statement (workload.grant does), in which case the render MUST equal that function's output.
  6. Security considerations — a statement binds display to payload only if the RP signs before any browser is involved (R3) and the issuer enforces R1 without an override; homoglyph and invisible-character attacks on rendered values are the cheapest attack on the design and are refused by R5, which MUST ship with a conformance suite. The statement proves nothing about comprehension.
  7. IANA considerations — none. Schemas are published by each issuer at /.well-known/manav-schemas/<action>.json.

← All specification documents