| Internet-Draft | Human-Authorization Binding | July 2026 |
| Schrock | Expires 4 January 2027 | [Page] |
A recurring pattern spans the agent-action record formats now in development: a record about an agent's action reserves a place for "the human authorization" — an approver disposition, an authority context, a human-override field, an actor slot, a signed grant, an approval reference — and leaves its semantics undefined. Each format, reasonably, does not want to specify human-authorization evidence itself; none, so far, says what filling the slot means. This document defines that one thing, host-agnostically: how any record binds named-human authorization evidence, either BY REFERENCE (a content digest of the authorization artifact's canonical bytes) or EMBEDDED (a compact, self-describing claim carrying named approvals and optional distinct-human quorum semantics), with five requirements that make the binding mean the same thing in every host: digest grounding, action agreement, verified-versus-accepted discipline, fail-closed absence, and embedded/referenced consistency. The SCITT signed-statement host family is expressed concretely (digest selection, and the observed-absence statement that is the only way absence of authorization becomes evidence); an informative appendix maps the binding onto the reserved slots of eleven current documents. This document defines no new authorization format: the referenced evidence verifies under its own specification.¶
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 (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.¶
Record formats for agent actions are proliferating, and almost all of them make the same, sound scoping decision: human authorization is somebody else's format. The result is a set of reserved-but-empty slots. A post-execution action capsule carries an approver disposition whose authority is opaque; a pre-execution permit stubs an authority context; audit-trail records carry a human-override field with a privacy carve-out where the human should be; a provenance graph has an optional actor; an audit architecture requires a "signed grant" whose format is an unassigned work item; an intent chain names an approval reference with no semantics. Each slot is an invitation. Eleven invitations with eleven ad-hoc answers would be worse than none.¶
This document is the single answer: a host-agnostic definition of what it means to bind named-human authorization evidence into any record, plus the small set of requirements that keep the binding trustworthy regardless of host. The reserved slots this profile serves appear, at this writing, in draft-mih-scitt-agent-action-capsule, draft-munoz-scitt-permit-profile, draft-sharif-agent-audit-trail, draft-bates-atp, draft-aylward-aiga, draft-nelson-agent-delegation-receipts, draft-rosenberg-aiproto-cheq, draft-yossif-psea, draft-kuehlewind-audit-architecture, the ACP charter, and the SPICE-adjacent intent-chain work — the mappings in Appendix A are offered for those authors to correct or adopt. It deliberately does not define the authorization evidence itself — a bound artifact verifies under its own specification (for example [I-D.schrock-ep-authorization-receipts] for named-human receipts and quorum) — and the appendix mappings to host formats are informative descriptions of public slot fields, offered for host authors to correct or adopt.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Host record: any signed or logged record about an agent action that carries the binding (a capsule, permit, audit record, provenance node, token, or chain). Authorization artifact: the evidence being bound (a named-human authorization receipt, a quorum receipt, or an equivalent artifact defined elsewhere).¶
The reference form is a JSON member (claim name "human_authorization_ref"; see Section 6) carried anywhere in the host record the host format designates:¶
"human_authorization_ref": {
"digest": "sha256:<hex of the artifact's canonical bytes>",
"format": "ep-receipt | ep-quorum | <other artifact type>",
"locator": "<OPTIONAL hint URI; acquisition is out of scope>"
}
¶
The digest MUST be computed over the authorization artifact's canonical bytes as defined by the artifact's own specification (for EP artifacts, the JCS [RFC8785] I-JSON profile). The locator is a hint only: a verifier obtains the artifact through whatever channel the deployment provides, and relies on digest equality, never on the channel. The reference form supports disclosure minimization: a host record can travel without the artifact, and a relying party that requires the evidence fails closed until the bytes are produced.¶
The embedded form carries the evidence inline as a compact, self-describing claim (claim name "human_authorization"):¶
"human_authorization": {
"v": "EP-HAC-v1",
"action_digest": "sha256:<hex>",
"mode": "single | quorum",
"approvals": [
{ "approver": "<named accountable principal>",
"role": "<OPTIONAL>",
"key_class": "A | B | C",
"signoff": { "...the approver's own signature object..." } }
],
"policy": "<OPTIONAL policy identifier>",
"quorum": { "required": 2, "distinct_humans": true,
"ordered": false }
}
¶
Each approval names an accountable human principal and carries that principal's own signature over the action binding, verifiable offline under the artifact specification the claim profiles. When mode is "quorum", the distinct-humans and ordering semantics of [I-D.schrock-ep-quorum] apply: the required number of DISTINCT accountable humans, not merely distinct signatures. Key classes classify key custody as defined by the receipts specification and imply nothing about assurance levels.¶
Five requirements hold for every host, and they are what make the binding mean the same thing everywhere:¶
Transparency-logged agent-action statements (SCITT [RFC9943]: capsules, permits, audit records) are the binding's most developed host family, and their expression is specified here concretely. The reference form's digest is one of the following, selected per deployment and FIXED for a given host-statement profile so that both sides bind identical bytes:¶
The COSE encoding of the receipt as a Signed Statement (canonical payload, content type) is the EP SCITT profile's job and out of scope here: this section specifies only the digest a host statement embeds and the verification that B1-B5 already require. A host profile defines its own concrete carrier (a dedicated field, a capsule's opaque authority reference, a permit's authority context); this document mandates the digest semantics, never the carrier's name. The verifier obtains the receipt through whatever channel the deployment provides — held locally, conveyed with the statement, or fetched from the transparency service — and relies on digest equality, never on the channel.¶
B4 (fail-closed absence) has one elaboration worth stating normatively for this host family, because settlement and audit flows rely on refusals as much as approvals. Three states, only two of which are evidence: a DENIAL (a named human refused, an approval was revoked, or a validity window lapsed and the expiry was recorded) is a signed event, and a host statement MAY reference a denied authorization exactly as it references an approval — "an accountable human refused this action" is a positive, verifiable fact. ABSENCE is not evidence and cannot be made so by assertion: the mere failure to present an authorization proves nothing. Absence becomes positive evidence only through a signed OBSERVED-ABSENCE statement — an attestation that the verifier performed a defined search against defined sources at a stated time and found no qualifying authorization; it attests the search and its emptiness, never a universal negative. A deterministic observed-absence vector ships with the reference implementation (examples/scitt/observed-absence-vector.mjs).¶
The canonical claim names are "human_authorization_ref" and "human_authorization". The claim was first deployed under the vendor-prefixed name "ep_human_authorization"; implementations SHOULD accept it and MUST treat it as an alias of the embedded form. Host formats that already name their slot (an authority context, an actor, an approval reference) MAY carry the binding object under their own member name; the object's members, not the slot's name, are what this document defines.¶
The slot is a target. An attacker who can fill a host record's authorization slot chooses what a relying party later treats as the human's approval; every defense here exists for that reason. B1 removes assertion-only filling; B2 defeats splicing a genuine artifact from a different action (the confused-deputy case); B3 prevents a self-issued artifact from being self-accepted; B4 prevents silence from being read as consent; B5 prevents the two forms from telling two stories. Replay and one-time-use semantics belong to the authorization artifact and its enforcement point; a host record MUST NOT extend an artifact's validity by carrying it. The reference form additionally serves privacy: the named human travels only in the artifact, which can be withheld until a relying party with a need to know requires it — at the cost, by B4, of the evidence not counting until produced.¶
This document has no IANA actions. Registration of the claim names in the JWT and CWT claims registries is anticipated for a future revision, after host-format feedback.¶
The following mappings describe, from each cited document's public text, where the binding fits. They are informative, derived from the revisions named, and offered for the host authors to correct or adopt; absence of a format from this list implies nothing, and no mapping asserts a host author's endorsement.¶
One adjacent family fits differently and deserves saying precisely. WIMSE workload credentials (WIT/WIC, and the WPT request binding) do not reserve a human-authorization slot; their working group is deliberately chartered for workload identity and explicitly does not define personal identities. They are, however, carry-capable: a WIT or transaction context is a JWT, and a deployment MAY carry human_authorization_ref as a claim alongside the workload identity — the workload credential then proves WHICH WORKLOAD is calling and proved possession, while the bound artifact proves WHICH ACCOUNTABLE HUMAN authorized the exact action it is about to perform. The two answers have different trust roots (a workload key versus a named human's key under organizational authority), which is why neither format can absorb the other and why the composition, rather than either alone, is what a relying party needs for an irreversible action.¶
The embedded claim profiles a shipped format (the EP receipt and quorum artifacts, three-language verifier suite with shared conformance vectors in one repository). The binding checks (digest grounding, action agreement, verified-versus-accepted, fail-closed absence) are exercised by the reference implementation's evidence-graph layer and by a deterministic binding vector published with the repository (examples/binding/human-authorization-binding-vector.mjs).¶