Multi-Party Quorum Authorization for High-Risk Agent Actions (EP-QUORUM)

Introduction The base EP authorization receipt closes the gap between "is this actor authorized in general?" and "should this exact action happen, and which accountable human said yes?" by binding one named approver's device-held signature to one exact action (see ). For the highest-consequence actions, one approver is not the right control. The discipline that governs nuclear release, large-value treasury movement, and production-credential change is the two-person rule: no single human -- however well-authenticated, however senior -- can unilaterally cause the action. Two or more distinct, accountable humans must each independently authorize, and the action proceeds only when all of them have. As autonomous agents acquire credentials sufficient for irreversible operations, the two-person rule is exactly the control that lets an organization grant an agent real authority without creating a single point of failure: a compromised, misaligned, or prompt-injected agent cannot act alone, and neither can a single compromised or coerced approver. EP-QUORUM specifies how to express that control as a cryptographic predicate over EP signoffs and how to enforce it both at the moment each approver signs and at the moment the action would execute. The base draft already contemplates multi-approver policies (): each approver signs an individual Authorization Context sharing the same action hash, and commitment occurs only when k valid, distinct signoffs exist before expiry. This document makes that sketch normative and testable. It adds: ordered approval trails (); an explicit role roster and admission semantics (); a bounded approval window with an asserted-time consistency constraint for ordered mode (); an incremental server-side admission rule that keeps a non-conforming signer out of the trail in the first place (); the consolidated fail-closed quorum predicate (); and an adversarial conformance suite ().

Design Goals EP-QUORUM inherits design goals G1-G7 of the base draft and adds:

Q1 -- Additivity. A quorum is a set of native signoffs over the same action hash. No new signature algorithm is introduced. The completed-signoff chain is an explicit signed-context profile extension; it does not silently extend a closed base receipt schema. A single-approver policy is the one-member quorum.
Q2 -- Fail-closed. The quorum predicate is not satisfied unless every element of the predicate holds. Absence of evidence, an unparseable member, a malformed policy, or any single failed check yields "not satisfied," never "satisfied."
Q3 -- Distinctness (separation of duties at the human level). A quorum of size k requires k pairwise-distinct human approvers, each distinct from the initiator. One human MUST NOT fill two slots.
Q4 -- Incremental enforcement. The protocol enforces conformance as each approver signs, not only at consume time, so that a wrong-action, wrong-role, duplicate, out-of-order, stale, or invalid signature never becomes part of the trail.
Q5 -- Offline-verifiable quorum. The satisfied/not-satisfied judgment is computable from the receipt's members and the policy alone, under the same offline verification model as the base draft ().

Terminology In addition to the terminology of : 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.

Quorum.: The set of distinct approver signoffs required to satisfy one human-authorization evidence requirement for an action under a Quorum Policy.
Quorum Policy.: A named, versioned rule set declaring the approval mode, the required count, the roster of eligible (role, approver) slots, the distinct-humans rule, and the approval window. Carried in the policy that governs the action; see .
Member.: One element of a candidate quorum: a (role, approver public key, signoff) triple, where the native signoff uses the verification machinery of over the Authorization Context the approver signed.
Trail.: The ordered sequence of members admitted so far for one action -- the partial quorum under construction.
Quorum Gate.: The fail-closed predicate () that decides whether a trail is a satisfied quorum. The Verifying Executor () MUST consult it before performing the action.

The Quorum Policy A Quorum Policy is a JSON object: Members:

Field	Required	Type	Meaning
`mode`	REQUIRED	string (enum)	`threshold` or `ordered` ().
`required`	REQUIRED	integer >= 1	The quorum size k.
`approvers`	REQUIRED	array	The roster of eligible {role, approver} slots. MUST be non-empty.
`distinct_humans`	OPTIONAL (default true)	boolean	When true, no approver identifier may fill more than one slot. Device-key distinctness is unconditional (, checks 5 and 5a). Implementations MUST treat a missing value as true.
`window_sec`	OPTIONAL (default 900)	integer > 0	Maximum span, in seconds, between the first and any later admitted signature.
`ordered_chain`	OPTIONAL (default false)	boolean	When true in ordered mode, requires the completed-signoff chain in . Context-only links do not satisfy this requirement.
`ordered_chain_profile`	Required when `ordered_chain` is true	string	Exactly `EP-QUORUM-SIGNOFF-CHAIN-v1`. A missing or unrecognized profile fails the strong-chain check.

Rules:

An approver slot identifies an eligible approver in the Approver Directory (). The role is the organizational role under which that approver is admitted to this quorum; it is the unit of role eligibility (, check 4).
A member is admitted only if its (role, approver) pair is present in the roster. A correct signature by a real, enrolled approver who is not on the roster for this action MUST be rejected (wrong_role).
required MUST NOT exceed the number of distinct human approvers the roster can supply under distinct_humans. A policy that cannot be satisfied is a misconfiguration; verifiers treat an unsatisfiable trail as not satisfied, as always.
The Quorum Policy is part of the action's governing policy and is therefore committed by the policy_hash of every member's Authorization Context (). A signature collected under one Quorum Policy version MUST NOT satisfy a requirement evaluated under another. The relying party MUST obtain the complete expected policy, including the chain profile, from an authenticated source outside the supplied quorum. It MUST reject a mismatching supplied policy before crediting the quorum; a matching artifact-supplied policy is not itself an authority source.

Approval Modes Threshold mode. Any required distinct eligible approvers satisfy the count requirement. Presentation order has no causal meaning. Plain ordered mode. Each presented member matches the corresponding roster slot in role and approver. The number presented is at least required and no greater than the roster size. Thus ordered k-of-n admits the first k slots, not automatically all n. Presented issued_at values MUST strictly increase and their span MUST fit window_sec. These are checks on asserted metadata, not proof of actual signing order or trusted elapsed time. Completed-signoff chain. A relying party requiring causal dependence between approvals MUST pin mode: "ordered", ordered_chain: true, and ordered_chain_profile: "EP-QUORUM-SIGNOFF-CHAIN-v1" in the governing policy. It MUST NOT infer this requirement from whichever fields the supplied artifact happens to retain. Let S[i] be the complete predecessor signoff JSON object, including its signed context and native proof fields, with the actual signature encoded exactly as carried. Define: JCS is the JSON Canonicalization Scheme . The separator is one zero octet, not printable backslash and zero. Hash the complete signoff, not the member wrapper, the predecessor context alone, or a reconstructed proof that drops fields. The first signed context MUST omit prev_signoff_hash. Each successor signed context MUST carry prev_signoff_hash = link(S[i-1]). Every context MUST omit the legacy prev_context_hash field; mixed links and a null first predecessor are invalid. Every native signature and the full quorum predicate MUST also verify. A digest match alone is insufficient. The successor challenge depends on a completed predecessor proof, not merely its public context. Substituting a different valid predecessor signature over the same context changes the link and requires a new successor signature. This establishes a dependency between proof artifacts under signature-unforgeability and hash preimage/collision-resistance assumptions. It does not identify a trusted signing time, establish that the human saw the prior proof, or prove understanding or voluntary approval.

Migration from context-only links Revisions through -03 used prev_context_hash. All such contexts can be prepared before any predecessor signs, then signed in reverse order and presented in roster order. They do not prove the causal property previously claimed. Under this revision's strong requirement a verifier MUST reject missing or unknown profiles and every context-only chain, even when all member signatures verify. An existing chain MUST NOT be upgraded by changing its policy label or inserting unsigned hashes. Fresh contexts and signatures are required. Historical evidence may be evaluated under an explicitly permitted weaker threshold or plain ordered policy, but MUST NOT be credited as a completed-signoff chain. This compatibility break does not change the native signature algorithms or threshold checks.

The Quorum Gate (fail-closed predicate) A trail is a satisfied quorum for an action with hash H under policy P if and only if ALL of the following hold. A verifier MUST return "satisfied" only when every check passes, and MUST return "not satisfied" on the first failure, on a malformed policy or member, or on any unrecognized condition (Q2):

Well-formed policy. P has a recognized mode, an integer required >= 1, and a non-empty approvers roster. Otherwise: not satisfied.
All signatures valid. For every member, the EP signoff verifies under -- the WebAuthn assertion (Class A) verifies against the member's approver_public_key, with the assertion challenge equal to the member's context hash and user verification asserted. One invalid signature (one_bad_signature) fails the whole quorum.
Action binding. Every member's Authorization Context carries action_hash == H (action_mismatch). A member bound to any other action does not count.
Role admission. Every member's (role, approver) pair is present in the roster (wrong_role).
Distinct humans. When distinct_humans is true (the default), approvers are pairwise distinct and (per the base draft's SelfApprovalImpossible) distinct from the initiator (duplicate_human).
Distinct keys (check 5a). Regardless of distinct_humans, the admitted members' canonically decoded approver_public_key values are pairwise distinct (duplicate_key). This defends against a single device key enrolled under two approver identifiers, which would otherwise pass the distinct-humans check by name while being one signer.
Threshold. At least required admitted members exist (under_threshold).
Order (ordered mode only). The i-th admitted member matches approvers[i-1]; signature times are strictly increasing (out_of_order, non_increasing_time).
Ordering chain (strong ordered mode only, check 7a). When ordered_chain is true, the exact pinned profile and every completed-signoff link satisfy (broken_chain). A missing or unknown profile, a legacy link, a null first link, or a substituted predecessor proof fails. When ordered_chain is false this check supplies no causal claim.
Window. Every admitted member's issued_at is within window_sec of the first member's issued_at (window_exceeded).

The predicate is the same whether computed by the orchestrating operator before consumption or by an independent Verifying Executor or auditor offline (Q5): it is a pure function of (P, H, members). Organizational acceptance additionally requires that P, H, and the approver directory are authenticated inputs, not arbitrary values chosen by the artifact supplier. Check 2 invokes the appropriate native signoff verifier per member; EP-QUORUM adds the set-level checks. A successful standalone wrapper check does not substitute for a carrier's own schema and signature requirements ().

Incremental Admission (canAccept) To keep a non-conforming signer out of the trail rather than discovering it only at consume time (Q4), an orchestrator MUST evaluate an incremental admission rule before recording each new signoff. Given the policy P, the action hash H, the already-admitted trail, and one incoming candidate member, the rule ADMITS the candidate only if all of the following hold, and otherwise REJECTS it with the named reason:

P is well-formed and its roster is non-empty (else no_policy / no_eligible_approvers).
The candidate's context carries action_hash == H (else action_mismatch).
The candidate's (role, approver) is on the roster (else ineligible_role).
When distinct_humans is true, no already-admitted member shares the candidate's approver (else duplicate_human).
In ordered mode, the candidate matches the next unfilled roster slot (approvers[len(trail)]) in both role and approver (else out_of_order).
If the trail is non-empty, the candidate's issued_at is within window_sec of the first member's issued_at (else window_exceeded); and in ordered mode it is strictly greater than the last admitted member's issued_at (else non_increasing_time).
When strong ordering is required, the exact chain profile is recognized and the incoming signed predecessor link satisfies against the last admitted complete signoff (else unsupported_chain_profile / broken_chain).
The candidate's signature verifies (else invalid_signature).

A rejected candidate MUST NOT be written into the trail. Incremental admission is an enforcement convenience and an early-rejection UX; it is not a substitute for the Quorum Gate. A conforming Verifying Executor MUST re-evaluate the full Quorum Gate () over the assembled trail before performing the action, regardless of incremental admission, because the executor does not trust the orchestrator to have applied admission honestly (this mirrors the base draft's execution-side enforcement, ).

Multi-Handshake Composition This section is informative. It describes, end to end, the process by which the normative machinery of through composes individual signing ceremonies into one multi-party decision. Every property named here is required elsewhere in this document or in the base draft; this section introduces no new requirements. The handshake is the unit of approval. Each quorum member is one complete run of the base draft's single-approver signing ceremony (): a fresh, one-time challenge is issued for that approver against a verified handshake, bound to the exact action bytes through the action hash and binding hash it commits to, and bounded by an explicit validity window; the approver answers it with a user-verified, device-held signature whose WebAuthn assertion challenge is the member's context hash (the per-member requirement is check 2 of the Quorum Gate, ). Nothing about the ceremony is weakened or amortized when the action needs several approvers: there is no batch signature and no shared signing session; k approvals are k separate ceremonies, each independently verifiable and each independently refusable. Admission rejects known-invalid candidates early. Composition is incremental and server-side. Each candidate member is evaluated against the admission rule of before it is recorded, so a wrong-action, off-roster, duplicate, out-of-order, stale, or invalidly signed member handshake is refused at the moment it is presented and never enters the trail. The stored trail has passed the listed admission checks. This does not establish every final set-level check or the authenticity of the supplied policy and enrollment data. The Verifying Executor still re-evaluates the full Quorum Gate over the assembled trail, as requires, precisely because it does not trust the orchestrator to have admitted honestly. The next proof depends on the completed prior proof. In the versioned strong profile, a successor signs the digest of the predecessor's complete signoff, including its actual signature. The chain transitively commits to prior proof artifacts. It does not establish trusted wall-clock order, backdating resistance, rendered pixels, or comprehension. Plain ordered mode checks only roster position and asserted timestamp consistency. Denial is a first-class terminal outcome. Any approver in the trail can refuse, and a refusal is not the mere absence of an approval. Under the base draft a denial is signed over the same context hash with a decision of "denied" and is terminal: a denied authorization can never later become approved (). At the composition level, one dissenting approver leaves durable, attributable evidence of the dissent, which a relying party can weigh as adverse evidence rather than as a gap in the trail. The composed decision is accepted at most once. A satisfied quorum is authorization evidence for one exact action and is consumable at most once within its atomic consumption domain; the relying party separately decides AUTHORIZED. Each member's signoff individually retains the base draft's one-time-consumption rule (), and consumption of the composed decision is refused until the Quorum Gate is satisfied; a partial trail confers no partial authority (). The whole composition is verifiable offline. Because the satisfied/not-satisfied judgment is a pure function of the policy, the action hash, and the members (, Q5), an auditor holding the members and authenticated policy and enrollment material can recompute the checks -- per-member signatures, action binding, distinctness of humans and keys, roster admission, threshold, order and ordering chain, and window -- without contacting the operator. As in the base draft, such offline verification establishes integrity relative to the pinned keys and policy, not a trusted signing time; it does not by itself establish current validity, such as the present enrollment or revocation status of the approvers involved.

Member Representation in the Receipt The quorum computation uses native signoffs, an authenticated action hash, an independently pinned policy, and enrolled approver keys. The following is the repository's standalone member wrapper. It is not an instruction to add an inline policy or other extension to the closed Trust Receipt schema of . A carrier profile using a base receipt MUST preserve that carrier's extension rules and authenticate any external policy or member mapping. The completed-signoff chain is an explicit signed context profile, not a claim that this wrapper by itself conforms to every current base-receipt wire requirement. Each member is the triple: ", "signoff": { "@type": "ep.signoff", "context": { "context_type": "ep.signoff.v1", "action_hash": "...", "approver": "...", "issued_at": "...", "...": "..." }, "webauthn": { "authenticator_data": "...", "client_data_json": "...", "signature": "..." } } } ]]> The context and webauthn members are exactly as verified by the native signoff verifier. The new chain adds a domain-separated hash over the complete prior signoff without changing the native signature algorithm. The role and approver_public_key are the join keys against the Quorum Policy roster and the Approver Directory.

Conformance An implementation conforms to EP-QUORUM if, for the published adversarial conformance vectors, it returns the expected satisfied/not-satisfied verdict for every vector and rejects every non-conforming candidate at incremental admission with the expected reason. The reference suite (EP-QUORUM-v1) comprises the following vectors, each carrying real Class-A WebAuthn assertions:

Vector	Expect	Exercises
`accept_ordered_3of3`	satisfied	Ordered PO, AO, IG; distinct; increasing time; all action-bound
`accept_threshold_2of3`	satisfied	Any 2 distinct approvers from a 3-slot roster
`reject_under_threshold`	not satisfied	Fewer than `required` valid members
`reject_duplicate_human`	not satisfied	One human filling two slots
`reject_out_of_order`	not satisfied	Ordered mode, members out of roster order
`reject_action_mismatch`	not satisfied	A member bound to a different action hash
`reject_expired_window`	not satisfied	A member outside `window_sec`
`reject_one_bad_signature`	not satisfied	One invalid member signature
`reject_wrong_role`	not satisfied	A correct signature by an off-roster approver
`reject_duplicate_key`	not satisfied	One device key signing under two approver identifiers (check 5a)
`reject_broken_chain`	not satisfied	Strong ordered mode, a member committing to the wrong completed predecessor signoff hash (check 7a)

The reference suite is maintained such that three cross-language reference verifiers (JavaScript, Python, Go), which share one repository and are therefore a consistency check rather than clean-room independent implementations, MUST agree on every vector; divergence is a conformance defect in at least one verifier. Independent implementations remain future interoperability evidence. The "accept" vectors guard against a verifier that is too strict (denying valid quorums); the "reject" vectors guard against a verifier that is too lenient (the security-critical direction). The updated corpus additionally includes an ordered 2-of-3 positive, reverse-signed context-only chains with and without the new profile label, missing and unknown profiles, and a null first predecessor. Unit tests separately exercise substitution of a different valid predecessor signature, stripping or mutation of an expected policy, and incremental admission. The corpus version is 1.1.0. Earlier symbolic evidence over a fixed 2-of-2 instance does not establish the new completed-signoff construction. No formal proof of this revision's causal-chain profile is claimed. Neither old symbolic results nor same-team cross-language tests prove general k-of-n security, WebAuthn internals, directory correctness, parser behavior, collusion resistance, human comprehension, or deployment behavior.

Security Considerations EP-QUORUM inherits all Security Considerations of and adds the following. Several restate, honestly, what a quorum does not buy.

What multi-party authorization does and does not prevent With authenticated enrollment and policy inputs, a satisfied distinct-human quorum establishes valid, action-bound signatures under k distinct enrolled keys and the declared quorum checks. Timestamp checks apply to asserted values; only the completed-signoff profile adds causal proof dependence. Under the signature assumptions the orchestrator cannot forge an uncompromised approver's signature (). It raises the cost of unilateral action: a single compromised agent, a single stolen key, a single coerced or malicious approver is insufficient. It does not defeat collusion among the required number of distinct humans, nor one human who controls multiple enrolled identities (an enrollment control -- the base draft's Approver Directory requirements), nor simultaneous coercion of a full quorum. As in the base draft, EP-QUORUM makes such events attributable -- named, signed, and evidenced for every member -- which is a deterrent and an audit primitive, not an impossibility proof. Implementations MUST NOT claim a quorum is collusion-proof.

Fail-closed is the only safe default The dangerous error in a multi-party gate is to treat ambiguity as approval. EP-QUORUM is specified so that a malformed policy, a missing or unparseable member, a partial trail, or any single failed check yields "not satisfied." A verifier MUST NOT default to satisfied on any unrecognized condition. The "reject" conformance vectors exist to catch a regression in this direction.

Partial trails confer no authority A trail short of the threshold, or one in which incremental admission has accepted some but not all required slots, authorizes nothing. A Verifying Executor presented with a partial trail MUST refuse, exactly as it refuses a missing single signoff. This is the multi-party form of the base draft's NoBypassWrite invariant.

Window and replay The approval window (window_sec) bounds how long a partial quorum remains completable, limiting the value to an attacker of compromising a remaining approver after some approvals already exist. Each member's signoff retains the base draft's one-time-consumption nonce (G3); the window is an additional, quorum-level constraint, not a substitute for per-signoff replay protection. Comparing asserted timestamps does not prevent backdating or establish freshness. The relying party separately enforces expiry, a trusted current-time policy, and replay state. The completed-signoff chain does not supply those properties.

Divide-and-misinform across members Because each approver signs their own Authorization Context, a malicious orchestrator can attempt to show different approvers different renderings or different initiator attestations () while each individual signature remains valid. EP-QUORUM does not change the base draft's cross-context consistency requirement; verifiers SHOULD surface per-member context differences, and high-value ordered policies SHOULD render the prior approvers' decisions to each subsequent approver so that the trail is a chain of informed approvals rather than parallel ones. The presentation-attack mitigations of the base draft's Security Considerations apply per member.

Approver fatigue, at quorum scale Requiring more humans does not help if each rubber-stamps; it can hurt, by diffusing responsibility across a group in which no member feels decisive (the base draft's Security Considerations). Quorum policies MUST be scoped to genuinely high-consequence, low-frequency actions, and deployments SHOULD monitor per-role time-to-sign and deny rates rather than assume that more signers means more scrutiny.

Rubber-stamping and review-latency evidence Signing-ceremony telemetry -- the times at which each member's challenge was issued, first viewed, and approved -- SHOULD be retained alongside the trail as evidence of how much review each approval actually received. A relying party MAY apply a minimum-review-latency policy when weighing an approval: an approval recorded a very short interval after the challenge was first viewed is evidence of rubber-stamping rather than review, and a relying party may discount it or treat the bundle as containing conflicting evidence accordingly. This raises the probability that rubber-stamping is detected after the fact and makes it attributable to a named approver; it does not prevent rubber-stamping, and it does not defeat collusion or coercion, for which applies. Ceremony telemetry originates with the orchestrator, so a relying party that depends on it should weigh unsigned telemetry with the same skepticism as any other operator-supplied metadata; deployments that need it to serve as evidence rather than log data can have the operator sign the ceremony record so that its integrity is independently checkable.

Human quorum is not threshold secret custody EP-QUORUM verifies distinct enrolled approvers, action-bound signatures, roles, order, and timing. Reconstructing a capability holder secret from m-of-n shares proves only that enough shares were combined. Unless each share holder separately performs the EP-QUORUM ceremony, threshold reconstruction does not prove that distinct humans reviewed or approved the action. Implementations and public claims MUST NOT describe threshold secret custody as EP-QUORUM authorization.

Changes from -03 Replaced the unsound context-only chronology claim with the versioned EP-QUORUM-SIGNOFF-CHAIN-v1 completed-proof dependency profile. Specified the domain-separated digest, first-member and mixed-link rejection, authenticated policy pin, and explicit compatibility break. Clarified ordered k-of-n, unconditional key distinctness, asserted timestamp limits, carrier boundaries, and the absence of a formal proof for the new chain.

Changes from -02 Clarified that EP-QUORUM's distinct-human, action-bound approval ceremony is not interchangeable with m-of-n reconstruction of a capability holder secret.

IANA Considerations This document has no IANA actions.