Consented and Attributable Agent Authority for Operational-Technology Control Actions
draft-morrison-ot-command-authority-01

Network Working Group                                        B. Morrison
Internet-Draft                                    Alter Meridian Pty Ltd
Intended status: Informational                                 July 2026
Expires: 23 January 2027

 Consented and Attributable Agent Authority for Operational-Technology
                            Control Actions
                 draft-morrison-ot-command-authority-01

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 consented to this specific action on
   this specific asset, whether a human authorised the action where the
   action's 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
   defined elsewhere, DNSSEC-rooted agent discovery, scoped and
   revocable consent, a human-in-the-loop binding moment, and a
   provenance-labelled audit record, into a single structure, the
   Command Authority Envelope, that an OT conduit 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 maps the
   profile onto the identification, use-control, and audit requirements
   that [IEC62443] and [NERCCIP] state but do not give a wire mechanism
   for.  The methods by which a principal's identity is inferred are out
   of scope by construction.

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/.

   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."

Morrison                 Expires 23 January 2027                [Page 1]
Internet-Draft            OT Command Authority                 July 2026

   This Internet-Draft will expire on 2 January 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   3
   3.  The Command Authority Envelope  . . . . . . . . . . . . . . .   4
     3.1.  Agent identity  . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Principal reference . . . . . . . . . . . . . . . . . . .   5
     3.3.  Consent grant . . . . . . . . . . . . . . . . . . . . . .   5
     3.4.  Binding moment  . . . . . . . . . . . . . . . . . . . . .   6
     3.5.  Audit record  . . . . . . . . . . . . . . . . . . . . . .   7
   4.  Conduit Evaluation and Fail-Closed Behaviour  . . . . . . . .   7
   5.  Risk Classes  . . . . . . . . . . . . . . . . . . . . . . . .   8
   6.  Safety Carve-Out  . . . . . . . . . . . . . . . . . . . . . .   8
   7.  Encoding and Transport Binding  . . . . . . . . . . . . . . .   9
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   10. Implementation Status . . . . . . . . . . . . . . . . . . . .  11
   11. Review Sought . . . . . . . . . . . . . . . . . . . . . . . .  11
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     12.2.  Informative References . . . . . . . . . . . . . . . . .  12
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  14
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   Two bodies of standards work are moving quickly in parallel, and they
   do not meet.

Morrison                 Expires 23 January 2027                [Page 2]
Internet-Draft            OT Command Authority                 July 2026

   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 [WEBBOTAUTH] effort standardises
   how an automated agent authenticates itself over HTTP, and its
   charter deliberately declines to bind that key to a human principal.
   This work is real and useful, and 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.

   The gap between the two is specific and, at present, unserved: 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
   a conduit 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 a conduit that evaluates it.

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.

Morrison                 Expires 23 January 2027                [Page 3]
Internet-Draft            OT Command Authority                 July 2026

   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.

   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, though a deployment MAY apply the profile to reads.

   Conduit:  In the sense of [IEC62443], the communication path between
      zones across which a control action travels, and the point at
      which this profile is enforced.

   Command Authority Envelope (CAE):  The structure defined in this memo
      that a control action MUST carry to be accepted by a conduit that
      implements this profile.

   Resolution receipt:  A durable record that a human resolved a control
      action requiring a binding moment (Section 3.4).  The receipt is
      distinct from the transient exchange, per [BINDINGMOMENT], that
      produced the resolution: it persists after that exchange
      completes, carries the outcome, and identifies the resolving
      human.  It is what a conduit or an auditor checks after the moment
      of consequence has passed.

   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 explicitly 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 a conduit
   that implements this profile MUST carry a Command Authority Envelope.
   The CAE is a signed structure carried alongside the control action.
   Its encoding and transport binding are specified in Section 7.  The
   CAE binds five things.

Morrison                 Expires 23 January 2027                [Page 4]
Internet-Draft            OT Command Authority                 July 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
   conduit.  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, which is the gap
   [WEBBOTAUTH] leaves open by design.

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.  This binding is the one the agent-authentication layer
   deliberately omits: 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.  Consent grant

   The CAE MUST carry a reference to a consent grant that satisfies all
   of the following, independent of which mechanism produces the grant:

   *  the grant is issued by the principal and is revocable by the
      principal at will;

   *  the grant names the specific asset (the zone, conduit, device, or
      point) the action targets;

   *  the grant names the specific control verb the action performs;

   *  the grant carries 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 a conduit MUST evaluate coverage against the specific
   action, not against the grant's breadth.  Consent is captured against
   the action, not inferred from an operator's one-time enrolment.

Morrison                 Expires 23 January 2027                [Page 5]
Internet-Draft            OT Command Authority                 July 2026

   This memo does not mandate a single mechanism for the grant.
   [CONSENT] is one candidate, not the only one: as specified, its grant
   scopes an attribute and a reader, which does not by itself bind an
   asset and a control verb.  A deployment filling this row with
   [CONSENT] MUST extend the grant object with the asset, control-verb,
   and expiry bindings required above before it satisfies this section.
   Any mechanism that produces a grant meeting the four bindings above,
   [CONSENT] so extended among them, satisfies this section.

   The EMILIA Protocol [EPARCH] carries a standing grant object, scoped
   to an asset, a control verb, and an expiry, and revoked by a separate
   revocation statement.  That object meets the four bindings above as
   specified, without the extension the preceding paragraph describes.

3.4.  Binding moment

   For a control action whose risk class requires it (Section 5), the
   CAE MUST carry, or commit to, a resolution receipt that satisfies all
   of the following, independent of which mechanism produces it:

   *  a human resolved the action at the moment of consequence, with the
      two-way veto property that neither the agent nor the human can
      railroad the other;

   *  the receipt identifies which human resolved it (an attribution
      slot);

   *  the receipt's outcome persists as durable state, retrievable by
      the conduit or an auditor after the moment of consequence has
      passed, independent of the lifecycle of the exchange that produced
      it.

   The live exchange between agent and human at the moment of
   consequence is, by construction, a transient payload: it exists to
   carry a decision across a channel, not to persist afterward.
   [BINDINGMOMENT] specifies that exchange and its two-way veto
   property, and remains the reference for how the moment itself is
   conducted.  It does not, by construction, carry an attribution slot
   or durable state, so a conduit checking a CAE against this section
   MUST NOT treat the transient exchange alone as satisfying it.  The
   CAE binds to the resolution receipt: a durable record, separate from
   the transient exchange, that carries the outcome and the attribution
   above and that persists at least as long as the audit record of
   Section 3.5.  This memo does not mandate a single mechanism for
   producing the resolution receipt; [BINDINGMOMENT]'s exchange is one
   source for the decision it records, and not the only one, and any
   mechanism that produces a receipt meeting the properties above
   satisfies this section.

Morrison                 Expires 23 January 2027                [Page 6]
Internet-Draft            OT Command Authority                 July 2026

   The authorization receipt of [EPRECEIPTS] is one such mechanism.  It
   binds named, enrolled approvers to the exact action by its hash,
   records that the approval reached a terminal state, and remains
   verifiable offline against a signed log checkpoint after the exchange
   that produced it has ended.

   The resolution receipt records a human decision at the moment of
   consequence; it is distinct from the consent grant, which records a
   prior, standing authorisation of a scope.

3.5.  Audit record

   The CAE MUST carry, or commit to, an append-only audit record of the
   action, labelled with a provenance term from the closed vocabulary of
   [PROVENANCE].  The record MUST be sufficient to attribute the action
   afterward: which agent, on which principal's authority, under which
   consent grant, with which binding-moment resolution receipt if any,
   against which asset, at which time per [RFC3339].  The audit record
   is the artefact that the evidence requirements of [IEC62443] and
   [NERCCIP] ask for and that no agent-authentication layer today
   produces.

   This memo does not set a retention period.  The period is a property
   of the deployment and of the regime it answers to, and a deployment
   MUST declare the retention period it applies to the audit record.
   The resolution receipt of Section 3.4 is retained for at least that
   same period, so that the record and the receipt it names remain
   retrievable together.

4.  Conduit Evaluation and Fail-Closed Behaviour

   A conduit 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.  A conduit
   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.  This is
   the same posture as the [COMPUTELOC] gate: the conduit refuses the
   request rather than attempting to prove, cryptographically, that the
   agent lacked authority.  That is an honest and contestable trust
   boundary, and Section 8 states it as such.

Morrison                 Expires 23 January 2027                [Page 7]
Internet-Draft            OT Command Authority                 July 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

   A conduit 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.  The CAE, if required at
      all, MUST carry agent identity and an audit record.  Principal
      reference, consent, and a resolution receipt 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, a consent
      grant covering the asset and verb, and an audit record.  A
      Section 3.4 resolution receipt 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
      Section 3.4 resolution receipt MUST be present and valid.

   A conduit MUST refuse a State-change action whose CAE lacks a valid
   Section 3.4 resolution receipt, without exception, and MUST NOT
   downgrade an action's class to avoid a binding requirement.

6.  Safety Carve-Out

   This is the requirement the profile refuses to compromise, and it is
   stated first among the security considerations because it is the one
   an OT engineer will test first.

   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

Morrison                 Expires 23 January 2027                [Page 8]
Internet-Draft            OT Command Authority                 July 2026

   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.

   The profile constrains who may command a process to move.  It has no
   authority over the process's own right to protect itself.  A design
   that allowed an identity check to block a trip would be a safety
   regression introduced in the name of security, and this memo forbids
   it.

7.  Encoding and Transport Binding

   [This section is deliberately thin in this -01 and is the first place
   a co-author with OT protocol depth is invited to shape the work.]

   The CAE is a signed structure.  This memo does not mandate a single
   encoding; it states the requirements an encoding MUST meet and lists
   the bindings a deployment is expected to specify.

   An encoding MUST be verifiable offline against a cached trust anchor,
   because many OT environments are segmented from public networks for
   long, declared intervals (Section 8).  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 and are the natural content of a companion document
   or a future revision.

8.  Security Considerations

   This section is written to be attacked.  Several of the boundaries
   below are honest and contestable rather than closed, and they are
   marked as such.  Independent review from an operational-technology
   and critical- infrastructure background is the review this document
   most needs.

Morrison                 Expires 23 January 2027                [Page 9]
Internet-Draft            OT Command Authority                 July 2026

   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.  The reviewer should test whether
   any path in a deployment could let an authority check stall a time-
   critical control loop; if one exists, the deployment has mis-placed
   the gate.

   Refuse, do not prove.  A conduit refuses an action whose authority it
   cannot verify.  It does not prove the agent lacked authority.  This
   is a deliberate, contestable boundary inherited from [COMPUTELOC].
   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 the reviewer is invited to find
   the residue.

   Revocation latency versus plant time.  A consent 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.  The
   trade between revocation freshness and offline operability is real
   and is not fully closed here; a deployment MUST declare its
   revocation latency budget and its maximum trust-anchor staleness, and
   MUST NOT let either gate a safety function.

   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 a cached trust anchor with a declared staleness
   bound.  The management of that anchor, its rotation, and its
   revocation across a fleet of long-lived devices is the same lifecycle
   problem that current OT security guidance identifies as largely
   unsolved, and this memo does not claim to solve it; it requires only
   that a deployment state its bound and fail closed on authority when
   the 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 and verb, Section 3.3), the resolution
   receipt for consequential classes (Section 3.4), 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
   bound its blast radius and guarantee its attribution.

Morrison                 Expires 23 January 2027               [Page 10]
Internet-Draft            OT Command Authority                 July 2026

   Operator as adversary.  Consistent with the wider architecture this
   profile belongs to, the operator of the identity and consent
   infrastructure is treated as a potential adversary.  The consent
   grant, the audit record, and the standardised, independently
   verifiable bindings exist so that no single operator is structurally
   required and every action is visible and attributable, rather than
   trusting the operator to behave.

   Scope and the deliberate omission.  This memo specifies only the
   binding and refusal semantics over already-specified discovery,
   consent, binding- moment, and provenance primitives.  The methods by
   which a principal's identity or trustworthiness is inferred are out
   of scope by construction, and no such method is described, referenced
   in detail, or required here.  A reviewer does not need those methods
   to judge the trust model, the fail-closed behaviour, or the safety
   carve-out, which are the parts that matter for this document.

9.  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].

10.  Implementation Status

   This section records the status of known implementations per
   [RFC7942].  There are no interoperable implementations at the time of
   this revision.  An independent implementation of CAE evaluation at a
   conduit, against one concrete control-protocol binding, is the
   strongest near-term signal this document could receive and is
   explicitly solicited.

11.  Review Sought

   The transport binding (Section 7), the risk-class mapping
   (Section 5), and the security considerations (Section 8) are the
   parts where further operational-technology and critical-
   infrastructure engineering review is most wanted.  That review is
   openly solicited, and a reviewer who wants to shape those sections
   rather than only comment on them is welcome to say so.

12.  References

12.1.  Normative References

Morrison                 Expires 23 January 2027               [Page 11]
Internet-Draft            OT Command Authority                 July 2026

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3339]  Klyne, G. and C. Newman, "Date and Time on the Internet:
              Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
              <https://www.rfc-editor.org/info/rfc3339>.

   [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
              Signature Algorithm (EdDSA)", RFC 8032,
              DOI 10.17487/RFC8032, January 2017,
              <https://www.rfc-editor.org/info/rfc8032>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC9110]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "HTTP Semantics", STD 97, RFC 9110,
              DOI 10.17487/RFC9110, June 2022,
              <https://www.rfc-editor.org/info/rfc9110>.

   [RFC9421]  Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP
              Message Signatures", RFC 9421, DOI 10.17487/RFC9421,
              February 2024, <https://www.rfc-editor.org/info/rfc9421>.

12.2.  Informative References

   [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,
              <https://www.rfc-editor.org/info/rfc7942>.

   [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,
              <https://www.rfc-editor.org/info/rfc8126>.

   [EPARCH]   Schrock, I., "The EMILIA Protocol: An Evidence
              Architecture for Consequential Agent Actions", 2026,
              <https://datatracker.ietf.org/doc/draft-schrock-ep-
              architecture/>.

   [EPRECEIPTS]
              Schrock, I., "Authorization Receipts for High-Risk Agent
              Actions", 2026, <https://datatracker.ietf.org/doc/draft-
              schrock-ep-authorization-receipts/>.

Morrison                 Expires 23 January 2027               [Page 12]
Internet-Draft            OT Command Authority                 July 2026

   [MCPDNS]   Morrison, B., "Discovery of Model Context Protocol Servers
              via DNS TXT Records", 2026,
              <https://datatracker.ietf.org/doc/draft-morrison-mcp-dns-
              discovery/>.

   [CONSENT]  Morrison, B., "Consent-Bound Identity Disclosure with
              Subject Settlement for HTTP-Native Agent Payments", 2026,
              <https://datatracker.ietf.org/doc/draft-morrison-consent-
              settlement/>.

   [BINDINGMOMENT]
              Morrison, B., "The Binding-Moment Envelope: A Machine-
              Checkable Shape for Returning a Consequential Decision to
              a Human Principal", 2026,
              <https://datatracker.ietf.org/doc/draft-morrison-binding-
              moment-envelope/>.

   [PROVENANCE]
              Morrison, B., "A Closed Vocabulary for the Provenance of
              Machine-Generated Statements", 2026,
              <https://datatracker.ietf.org/doc/draft-morrison-
              substrate-provenance-grammar/>.

   [COMPUTELOC]
              Morrison, B., "The Compute-Location Gate: Constraining
              Where an Identity Inference May Run by the Provenance of
              Its Input", 2026, <https://datatracker.ietf.org/doc/draft-
              morrison-compute-location-gate/>.

   [WEBBOTAUTH]
              IETF web-bot-auth Working Group, "Web Bot Authentication",
              2026, <https://datatracker.ietf.org/wg/webbotauth/>.

   [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.

Morrison                 Expires 23 January 2027               [Page 13]
Internet-Draft            OT Command Authority                 July 2026

Contributors

   Christopher Whiteside
   Email: cwhiteside.engineering@gmail.com

Author's Address

   Blake Morrison
   Alter Meridian Pty Ltd
   Email: blake@truealter.com

Morrison                 Expires 23 January 2027               [Page 14]