| Internet-Draft | Mission Substrate | August 2026 |
| McGuinness | Expires 22 February 2027 | [Page] |
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.¶
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.¶
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 22 February 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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 Person 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);¶
rules for profiles that consume only the capabilities they need (Section 6); and¶
a Mission Substrate Statement that makes each binding's guarantees and limits checkable (Section 7.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.¶
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.¶
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:¶
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.¶
The person, policy authority, or other accountable party that makes the approval decision through the binding's native ceremony.¶
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.¶
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.¶
The durable relationship among a Controller, Actor, Approved Context, approval event, governance state, and governance record.¶
The substrate-native value, or tuple of values, that identifies one Mission Context within a defined Controller namespace.¶
A specification that maps the Mission Context kernel and zero or more optional capabilities onto an authorization substrate and claims conformance to this document.¶
The section of a Mission Substrate Binding that declares the binding's kernel mapping and optional capabilities (Section 7.1).¶
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.¶
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.7).¶
| Kernel duty | The binding defines |
|---|---|
| Native reference and Controller (Section 3.1) | A stable, non-reassigned Mission Reference, its uniqueness namespace, how unguessability is met where the reference is disclosed beyond the Controller, and how relying components identify the Controller |
| Authority roles (Section 3.2) | The authorities responsible for the functions it uses; roles never collapse silently |
| Actor binding (Section 3.3) | The Actor handle, its authenticated establishment at approval, and how later decisions establish the acting party |
| Approved context and immutability (Section 3.4) | The immutable approved value or a verifiable commitment to it, distinct from mutable operational fields |
| Approval event (Section 3.5) | A native ceremony that atomically creates an active Mission from an authenticated approval |
| Basic governance gate (Section 3.6) | An active predicate; positive decisions only while active, and every unrecognized condition fails closed |
| Bounded reliance (Section 3.7) | A stated reliance bound on every positive decision and every Mission-governed artifact |
| Context propagation (Section 3.8) | The join between decisions or artifacts and the Mission Reference, and exactly what that join proves |
| Ordered governance record (Section 3.9) | An integrity-protected, ordered, attributable record of governance events |
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.¶
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.¶
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. A default construction a binding MAY adopt for these duties is defined in Section 4.¶
A binding MUST define a native approval ceremony that atomically creates an active Mission Context or has equivalent transactional semantics. The ceremony MUST:¶
authenticate the Approver at the assurance level required by the deployment;¶
establish the Actor as specified in Section 3.3;¶
present or otherwise make available to the Approver a faithful representation of the context being approved;¶
record the approval decision, Approver, Actor binding, Approved Context or its commitment, Mission Reference, and Controller; and¶
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 5.3).¶
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.¶
Authority derived from a Mission MUST NOT be usable indefinitely. For every positive decision under Section 3.6, 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 binding's stateless baseline does. The bound gives the non-active transition of Section 3.6 its force: a party who causes a Mission to become non-active is assured that reliance under the Mission ends within the stated interval.¶
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.¶
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 5.¶
Any specification that defines a commitment, a Mission Substrate Binding or an importing profile alike, MAY satisfy the commitment duties of Section 3.4, 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 specification 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 of Section 3.4.¶
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.¶
The OAuth binding's Integrity Anchor Test Vectors
([I-D.draft-mcguinness-oauth-mission]) give a byte-level worked
example of the envelope-anchor species alone (intent_hash,
proposal_hash, authority_hash); an implementation can check its
own computation against them. The canonical-object and raw-octet
species above, the parse-time duplicate-detection rule, the I-JSON
numeric domain, and the reject-unknown-prefix and no-downgrade
agility rules remain prose-only: no vector pins them.¶
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.¶
| Capability | Property claimed |
|---|---|
| Lifecycle-Gated Authorization (Section 5.1) | Named authorization operations are gated on currently active state |
| State-Observable (Section 5.2) | An authenticated source lets a named consumer determine whether a Mission is active |
| Structured Authority (Section 5.3) | A machine-evaluable authority representation with an identified semantics owner |
| Monotonic Derivation (Section 5.4) | Covered derivations verify a no-broader-than relation within a declared boundary |
| Credential-Bound (Section 5.5) | An integrity-protected association between an artifact and exactly one Mission, with selected fact semantics |
| Authorized Context Correlation (Section 5.6) | An authorized association among independently established facts, made by an identified joining authority |
| Independently Verifiable (Section 5.7) | A named consumer verifies a specified property without an online query to the Controller |
| Portable Evidence (Section 5.8) | Evidence crosses a stated administrative boundary and verifies there |
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.¶
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].¶
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.¶
Every covered transition is classified as exactly one of:¶
preserve:the same authoritative fact remains applicable across the transition;¶
attenuate:the result's validity derives from a provable no-broader-than relationship to its declared parent under the claimed relation; or¶
decide_anew:a target-recognized authority makes a fresh decision under its own policy.¶
Incomparability routes to refusal or to decide_anew; a translation
between vocabularies is never silently treated as attenuation.¶
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; in the
classification above those decisions are decide_anew.¶
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.¶
A Credential-Bound claim MUST select which of the following fact semantics the mechanism establishes, and a claim MUST NOT say "Mission-bound" without that selection:¶
correlation only;¶
artifact issuance under the Mission;¶
authority derivation under the Mission;¶
lifecycle-gated issuance; or¶
current state as of an observation.¶
These are separate facts: none follows from another, they provide different assurance, and the issued-under and correlation-only semantics MUST NOT share an unqualified claim. Actor or presenter proof is a separate element of the claim: a bearer artifact can be Mission-bound under any of these semantics while offering a weaker holder guarantee.¶
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.¶
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]).¶
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.¶
This document defines conformance for a specification. An implementation conforms to the binding specification it implements.¶
A conforming Mission Substrate Binding:¶
defines every element of the contextual-governance kernel in Section 3;¶
publishes a Mission Substrate Statement as specified in Section 7.1;¶
claims only optional capabilities whose complete requirements it satisfies in the claimed scope; and¶
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.¶
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:¶
the Mission Reference, its uniqueness namespace, comparison rules, retention, non-reassignment rule, and how the unguessability requirement of Section 3.1 is met;¶
the Controller identity and how relying components establish it;¶
the Actor handle, its authentication at approval, later Actor binding, delegation if any, and identifier mappings;¶
the Approved Context, its immutable boundary, and any commitment and verification procedure;¶
the native approval ceremony and each step of Section 3.5;¶
the active predicate, non-active outcome, authorized transition mechanisms, and effect on subsequent Controller decisions;¶
the reliance bound of Section 3.7 for each decision and Mission-governed artifact class: the stated maximum residual interval, the expiry rule, or both;¶
every propagation or join surface claimed to establish Mission governance and the exact property each surface proves; and¶
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 5. Each row MUST say supplied or
not supplied: a capability is supplied in a named scope when the
row's stated activation conditions hold, or it is not supplied.
There is no third state. An activation condition states separately
what a specification defines, what an implementation supports, what
a deployment enables, and where the resulting property applies. A
supplied row MUST:¶
cite the binding sections that satisfy the capability;¶
state its mode and operational scope;¶
state its activation conditions: the extension, deployment
configuration, or cooperating component that must hold for the
property to be supplied in that scope, or always;¶
state its temporal elements: the fact's freshness at use, the decision or artifact lifetime, and the residual interval after the Mission becomes non-active, each stated directly or expressly inherited from the reliance floor of Section 3.7;¶
state its failure behavior for absent, stale, unknown, incomparable, invalid, or unavailable input; and¶
list material limitations.¶
An extension can itself publish a provider claim as a Statement extension; a deployment profile declares which extensions and activation conditions are active.¶
The following is a non-normative skeleton:¶
| Capability | Claim | Activation | Scope and defining sections | Limitations |
|---|---|---|---|---|
| Lifecycle-Gated Authorization | supplied | always | Controller permission decisions | Previously issued resource credentials expire independently |
| State-Observable | supplied | Status extension active | Status responses | Maximum staleness is deployment-configured |
| Structured Authority | not supplied | -- | -- | Approved Context is descriptive |
| Monotonic Derivation | not supplied | -- | -- | No authority comparison relation is defined |
| Credential-Bound | supplied | always | Native authorization artifact | Covers correlation, not context disclosure |
| Authorized Context Correlation | supplied | Verified join active | Join assertions | Joining authority is the Controller |
| Independently Verifiable | supplied | Signed receipt profile active | Signed receipts | Proves approval as of issuance, not current state |
| Portable Evidence | not supplied | -- | -- | Governance record is Controller-local |
A real Statement also carries each supplied row's temporal elements and failure behavior; the skeleton omits those columns for width.¶
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.¶
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, claimed with unmet activation conditions, or outside its declared scope. It does not upgrade a kernel-only reference because its syntax resembles a credential claim or content digest.¶
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.¶
An attacker can combine valid identity evidence, a valid credential, and a valid Mission from different transactions. Each piece verifies on its own; the composite is unauthorized. Authorized Context Correlation (Section 5.6) is required whenever one authority did not itself bind all required facts in the applicable context, and a consumer MUST NOT treat co-presentation of independently valid facts as an authorized association.¶
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.¶
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.¶
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.¶
This document has no IANA actions.¶
This appendix is informative. Each of the five bindings publishes the normative Mission Substrate Statement for its substrate: the OAuth binding's Statement is Appendix B.1 of this document, and the standalone MAS ([I-D.draft-mcguinness-mission-authority-server]), AAuth ([I-D.draft-mcguinness-mission-aauth]), UMA ([I-D.draft-mcguinness-mission-uma]), and GNAP ([I-D.draft-mcguinness-mission-gnap]) bindings each publish their own. Those Statements, not this appendix, are the authoritative capability claims. This appendix illustrates the mapping method through three design poles among which a new substrate can locate itself.¶
The OAuth binding can intentionally claim a broad set of capabilities. Its Authorization Server can act as Controller, OAuth identifiers can instantiate Actor and subject mappings, and protected access-token fields can supply Credential-Bound. Registered authorization-detail types can supply Structured Authority: each type's semantics owner defines its operations, constraints, and comparison behavior, and Rich Authorization Requests are the carrier, not the semantics. 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 is supplied when a status, introspection, or signals mechanism such as [I-D.draft-mcguinness-oauth-mission-status] is active. 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.¶
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 with their activation conditions and preserve the boundary between MAS assertions and Authorization Server behavior.¶
An AAuth Mission naturally implements the contextual-governance kernel: the Person Server (PS) 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.¶
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 binding ([I-D.draft-mcguinness-oauth-mission]), use the vocabulary this contract was generalized from. The terms correspond as follows:¶
| This document | Family documents |
|---|---|
| Mission Context | Mission |
| Mission Reference | Mission Identifier |
| 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 Context | the Mission Intent, the recorded authority proposal where one was submitted, and the derived Authority Set |
| Ordered governance record | the Mission log, assessment log, or audit record |
A family document that maps its own vocabulary to the kernel's MUST use these correspondences.¶
The authority-role map (Section 3.2) aligns with the OAuth binding's
Authority Sources: the authority_source record member and its three
sources (user-delegated, service-owned, organizational) are the OAuth
binding's realization of the authority-source authority role, and its
source ceiling is that role's assertion staying within the named
source's authority.¶
Precedence is scoped, not global. For the OAuth-native binding, the OAuth binding'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.¶
This section is the Mission Substrate Statement of the OAuth Mission binding ([I-D.draft-mcguinness-oauth-mission]), hosted here so the OAuth binding remains self-contained with no companion normative dependency. It applies to the OAuth binding's editor's-draft lineage and to the kernel and capability vocabulary of this document. The OAuth binding's own definitions govern every mapped construct; this Statement claims no property the OAuth binding does not define.¶
For the kernel:¶
The Mission Reference is mission_id: high-entropy, unambiguous
within the issuer namespace, compared by exact string equality
together with mission.issuer, never reassigned, retained for the
audit horizon, and disclosed beyond the issuer only on the
binding's authorized surfaces.¶
The Controller is the Mission Issuer (the Authorization Server),
established through mission.issuer and the deployment's issuer
trust (AS metadata and published keys).¶
The Actor handle is the authenticated OAuth client at approval;
the external Subject is fixed by the OAuth binding's injective mapping;
delegates ride the act chain; child and successor lineage is
recorded through the parent and predecessor members; actor-type
classification uses sub_profile and instance assertions where
deployed.¶
The Approved Context is the Mission Intent recorded verbatim, the
recorded authority proposal where one was submitted, and the
derived Authority Set; the immutable boundary is the record's
immutable members; commitments are the typed integrity anchors
(intent_hash, proposal_hash, authority_hash); a material
change obtains a new approval through an expansion successor.¶
The approval ceremony is the OAuth binding's approval event: authenticated Approver, the distinct-approver rule for write-bearing Missions, rendering of the derived Authority Set and the effective expiry, and atomic record commit, with deferred, interactive, and dispatch realizations.¶
The active predicate is state equal to active, exactly; any
other value, recognized or not, is non-active; transitions are
authenticated lifecycle operations; a non-active Mission refuses
issuance and derivation.¶
The reliance bound is the record's effective expires_at (never
later than the requested ceiling), which caps every derived
credential's exp; the maximum residual after a Mission becomes
non-active is the outstanding credential lifetime, bounded by the
deployment's declared access-token TTL.¶
The propagation and join surfaces are: the mission claim
(artifact issuance under the Mission, authority derivation, and
lifecycle-gated issuance); the mission_id and
mission_expires_at response members (correlation only); the
introspection projection (state as of the response, caller
authorization and minimization applying); the Status surfaces
(state as of a signed observation with explicit freshness); and
the grant binding (the issuer's native association of Mission,
Subject, client, and credential).¶
The governance record is the Mission Record with its approval evidence and lifecycle history, retained for the audit horizon, with integrity resting on record custody and the typed anchors.¶
The capability table:¶
| Capability | Claim | Activation | Scope and defining sections | Limitations |
|---|---|---|---|---|
| Lifecycle-Gated Authorization | supplied | always | State-gated issuance and every derivation gate | Outstanding credentials run to their own exp; the residual is bounded, not zero |
| State-Observable | supplied | Status, introspection, or Signals companion active | Those surfaces | Staleness bounded by each surface's declared freshness |
| Structured Authority | supplied | always |
authorization_details with registered types and the Common Constraints |
Semantics exist per registered type, not universally |
| Monotonic Derivation | supplied | always | The subset rule over covered types at every derivation, delegation, and attenuation point | Covered transitions are attenuate; a cross-vocabulary transition is decide_anew, never silent attenuation |
| Credential-Bound | supplied | always | The mission claim on issued tokens |
Fact semantics: issuance under the Mission, authority derivation, lifecycle-gated issuance; state-as-of only via the State-Observable surfaces |
| Authorized Context Correlation | supplied | the Delegation role active ([I-D.draft-mcguinness-oauth-mission]) | The Token Exchange join at delegated issuance: the AS, as joining authority, joins the Mission and Subject carried by the Mission-bound subject_token with the delegate identity independently established by the actor_token or the delegate's own client authentication, binding both to the newly issued credential |
The base grant binding at issuance co-establishes its facts and is not a join; cross-authority joins are the Mission Authority Server's machinery, not this binding's |
| Independently Verifiable | supplied | Mandate, signed Status, or audit companion active | Anchor recomputation and signed artifacts per those profiles | Signature verification never establishes current state |
| Portable Evidence | supplied | Evidence, Mandate, or audit companion active | Per those profiles | The governance record is otherwise issuer-local |
Temporal elements: every issued credential's exp is capped by the
record's effective expires_at; state observations carry their
surface's declared freshness; the residual after non-active is the
outstanding credential lifetime under the deployment's declared TTL.
Failure behavior: an unknown lifecycle state is non-active; an
unresolvable reference, a failed anchor verification, and an unknown
authorization_details type fail closed; where a row's activation
condition does not hold, the property is not supplied and a consumer
MUST NOT rely on it.¶
The OAuth binding's three OPTIONAL implementation roles, which its Conformance section names OPTIONAL capabilities ([I-D.draft-mcguinness-oauth-mission]), are surfaces an implementation may or may not offer, each independent of the others. The capability table above states scoped guarantee claims: properties the OAuth binding supplies and the conditions under which each is supplied. The two vocabularies answer different questions and are not equivalent; the entries below relate them without collapsing one into the other. Declaring an OPTIONAL role never creates a claim beyond the eight already stated above.¶
Exercises State-Observable. One of State-Observable's three named activation surfaces, alongside Status and Signals; declaring it activates that otherwise-conditional claim.¶
Exercises Lifecycle-Gated Authorization, Structured Authority,
Monotonic Derivation, Credential-Bound, and Authorized Context
Correlation. The OAuth binding's delegation subset-checks
authorization_details, carries the mission claim unchanged,
sender-constrains the delegated credential to the delegate's own
key, and refuses issuance unless the Mission is active. The Token
Exchange that issues the delegated credential is itself a grant
binding at issuance: the AS joins the Mission and Subject carried
by the Mission-bound subject_token with the delegate identity
established by the actor_token or the delegate's own client
authentication, binding both to the newly issued credential. Four
of the five claims are supplied always, and Delegation exercises
them rather than creating them; Authorized Context Correlation is
the exception, activated by this role, whose Token Exchange join
is its supplier. The act chain itself supplies none of them: it
is attribution, never authority.¶
Exercises Lifecycle-Gated Authorization, Structured Authority,
Monotonic Derivation, and Credential-Bound. Carries these four
always-supplied guarantees across the domain hop: the Mission
reference and authority_hash intact, authority that only
narrows, and projection gated on active state, while adding an
interoperable projection surface the guarantees alone do not
provide. It does not become Portable Evidence by crossing a
domain: that claim activates only when an Evidence, Mandate, or
audit companion is active, and Cross-Domain is not among them.¶
This document refines the substrate interface first consolidated informationally by the architecture document. The author thanks the Mission-Bound Authorization implementer community for feedback.¶