Independent Submission B. Morrison Internet-Draft Alter Meridian Pty Ltd Intended status: Informational C. Whiteside Expires: 18 April 2027 Independent I. Schrock EMILIA Protocol, Inc. 15 October 2026 Authorised and Attributable Agent Authority for Operational-Technology Control Actions draft-morrison-ot-command-authority-04 Abstract This memo specifies a binding profile by which a control action issued to an operational-technology (OT) or industrial control system on the authority of a software agent is refused unless it carries a verifiable statement of who the agent is, which human principal it acts for, whether that principal authorised this specific action on this specific asset, whether a named human signed off on the action where its risk class requires it, and an append-only record sufficient to attribute the action afterward. The profile does not invent new cryptography or a new identity mechanism. It composes primitives specified elsewhere, DNSSEC-rooted agent discovery, a scoped and revocable authorisation grant, and a named-human authorization receipt bound into the record as human-authorization evidence, together with an append-only audit record, into a single structure, the Command Authority Envelope, that an enforcement point evaluates and, on any missing or invalid binding, refuses. The profile is availability-first and fails closed on authority, never on safety: it MUST NOT be placed in the trip path of a safety function. The memo relates the profile to the identification, use-control, and audit requirements that the IEC 62443 and NERC CIP frameworks state but do not give a wire mechanism for. A neighbouring proposal gates safety-critical commands on an agent's trust level; this profile takes the opposite position, and states why. Status of This Memo 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/. Morrison, et al. Expires 18 April 2027 [Page 1] Internet-Draft OT Command Authority October 2026 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 18 April 2027. Copyright Notice 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. A neighbouring proposal, and where this profile parts from it . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 3. The Command Authority Envelope . . . . . . . . . . . . . . . 6 3.1. Agent identity . . . . . . . . . . . . . . . . . . . . . 7 3.2. Principal reference . . . . . . . . . . . . . . . . . . . 7 3.3. Authorisation grant . . . . . . . . . . . . . . . . . . . 7 3.4. Binding moment . . . . . . . . . . . . . . . . . . . . . 9 3.5. Audit record . . . . . . . . . . . . . . . . . . . . . . 10 4. Enforcement-Point Evaluation and Fail-Closed Behaviour . . . 11 5. Risk Classes . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Safety Carve-Out . . . . . . . . . . . . . . . . . . . . . . 14 7. Encoding and Transport Binding . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. Deployment and Incremental Adoption . . . . . . . . . . . . . 18 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 11. Note on the Normative References . . . . . . . . . . . . . . 19 12. Implementation Status . . . . . . . . . . . . . . . . . . . . 19 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21 14. Normative References . . . . . . . . . . . . . . . . . . . . 21 15. Informative References . . . . . . . . . . . . . . . . . . . 22 Appendix A. Document History . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Morrison, et al. Expires 18 April 2027 [Page 2] Internet-Draft OT Command Authority October 2026 1. Introduction Two bodies of standards work address parts of this problem, and neither addresses the whole of it. One is agent identity for the enterprise cloud. A software agent that acts for a person or an organisation is being given a verifiable identity and a way to authenticate itself, composing existing web and workload-identity primitives. The web-bot-auth effort [WEBBOTAUTH] specifies how an automated agent authenticates itself over HTTP using HTTP Message Signatures [RFC9421], and it does not bind that key to a human principal. It is scoped to general information systems. It does not address operational technology. The other is operational-technology security. Frameworks such as [IEC62443], [SP80082], and the [NERCCIP] reliability standards govern the industrial control systems that run the electric grid, water, pipelines, and manufacturing. They require that actors be identified (the identification and authentication control family), that use be controlled (the use-control family), and that consequential actions be auditable. They state these as requirements. They do not specify a wire mechanism by which an agent-originated command carries the proof that satisfies them, and the installed base of control protocols (Modbus, DNP3, and their peers) authenticates a command largely by its position on the network rather than by anything the sender proved. There is no interoperable way for a command issued to a control system on the authority of an agent to carry a revocable, auditable, principal-bound statement of the authority under which it is issued, such that an enforcement point can refuse the command when that statement is absent or invalid. An agent that can write a setpoint to a turbine, open a breaker, or change a treatment dose is a workload whose authority to do so must be provable, scoped, revocable, and attributable after the fact, at stakes where a wrong action is a physical event rather than a corrupted record. This memo specifies that binding. It introduces no new identity mechanism. It composes primitives specified in separate memos into one envelope, the Command Authority Envelope (CAE), that accompanies an agent-originated OT control action, and it specifies the fail- closed behaviour of an enforcement point that evaluates it. Applicability. The operating condition this profile is written for is a plant that must keep its critical services running through a sustained loss of external connectivity, whether that loss is permanent by design or produced by an isolation event. Nothing in the envelope requires a network path beyond the conduit at the moment Morrison, et al. Expires 18 April 2027 [Page 3] Internet-Draft OT Command Authority October 2026 of evaluation: an encoding MUST be verifiable offline against cached trust anchors with declared staleness bounds (Section 7), which covers the agent key material, the approver directory and the audit- log checkpoint alike (Section 8). Where a bound is exceeded the enforcement point fails closed on authority, and never on safety (Section 6). Scope. The actions this profile is written for are those requiring an auditable point in time that ties the user, the command and the authorisation together: an operator-requested process stop outside the independent safety path, a setpoint pushed outside normal operating parameters, the starting or stopping of a process. More generally, it addresses deployments where traditional control protocols are in use but additional controls on the authorisation of commands are required. It is not a general mechanism for machine-to- machine communication within a plant operating inside its set boundaries. 1.1. A neighbouring proposal, and where this profile parts from it One other Internet-Draft addresses agent authority for industrial control directly. [SHARIFICS] applies an agent-trust transport to Modbus/TCP, OPC UA, MQTT, and CoAP, mandates ECDSA message signing over those protocols, and maps agent trust levels to the Security Levels of [IEC62443]. It supplies, in concrete wire form, much of the transport binding this memo defers (Section 7), and a deployment that wants a worked control-protocol encoding today will find one there. On one point the two proposals disagree. [SHARIFICS] gates safety- critical commands on the agent's trust level: a command to a safety- classified point is rejected when the issuing agent presents an insufficient trust level. This memo forbids that (Section 6). A safety function's right to bring or hold the process in a safe state, and its right to refuse an unsafe command on its own criteria, MUST NOT be made to depend on the resolution, verification, or trust level of any agent credential. Gating a safety command on an identity check makes the safety function unavailable when the identity infrastructure is degraded, and that is a safety regression introduced in the name of security. The two proposals can compose on everything below the safety boundary: agent signing, trust-level-to- Security-Level mapping, and the per-protocol envelopes are complementary to the bindings this memo defines. They cannot compose across the safety boundary, and this memo places that boundary where an OT safety case requires it. Morrison, et al. Expires 18 April 2027 [Page 4] Internet-Draft OT Command Authority October 2026 What this memo adds is the coupling: an authorised, resolvable, human-principal authority, plus a named-human authorization at the moment of consequence, plus an attributable append-only record, drawn into a single enforcement-point-evaluated, risk-class-graded, fail- closed refusal profile in which a safety function is never gated on any of it. The discovery, grant and human-authorization primitives are specified elsewhere. The audit record's required properties, the refusal profile and the safety carve-out are specified here. 2. Conventions and Terminology 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. This document uses the following terms. Agent: A software actor that issues a control action to an OT system. An agent is a workload with a discoverable identity, not a human. Principal: The human, or the organisation acting through a human, on whose authority the agent issues an action. The principal is the party that issues the authorisation grant (Section 3.3) under which the agent acts. Approver: A named, accountable human who signs off on a specific control action at the moment of consequence, per [EPRECEIPTS]. The approver need not be the principal. The approver MUST be a human distinct from the initiating agent. For consequential actions, the deployment SHOULD require an approver distinct from any human requester of that action. Where this separation is required, the deployment MUST establish it from trusted identity bindings, not merely from different keys or identifiers. Control action: A request that changes, or commands the change of, the state of a physical process or of a device that governs one: a setpoint write, a breaker operation, a mode change, a dose change. A read-only observation is not a control action for the purposes of this memo. Where a deployment elects to apply this profile to reads, it does so under the Observe class (Section 5). Conduit: In the sense of [IEC62443], the communication path between zones across which a control action travels. This profile is enforced at the conduit, by the evaluating function this memo calls the enforcement point. Morrison, et al. Expires 18 April 2027 [Page 5] Internet-Draft OT Command Authority October 2026 Enforcement point: The function, resident on or at the boundary of a conduit, that evaluates the CAE of an agent-originated control action and refuses the action on any missing or invalid binding. This memo gives the function its own name because [IEC62443] uses "conduit" for a channel grouping rather than for an evaluating function, and the two need to be distinguishable in a sentence. The enforcement point is the conduit's evaluating function; it is not a different place. Command Authority Envelope (CAE): The structure defined in this memo that a control action MUST carry to be accepted by an enforcement point that implements this profile. Authorisation grant: A scoped, revocable object, signed by the principal, that authorises a named agent to perform a named control verb on a named asset until a stated expiry (Section 3.3). Binding moment: A named human's signed authorization of one exact control action at the moment of consequence, carried as human- authorization evidence (Section 3.4). The evidence is the pre- execution authorization bundle of [EPRECEIPTS]; the interaction that produces it MAY be delivered through the briefing-and-binding envelope of [BINDINGMOMENT]. Risk class: The category assigned to a control action by its potential physical consequence, which determines which bindings the CAE MUST carry. Safety function: A function whose purpose is to bring or hold the process in a safe state, including a safety-instrumented system (SIS). Safety functions are outside the authority path of this profile (Section 6). 3. The Command Authority Envelope A control action issued on the authority of an agent to an enforcement point that implements this profile MUST carry a Command Authority Envelope. The CAE is a signed structure carried alongside the control action. The bindings it carries are listed below; the mapping from each binding to the composed artefact that supplies its concrete fields is in Section 7. The CAE binds five things. Morrison, et al. Expires 18 April 2027 [Page 6] Internet-Draft OT Command Authority October 2026 3.1. Agent identity The CAE MUST identify the issuing agent by a discoverable identifier whose key material is resolvable and verifiable independently of the enforcement point. A deployment reachable from public DNS SHOULD resolve the agent identifier per [MCPDNS], for which verification is DNSSEC-rooted and fails closed when DNSSEC is absent. The agent's request signature MUST be verifiable per [RFC9421], consistent with [WEBBOTAUTH]. This binding answers "which machine issued this", and nothing more; on its own it is insufficient, because it does not name a principal. 3.2. Principal reference The CAE MUST carry a reference to the principal on whose authority the agent acts. The reference is a resolvable identity handle, not a bare string. One such handle form is the alter: URI defined in [ALTER-URI], for example alter:~alice; this memo does not require it. This binding is the one the agent-authentication layer does not carry: it names the human behind the machine. A control action whose CAE names no principal MUST be treated as principal-less and refused at any risk class above the lowest (Section 5). 3.3. Authorisation grant The CAE MUST carry a reference to a scoped, revocable authorisation grant, issued and signed by the principal, that authorises this action. The grant MUST name the specific asset (the zone, conduit, device, or point), the specific control verb it authorises, and the specific agent authorised to exercise it, and it MUST carry an expiry. A grant that names a broader scope than the action does not satisfy this requirement more strongly; it satisfies it exactly to the overlap, and an enforcement point MUST evaluate coverage against the specific action, not against the grant's breadth. Authority is evaluated against each action and is never inferred from an operator's enrolment. A grant may stand until its expiry and cover more than one action, but each action is admitted only on its own coverage check and, at the classes that require one, on its own binding moment (Section 3.4). This section states conformance requirements, not one mandated object. Any grant artefact meeting the requirements below is a conforming filler, and this memo names the fillers known to it without preferring one. A conforming authorisation grant: G1. is signed by the principal whose authority the action invokes; G2. names the asset, the control verb, and the authorised agent; Morrison, et al. Expires 18 April 2027 [Page 7] Internet-Draft OT Command Authority October 2026 G3. carries an expiry; G4. is content-addressed, so that a record can reference exactly the grant that was in force; G5. is revocable, and permits an enforcement point to establish its revocation state or to refuse for want of it; and G6. permits an enforcement point to evaluate coverage against the specific action and to fail closed, under a distinguishable reason, on any requirement it cannot meet. Two fillers are known at the time of writing, and neither is privileged by this memo. EP-CONSENT-GRANT-v1 [EPCONSENTGRANT] meets G1 and G3 through G6, and needs an authorised-agent profile and check before it meets G2. It is a signed standing grant naming an asset, a control verb, and an expiry, content-addressed by a grant hash, revocable by a revocation statement against that hash, and its verifier refuses under distinct reasons for signature, validity window, revocation, asset, verb, and grant-binding failures. G2 requires the grant to name the authorised agent, and this filler does not yet define or check that binding; its asset, verb and validity checks are unaffected. Current revocation status at an enforcement point depends on that point's freshness policy (Section 8), and offline signature verification alone does not establish it. [EPCAEPROFILE] maps it against the authorisation- grant, binding-moment and audit-record bindings of this memo. It is, so far as the authors are aware, the first artefact specified and implemented against this binding. The grant of [CONSENT] does not meet G1 or G2 as it stands. It authorises a reader to READ an attribute about a data subject and is signed by that subject, so it grants a read of an attribute rather than a command over an asset, and it requires profiling with asset, verb, and authorised-agent fields before it fills this binding. The grant of this section authorises an agent to ACT on an asset and is signed by the principal whose authority the action invokes. The grant of [CONSENT] authorises a read and is signed by the data subject. The two carry the same revocation and content-addressing machinery and the same signed-by-the-authorising-party discipline; they differ in what they authorise and in who signs. The principal of this memo and the subject of [CONSENT] are different roles occupying the signer slot of two different objects. Morrison, et al. Expires 18 April 2027 [Page 8] Internet-Draft OT Command Authority October 2026 3.4. Binding moment For a control action whose risk class requires it (Section 5), the CAE MUST carry an authorisation artefact that binds a named, accountable human to this exact action before the action executes. The artefact is bound into the CAE as human-authorization evidence per [HUMANAUTHBIND], and the bound evidence is the pre-execution Authorization Bundle of [EPRECEIPTS] (Section 6 of draft-schrock-ep- authorization-receipts-13), or an equivalent artefact carrying the same properties. The terminal Trust Receipt of [EPRECEIPTS] records consumption and an outcome, and an enforcement point MUST NOT require it before dispatch. The artefact MUST satisfy, at the enforcement point, the binding requirements of [HUMANAUTHBIND]: * it is credited only against artefact bytes, a signature the enforcement point verifies or a digest it matches, and never against a bare assertion that a human approved (B1, digest grounding); * its action binding MUST agree with the control action's asset and verb, so that an approval issued for one action cannot be spent on another (B2, action agreement). An artefact authorising a different action MUST invalidate the binding, not merely weaken it; * the enforcement point MUST distinguish verifying the artefact (its digests and signatures hold) from accepting it (its issuer's key is pinned out of band), and MUST NOT accept an artefact from an unpinned issuer (B3, verified versus accepted); * the absence of the artefact is the absence of evidence, never a default grant of authority (B4, fail-closed absence); * where the artefact is available in both an embedded and a referenced form, the two MUST agree, and an enforcement point that resolves the reference MUST refuse the action if the resolved artefact differs from the embedded one (B5, form consistency). Section 7 offers both forms, so this requirement is live in this profile. The action the enforcement point evaluates and the action it forwards MUST be the same action. An enforcement point MUST fix the action's asset, verb and parameters before it verifies the artefact, and MUST forward that fixed action to the process. Where verification, revocation lookup or spend recording introduces a wait, the action MUST NOT be re-read from a mutable structure after that wait. An Morrison, et al. Expires 18 April 2027 [Page 9] Internet-Draft OT Command Authority October 2026 enforcement point that verifies one object and forwards another satisfies B2 against an action nobody authorised. B2 alone does not reach this, because agreement is checked at one moment and the action executes at another, and the interval between them is where the substitution happens. The artefact MUST carry the approving human's own signature over a digest of the action, and the enforcement point MUST apply its signature, action, authority and validity checks per [EPRECEIPTS] before dispatch, offline against cached key material and the approver directory. The artefact MUST NOT be usable more than once. A binding moment MUST carry an expiry. An enforcement point MUST refuse an artefact presented after its expiry, and MUST NOT treat a captured approval as valid for any window the artefact does not itself state. A captured decision is evidence of a decision taken at a moment, not a standing token. 3.5. Audit record The CAE MUST carry the fields an append-only, independently attributable record of the action requires, and the enforcement point writes that record as signed statements in an append-only log, in two phases. The enforcement point MUST record its admission or refusal decision. Before forwarding an accepted action, it MUST durably record the admission, bound to the fixed action digest and stable operation identifier. It MUST append subsequent outcome or reconciliation records linked to that admission record, including unresolved outcomes, without rewriting earlier entries. The admission record MUST be sufficient to attribute the action afterward: which agent, on which principal's authority, under which authorisation grant, with which binding moment where one was required, against which asset, at which time per [RFC3339]. Where a binding moment was required, the admission record MUST reference the authorisation artefact by digest per [HUMANAUTHBIND], so that the record of the action and its human-authorization evidence bind the same bytes. A pre-dispatch record MUST NOT assert an effect. Where a deployment additionally requires log inclusion before dispatch, that inclusion covers the admission record, not an outcome that has not happened. For offline verification, each logged record MUST be accompanied by an inclusion proof and a signed checkpoint covering it. The verifier MUST authenticate the checkpoint under an independently trusted log key and, when advancing from a previously accepted checkpoint, verify an append-only consistency proof. These checks establish consistency with the supplied log view; detecting conflicting views additionally Morrison, et al. Expires 18 April 2027 [Page 10] Internet-Draft OT Command Authority October 2026 requires comparison with independently obtained checkpoints or witnesses (Section 13.5 of draft-schrock-ep-authorization-receipts- 13). A verifier unable to obtain a required covering checkpoint or consistency proof cannot declare those checks satisfied. Checkpoint availability is separate from whether a physical action occurred. These are the properties the evidence requirements of [IEC62443] and [NERCCIP] call for: a record that a third party can check without trusting whoever operates the log. This memo does not mandate a log format. The agent-authentication layer does not produce such a record, and this binding fills that gap. The outcome record states what the enforcement point observed, not what it intended. Where the outcome of the action is unresolved in the sense of Section 4, the outcome record MUST say so, and MUST NOT assert that the action took effect. A statement that an asset reached a state, written without observing the process, corroborates nothing. 4. Enforcement-Point Evaluation and Fail-Closed Behaviour An enforcement point that implements this profile MUST evaluate the CAE of every agent-originated control action before the action reaches the process, and MUST refuse the action if any binding required for the action's risk class is absent, malformed, expired, revoked, or unverifiable. Refusal is the default and the safe state for authority. An enforcement point MUST NOT accept a control action on the ground that the CAE could not be evaluated (for example because a revocation status could not be reached); an unevaluable authority is a refused authority. The enforcement point refuses the request rather than attempting to prove, cryptographically, that the agent lacked authority. That trust boundary is open to challenge, and Section 8 says so. Evaluation before the action yields one of two outcomes, accept or refuse. The action itself yields a third. Where an enforcement point has accepted a CAE, dispatched the action, and cannot determine from the process whether the action took effect, the outcome is unresolved. An enforcement point MUST NOT report an unresolved outcome as performed, and MUST NOT report it as refused. Reporting it as refused is the worse of the two, because a refusal asserts that nothing reached the process. An unresolved outcome carries no authority forward. Retrying the action is a new control action, requiring its own CAE and, where the action's risk class requires a binding moment, its own binding moment Morrison, et al. Expires 18 April 2027 [Page 11] Internet-Draft OT Command Authority October 2026 (Section 5). An enforcement point MUST NOT re-present the artefact of an unresolved action, and MUST NOT resolve the outcome by asking the agent what happened. Fresh authorization alone MUST NOT permit another attempt at the same unresolved operation. The deployment MUST retain a stable operation identifier and a durable unresolved state across restart and re- authorization. It MUST NOT release another attempt merely because the original response was lost. Authenticated reconciliation or a deployment-specific recovery procedure must establish whether, and under what conditions, another attempt is permissible. Section 3.4 requires that a binding-moment artefact MUST NOT be usable more than once, and the enforcement point is what makes that hold. An enforcement point MUST record each artefact it accepts as spent, and MUST refuse any later action presenting an artefact already recorded. Two records carry that requirement rather than one. The spend record at the enforcement point MUST survive a restart of the enforcement point, and where a downstream conduit can duplicate an action already dispatched, the record that suppresses the duplicate MUST survive a restart of that conduit. Survival of power loss is a requirement on the deployment, and no implementation reported in Section 12 demonstrates it. Spend state held only in volatile memory makes the requirement once per uptime rather than once, and a power cycle is an ordinary event in an OT deployment rather than an exceptional one. An artefact dispatched against an unresolved outcome is spent. Single spend holds only where one enforcement point evaluates every agent-originated control action for a given asset. Where more than one enforcement point can admit an action for the same asset, no single enforcement point can hold the spend record that Section 3.4 requires, and a deployment MUST either scope each asset to a single enforcement point or refuse the action, on the same ground as an unreachable revocation status. What this section requires of an enforcement point is at-most-once admission and forwarding of the authorised attempt. It does not require, and cannot deliver, exactly-once physical effect. An unresolved outcome means the process may or may not have acted, and no property of the authority path resolves that question. Exactly- once physical effect depends on the executor, the device, and how uncertain outcomes are resolved, and reconciliation alone does not establish it. Morrison, et al. Expires 18 April 2027 [Page 12] Internet-Draft OT Command Authority October 2026 Refusal of a control action on authority grounds MUST NOT itself be able to prevent, delay, or gate a safety function (Section 6). The authority path and the safety path are separate, and the profile lives only in the former. 5. Risk Classes An enforcement point assigns each control action a risk class by its potential physical consequence. The mapping from action to class is a property of the deployment and its process hazard analysis, not of this memo; this memo specifies only which bindings each class requires. A deployment SHOULD align its classes with the Security Levels of [IEC62443]. Three classes are defined; a deployment MAY define finer gradations between them. Observe (lowest): A read of process state, carried under this profile only where a deployment has elected to apply the profile to reads (Section 2). Where it applies, the CAE MUST carry agent identity and an audit record. Principal reference, an authorisation grant, and a binding moment are OPTIONAL. Adjust (middle): A change within a bounded, pre-authorised safe envelope, for example a setpoint move within an interlocked range. The CAE MUST carry agent identity, principal reference, an authorisation grant covering the asset and verb, and an audit record. A binding moment is RECOMMENDED and MAY be required by the deployment. State-change (highest): A change of process or device state with safety or reliability consequence, for example a breaker operation, a mode change, or a change that leaves an interlocked envelope. The CAE MUST carry all five bindings, and the binding moment MUST be present and valid. An enforcement point MUST refuse a State-change action whose CAE lacks a valid binding moment, without exception, and MUST NOT downgrade an action's class to avoid a binding requirement. Where a State-change action's outcome is unresolved (Section 4), a retry is a new action of the same class. Its binding moment MUST be present and valid in its own right, which means a human decides again. That decision is necessary where this section requires it and is not sufficient: the retry remains subject to the rule in Section 4 on another attempt at an unresolved operation, and a fresh binding moment does not by itself clear the uncertainty. Morrison, et al. Expires 18 April 2027 [Page 13] Internet-Draft OT Command Authority October 2026 6. Safety Carve-Out A safety function MUST NOT be gated on any binding in this profile. A safety-instrumented system, an emergency shutdown, a hardware interlock, a protective relay operating on its own criteria: none of these is an agent-originated control action in the sense of this memo, and none of them MAY be made to depend on the resolution, verification, or revocation status of a CAE. A safety action that a plant would take autonomously MUST remain takeable when every network, every DNS resolver, and every consent endpoint is unreachable. This is where this profile and [SHARIFICS] part (Section 1.1). A design that rejects a safety-classified command because the issuing agent presented an insufficient trust level has placed an identity check in the safety path. This memo forbids that placement. The profile constrains who may command a process to move. It has no authority over the process's own right to protect itself. 7. Encoding and Transport Binding This section maps each CAE binding to the composed artefact that supplies its concrete fields. This memo does not mandate, and this revision does not specify, a single outer CAE encoding or a new wire structure of its own. Where the profile needs a field, it takes it from a primitive already specified elsewhere; where a concrete encoding decision remains, it is named as such and not specified here. The CAE is a signed structure. Each binding is filled as follows. +===============+=====================+============================+ | CAE binding | Filled by | Concrete fields come from | +===============+=====================+============================+ | Agent | Resolvable agent | [MCPDNS] for the | | identity | identifier and | identifier and its DNSSEC- | | (3.1) | request signature | rooted key material; | | | | [RFC9421] for the | | | | signature, consistent with | | | | [WEBBOTAUTH] | +---------------+---------------------+----------------------------+ | Principal | Resolvable | A resolvable identity | | reference | principal handle | handle naming the human on | | (3.2) | | whose authority the agent | | | | acts | +---------------+---------------------+----------------------------+ | Authorisation | Principal-signed, | Any filler meeting G1 to | | grant (3.3) | scoped, revocable | G6 of Section 3.3. | Morrison, et al. Expires 18 April 2027 [Page 14] Internet-Draft OT Command Authority October 2026 | | grant naming asset, | [EPCONSENTGRANT] meets G1 | | | verb, agent, and | and G3 to G6 and needs an | | | expiry | authorised-agent profile | | | | and check for G2; the | | | | grant structure of | | | | [CONSENT] does not meet G1 | | | | or G2 and requires | | | | profiling with asset, | | | | verb, and authorised-agent | | | | fields first | +---------------+---------------------+----------------------------+ | Binding | Named-human | The binding object | | moment (3.4) | authorization | (human_authorization_ref | | | evidence carrying | by digest, or | | | an approver's | human_authorization | | | signature over the | embedded) of | | | action digest | [HUMANAUTHBIND], carrying | | | | the pre-execution | | | | Authorization Bundle of | | | | [EPRECEIPTS], never the | | | | terminal Trust Receipt; | | | | the interaction optionally | | | | via [BINDINGMOMENT] | +---------------+---------------------+----------------------------+ | Audit record | An admission record | The properties of | | (3.5) | written before | Section 3.5; the binding | | | dispatch, and | moment referenced by | | | outcome or | digest per [HUMANAUTHBIND] | | | reconciliation | in the admission record | | | records appended | | | | after it, each a | | | | signed statement in | | | | an append-only log | | | | with an inclusion | | | | proof and covering | | | | checkpoint | | +---------------+---------------------+----------------------------+ Table 1 An encoding of the CAE MUST meet the following requirements, which are properties the OT environment imposes and are independent of the field map above. An encoding MUST be verifiable offline against cached trust anchors, because many OT environments are segmented from public networks for long, declared intervals (Section 8). The offline-verifiable authorization bundle of [EPRECEIPTS] and the offline inclusion proof Morrison, et al. Expires 18 April 2027 [Page 15] Internet-Draft OT Command Authority October 2026 and checkpoint of each audit record (Section 3.5) are required for this reason. An encoding MUST carry a freshness element (a nonce and an [RFC3339] timestamp with a declared maximum age) to bound replay. An encoding SHOULD ride above, and MUST NOT weaken, the transport security of the underlying session; where the session is [OPCUA], the CAE rides above the OPC-UA secure channel, which proves the channel while the CAE proves the authority. Transport bindings for specific control protocols are out of scope for this revision. [SHARIFICS] specifies per-protocol signed envelopes for Modbus/TCP, OPC UA, MQTT, and CoAP, and a deployment MAY carry a CAE within such an envelope; the two are complementary below the safety boundary (Section 1.1). This revision does not specify the concrete outer encoding of the CAE, that is, how the five bindings above are serialised together into one structure. 8. Security Considerations Several of the boundaries below are open rather than closed, and are marked as such. Availability over authentication. In OT the priority order is availability, then integrity, then confidentiality, the inverse of the usual information-systems order. This profile is built to that order: it fails closed on authority and never on safety (Section 6), and it refuses rather than blocks. If any path in a deployment could let an authority check stall a time-critical control loop, the deployment has mis-placed the gate. Command integrity and diverse-channel confirmation. The CAE binds authority to a control action and makes the action attributable; it is not, on its own, an integrity mechanism for the command value on the wire. The profile requires that an encoding ride above and not weaken the transport security of the underlying session (Section 7), so the command value is protected to the integrity the session provides, and no further. Where a corrupted or spoofed command value is itself a hazard, and in particular where the controlled function carries a safety-integrity requirement at SIL 2 or above in the sense of [IEC61508] and [IEC61511], the transport integrity of a single command path is not sufficient by itself: a deployment SHOULD confirm the commanded state over a channel independent of the command path, for example an independent read-back of the achieved process state, and SHOULD treat a discrepancy as a fault for the process's own safety logic to handle rather than for this profile to handle. Providing such a diverse channel, and meeting a stated SIL target for the end-to-end control function, is a functional-safety engineering task governed by [IEC61508] and [IEC61511]; it is a property of the deployment and its safety case, and it is out of scope for the Morrison, et al. Expires 18 April 2027 [Page 16] Internet-Draft OT Command Authority October 2026 authority binding this memo specifies. This memo neither supplies nor weakens that integrity: a diverse-channel confirmation composes beneath the authority profile, and, like every mechanism here, it MUST NOT be placed where it can gate a safety function (Section 6). Refuse, do not prove. An enforcement point refuses an action whose authority it cannot verify. It does not prove the agent lacked authority. This is a deliberate boundary and is open to challenge. An adversary who can make a valid CAE unevaluable can cause refusal, which in an availability-first setting is itself a denial-of-control concern; the mitigation is the offline-verifiable trust anchor and cached revocation state below, and some residue may remain. Binding-moment forgery and the human-in-the-loop. The gravest failure this profile must exclude is a State-change that executes on no human decision. The requirement that the binding moment be authorization evidence carrying the approver's own signature over the action digest, verifiable offline and not usable more than once (Section 3.4), is what excludes it: an agent cannot manufacture that signature, and cannot replay a genuine one. One residual surface remains: the presentation attacks of [EPRECEIPTS] (Section 13.4 of draft-schrock-ep-authorization-receipts-13), in which an approver may sign a faithful-looking rendering of the wrong action. This memo inherits that residual and the mitigations [EPRECEIPTS] states (render from the hashed bytes, register render templates under the policy, and for the highest classes render the material parameters on a surface the orchestrating operator did not author). It is an enforcement-side obligation this profile places on the enforcement point, not a property it can assume. Revocation latency versus plant time. An authorisation grant revoked mid-session MUST stop future actions it covered within a bounded, declared latency. In a plant, that latency competes with real-time control constraints and with intervals of network segmentation. This memo does not fully resolve the trade between revocation freshness and offline operability; a deployment MUST declare its revocation latency budget and its maximum trust-anchor staleness, and MUST NOT let either gate a safety function. A revocation cannot recall an action already released to the process, and this profile does not close that gap. Key distribution in segmented plants. DNSSEC-rooted discovery per [MCPDNS] assumes the resolver is reachable. A segmented or air- gapped plant is not. This profile therefore requires offline verification against cached trust anchors with declared staleness bounds, for the agent key material, the approver directory of [EPRECEIPTS], and the audit-log checkpoint (Section 3.5). The management of those anchors, their rotation, and their revocation Morrison, et al. Expires 18 April 2027 [Page 17] Internet-Draft OT Command Authority October 2026 across a fleet of long-lived devices is a lifecycle problem this memo does not solve; it requires only that a deployment state its bounds and fail closed on authority when a bound is exceeded. Confused deputy and compromised agent. A valid CAE proves authority, not intent. A compromised agent holding a valid grant can issue any action the grant covers. The mitigations are scope minimality (a grant naming the exact asset, verb, and agent, Section 3.3), the binding moment for consequential classes (Section 3.4), which a compromised agent cannot forge because it carries a human's own signature, and the audit record (Section 3.5) that makes the action attributable after the fact. None of these prevents a first malicious action within scope; they limit what it can reach and make it attributable afterward. Operator as adversary. The operator of the identity and authorisation infrastructure is treated as a potential adversary. The authorisation grant is signed by the principal and not the operator; the binding moment is signed by an approver key the operator does not hold (Section 3.4, and the corresponding guarantee in [EPRECEIPTS]); the audit record is held in an append-only log, and a verifier holding an independently trusted log key can check each record's inclusion and the log's append-only consistency against the view it is given (Section 3.5). Those checks do not by themselves reveal a split view; that needs checkpoints or witnesses obtained independently of the operator. These exist so that no single operator is structurally required and every action is visible and attributable. Scope. This memo specifies the binding and refusal semantics over already-specified discovery, authorisation and human-authorization primitives, and the required properties of the audit record. How a principal comes to be identified to the issuer of a grant is out of scope. 9. Deployment and Incremental Adoption This profile is meant to be adopted incrementally, alongside the installed base rather than in place of it. The enforcement point (Section 2) is an added function at a conduit boundary; it does not replace a control protocol, a safety system, or a historian, and a deployment can introduce it for one asset class or one high- consequence verb before extending it. The authority bindings compose above existing per-protocol transports, including the signed control- protocol envelopes of [SHARIFICS] where those are deployed, so a site that has already invested in a transport binding keeps that investment. Morrison, et al. Expires 18 April 2027 [Page 18] Internet-Draft OT Command Authority October 2026 Adoption of a profile like this depends on the integrating parties, the control-system vendors, the asset owners, and the operators of the discovery, authorisation, and audit-log primitives, each investing in the integration on its own side, and a specification alone does not create that investment. The profile addresses an obligation the deployer already holds. [IEC62443] and the [NERCCIP] reliability standards already require that consequential actions be identified, use-controlled, and auditable; a deployer meets those requirements today with bespoke, non-interoperable, and often manual evidence. The append-only, independently verifiable audit record this profile carries (Section 3.5) gives that obligation a reusable, interoperable mechanism. The concrete integration path on each party's side, and the commercial and operational incentives that make a given party invest, are deployment matters beyond the scope of this memo. 10. IANA Considerations This document has no IANA actions in this revision. A future revision that specifies a concrete CAE encoding is expected to register a media type and MAY request registries for binding types and risk-class identifiers, per [RFC8126]. 11. Note on the Normative References Several references in this document are normative because an implementer requires them to construct or verify a Command Authority Envelope, yet they are individual Internet-Drafts rather than published standards: the individual drafts [CONSENT], [BINDINGMOMENT], [MCPDNS], [HUMANAUTHBIND] and [EPRECEIPTS]. A normative reference to a work in progress will hold this document in the RFC Editor queue until the referenced drafts are published or the references are re-scoped; the authors acknowledge this and expect to revisit the normative and informative split as the referenced work matures. The remaining normative references are to published RFCs: [RFC2119], [RFC8174], [RFC3339] and [RFC9421]. 12. Implementation Status This section records the status of known implementations in accordance with [RFC7942]. It is intended to assist the IETF in its decision processes for this document. The description of implementations in this section is intended neither to describe those implementations as complete or correct nor to endorse them; the listing of an implementation here does not imply endorsement by the IETF. This section is to be removed before publication as an RFC. Morrison, et al. Expires 18 April 2027 [Page 19] Internet-Draft OT Command Authority October 2026 No independent implementation of CAE evaluation at an enforcement point is known at the time of this revision. An independent implementation, against one concrete control-protocol binding, remains the strongest near-term signal this document could receive, and is solicited. Several of the composed primitives do have running code, and two results are reported here. The EMILIA Protocol implementation ([EPCONSENTGRANT], [EPCAEPROFILE]) reports three same-team reference ports, in JavaScript, Python and Go, agreeing across 21 suites and 332 conformance vectors at revision 8f0d9a9fec507a70ea006a91c0765e539a96ffaa, together with an externally authored Rust implementation built from a pinned public source tree that matched 16 suites and 164 of those vectors at that pin; that Rust result is recorded at revision 2535c192553903c63bdc56499da8db7b5d719afc, which fixes the Rust source at 7faba36010e7590727bebbc5b9dcceee60539b9b and the evaluator run at 18739076c822bdc757147326e8d36716432d1b41. This Rust result is time- pinned and is not yet a strict clean-room acceptance result. Each revision named in this paragraph was supplied by the implementer and is reported as supplied; none was independently re-run for this document. Separately, the canonicalisation on which digest grounding depends (B1, Section 3.4) is reported by two implementations written by the same team, one in Python and one in TypeScript, agreeing on a vector suite of 16 canonicalisation cases and 5 required refusals. Nineteen of the twenty-one are exercised on both sides. Two of the refusals run on the Python side only: a parsed JavaScript value cannot present a duplicate member name, and an integer outside the IEEE 754 double range is outside the range RFC 8785 specifies. Both implementations' test suites read that suite from a single file, and the suite was derived once and then re-derived independently on the other implementation before being accepted. The result reported here was obtained on 18 September 2026 against the then-current revision of both implementations, and both have since been published. This is agreement on what the two sides hash and not on CAE evaluation, and it is reported because a digest-grounded binding is only as interoperable as the bytes the two sides hash. Two implementations that disagree about an action's canonical form disagree about every binding computed over it, and do so silently: the signatures verify on each side and match on neither. Morrison, et al. Expires 18 April 2027 [Page 20] Internet-Draft OT Command Authority October 2026 13. Contributors The separation held in Sections 3.3 and 3.4, under which a per-action artefact at the binding moment never rounds up into a standing authorisation, was settled in exchange between the authors. Sections 3.3, 3.4, 4 and 12 of this revision carry text originating with I. Schrock, who was credited as a contributor in earlier revisions and is an author of this one. 14. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, . [CONSENT] Morrison, B., "Consent-Bound Identity Disclosure with Subject Settlement for HTTP-Native Agent Payments", 2026, . [BINDINGMOMENT] Morrison, B., "The Briefing-and-Binding Envelope: A Delivery Contract for Agent-to-Principal Decision Moments with Dual-Veto Reconciliation", 2026, . [MCPDNS] Morrison, B., "Discovery of Model Context Protocol Servers via DNS TXT Records", 2026, . Morrison, et al. Expires 18 April 2027 [Page 21] Internet-Draft OT Command Authority October 2026 [HUMANAUTHBIND] Schrock, I., "Binding Named-Human Authorization Evidence into Agent-Action Records", 2026, . [EPRECEIPTS] Schrock, I., "Authorization Receipts for High-Risk Agent Actions", Work in Progress, Internet-Draft, draft-schrock- ep-authorization-receipts-13, 2026, . 15. Informative References [ALTER-URI] Morrison, B., "The 'alter' URI Scheme for Dispatchable ~handle References", Work in Progress, Internet-Draft, draft-morrison-alter-uri-scheme, 2026, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [EPCONSENTGRANT] Schrock, I., "EP-CONSENT-GRANT-v1: A Signed, Scoped, Revocable Standing Grant", 2026, . [EPCAEPROFILE] Schrock, I., "EP profile of the Command Authority Envelope consent-grant and binding-moment slots", 2026, . Morrison, et al. Expires 18 April 2027 [Page 22] Internet-Draft OT Command Authority October 2026 [WEBBOTAUTH] Meunier, T. and S. Major, "HTTP Message Signatures for automated traffic", 2026, . [SHARIFICS] Sharif, R., "ATTP for Industrial Control Systems: Cryptographic Agent Authentication in SCADA and IoT Environments", 2026, . [IEC62443] International Electrotechnical Commission, "IEC 62443, Security for Industrial Automation and Control Systems", 2018. [NERCCIP] North American Electric Reliability Corporation, "NERC Critical Infrastructure Protection (CIP) Reliability Standards", 2026. [SP80082] National Institute of Standards and Technology, "NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security", 2023. [OPCUA] OPC Foundation, "OPC Unified Architecture, Part 2: Security Model", 2022. [IEC61508] International Electrotechnical Commission, "IEC 61508, Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems", 2010. [IEC61511] International Electrotechnical Commission, "IEC 61511, Functional Safety: Safety Instrumented Systems for the Process Industry Sector", 2016. Appendix A. Document History draft-morrison-ot-command-authority-04 (October 2026): * Names the alter: URI [ALTER-URI] in Section 3.2 as one optional form of the principal reference, without requiring it. * Specifies the audit record (Section 3.5) by its required properties, a signed statement in an append-only log with an offline-checkable inclusion proof, in place of the signed- statement format and receipt it cited, and removes the provenance term and the refusal that depended on it. Updates Sections 1, 7 and 8 and the references to match. Morrison, et al. Expires 18 April 2027 [Page 23] Internet-Draft OT Command Authority October 2026 * States in Section 3.3 that authority is evaluated against each action, and that the grant of the consent-settlement draft does not meet G1 or G2 as it stands. * Splits the audit record in Section 3.5 into an admission record written before dispatch and outcome records appended after it, and qualifies the log guarantee to the checkpoint and consistency checks a verifier can actually make. Sections 3.4, 7 and 8 match. * Names the pre-execution Authorization Bundle as the binding-moment evidence in Section 3.4, and states the approver separation in Section 2 as an explicit policy resting on trusted identity bindings. * Corrects the presentation-attack section reference to the authorization-receipts draft in Section 8, and pins that draft at -13. * Points the web-bot-auth reference at the working-group draft. * Retitles the document, and removes statements about other documents' intent, positioning language and repeated text. No requirement elsewhere changes. Authors' Addresses Blake Morrison Alter Meridian Pty Ltd Email: blake@truealter.com Christopher Whiteside Independent Email: cwhiteside.engineering@gmail.com Iman Schrock EMILIA Protocol, Inc. United States of America Email: team@emiliaprotocol.ai Morrison, et al. Expires 18 April 2027 [Page 24]