Network Working Group K. McGuinness Internet-Draft Independent Intended status: Standards Track 2 October 2026 Expires: 5 April 2027 Mission Control-Plane Consistency draft-mcguinness-mission-control-plane-latest Abstract This optional profile specifies topology-neutral consistency and recovery invariants for Mission issuers and state-observation consumers. It separates serialized authority changes from asynchronous publication, prevents freshness from being manufactured after lag or recovery, and keeps emergency authority outside the Mission enforcement claim. It defines no endpoint or wire member. 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-control-plane.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft- mcguinness-mission-control-plane/. 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 5 April 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 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 2. Conventions 3. Shared Consistency and Availability Rule 4. Issuer Consistency Invariants 4.1. 1. Serialization domains 4.2. 2. Fresh observations, not fresh signatures 4.3. 3. One state-observation model 4.4. 4. Rollback resistance 4.5. 5. Terminal-state tombstones 4.6. 6. Authoritative mutation under partition 4.7. 7. Emergency narrowing 4.8. 8. Positive emergency authority is separate 4.9. 9. Isolation at mutable seams 4.10. 10. Repairable fan-out 5. Deployment Declaration 6. Fault Conformance Cases 7. Conformance 8. Security Considerations 9. Privacy Considerations 10. IANA Considerations 11. Normative References Appendix A. Document History Acknowledgments Author's Address 1. Introduction Mission approval anchors, mutable lifecycle state, and runtime policy views solve different problems. A correctly signed artifact is insufficient if its issuer lost a committed revocation, double-spent a creation budget, or re-stamped a stale observation. This profile gives those failure modes a testable consistency contract without prescribing a database, leader topology, or replication product. The OAuth binding's existing atomic issuance and identifier-nonreuse duties ([I-D.draft-mcguinness-oauth-mission]) remain unconditional for adopters of that binding. Declining this optional profile cannot waive them. Status owns state versions and freshness ([I-D.draft-mcguinness-oauth-mission-status]), Signals owns its delivery protocol ([I-D.draft-mcguinness-oauth-mission-signals]), and Runtime owns point-of-use bounded reliance ([I-D.draft-mcguinness-mission-runtime]). 2. Conventions 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. "Mission Issuer" identifies the authority owning the Mission record, not necessarily an OAuth Authorization Server. "Canonical tuple" means the binding-established issuer identity and Mission identifier, not caller-chosen aliases. State versions and PDP policy-view identifiers inhabit different identifier spaces and are not compared for raw equality. 3. Shared Consistency and Availability Rule A deployment may trade availability inside a declared freshness window, but it cannot manufacture freshness, lose a serialized narrowing transition, or relabel emergency authority as Mission authority. Operational availability guidance composes with this anchor; it does not define a second set of issuer invariants. Recovery objectives guide selecting bounds within the security ceiling, never extending them during an incident. 4. Issuer Consistency Invariants The following requirements apply when the deployment claims this profile, in addition to the unconditional requirements of each adopted binding. Each subsection identifies its enforcing subject. 4.1. 1. Serialization domains The Mission Issuer MUST provide one serialization order per Mission and per multi-object invariant. Atomic domains include lifecycle state, state version, and durable fan-out work; predecessor supersession and successor creation; parent fan-out accounting and child creation; counter checks/increments and artifact issuance; and an idempotency claim and its side effect. These members commit together or none does. A region label is not a serialization mechanism. This tightens the binding's existing atomic-issuance obligations and adds explicit durable fan-out coupling. 4.2. 2. Fresh observations, not fresh signatures A signer of a state observation MUST NOT manufacture freshness by assigning a new iat or fresh_until to an older observation without establishing that its value reflects the authoritative committed state at the new observation point. The issuer establishes an authenticated observation/commit watermark justified by its consistency mechanism. An authoritative transactional read, quorum/read-index, or correctly defined lease mechanism can provide that guarantee; a lease alone does not prove inclusion of a committed transition. Without it, the signer may replay an original authenticated snapshot only within that snapshot's original validity and audience binding, or refuse. Signature validity proves producer and integrity, not recency. The Status freshness ceiling is unchanged. 4.3. 3. One state-observation model A binding claiming this profile MUST map its state observations onto the existing Status, introspection, Mission Status List, or Signals semantics, rather than define a parallel signed state-snapshot protocol. A binding-native realization can map those semantics without adopting another binding's endpoint or claim. Push delivery supplies invalidation and ordered-transition information; it is not the sole evidence of active state after freshness confidence is lost. Conflicting observations are reconciled under the version and freshness rules, never by selecting the more permissive surface. 4.4. 4. Rollback resistance After restore or failover, the Mission Issuer MUST NOT issue a lower state version for an existing Mission, and MUST refuse state- dependent service while its durable version or commit metadata is uncertain. A retaining consumer MUST key its high-water mark by the canonical (issuer, mission_id) tuple, reject a lower version, and retain the high-water mark across its own recovery. A legitimate higher-version resume to active is accepted under the other validity checks; state names are not ordered by severity. Issuer durability is required even when a consumer has never seen the pre-restore version. 4.5. 5. Terminal-state tombstones The Mission Issuer MUST retain terminal-state tombstones for the maximum applicable credential/artifact lifetime, state-staleness plus skew, idempotency/retry horizon, child-cascade horizon, and audit- retention horizon. A tombstone identifies the canonical issuer/Mission tuple, terminal state, final version, and transition time or commit reference. After detailed retention expires, the issuer MUST retain enough namespace state to prevent identifier reuse or a return to active. This composes retention horizons; it does not weaken the binding's existing identifier-nonreuse requirement. 4.6. 6. Authoritative mutation under partition The Mission Issuer MUST perform issuance, refresh, expansion, child creation, and lifecycle mutation against authoritative current state within the operation's serialization domain, and MUST refuse when it cannot establish that condition. A read from a node called a replica is not inherently forbidden if the consistency mechanism establishes its authority and currency for this operation. A stale or non-authoritative read is forbidden regardless of node name. The data plane may rely on already-valid observations only within its separate Runtime bounds; that does not authorize a stale control-plane write. 4.7. 7. Emergency narrowing An issuer or deny cache MUST NOT use emergency deny information to create authority or extend the freshness of an active observation. A separately authenticated suspend, revoke, or containment operation may narrow immediately under its own governed authorization, idempotency, versioning, and evidence. A non-terminal deny entry MUST carry version, authenticated source, and expiry or a reconciliation rule. Expiration of such an entry only removes that additional denial; ordinary positive checks still apply. A terminal tombstone MUST NOT expire into active behavior. 4.8. 8. Positive emergency authority is separate A deployment MUST NOT represent positive emergency permission as a Mission permit, active Mission state, or Authority Set authorization, and MUST exclude actions relying on that permission from its Mission enforcement claim. The ordinary Mission path still fails closed. Operator-facing emergency-mode activation and truthful evidence belong to the operational profile; narrowing emergency control is described in Section 4.7. No emergency flag turns a failed Mission check into a successful one. 4.9. 9. Isolation at mutable seams Issuers and retaining consumers MUST isolate mutable Mission state by the canonical (issuer, mission_id) tuple, or a tenant-qualified equivalent that unambiguously preserves both identities. This applies to version high-water marks, idempotency records, deny caches, counters, queues, signing authorization, quotas, and replication authority. Tenant-wide services such as signing keys or queues bind each operation to that qualified identity; this does not require one key or queue per Mission. Shared infrastructure declares its tenant separation and resource isolation so one tenant cannot silently consume another's state-propagation guarantee. 4.10. 10. Repairable fan-out The Mission Issuer MUST atomically retain durable publication or repair work with each committed transition and publish only after that commit, with idempotent recovery that prevents loss of the committed transition. An outbox or equivalent satisfies this only when it shares the state transaction. A second Signals database does not join that transaction merely because its API is called inside it. Publication can duplicate, reorder, or stop after commit: event identity and Mission/version correlation make redelivery idempotent and gaps detectable, and consumers resynchronize from an authoritative state surface. Non-active transitions receive priority. The profile does not promise global delivery order or require a particular worker/ claiming topology. 5. Deployment Declaration A claiming deployment MUST document its serialization domains, authoritative observation mechanism, replication and recovery model, applicable recovery objectives, tenant isolation, and residual risks. The declaration may use the Deployment Profile's illustrative state_sources entries, for example serialization_domain, replication, and recovery_objective_seconds; those illustrative names define no standardized metadata member or endpoint. The existing mission_max_stale_seconds ceiling retains its meaning. A residual risk is a disclosed limitation, not an exemption from a requirement the deployment claims. 6. Fault Conformance Cases +=======================+=============================+===========+ | Fault or race | Required outcome | Invariant | +=======================+=============================+===========+ | Two writers race a | One serialized result; no | Section | | transition or counter | double budget spend | 4.1 | +-----------------------+-----------------------------+-----------+ | Child creation races | Child record and counter | Section | | the fan-out cap | commit together | 4.1 | +-----------------------+-----------------------------+-----------+ | Expansion fails | Neither half survives alone | Section | | between predecessor | | 4.1 | | and successor writes | | | +-----------------------+-----------------------------+-----------+ | Crash after state | Durable repair publishes | Section | | commit, before | without losing the | 4.10 | | publication | transition | | +-----------------------+-----------------------------+-----------+ | Lagging node signs a | Refusal unless an | Section | | newly fresh active | authoritative observation | 4.2 | | value | establishes that value | | +-----------------------+-----------------------------+-----------+ | Restore exposes a | Issuer refuses until | Section | | lower version | reconciled; retaining | 4.4 | | | consumer rejects rollback | | +-----------------------+-----------------------------+-----------+ | Legitimate higher- | State is not rejected | Section | | version resume | merely because active seems | 4.4 | | | less severe | | +-----------------------+-----------------------------+-----------+ | Partition outlasts | No new control-plane | Section | | the existing | mutation; stale reliance | 4.6 | | freshness horizon | stops | | +-----------------------+-----------------------------+-----------+ | Terminal record is | Identifier does not regain | Section | | absent after backup | active authority | 4.5 | | restore | | | +-----------------------+-----------------------------+-----------+ | Same Mission ID under | No shared high-water mark, | Section | | two issuers | budget, or idempotency | 4.9 | | | result | | +-----------------------+-----------------------------+-----------+ | Key rotation during | A new signing key does not | Section | | replication lag | create freshness | 4.2 | +-----------------------+-----------------------------+-----------+ | Duplicate or out-of- | Idempotent handling, gap | Section | | order transition | detection, authoritative | 4.10 | | events | resynchronization | | +-----------------------+-----------------------------+-----------+ | Positive emergency | Truthfully separate | Section | | permission | authority; affected actions | 4.8 | | | excluded from the claim | | +-----------------------+-----------------------------+-----------+ Table 1 7. Conformance A deployment claiming Mission Control-Plane Consistency MUST satisfy every applicable requirement for the issuer, binding, and consumer roles it runs. The conformance ledger separates the ten invariant groups from implementation coverage; an unimplemented test is not evidence of compliance. Existing binding-level conformance remains independent of this optional claim. 8. Security Considerations A valid signature can authenticate a stale or rolled-back assertion. Consumer high-water marks complement, but do not replace, issuer durability: a new consumer has no history against which to detect rollback. Failure between the authoritative transaction and an external publisher requires repair work in the former, not a best- effort call to the latter. Emergency denial is not positive authorization. Expiring an emergency deny never skips ordinary state, authority, identity, or point-of-use checks. Shared infrastructure needs both identity isolation and bounded propagation capacity; correct cache keys alone do not establish tenant availability. 9. Privacy Considerations Durable tombstones, idempotency records, and qualified Mission identifiers can correlate activity. Retain the minimum facts needed for the stated security horizons, restrict disclosure, and avoid putting human identity or action content into replication and queue keys. 10. IANA Considerations This document requests no IANA actions. 11. Normative References [I-D.draft-mcguinness-mission-runtime] McGuinness, K., "Mission-Bound Runtime Enforcement", 2026, . [I-D.draft-mcguinness-oauth-mission] McGuinness, K., "Mission-Bound Authorization for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-signals] McGuinness, K., "Mission Lifecycle Signals for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-status] McGuinness, K., "Mission Status and Lifecycle for OAuth 2.0", 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Appendix A. Document History [[ To be removed from the final specification ]] * Initial topology-neutral consistency foundation (#250): ten issuer invariant groups, the shared consistency and availability rule, the deployment declaration riding existing surfaces, and the fault conformance table. Implementation, multi-process claiming, and operator performance measurement are separate work. Acknowledgments The author thanks the Mission-Bound Authorization implementer community. Author's Address Karl McGuinness Independent Email: public@karlmcguinness.com