Network Working Group K. McGuinness Internet-Draft Independent Intended status: Standards Track 6 July 2026 Expires: 7 January 2027 Mission Mandate draft-mcguinness-mission-mandate-latest Abstract A Mission's committed facts (the approved task, the consented authority, the principals, and the expiry) live on the Mission record at its issuer, and a party outside the issuing domain cannot verify what was approved short of a token-exchange hop or trust in the issuer's own records. This document defines the Mission Mandate: a signed, portable, independently verifiable statement of a Mission's committed facts, minted by the Mission Issuer. A Mandate is evidence, not a credential; presenting one authorizes nothing. It lets a cross-domain verifier, an external rail deriving its own vertical mandate, or an auditor verify what was approved from the artifact plus a current-state check. An optional selective- disclosure presentation limits what a given verifier sees. 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/draft-mcguinness-oauth-mission/draft- mcguinness-mission-mandate.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft- mcguinness-mission-mandate/. Source for this draft and an issue tracker can be found at https://github.com/mcguinness/draft-mcguinness-oauth-mission. 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 7 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 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. Status: An OPTIONAL Extension 3. Conventions and Terminology 4. Mission Substrate 5. Mission Mandate 5.1. JOSE Header 5.2. Mandate Claims 5.3. State at Issuance 5.4. Minting 5.5. Example 6. Selective Disclosure 7. Mandate Verification 7.1. Failure Taxonomy 8. Mandate Use 8.1. Cross-Domain Verification 8.2. Vertical Derivation 8.3. Mission Evidence 9. Non-Goals and Deferred Work 10. Conformance 11. Security Considerations 11.1. Mandate-as-Credential Misuse 11.2. Stale-State Reliance 11.3. Issuer Key Compromise 11.4. Confusion with the Cross-Domain Grant 12. Privacy Considerations 12.1. Task-Data Propagation 13. IANA Considerations 13.1. Media Type Registration 13.1.1. application/mission-mandate+jwt 14. References 14.1. Normative References 14.2. Informative References Acknowledgments Author's Address 1. Introduction Mission-Bound Authorization for OAuth 2.0 [I-D.draft-mcguinness-oauth-mission] (the "issuance profile") commits a Mission's facts at the approval event: the approved Mission Intent and consented Authority Set under their integrity anchors, the Subject and Approver, the agent client_id, the derivation policy_version, and the mission_expiry. Those facts live on the Mission record, held by the Mission Issuer; a derived token or cross- domain grant projects only the mission claim and an audience-scoped subset of the authority. A verifier that needs the committed facts themselves (a partner domain, a payments network deriving its own vertical mandate, an auditor in another organization) has today only a token-exchange hop it may have no standing to perform, or trust in records it cannot check. This document defines the *Mission Mandate*: a signed JWT in which the Mission Issuer states a Mission's committed facts. Any holder can verify it against the issuer's published keys, with no exchange and no callback for the facts themselves. Only currency is external: a Mandate proves what was committed as of its iat, and a verifier that relies on the Mission being active checks current state separately (Section 5.3). A Mandate is evidence, not a credential. The issuance profile makes mission_id an informational reference: presenting it authorizes nothing ([I-D.draft-mcguinness-oauth-mission], Section "Binding the Mission to the Grant"). A Mandate extends that rule from the identifier to the full committed record: presenting a Mandate authorizes nothing either. It lets a verifier know what was approved; authority remains the substrate's job (Section 8.1). 2. Status: An OPTIONAL Extension This document is OPTIONAL. A deployment that never mints Mandates is fully conformant to the issuance profile and its companions and is unaffected by this document; the Mandate defines no authority surface and places no requirement on deployments that do not claim it. The Mandate is among the newest artifacts in the family. Its normative dependencies are ratified: JWS, JWT, and SD-JWT are published standards, and the issuance profile's committed record is its only Mission input. The artifact itself is not yet exercised in deployment, so an implementer validates the verification steps and failure taxonomy against real cross-domain use before relying on them. 3. 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. All JSON shown in this document is non-normative and illustrative; the member definitions in the surrounding text are authoritative. This document uses the terms Mission, Mission record, Mission Intent, Authority Set, integrity anchor, mission claim, mission_id, Subject, Approver, and audit horizon as the issuance profile [I-D.draft-mcguinness-oauth-mission] defines them. It additionally uses: Mission Issuer: The component that approved and holds the Mission, identified by the Mission's origin: the OAuth Authorization Server under the issuance profile, or a Mission Authority Server ([I-D.draft-mcguinness-mission-authority-server]) under the standalone binding. Mission Mandate (Mandate): A signed, portable statement of a Mission's committed facts, minted by the Mission Issuer (Section 5). Mandate Issuer, Mandate Verifier: The conformance roles of Section 10: the Mission Issuer acting as the minter of Mandates (always the Mission origin), and a party that validates a Mandate (Section 7) and relies on it as evidence. 4. Mission Substrate This profile is defined against the Mission model rather than against OAuth 2.0 mechanics. It consumes these substrate primitives: the Mission record's committed members and their immutability; the integrity-anchor envelope with its encoded digest form; the lifecycle state space with its only-active-permits rule; and the Mission Issuer's published key material, resolvable by kid. The issuance profile [I-D.draft-mcguinness-oauth-mission] is this version's normative substrate, publishing keys through its Authorization Server metadata jwks_uri; the Mission Authority Server ([I-D.draft-mcguinness-mission-authority-server]) is a standalone binding of the same primitives with its own metadata jwks_uri. A Mandate minted under either binding is verified identically. 5. Mission Mandate A Mission Mandate is a JWT [RFC7519] signed as a JWS [RFC7515] by the Mission Issuer, stating the committed facts of exactly one Mission as of the Mandate's iat. The JWS Compact Serialization is the Mandate's wire and evidence form. 5.1. JOSE Header The protected header MUST carry: typ: REQUIRED. mission-mandate+jwt. Per [RFC7515] Section 4.1.9 the value omits the application/ prefix of the media type registered in Section 13. alg: REQUIRED. An asymmetric JWS algorithm. none MUST NOT be used. kid: REQUIRED. A key identifier that resolves in the Mission Issuer's published key material (Section 4). 5.2. Mandate Claims iss: REQUIRED. A string. The Mission origin. iat: REQUIRED. A NumericDate [RFC7519]. When the Mandate was minted. jti: REQUIRED. A string. A unique identifier for this Mandate. It MUST NOT be reused by the issuer. mission: REQUIRED. An object in the mission claim shape of the issuance profile, extended per its extensibility rules: id, origin, and authority_hash, plus intent_hash committing the approved Mission Intent. All four members are REQUIRED here. mission.origin MUST equal iss. subject: REQUIRED. An object with iss and sub, the Mission record's subject. approver: REQUIRED. An object with iss and sub, the Mission record's approver. client_id: REQUIRED. A string. The Mission record's client_id. mission_expiry: REQUIRED. A string. An RFC 3339 [RFC3339] date- time, the Mission record's mission_expiry. policy_version: REQUIRED. A string. The Mission record's policy_version. state_at_issuance: REQUIRED. A string. The Mission's lifecycle state at iat (Section 5.3). authority_set: OPTIONAL. An array. The full consented Authority Set, exactly as recorded on the Mission record, preserving array order (the order is part of the canonical form under the issuance profile's canonicalization rules). When present, a verifier MAY recompute authority_hash over it (Section 7). mandate_exp: OPTIONAL. A NumericDate. An expiry of the Mandate artifact itself, distinct from mission_expiry: after it, the Mandate MUST NOT be relied on as evidence. When absent, the Mandate is valid as evidence for the Mission's audit horizon, the retention term the issuance profile defines. It is deliberately not the standard exp claim, whose validity window would read as a credential lifetime. The claim set is open in the manner of the mission claim: a companion profile of the issuance profile MAY add members with coordinated short names, and any other extension member MUST use a collision- resistant name. A consumer MUST ignore members it does not understand and MUST NOT derive authority from any member. 5.3. State at Issuance state_at_issuance records history, not currency. A Mandate proves the Mission's committed facts as of iat; it MUST NOT be treated as proof of the Mission's current state. The Mission may have transitioned since minting, and nothing in the artifact would show it. Current state comes from a state surface, not from the Mandate: the Mission Status operation, keyed by the mission.id the Mandate carries ([I-D.draft-mcguinness-oauth-mission-status]); a lifecycle Signals stream ([I-D.draft-mcguinness-oauth-mission-signals]); or token introspection where the verifier holds a Mission-bound token ([I-D.draft-mcguinness-oauth-mission]). A verifier whose reliance requires the Mission to be active MUST obtain current state from a source its deployment trusts, within a freshness bound its policy sets; where the origin advertises a propagation bound, the freshness bound SHOULD be no looser ([I-D.draft-mcguinness-oauth-mission-status]). Reliance that needs no active Mission, such as auditing a completed one, needs no check. 5.4. Minting The Mission Issuer MAY mint a Mandate at any time within the Mission's audit horizon, including after the Mission reaches a terminal state. Each claim MUST be populated from the Mission record's committed members; state_at_issuance MUST equal the Mission's lifecycle state at iat. The issuer MUST NOT mint a Mandate whose facts diverge from the record. To whom Mandates are issued, and through what request surface, is deployment policy; this document defines the artifact, not a delivery protocol. An issuer SHOULD mint narrowly for the recipient's need, in particular omitting authority_set when the recipient does not recompute the anchor (Section 12). 5.5. Example A decoded Mandate for the issuance profile's worked-example Mission. The signature value is illustrative; all other segments are computed from the displayed JSON. Protected header: { "typ": "mission-mandate+jwt", "alg": "ES256", "kid": "as-key-2026-q3" } Payload: { "iss": "https://as.example.com", "iat": 1797841000, "jti": "mnd_4Xq7vB2kR9sT1mZ6pL3n", "mission": { "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-", "origin": "https://as.example.com", "authority_hash": "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ", "intent_hash": "sha-256:wQ7p4LHnX9Md0LqJ6sZJ8b8mZ3rN2xT5pV4lE6sQqYY" }, "subject": { "iss": "https://idp.example.com", "sub": "user_3p2q8mN1a0kV7tR" }, "approver": { "iss": "https://idp.example.com", "sub": "user_3p2q8mN1a0kV7tR" }, "client_id": "s6BhdRkqt3", "mission_expiry": "2026-12-31T23:59:59Z", "policy_version": "deploy-policy:v17", "state_at_issuance": "active", "mandate_exp": 1805617000, "authority_set": [ { "type": "mission_resource_access", "resource": "https://erp.example.com", "actions": ["invoices.read"], "delegation": { "max_depth": 2, "allowed_delegates": [{ "sub_profile": "ai_agent" }] } }, { "type": "mission_resource_access", "resource": "https://erp.example.com", "actions": ["journal-entries.write"], "constraints": { "max_amount_usd": "500.00" } } ] } The JWS segments are computed over the header and payload above, serialized with no whitespace and members in the order displayed. Line breaks within encoded segments are for display only. Protected header, base64url: eyJ0eXAiOiJtaXNzaW9uLW1hbmRhdGUrand0IiwiYWxnIjoiRVMyNTYiLCJraWQiOi Jhcy1rZXktMjAyNi1xMyJ9 Payload, base64url: eyJpc3MiOiJodHRwczovL2FzLmV4YW1wbGUuY29tIiwiaWF0IjoxNzk3ODQxMDAwLC JqdGkiOiJtbmRfNFhxN3ZCMmtSOXNUMW1aNnBMM24iLCJtaXNzaW9uIjp7ImlkIjoi bXNuXzhSZlgyTHF2OVRxTXY0ejdzQTJiTjFrMFlwRWRIYzktIiwib3JpZ2luIjoiaH R0cHM6Ly9hcy5leGFtcGxlLmNvbSIsImF1dGhvcml0eV9oYXNoIjoic2hhLTI1Njps M0t2WjRtUDV4MHdRclI2dFkybkQ5Yk03c1gxY0Y4Z0gydko0a0U1cE5RIiwiaW50ZW 50X2hhc2giOiJzaGEtMjU2OndRN3A0TEhuWDlNZDBMcUo2c1pKOGI4bVozck4yeFQ1 cFY0bEU2c1FxWVkifSwic3ViamVjdCI6eyJpc3MiOiJodHRwczovL2lkcC5leGFtcG xlLmNvbSIsInN1YiI6InVzZXJfM3AycThtTjFhMGtWN3RSIn0sImFwcHJvdmVyIjp7 ImlzcyI6Imh0dHBzOi8vaWRwLmV4YW1wbGUuY29tIiwic3ViIjoidXNlcl8zcDJxOG 1OMWEwa1Y3dFIifSwiY2xpZW50X2lkIjoiczZCaGRSa3F0MyIsIm1pc3Npb25fZXhw aXJ5IjoiMjAyNi0xMi0zMVQyMzo1OTo1OVoiLCJwb2xpY3lfdmVyc2lvbiI6ImRlcG xveS1wb2xpY3k6djE3Iiwic3RhdGVfYXRfaXNzdWFuY2UiOiJhY3RpdmUiLCJtYW5k YXRlX2V4cCI6MTgwNTYxNzAwMCwiYXV0aG9yaXR5X3NldCI6W3sidHlwZSI6Im1pc3 Npb25fcmVzb3VyY2VfYWNjZXNzIiwicmVzb3VyY2UiOiJodHRwczovL2VycC5leGFt cGxlLmNvbSIsImFjdGlvbnMiOlsiaW52b2ljZXMucmVhZCJdLCJkZWxlZ2F0aW9uIj p7Im1heF9kZXB0aCI6MiwiYWxsb3dlZF9kZWxlZ2F0ZXMiOlt7InN1Yl9wcm9maWxl IjoiYWlfYWdlbnQifV19fSx7InR5cGUiOiJtaXNzaW9uX3Jlc291cmNlX2FjY2Vzcy IsInJlc291cmNlIjoiaHR0cHM6Ly9lcnAuZXhhbXBsZS5jb20iLCJhY3Rpb25zIjpb ImpvdXJuYWwtZW50cmllcy53cml0ZSJdLCJjb25zdHJhaW50cyI6eyJtYXhfYW1vdW 50X3VzZCI6IjUwMC4wMCJ9fV19 JWS signing input, the two segments joined by .: eyJ0eXAiOiJtaXNzaW9uLW1hbmRhdGUrand0IiwiYWxnIjoiRVMyNTYiLCJraWQiOi Jhcy1rZXktMjAyNi1xMyJ9.eyJpc3MiOiJodHRwczovL2FzLmV4YW1wbGUuY29tIiw iaWF0IjoxNzk3ODQxMDAwLCJqdGkiOiJtbmRfNFhxN3ZCMmtSOXNUMW1aNnBMM24iL CJtaXNzaW9uIjp7ImlkIjoibXNuXzhSZlgyTHF2OVRxTXY0ejdzQTJiTjFrMFlwRWR IYzktIiwib3JpZ2luIjoiaHR0cHM6Ly9hcy5leGFtcGxlLmNvbSIsImF1dGhvcml0e V9oYXNoIjoic2hhLTI1NjpsM0t2WjRtUDV4MHdRclI2dFkybkQ5Yk03c1gxY0Y4Z0g ydko0a0U1cE5RIiwiaW50ZW50X2hhc2giOiJzaGEtMjU2OndRN3A0TEhuWDlNZDBMc Uo2c1pKOGI4bVozck4yeFQ1cFY0bEU2c1FxWVkifSwic3ViamVjdCI6eyJpc3MiOiJ odHRwczovL2lkcC5leGFtcGxlLmNvbSIsInN1YiI6InVzZXJfM3AycThtTjFhMGtWN 3RSIn0sImFwcHJvdmVyIjp7ImlzcyI6Imh0dHBzOi8vaWRwLmV4YW1wbGUuY29tIiw ic3ViIjoidXNlcl8zcDJxOG1OMWEwa1Y3dFIifSwiY2xpZW50X2lkIjoiczZCaGRSa 3F0MyIsIm1pc3Npb25fZXhwaXJ5IjoiMjAyNi0xMi0zMVQyMzo1OTo1OVoiLCJwb2x pY3lfdmVyc2lvbiI6ImRlcGxveS1wb2xpY3k6djE3Iiwic3RhdGVfYXRfaXNzdWFuY 2UiOiJhY3RpdmUiLCJtYW5kYXRlX2V4cCI6MTgwNTYxNzAwMCwiYXV0aG9yaXR5X3N ldCI6W3sidHlwZSI6Im1pc3Npb25fcmVzb3VyY2VfYWNjZXNzIiwicmVzb3VyY2UiO iJodHRwczovL2VycC5leGFtcGxlLmNvbSIsImFjdGlvbnMiOlsiaW52b2ljZXMucmV hZCJdLCJkZWxlZ2F0aW9uIjp7Im1heF9kZXB0aCI6MiwiYWxsb3dlZF9kZWxlZ2F0Z XMiOlt7InN1Yl9wcm9maWxlIjoiYWlfYWdlbnQifV19fSx7InR5cGUiOiJtaXNzaW9 uX3Jlc291cmNlX2FjY2VzcyIsInJlc291cmNlIjoiaHR0cHM6Ly9lcnAuZXhhbXBsZ S5jb20iLCJhY3Rpb25zIjpbImpvdXJuYWwtZW50cmllcy53cml0ZSJdLCJjb25zdHJ haW50cyI6eyJtYXhfYW1vdW50X3VzZCI6IjUwMC4wMCJ9fV19 The Mandate's JWS Compact Serialization appends . and the signature over the signing input; the signature value depends on the issuer's key and is not reproduced here. 6. Selective Disclosure This section is OPTIONAL. The plain JWS form of Section 5 is the mandatory-to-implement baseline. An issuer MAY additionally mint a Mandate as an SD-JWT [RFC9901], so a holder passing the Mandate onward discloses to a given verifier only what it needs; this addresses the payload-disclosure concern the issuance profile's privacy considerations record. The disclosable elements are exactly: the authority_set entries, each an array-element disclosure per [RFC9901], and any free-text Intent- derived extension member added under Section 5.2. All other claims, in particular iss, mission, subject, and state_at_issuance, MUST remain plaintext, so every presentation still identifies the Mission, its issuer, its Subject, and its state as of minting. A verifier MUST NOT recompute authority_hash from a partial presentation: the anchor is defined only over the full Authority Set ([I-D.draft-mcguinness-oauth-mission]), and an undisclosed array- element digest in authority_set means the set is partial. The SD-JWT form carries the protected header typ mission-mandate+sd- jwt and the SD-JWT serialization of [RFC9901], with no Key Binding JWT (Section 9). This document registers a media type only for the plain JWS form (Section 13); the SD-JWT form is identified by its typ. 7. Mandate Verification A Mandate Verifier MUST perform these steps before relying on a Mandate: 1. *Type.* Confirm the protected header typ is mission-mandate+jwt (or mission-mandate+sd-jwt for the SD-JWT form, then applying [RFC9901] processing). Reject any other value. 2. *Signature.* Resolve the REQUIRED kid in the Mission Issuer's published key material (Section 4) and verify the JWS signature. Confirm mission.origin equals iss. 3. *Issuer trust.* Decide by local policy or configured trust anchors whether the iss origin is trusted. A verifier MUST NOT trust an origin merely because it appears inside a signed artifact, mirroring the issuer-trust rule of the cross-domain projection profile ([I-D.draft-mcguinness-oauth-mission-cross-domain]). A Mandate from an untrusted origin proves nothing. 4. *Anchor recomputation.* When authority_set is present in full, the verifier MAY recompute authority_hash over it per the issuance profile's integrity-anchor rules (the mission-authority- set envelope with iss set to the origin) and MUST reject the Mandate on mismatch. It MAY likewise verify intent_hash against a Mission Intent it holds. 5. *Freshness.* When reliance requires an active Mission, obtain current state within the freshness bound of Section 5.3. state_at_issuance never substitutes. 6. *Hash agility.* Reject any integrity anchor whose algorithm prefix the verifier does not recognize, and never treat an unrecognized prefix as sha-256, per the issuance profile. A verifier MUST additionally reject a Mandate whose required claims are absent or malformed, and MUST NOT rely on a Mandate whose mandate_exp has passed. 7.1. Failure Taxonomy Verification failures fall into three classes, and a verifier MUST distinguish them: Invalid: The artifact fails as an artifact: signature, typ, required-claim structure, iss/origin mismatch, anchor mismatch under step 4, or an unrecognized hash prefix under step 6. The Mandate MUST be rejected and MUST NOT be relied on for anything. Unverifiable: Verification cannot complete: the issuer's key material is unreachable, the kid does not resolve, or no trust anchor covers the origin. This is not evidence of tampering, mirroring the audit profile's classification ([I-D.draft-mcguinness-mission-audit]); the verifier MUST NOT treat the Mandate as verified and MUST NOT treat the failure as proof the artifact is false. Stale: The artifact verifies, but reliance requires an active Mission and no current state was obtained within the freshness bound (step 5). The verifier MUST NOT proceed with that reliance until it obtains current state. 8. Mandate Use 8.1. Cross-Domain Verification Mission Cross-Domain Projection for OAuth 2.0 [I-D.draft-mcguinness-oauth-mission-cross-domain] projects authority: the cross-domain grant carries the mission claim and the audience- scoped Authority Set entries to one Resource AS, which mints local tokens from it. That projection remains the only path to local tokens; a Mandate replaces nothing in it, is not redeemable, is not audienced, and authorizes nothing. What a Mandate adds is knowledge. A verifier that needed to know what a Mission approved previously had only the token-exchange projection, available only in the grant flow and only audience- scoped. With a Mandate plus a current-state check (Section 5.3), any authorized recipient verifies the committed facts without standing in the token path at all. 8.2. Vertical Derivation This subsection is informative. An external rail with its own mandate artifact, for example a payments network's payment mandate, can mint its vertical artifact from a Mission Mandate, recording the Mandate's mission.id and authority_hash in its own artifact. The two then share an audit anchor: activity on the rail joins back to the approved Mission that motivated it. The derivation itself, what the rail's artifact authorizes and how it is consented and revoked, is governed by that rail, not by this document; the Mission Mandate contributes committed facts and audit continuity, never authority. 8.3. Mission Evidence A Mandate is registrable Mission evidence. For deployments running the audit transparency profile ([I-D.draft-mcguinness-mission-audit]), the Mandate slots into its evidence-type pattern with these values: * *Canonical bytes*: the JWS Compact Serialization as issued, hashed as-is (an already-signed object is not re-canonicalized). * *preimage-content-type*: application/mission-mandate+jwt (Section 13). * *Authoritative producer*: the Mission origin; the registering iss MUST equal it, which holds by construction since a Mandate's iss is the origin (Section 10). Registration gives a Mandate an independent existence proof, which bounds a later issuer key compromise (Section 11). 9. Non-Goals and Deferred Work * A Mandate is not a credential and is never authority-bearing; anything authority-bearing belongs to the substrate's issuance surfaces. * No key binding. A Mandate binds no holder key, and its presentation proves nothing about the presenter. A holder-bound Mandate, a cnf-style confirmation with key-bound presentation, is named future work. * No revocation of the Mandate artifact. State currency is the status surface's job (Section 5.3); mandate_exp bounds the artifact's evidence lifetime, and no revocation list is defined. * No multi-Mission bundling. A Mandate states exactly one Mission. 10. Conformance A *Mandate Issuer* MUST: * be the Mission origin and set iss to it; * mint only over an existing Mission record, populating every claim from its committed members (Section 5.4); * set state_at_issuance to the Mission's lifecycle state at iat; * when including authority_set, include the consented Authority Set exactly as recorded, in recorded order; * sign with a key resolvable by kid in its published key material, with the protected typ of Section 5.1; and * issue jti values it never reuses. A *Mandate Verifier* MUST: * perform steps 1 through 6 of Section 7 before reliance; * classify failures per Section 7.1 and treat only the invalid class as evidence against the artifact; * obtain current state within its freshness bound whenever reliance requires an active Mission; and * never grant access, mint credentials, or widen authority on presentation of a Mandate (Section 11). 11. Security Considerations 11.1. Mandate-as-Credential Misuse The central risk is the mandate-as-credential anti-pattern: granting access because a presenter holds a well-signed Mandate. A Mandate binds no presenter, proves no possession, and commits no current state; accepting it as a credential turns a freely copyable audit artifact into a bearer token. A verifier MUST NOT grant access, mint a credential, or widen any authority on presentation of a Mandate. Authority flows only through the substrate's issuance surfaces ([I-D.draft-mcguinness-oauth-mission]). 11.2. Stale-State Reliance A verified Mandate over a revoked Mission is still a verified Mandate: treating state_at_issuance as current state extends reliance past revocation with no artifact-level signal. The freshness rule of Section 5.3 is the control; the stale class of Section 7.1 makes the omission a named failure rather than a silent acceptance. 11.3. Issuer Key Compromise A party holding the Mission Issuer's signing key can mint Mandates for Missions that never existed, until the key is rotated out of the published set. Verifiers bound this by resolving kid against live key material; audit registration (Section 8.3) narrows it further, since a genuine Mandate has an independent, timestamped existence proof and a forged one either goes unregistered or leaves a permanent, attributable trace. A deployment whose Mandates feed high-consequence decisions SHOULD register them. 11.4. Confusion with the Cross-Domain Grant Both artifacts are issuer-signed JWTs carrying Mission facts. The cross-domain grant ([I-D.draft-mcguinness-oauth-mission-cross-domain]) is redeemable, audienced, sender-constrained, and single-use; the Mandate is none of these. The distinct protected typ is the mechanical separator: a token endpoint MUST NOT accept a mission-mandate+jwt as any grant or assertion, and a Mandate Verifier rejects a grant presented as a Mandate at step 1 of Section 7. 12. Privacy Considerations 12.1. Task-Data Propagation A Mandate carries what the Mission record committed: principals, task anchors, expiry, and optionally the full Authority Set with its business bounds. It travels to parties that would otherwise never hold Mission data, and unlike a token it has no audience to scope it. An issuer SHOULD apply the restraint the issuance profile applies at a domain boundary: omit authority_set unless the recipient needs anchor recomputation, prefer the selective-disclosure form (Section 6) where a holder re-presents the Mandate onward, and avoid Intent-derived free-text extension members by default. The Mandate also extends the correlation surface the issuance profile's privacy considerations describe: it carries mission.id and authority_hash to parties outside the token path, and any two holders can correlate on them. That is the artifact's purpose, an auditable shared anchor; a deployment SHOULD weigh it before minting Mandates for recipients that do not need durable correlation. 13. IANA Considerations 13.1. Media Type Registration IANA is requested to register one media type per [RFC6838]. 13.1.1. application/mission-mandate+jwt * Type name: application * Subtype name: mission-mandate+jwt * Required parameters: none * Optional parameters: none * Encoding considerations: binary; JWS Compact Serialization * Security considerations: see Section 11 * Interoperability considerations: see this document * Published specification: this document * Applications that use this media type: Mission-Bound Authorization issuers, verifiers, and audit deployments * Fragment identifier considerations: not applicable * Additional information: - Deprecated alias names for this type: none - Magic number(s): none - File extension(s): none - Macintosh file type code(s): none * Person & email address to contact for further information: Karl McGuinness public@karlmcguinness.com (mailto:public@karlmcguinness.com) * Intended usage: COMMON * Restrictions on usage: none * Author: IETF * Change controller: IETF 14. References 14.1. Normative References [I-D.draft-mcguinness-oauth-mission] McGuinness, K., "Mission-Bound Authorization for OAuth 2.0", Work in Progress, Internet-Draft, draft-mcguinness- oauth-mission, 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9901] Fett, D., Yasuda, K., and B. Campbell, "Selective Disclosure for JSON Web Tokens", RFC 9901, DOI 10.17487/RFC9901, November 2025, . 14.2. Informative References [I-D.draft-mcguinness-mission-audit] McGuinness, K., "Mission Audit Transparency", Work in Progress, Internet-Draft, draft-mcguinness-mission-audit, 2026, . [I-D.draft-mcguinness-mission-authority-server] McGuinness, K., "Mission Authority Server", Work in Progress, Internet-Draft, draft-mcguinness-mission- authority-server, 2026, . [I-D.draft-mcguinness-oauth-mission-cross-domain] McGuinness, K., "Mission Cross-Domain Projection for OAuth 2.0", Work in Progress, Internet-Draft, draft-mcguinness- oauth-mission-cross-domain, 2026, . [I-D.draft-mcguinness-oauth-mission-signals] McGuinness, K., "Mission Lifecycle Signals for OAuth 2.0", Work in Progress, Internet-Draft, draft-mcguinness-oauth- mission-signals, 2026, . [I-D.draft-mcguinness-oauth-mission-status] McGuinness, K., "Mission Status and Lifecycle for OAuth 2.0", Work in Progress, Internet-Draft, draft-mcguinness- oauth-mission-status, 2026, . Acknowledgments This document is part of the Mission-Bound Authorization work and makes a Mission's committed facts portable, verifiable evidence. Author's Address Karl McGuinness Independent Email: public@karlmcguinness.com