Network Working Group K. McGuinness Internet-Draft Independent Intended status: Standards Track 13 August 2026 Expires: 14 February 2027 Mission Substrate Requirements draft-mcguinness-mission-substrate-latest Abstract A Mission binds an actor to approved context under the governance of an identified controller. Authorization substrates realize that relationship in materially different ways. Some carry structured authority in credentials; others keep contextual policy at an online service and use substrate-native authorization at each resource. This document defines a small, substrate-neutral Mission kernel and a set of separately claimable capabilities. The kernel covers a native Mission reference, controller and actor binding, approved context, an approval event, an active/non-active governance gate with bounded reliance, context propagation, and an ordered governance record. Optional capabilities cover lifecycle gating, state observation, structured authority, monotonic derivation, credential binding, independent verification, and portable evidence. A Mission Substrate Statement declares which capabilities a binding supplies and the limits of each claim. The contract deliberately does not require OAuth identifiers or issuer semantics, a particular authorization-details format, a universal Authority Set or subset algebra, a JWT claim, or common intent and authority hashes. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://mcguinness.github.io/mission-bound-authorization/draft- mcguinness-mission-substrate.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft- mcguinness-mission-substrate/. Source for this draft and an issue tracker can be found at https://github.com/mcguinness/mission-bound-authorization. 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." This Internet-Draft will expire on 14 February 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. 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. Table of Contents 1. Introduction 1.1. Scope and Non-Goals 2. Conventions and Terminology 3. Contextual-Governance Kernel 3.1. Native Reference and Controller 3.2. Actor Binding 3.3. Approved Context and Immutability 3.3.1. Default Commitment Construction 3.4. Approval Event 3.5. Basic Governance Gate 3.6. Bounded Reliance 3.7. Context Propagation 3.8. Ordered Governance Record 4. Optional Capabilities 4.1. Lifecycle-Gated Authorization 4.2. State-Observable 4.3. Structured Authority 4.4. Monotonic Derivation 4.5. Credential-Bound 4.6. Independently Verifiable 4.7. Portable Evidence 5. Composition by Capability 6. Mission Substrate Conformance 6.1. Mission Substrate Statement 7. Security Considerations 7.1. Capability Confusion 7.2. Reference and Context Substitution 7.3. Controller Compromise 7.4. State and Residual Authority 7.5. Governance Record Integrity 8. Privacy Considerations 9. IANA Considerations 10. References 10.1. Normative References 10.2. Informative References Appendix A. Binding Mapping Guidance A.1. OAuth-Native Mapping A.2. Standalone MAS Mapping A.3. AAuth-Native Mapping Appendix B. Mission-Bound Authorization Family Use Acknowledgments Author's Address 1. Introduction A Mission is a durable contextual-governance relationship created by an approval event. It associates an actor and approved context with an identified controller, gives that relationship a stable reference, and makes subsequent governance decisions attributable to it. That common relationship does not imply a common authorization model. For example, an OAuth deployment can derive a portable, structured authority envelope and carry it in an access token ([I-D.draft-mcguinness-oauth-mission]). A standalone Mission Authority Server (MAS) can manage the relationship without issuing the resource credential that exercises authority ([I-D.draft-mcguinness-mission-authority-server]). An AAuth Policy Server can keep contextual Mission data private while scopes, resource-owned policy, and per-hop authorization decisions provide deterministic resource access ([I-D.draft-mcguinness-mission-aauth]). Treating the first model as the minimum contract would force the other models to emulate OAuth mechanics. It would also make a claim such as "Mission substrate" ambiguous: a consumer could not tell whether it meant contextual governance, portable authority, current- state enforcement, or independently verifiable evidence. This document therefore defines: * a contextual-governance kernel that every conforming Mission Substrate Binding provides (Section 3); * optional, independently declared capabilities (Section 4); * rules for profiles that consume only the capabilities they need (Section 5); and * a Mission Substrate Statement that makes each binding's guarantees and limits checkable (Section 6.1). The architectural relationship among Mission specifications is described informationally in [I-D.draft-mcguinness-mission-architecture]. This document is the normative contract for substrate-neutral claims. 1.1. Scope and Non-Goals This document standardizes the semantics a binding exposes, not the wire representation used to expose them. It does not define an approval endpoint, credential format, state protocol, authority language, evidence format, or identifier syntax. In particular, the kernel does not require: * an OAuth client_id, Authorization Server, or OAuth issuer identifier; * JSON, JWT, or a member named mission; * authorization_details or any other particular structured authorization language; * one global Authority Set or a subset relation that applies across administrative or protocol boundaries; * intent_hash, authority_hash, or any common set of integrity anchors; or * disclosure of the approved context to a resource or other downstream consumer. A binding MAY use any of those mechanisms. When it does, their guarantees arise from the binding and the capabilities it claims, not from the kernel. This document is designed to be adopted on its own. Conformance requires no other document, and the kernel vocabulary is defined entirely here. The Mission-Bound Authorization family uses this document as its binding-neutral contract; the family vocabulary mapping, the scoped precedence rule for the OAuth-native binding, and the change-ownership rule are collected in Appendix B and are not needed by an adopter outside that family. 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: Actor: The agent, service, workload, person, or other entity whose operations are governed in the Mission context. A binding defines how the Actor is identified and authenticated. "Actor" is not synonymous with OAuth client_id. Approver: The person, policy authority, or other accountable party that makes the approval decision through the binding's native ceremony. Approved Context: The task description, purpose, instructions, boundaries, or other contextual material to which the Approver agreed. It can be machine-readable, human-readable, opaque to consumers, or a combination. It is not necessarily an authorization policy. Controller: The identified authority responsible for the Mission's approval, governance state, and governance record. A binding can distribute these functions, but it identifies the party accountable for them and describes the trust relationships among the components. "Controller" does not imply OAuth token issuance. Mission Context: The durable relationship among a Controller, Actor, Approved Context, approval event, governance state, and governance record. Mission Reference: The substrate-native value, or tuple of values, that identifies one Mission Context within a defined Controller namespace. Mission Substrate Binding: A specification that maps the Mission Context kernel and zero or more optional capabilities onto an authorization substrate and claims conformance to this document. Mission Substrate Statement: The section of a Mission Substrate Binding that declares the binding's kernel mapping and optional capabilities (Section 6.1). Positive governance decision: A Controller decision that approves, permits, or continues an operation specifically by relying on the Mission Context. It does not include an independent resource authorization decision that does not rely on that context. Appendix B maps these terms to the vocabulary of the Mission-Bound Authorization family. 3. Contextual-Governance Kernel Every Mission Substrate Binding MUST provide all requirements in this section. Meeting the kernel means only that a substrate carries Mission contextual governance. It does not by itself mean that authority is portable, machine-evaluable, monotonically derived, credential-bound, or independently verifiable. It does mean that no reliance derived from a Mission is unbounded (Section 3.6). 3.1. Native Reference and Controller A binding MUST define a Mission Reference that is: * stable for the lifetime and retention period of the Mission Context; * unambiguous within the Controller namespace declared by the binding; and * never reassigned to a different Mission Context within that namespace. If the native reference is not globally unambiguous, the binding MUST define the Controller identifier or other namespace value with which it is compared. A reference can be random, content-addressed, sequential within a protected namespace, or a substrate-native tuple. The kernel does not impose a particular syntax. A reference disclosed beyond the Controller MUST NOT be guessable by parties outside the Mission's authorized set: a binding satisfies this with at least 128 bits of reference entropy, with a reference derived from content that is not disclosed beyond that set, or by confining a predictable reference to a namespace whose every keyed surface authenticates the caller and does not disclose existence. The binding MUST define how a relying component identifies the Controller responsible for the reference. This can be local configuration, a protocol identifier, a trust anchor, or another substrate-native mechanism. A binding MUST NOT describe a bare value as globally identifying a Mission when its uniqueness actually depends on unstated local context. 3.2. Actor Binding At approval, the Controller MUST bind the Mission Context to the Actor identity, key, workload identity, authenticated session, or other actor handle defined by the binding. The value MUST be derived from authenticated context or verified proof; it MUST NOT be accepted solely from an unauthenticated proposal. The binding MUST state: * what the Actor handle identifies; * how the Controller establishes it at approval; and * how a later positive governance decision establishes that the acting party is the bound Actor or an authorized delegate. The kernel does not require the same identifier syntax at every hop. A binding that maps between identifiers MUST define which component performs the mapping and the assurance and ambiguity of that mapping. 3.3. Approved Context and Immutability The binding MUST maintain either the Approved Context itself or a verifiable commitment to it. After approval, the approved value MUST be immutable. Mutable operational fields, including current state and log entries, MUST be distinguishable from the approved value. Changing the Approved Context requires a new approval event and a new Mission Reference, unless a binding defines the change as approval of a new immutable version with its own unambiguous reference. A binding MUST NOT silently replace the approved value behind an existing reference. When a binding uses a commitment instead of retaining or disclosing the value, it MUST define: * the exact committed bytes or canonicalization procedure; * algorithm identification and algorithm-agility behavior; * domain separation sufficient to prevent cross-type substitution; and * how a party that possesses the value verifies the commitment. The commitment can be a native content address, a digest, a signed object, or another binding-defined construction. The kernel does not require two distinct commitments for descriptive context and structured authority. A binding that retains the Approved Context at every governance party satisfies this section through the maintained value; a native content address it also uses as the Mission Reference is then verification material for parties holding the value, not a commitment in place of it. 3.3.1. Default Commitment Construction A binding MAY satisfy the duties above, for the Approved Context and for any other artifact it commits, with the following default construction. The OAuth issuance profile ([I-D.draft-mcguinness-oauth-mission]) instantiates it, and family profiles import it from this section; a binding with a native or member-named commitment (a content address, a signed object, a digest whose member name fixes the algorithm) remains free to use that instead, stating its own algorithm identification and agility behavior under the duties above. The default commits to bytes in one of three species, and a specification defining a commitment classifies it: * *Envelope anchor*: SHA-256 [RFC6234] over the JCS [RFC8785] canonical bytes of a closed JSON object carrying exactly three members and no others: typ, a string naming the committed object, collision-resistant because a namespace the defining specification controls qualifies it; iss, a string whose value the defining commitment specifies; and value, the committed JSON value. * *Canonical-object digest*: SHA-256 over the JCS serialization of a normalized JSON object without the envelope, where protocol context already fixes what is committed. * *Raw-octet digest*: SHA-256 over an exact, specification-defined octet sequence, with no canonicalization: a whole artifact as exchanged, or the UTF-8 encoding of a defined scalar value. The envelope's iss is a namespace binding that domain-separates commitments across issuing authorities; it does not authenticate whoever computed the commitment, which stays a signature or evidence property. A digest is encoded as an algorithm prefix followed by the base64url, no-padding [RFC4648] encoding of the digest: sha-256: identifies SHA-256, which is mandatory to implement and the only algorithm defined. Every committed JSON value, and the envelope around it, MUST satisfy I-JSON [RFC7493], and the party computing or verifying a commitment MUST reject non-conformant input before canonicalization: externally received JSON destined for commitment is parsed by a duplicate- detecting parser, and an object carrying duplicate member names is rejected at parse time, before the parsed data model exists; string data is valid Unicode, free of the surrogate and noncharacter code points I-JSON prohibits, and is preserved unchanged; number data supplied to JCS is representable as a finite IEEE 754 binary64 value ([RFC8785], Section 3.1). The commitment is over the parsed I-JSON data value, not the source text; a value needing exact decimal or large-integer semantics rides as a string or under a stricter declared numeric domain. The algorithm prefix is the agility mechanism. A new algorithm enters only through a new prefix defined by a referencing specification, its name drawn from the Named Information Hash Algorithm Registry ([RFC6920]). A verifier MUST reject a digest whose algorithm prefix it does not recognize and MUST NOT treat an unrecognized prefix as sha-256. No transition mechanism is defined: every commitment a current carrier defines is a single prefixed string, and a specification introducing a new prefix MUST define the carrier and schema of any parallel commitment, the binding that proves the old and new values commit to the same object, producer behavior during the transition, verifier selection and downgrade behavior when recognition sets differ, and the transition procedure itself. 3.4. Approval Event A binding MUST define a native approval ceremony that atomically creates an active Mission Context or has equivalent transactional semantics. The ceremony MUST: 1. authenticate the Approver at the assurance level required by the deployment; 2. establish the Actor as specified in Section 3.2; 3. present or otherwise make available to the Approver a faithful representation of the context being approved; 4. record the approval decision, Approver, Actor binding, Approved Context or its commitment, Mission Reference, and Controller; and 5. initialize the Mission as active only after the approval succeeds. If the context being approved changes between presentation and the approval decision, the ceremony MUST NOT create the Mission Context without the Approver's consent to the changed context, and any commitment is computed over the context actually approved. Presentation requirements are substrate-specific. A binding MUST identify security-relevant material supplied by an untrusted proposer and describe how the approval ceremony prevents it from being mistaken for Controller-derived policy or trusted explanation. The kernel does not require the Approved Context to enumerate every resource operation. If the ceremony approves structured authority, the binding claims and follows the Structured Authority capability (Section 4.3). 3.5. Basic Governance Gate Every binding MUST define an active predicate and a non-active outcome. The underlying state vocabulary can be as small as active and terminated, or can contain additional native states and reasons. The Controller MUST make a positive governance decision only while the Mission is active. Every value or condition not recognized as active MUST fail closed for that decision. A non-active Mission can remain available for audit and can be the subject of denial or cleanup decisions. This rule governs decisions made by relying on the Mission Context. It does not assert that every downstream authorization decision is a derivation from the Mission, nor that every resource can observe current Mission state. Those stronger properties require optional capabilities. The binding MUST define at least one authenticated means by which an authorized party can cause the Mission to become non-active. It MUST identify the authorized parties and the effect of the transition on subsequent Controller decisions. A binding MAY express completion, revocation, expiry, or supersession as reasons without making each a distinct protocol state. 3.6. Bounded Reliance Authority derived from a Mission MUST NOT be usable indefinitely. For every positive decision under Section 3.5, and for every credential or other artifact the binding describes as governed by the Mission, the binding MUST state a reliance bound in at least one of two forms: * the decision point establishes that the Mission is active when the decision is made, and the binding states the maximum interval during which the result or artifact remains usable after the Mission becomes non-active; or * the artifact carries an expiry, and the binding states how that expiry is bounded by or disclosed with the Approved Context. A decision or artifact with neither bound does not conform, and a stated bound SHOULD NOT exceed the interval the Mission's purpose requires. This floor requires no consumer-facing freshness source: a binding whose credential lifetimes sit inside the Mission's own bound satisfies it unmodified, as the OAuth core's stateless baseline does. The bound gives the non-active transition of Section 3.5 its force: a party who causes a Mission to become non-active is assured that reliance under the Mission ends within the stated interval. 3.7. Context Propagation Each positive governance decision and each artifact that a binding claims is Mission-governed MUST carry, or be unambiguously joinable to, the Mission Reference and Controller namespace. The binding MUST define the join and the party that performs it. Propagation can occur in a credential, a decision response, a protected protocol exchange, a local execution context, or an audit record. Merely accepting an unverified reference supplied by the Actor does not establish Mission governance. The binding MUST state what the propagation mechanism proves. In particular, it MUST distinguish among: * correlation with a Mission Context; * proof that the Controller made a particular decision; * proof that a credential was issued under that Mission; and * proof that a requested operation is within approved structured authority. The kernel requires only the first property with authenticated or integrity-protected provenance from the Controller. The remaining properties require binding-specific mechanisms and, where applicable, optional capabilities. 3.8. Ordered Governance Record The Controller MUST maintain an integrity-protected, ordered record of governance events for the Mission. At minimum, the record MUST cover approval, positive and negative Controller decisions that rely on the Mission Context, and transition to a non-active outcome. Events MUST be attributable to their source and correlated with the Mission Reference. The ordering mechanism can be a sequence, trusted timestamp plus a defined tie-break rule, append position, or another unambiguous native mechanism. The binding MUST state its ordering semantics, integrity protection, authorized readers, and retention period. The retention period MUST include the active lifetime and a declared post-termination period. This record need not be portable or independently verifiable. A binding that makes either claim also supplies the corresponding capability in Section 4. 4. Optional Capabilities Capabilities are additive claims. A binding MUST NOT claim a capability unless it meets every requirement in that capability's subsection. A capability can be scoped to particular modes, roles, operations, or deployments; such scope is part of the claim and MUST appear in the Mission Substrate Statement. Absence of a capability is not partial conformance. It means that a consumer requiring that property does not compose with the binding in that mode. 4.1. Lifecycle-Gated Authorization A binding claiming *Lifecycle-Gated Authorization* extends the basic governance gate to named authorization operations. Its Statement MUST enumerate those operations, such as authority derivation, delegation, credential issuance, credential refresh, permission decisions, or continued reliance. For every operation in the claim, the decision point MUST establish that the Mission is currently active before returning a positive result. It MUST fail closed when current state cannot be established within the binding's stated freshness bound. The binding MUST state the maximum interval during which a previously issued positive result can remain usable after the Mission becomes non-active. A binding can therefore claim this capability for Controller-issued permission decisions while not claiming it for independently issued resource tokens. It MUST NOT generalize the narrower claim to the uncovered path. 4.2. State-Observable A binding claiming *State-Observable* MUST expose at least one authenticated, integrity-protected source from which a named consumer can determine whether a Mission is active. For each source, the Statement MUST identify: * the authorized consumers; * the state vocabulary and active predicate; * authentication and integrity protection; * the freshness or maximum staleness bound; and * fail-closed behavior for unavailable, invalid, or unknown state. The source MAY return native state names. A projection onto another protocol's vocabulary MUST preserve the active/non-active distinction; an unknown or non-active native value MUST NOT project to active. State-Observable does not by itself require a consumer to check state. That enforcement property is claimed by Lifecycle-Gated Authorization or by a consuming runtime profile such as [I-D.draft-mcguinness-mission-runtime]. 4.3. Structured Authority A binding claiming *Structured Authority* MUST define a machine- evaluable representation of authority associated with the Mission and MUST identify the authority that owns the representation's semantics. The Statement MUST specify: * the representation and its version or type-identification rules; * how resources, operations, and constraints are interpreted; * which decision points consume it; * whether it is approved context, Controller-derived policy, a resource-owned policy input, or a decision result; and * the scope in which two values can be compared. Different resources or administrative domains MAY use different authority languages. This capability does not create a universal Authority Set, require RFC 9396 authorization details, or imply that arbitrary values have a meaningful subset relation. Where constraints admit comparison, the binding MUST define comparison in the constraint's value space. Unknown types or constraints MUST fail closed at a decision point that requires their semantics. 4.4. Monotonic Derivation A binding claiming *Monotonic Derivation* MUST also claim Structured Authority for the values covered by the derivation. It MUST define a no-broader-than relation for those values and the protocol boundary within which that relation is valid. Every derivation, delegation, or attenuation operation included in the claim MUST verify that its result is no broader than its declared parent under that relation. Unsupported or incomparable values MUST fail closed. The Statement MUST identify each narrowing point and the component that performs the comparison. The claim can cover a single authorization language or delegation chain. It MUST NOT be presented as constraining fresh authorization decisions made under a different resource-owned policy or at an uncovered protocol hop. A binding can correlate those decisions with the same Mission while leaving them outside this capability. 4.5. Credential-Bound A binding claiming *Credential-Bound* MUST define an integrity- protected association between a credential or authorization artifact and exactly one Mission Reference and Controller namespace. It MUST identify: * the protected fields or join inputs that establish the association; * the credential or artifact issuer and verifier trust relationship; * how the credential is bound to the Actor or authorized delegate; * substitution and replay protections; and * whether issuance or refresh is covered by Lifecycle-Gated Authorization. The association MAY be a JWT claim, another credential field, a protected protocol parameter, or a verified join. A reference copied from Actor-controlled input without Controller or credential-issuer validation does not satisfy this capability. The Statement MUST distinguish a credential cryptographically issued under the Mission from a credential merely correlated with a Mission by an external join. Either can be useful, but they provide different assurance and MUST NOT share an unqualified claim. 4.6. Independently Verifiable A binding claiming *Independently Verifiable* MUST let the named consumer verify a specified Mission property without an online query to the Controller. The Statement MUST enumerate the properties, for example Controller approval, context commitment, credential binding, structured authority, or state as of a signed observation. For every property, the binding MUST define the verification artifact, canonical input, trust anchor or key discovery mechanism, algorithm agility, validity interval, and revocation or freshness limitations. Verification failure or an unsupported algorithm MUST fail closed. Independent verification of a signature does not establish current state unless the artifact and its validity rules provide that property. It also does not make private Approved Context available or turn contextual governance into a machine-evaluable policy language. 4.7. Portable Evidence A binding claiming *Portable Evidence* MUST define evidence that can be transferred across the administrative boundary stated in the claim and verified there. The Statement MUST identify: * each evidence type and the event or decision it represents; * its binding to the Mission Reference, Controller, Actor where appropriate, and relevant decision or artifact; * canonical bytes, integrity protection, and verification procedure; * ordering, duplicate handling, and correlation semantics; * retention and key-availability periods; and * disclosure, minimization, and unlinkability considerations. Portable Evidence MAY reveal only a commitment to Approved Context. The capability does not require disclosure of the context itself. Signed receipts, Mandates, or transparency statements can supply this capability when their profiles meet these requirements ([I-D.draft-mcguinness-mission-mandate], [I-D.draft-mcguinness-mission-audit]). 5. Composition by Capability A substrate-neutral profile MUST declare the kernel functions and optional capabilities it consumes. It MUST NOT infer an undeclared capability from the generic statement that a binding supports Missions. Examples include: * a profile that only correlates Controller decisions and log entries can consume the kernel; * action-time termination enforcement consumes State-Observable and a lifecycle-gating rule at the relevant enforcement point; * offline attenuation consumes Structured Authority, Monotonic Derivation, Credential-Bound, and usually Independently Verifiable; * cross-domain audit consumes Portable Evidence and whatever underlying property the evidence proves; and * resource-side policy evaluation consumes Structured Authority only when that representation is defined for the resource. A Mission reference alone is not structured authority. Where a binding lacks a required capability, a profile can define an explicit adapter or join. The adapter's specification MUST state the new trust assumptions, what it proves, what it cannot prove, and its failure behavior. The adapter then supplies the capability; the kernel does not acquire it retroactively. Capability claims compose only over their declared scope. For example, an online Controller decision can be lifecycle-gated while a previously issued resource token remains valid until expiry, and one authority language can support monotonic delegation while a later resource-owned decision is independent. Specifications MUST preserve those boundaries rather than describe the whole deployment with the stronger local property. 6. Mission Substrate Conformance This document defines conformance for a specification. An implementation conforms to the binding specification it implements. A conforming Mission Substrate Binding: 1. defines every element of the contextual-governance kernel in Section 3; 2. publishes a Mission Substrate Statement as specified in Section 6.1; 3. claims only optional capabilities whose complete requirements it satisfies in the claimed scope; and 4. defines fail-closed behavior when a required reference, binding, state, authority value, commitment, proof, or capability cannot be established. There are no "full" and "partial" provision levels. Those labels hide which guarantees are actually present. The capability list and scope in the Mission Substrate Statement are the conformance result. 6.1. Mission Substrate Statement A Mission Substrate Binding MUST contain a section titled "Mission Substrate Statement". It MUST identify the specification version and mode to which the statement applies. For the kernel, the Statement MUST provide a checkable mapping for: 1. the Mission Reference, its uniqueness namespace, comparison rules, retention, non-reassignment rule, and how the unguessability requirement of Section 3.1 is met; 2. the Controller identity and how relying components establish it; 3. the Actor handle, its authentication at approval, later Actor binding, delegation if any, and identifier mappings; 4. the Approved Context, its immutable boundary, and any commitment and verification procedure; 5. the native approval ceremony and each step of Section 3.4; 6. the active predicate, non-active outcome, authorized transition mechanisms, and effect on subsequent Controller decisions; 7. the reliance bound of Section 3.6 for each decision and Mission- governed artifact class: the stated maximum residual interval, the expiry rule, or both; 8. every propagation or join surface claimed to establish Mission governance and the exact property each surface proves; and 9. governance-record event coverage, ordering, integrity, access, and retention. The Statement MUST then include a capability table with one row for each capability in Section 4. Each row MUST say supported, not supported, or conditional. A supported or conditional row MUST cite the binding sections that satisfy the capability, state its mode and operational scope, and list material limitations. A conditional row MUST state the extension, deployment property, or cooperating component that supplies the condition. The following is a non-normative skeleton: +================+===========+=============+=======================+ |Capability |Claim |Scope and | Limitations | | | |defining | | | | |sections | | +================+===========+=============+=======================+ |Lifecycle-Gated |supported |Controller | Previously issued | |Authorization | |permission | resource credentials | | | |decisions | expire independently | +----------------+-----------+-------------+-----------------------+ |State-Observable|conditional|Status | Maximum staleness is | | | |extension | deployment-configured | +----------------+-----------+-------------+-----------------------+ |Structured |not |-- | Approved Context is | |Authority |supported | | descriptive | +----------------+-----------+-------------+-----------------------+ |Monotonic |not |-- | No authority | |Derivation |supported | | comparison relation | | | | | is defined | +----------------+-----------+-------------+-----------------------+ |Credential-Bound|supported |Native | Covers correlation, | | | |authorization| not context | | | |artifact | disclosure | +----------------+-----------+-------------+-----------------------+ |Independently |conditional|Signed | Proves approval as of | |Verifiable | |receipt | issuance, not current | | | |profile | state | +----------------+-----------+-------------+-----------------------+ |Portable |not |-- | Governance record is | |Evidence |supported | | Controller-local | +----------------+-----------+-------------+-----------------------+ Table 1: Illustrative Mission Substrate Statement capability table Text outside the Statement cannot silently broaden a capability claim. If another specification adds a capability, that specification MUST publish an updated Statement or a Statement extension that identifies the base binding and precise added scope. 7. Security Considerations 7.1. Capability Confusion The principal risk this document addresses is capability confusion: treating Mission correlation as proof of authority, an approval as proof of current state, a local narrowing relation as a universal subset rule, or a signed artifact as proof of facts it does not carry. Consumers need to match every required property to an explicit capability claim and its scope. A secure implementation fails closed when a required capability is absent, conditional but unavailable, or outside its declared scope. It does not upgrade a kernel-only reference because its syntax resembles a credential claim or content digest. 7.2. Reference and Context Substitution The Controller namespace is part of Mission identity whenever a reference is not globally unique. Omitting it permits references from one Controller to be substituted at another. A content- addressed reference additionally depends on correct canonicalization, domain separation, and algorithm identification; a random or sequential reference depends on the Controller's protected lookup. Actor, context, credential, and decision bindings need to cover the same Mission Reference and Controller namespace. An implementation that joins values from different namespaces or accepts an Actor- supplied reference without authentication can attribute unrelated authority or activity to a Mission. 7.3. Controller Compromise The Controller is trusted for the kernel properties it asserts. A compromised Controller can approve false context, bind the wrong Actor, make false decisions, suppress governance events, or report false state. Independently Verifiable and Portable Evidence can make some misbehavior detectable or attributable, but do not prevent a trusted Controller from making a malicious decision. The broader threat model is analyzed by [I-D.draft-mcguinness-mission-security-model]. Where Controller functions are distributed, the binding's Statement needs to expose the trust and authentication between approval, state, decision, logging, and credential components. Naming one logical Controller does not eliminate those internal trust boundaries. 7.4. State and Residual Authority The kernel's non-active outcome stops new positive Controller governance decisions. It does not automatically invalidate every artifact previously issued or stop a resource that cannot observe state. Lifecycle-Gated Authorization and State-Observable claims must state their coverage and residual interval. Short credential lifetime can bound residual authority but is not instantaneous termination. The bounded-reliance floor (Section 3.6) guarantees that a stated bound exists on every conforming path; it does not make any bound short. A bound long enough to be vacuous defeats the floor's purpose; consumers evaluate the stated interval, not only its presence. 7.5. Governance Record Integrity An ordered record that is not externally witnessed can still be truncated or rewritten by a compromised Controller. The kernel requires integrity protection against unauthorized modification, not public transparency. Deployments needing third-party detection of equivocation or truncation require Portable Evidence or a separate transparency profile. 8. Privacy Considerations Mission References are correlation handles. Reusing them across resources or administrative domains can reveal that otherwise unrelated actions belong to one task. Bindings SHOULD disclose a reference only to components that require Mission correlation and SHOULD prefer audience-specific derived handles where cross-context correlation is unnecessary. Approved Context can contain sensitive instructions, resource names, personal data, and business purpose. The kernel allows it to remain at the Controller and allows downstream surfaces to carry only a reference or commitment. A binding SHOULD minimize context in credentials, state responses, and evidence and MUST document the additional disclosure introduced by Structured Authority, Independently Verifiable, or Portable Evidence claims. Governance records create durable behavioral histories. Bindings need access control, declared retention, deletion policy after the retention period, and minimization of Actor and Approver identifiers. Integrity commitments and predictable Mission References can themselves become stable correlation values, and a commitment can enable guessing attacks when the committed context has low entropy. 9. IANA Considerations This document has no IANA actions. 10. References 10.1. 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, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., Keranen, A., and P. Hallam-Baker, "Naming Things with Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, . [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . 10.2. Informative References [I-D.draft-mcguinness-mission-aauth] McGuinness, K., "Mission Context Binding for AAuth", 2026, . [I-D.draft-mcguinness-mission-architecture] McGuinness, K., "An Architecture for Mission-Bound Authorization", 2026, . [I-D.draft-mcguinness-mission-audit] McGuinness, K., "Mission Audit Transparency", 2026, . [I-D.draft-mcguinness-mission-authority-server] McGuinness, K., "Mission Authority Server", 2026, . [I-D.draft-mcguinness-mission-mandate] McGuinness, K., "Mission Mandate", 2026, . [I-D.draft-mcguinness-mission-runtime] McGuinness, K., "Mission-Bound Runtime Enforcement", 2026, . [I-D.draft-mcguinness-mission-security-model] McGuinness, K., "Mission Security Model", 2026, . [I-D.draft-mcguinness-oauth-mission] McGuinness, K., "Mission-Bound Authorization for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-status] McGuinness, K., "Mission Status and Lifecycle for OAuth 2.0", 2026, . Appendix A. Binding Mapping Guidance This appendix is informative. It illustrates how existing Mission architectures map to the capability model. It is not a substitute for the normative Mission Substrate Statement published by each binding, and an extension or deployment can change a row. +===============+================+================+=================+ | Capability | OAuth Mission | Standalone MAS | AAuth Mission | +===============+================+================+=================+ | Contextual- | Native Mission | Native Mission | Native Mission | | governance | record, AS | record, MAS | reference and | | kernel | controller, | controller, | PS-controlled | | | OAuth client/ | explicit join | contextual | | | subject | boundary | Mission | | | mappings | | | +---------------+----------------+----------------+-----------------+ | Lifecycle- | AS gates | MAS gates its | PS gates | | Gated | covered token | own decisions; | covered | | Authorization | issuance and | OAuth | permission or | | | derivation | credential | token | | | | issuance | decisions; | | | | requires a | coverage | | | | cooperating | depends on the | | | | credential | AAuth access | | | | issuer | mode | +---------------+----------------+----------------+-----------------+ | State- | Conditional on | Conditional on | Not implied by | | Observable | Status, | the exposed | the private | | | introspection, | MAS status | Mission blob; | | | or signal | mechanism | requires a | | | support | | management or | | | | | state | | | | | extension for | | | | | other | | | | | consumers | +---------------+----------------+----------------+-----------------+ | Structured | OAuth | Can use the | Not inherent | | Authority | authorization | OAuth Mission | in the Mission | | | details and | authority | description; | | | their type- | representation | scopes or a | | | specific | | resource-owned | | | semantics | | structured | | | | | language can | | | | | supply it for | | | | | their own | | | | | decision | | | | | boundary | +---------------+----------------+----------------+-----------------+ | Monotonic | Applies where | Applies to | Not a baseline | | Derivation | the OAuth | MAS-governed | cross-hop | | | profile | authority | property; a | | | defines and | operations; | structured | | | checks its no- | not | resource | | | broader-than | automatically | policy can | | | relation | to an | define | | | | unchanged AS | monotonicity | | | | | within its own | | | | | vocabulary | +---------------+----------------+----------------+-----------------+ | Credential- | Mission-bound | Not supplied | Native Mission | | Bound | OAuth | by the MAS | reference can | | | credential | alone; | be credential- | | | | conditional on | bound where | | | | a verified | the PS or | | | | join or | federated AS | | | | cooperating | carries and | | | | credential | validates it; | | | | issuer | not every | | | | | access mode | | | | | does | +---------------+----------------+----------------+-----------------+ | Independently | Possible where | Conditional on | A resource can | | Verifiable | signed | signed | verify a | | | credentials | artifacts and | credential, | | | expose the | the property | but cannot | | | property and | they expose | thereby | | | verification | | independently | | | material | | verify private | | | | | contextual | | | | | Mission | | | | | content or the | | | | | PS's full | | | | | reasoning | +---------------+----------------+----------------+-----------------+ | Portable | Supplied only | Likewise | A PS-local | | Evidence | by evidence, | conditional on | Mission log is | | | Mandate, or | an evidence | not portable | | | audit profiles | profile | evidence; | | | that define | | signed | | | portable | | receipts or | | | artifacts | | checkpoints | | | | | would be an | | | | | extension | +---------------+----------------+----------------+-----------------+ Table 2: Illustrative capability mapping for existing architectures A.1. OAuth-Native Mapping OAuth Mission can intentionally claim a broad set of capabilities. Its Authorization Server can act as Controller, OAuth identifiers can instantiate Actor and subject mappings, Rich Authorization Requests can supply Structured Authority, and protected access-token fields can supply Credential-Bound. Its defined subset relation can support Monotonic Derivation within the authorization-detail types and operations covered by that relation. Those are strengths of the OAuth binding, not kernel requirements. State observation remains conditional on a status, introspection, or signals mechanism such as [I-D.draft-mcguinness-oauth-mission-status]. Independent verification is limited to the properties actually present in a verifiable credential; current state and undisclosed context do not follow from a Mission identifier or hash alone. A.2. Standalone MAS Mapping The MAS separates Mission governance from an otherwise unchanged Authorization Server. It can satisfy the kernel and can provide Structured Authority and Monotonic Derivation for operations it owns. It does not, by itself, prove that an OAuth access token was issued under a Mission. A verified join can establish correlation, and a cooperating credential issuer can add stronger lifecycle and credential-binding properties. The MAS Statement needs to describe those as conditional capabilities and preserve the boundary between MAS assertions and Authorization Server behavior. A.3. AAuth-Native Mapping An AAuth Mission naturally implements the contextual-governance kernel: the Policy Server controls approval and contextual decisions, the native Mission reference identifies the approved blob, and the Mission log records governance interactions. The private mission description need not be a machine-evaluable authorization policy. Deterministic access can remain with scopes, Access Server policy, or a resource-owned structured policy language. Such a language can claim Structured Authority, and possibly Monotonic Derivation, only inside the boundary where its semantics and comparison relation are defined. A fresh downstream authorization decision is not required to be a subset of a single upstream Mission Authority Set. Credential-Bound and Lifecycle-Gated Authorization claims need to be made per AAuth access mode. A PS-issued authorization artifact can carry a protected native Mission reference and be gated at issuance; an independently issued resource credential does not acquire those properties merely because the agent also has a Mission. Similarly, a PS-local log supplies the kernel governance record but not Portable Evidence. State management, signed evidence, and resource-verifiable structured decisions are useful AAuth extensions rather than baseline kernel requirements. Appendix B. Mission-Bound Authorization Family Use This appendix is normative for documents of the Mission-Bound Authorization family and informative for every other adopter. An adopter outside the family does not need it. The family's earlier documents, including the published OAuth core ([I-D.draft-mcguinness-oauth-mission]), use the vocabulary this contract was generalized from. The terms correspond as follows: +============+====================================================+ | This | Family documents | | document | | +============+====================================================+ | Mission | Mission | | Context | | +------------+----------------------------------------------------+ | Mission | Mission Identifier | | Reference | | +------------+----------------------------------------------------+ | Controller | Mission Issuer, where the binding issues; natively | | | the AS, MAS, UMA authorization server, or AAuth PS | +------------+----------------------------------------------------+ | Actor | the authenticated acting client or agent | +------------+----------------------------------------------------+ | Approver | Approver | +------------+----------------------------------------------------+ | Approved | the Mission Intent, the recorded authority | | Context | proposal where one was submitted, and the derived | | | Authority Set | +------------+----------------------------------------------------+ | Ordered | the Mission log, assessment log, or audit record | | governance | | | record | | +------------+----------------------------------------------------+ Table 3: Family vocabulary mapping A family document that maps its own vocabulary to the kernel's MUST use these correspondences. Precedence is scoped, not global. For the OAuth-native binding, the core's definitions govern that mapping; this document governs the kernel and capability vocabulary. Neither document depends normatively on the other. Ownership migrates by touch, not by relocation. When a binding- neutral definition next changes substantively, the change MUST land in this document, and the owning family section becomes a reference to it; no change is ever made solely to move words. Acknowledgments This document refines the substrate interface first consolidated informationally by the architecture document. The author thanks the Mission-Bound Authorization implementer community for feedback. Author's Address Karl McGuinness Independent Email: public@karlmcguinness.com