Summary

  • EP-QUORUM revision 03 hashed the predecessor’s context, so an orchestrator could prepare the whole chain before any signature existed and collect signatures in reverse.
  • Revision 04 makes a successor sign a digest of the complete predecessor signoff, including the actual signature, and rejects legacy or mixed chains under the strong profile.
  • The repaired link proves dependency between proof artifacts under stated cryptographic assumptions. It does not prove trusted time, faithful display, human comprehension, final authorization, execution or effect.

A signature can be valid and still tell the wrong story about sequence. That is the lesson inside draft-schrock-ep-quorum-04, an Individual Submission filed on 6 September. The draft does something standards work should do more visibly: it names an earlier security claim as unsound, breaks compatibility with the weak construction and narrows the replacement claim to what the bytes can support.

Revision 03 offered an ordered quorum for high-risk agent actions. Every later approver’s signed context contained prev_context_hash, the digest of the previous approver’s context. The text said this proved that the later approval followed the earlier one.

But a context is not a signature. An orchestrator could generate all contexts in advance because each predecessor context was already known. It could then ask the final person to sign first, work backwards through the roster and finally present the signatures in the expected order. Every signature could verify. Every context link could match. The supposed chronology would still be theatre.

The repair moves the dependency

Revision 04 defines EP-QUORUM-SIGNOFF-CHAIN-v1. Instead of hashing only the predecessor context, it hashes the complete predecessor signoff JSON object, including its actual signature. The construction uses a domain separator, one zero octet and the UTF-8 JSON Canonicalization Scheme representation before SHA-256. The successor carries that result as prev_signoff_hash inside its own signed context.

Now the successor proof cannot be completed until the predecessor proof exists. A different valid signature over the same predecessor context produces a different link, so substitution requires a new successor signature. The first context must omit the predecessor field. Null-first, legacy-context, mixed-link, missing-profile, unknown-profile and broken-link cases fail the strong-chain check.

That is meaningful progress. It is also a deliberately limited result. The link creates causal dependence among proof artifacts under signature-unforgeability and hash preimage/collision-resistance assumptions. It does not install a trusted clock. The issued_at window remains asserted metadata. Nor does the hash show what appeared on screen, whether the successor read the earlier decision, understood the action, acted voluntarily or resisted a misleading orchestrator.

Authority still enters from outside

The draft’s gate checks policy shape, valid signoffs, exact action binding, roster roles, distinct human identifiers, distinct public keys, threshold, order, the optional strong chain and the asserted approval window. A real enrolled signer in the wrong role does not count. One key enrolled under two names does not become two people. A partial trail authorizes nothing.

Yet the artifact cannot appoint its own authority. The relying party must obtain the expected policy and approver directory from authenticated sources outside the supplied quorum. The base receipt draft is equally precise: an enrolled key proves that the key assigned to an approver identifier signed; the mapping from that identifier to a natural person belongs to the directory’s identity-proofing layer.

The final boundary is operational. Incremental admission can reject a bad member early, but the executor must recompute the whole gate because it does not trust the orchestrator’s admission work. Even a satisfied gate remains approval evidence. A local relying party still decides whether the action is authorized, the executor still has to perform it, the target still has to change as intended, and one-time consumption still has to prevent reuse.

Tests are receipts, not adoption

Revision 04 says JavaScript, Python and Go verifiers agree over a shared corpus, including reverse-signed legacy chains and predecessor-signature substitution. That is useful same-team consistency evidence. It is not a clean-room implementation, formal proof, interoperability event or production deployment. The document is Informational work in progress, has no IANA action and carries no IETF consensus merely because it sits in the Datatracker.

This restraint matches a thin-specification principle: standardize the smallest common invariant—the successor must depend on the completed predecessor proof—while keeping organizational authorization, human procedure and operational effect visible as separate decisions. A cryptographic chain should prevent evidence from being rearranged into a false sequence. It should not become a machine for laundering a green verdict into institutional truth.

Sources

  1. IETF Datatracker document record
  2. EP-QUORUM, revision 04
  3. EP-QUORUM, revision 03
  4. EP Authorization Receipts, revision 12
  5. RFC 8785: JSON Canonicalization Scheme
  6. Web Authentication: Level 2
  7. RFC 2119: Requirement-Level Keywords
  8. RFC 8174: Uppercase and Lowercase Requirement Keywords
  9. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  10. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  11. Running-Code Primacy