Internet-Draft Mission Mandate July 2026
McGuinness Expires 4 January 2027 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-mcguinness-mission-mandate-latest
Published:
Intended Status:
Standards Track
Expires:
Author:
K. McGuinness
Independent

Mission Mandate

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 4 January 2027.

▲

Table of Contents

1. Introduction

The issuance profile [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 4.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 7.1).

2. Conventions and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

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 4).

Mandate Issuer, Mandate Verifier:

The conformance roles of Section 9: the Mission Issuer acting as the minter of Mandates (always the Mission origin), and a party that validates a Mandate (Section 6) and relies on it as evidence.

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

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

4.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 4.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 6).

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.

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

4.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 11).

4.5. Example

A decoded Mandate for the issuance profile's worked-example Mission. All values are illustrative; the hash values are not 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 } }
  ]
}

5. Selective Disclosure

This section is OPTIONAL. The plain JWS form of Section 4 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 4.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 8). This document registers a media type only for the plain JWS form (Section 12); the SD-JWT form is identified by its typ.

6. 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 3) 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 issuance profile's cross-domain issuer-trust rule. 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 4.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.

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

7. Mandate Use

7.1. Cross-Domain Verification

The issuance profile's cross-domain binding 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 4.3), any authorized recipient verifies the committed facts without standing in the token path at all.

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

7.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 12).

  • Authoritative producer: the Mission origin; the registering iss MUST equal it, which holds by construction since a Mandate's iss is the origin (Section 9).

Registration gives a Mandate an independent existence proof, which bounds a later issuer key compromise (Section 10).

8. Non-Goals and Deferred Work

9. Conformance

A Mandate Issuer MUST:

A Mandate Verifier MUST:

10. Security Considerations

10.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]).

10.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 4.3 is the control; the stale class of Section 6.1 makes the omission a named failure rather than a silent acceptance.

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

10.4. Confusion with the Cross-Domain Grant

Both artifacts are issuer-signed JWTs carrying Mission facts. The cross-domain grant 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 6.

11. Privacy Considerations

11.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 5) 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.

12. IANA Considerations

12.1. Media Type Registration

IANA is requested to register one media type per [RFC6838].

12.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 10

  • 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

  • Intended usage: COMMON

  • Restrictions on usage: none

  • Author: IETF

  • Change controller: IETF

13. References

13.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, , <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-mission>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3339]
Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, , <https://www.rfc-editor.org/rfc/rfc3339>.
[RFC6838]
Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, , <https://www.rfc-editor.org/rfc/rfc6838>.
[RFC7515]
Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, , <https://www.rfc-editor.org/rfc/rfc7515>.
[RFC7519]
Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, , <https://www.rfc-editor.org/rfc/rfc7519>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9901]
Fett, D., Yasuda, K., and B. Campbell, "Selective Disclosure for JSON Web Tokens", RFC 9901, DOI 10.17487/RFC9901, , <https://www.rfc-editor.org/rfc/rfc9901>.

13.2. Informative References

[I-D.draft-mcguinness-mission-audit]
McGuinness, K., "Mission Audit Transparency", Work in Progress, Internet-Draft, draft-mcguinness-mission-audit, , <https://datatracker.ietf.org/doc/html/draft-mcguinness-mission-audit>.
[I-D.draft-mcguinness-mission-authority-server]
McGuinness, K., "Mission Authority Server", Work in Progress, Internet-Draft, draft-mcguinness-mission-authority-server, , <https://datatracker.ietf.org/doc/html/draft-mcguinness-mission-authority-server>.
[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, , <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-mission-signals>.
[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, , <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-mission-status>.

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