Mission Mandate

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

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, issuer, and authority_hash, plus intent_hash committing the approved Mission Intent, and expires_at, an RFC 3339 [RFC3339] date-time mirroring the Mission record's expires_at (the mission claim member the issuance-grant profile defines, [I-D.draft-mcguinness-oauth-mission-issuance-grant]). All five members are REQUIRED here. mission.issuer 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.¶

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 that relies on its contents recomputes authority_hash over it (Section 7).¶

mandate_exp:

OPTIONAL. A NumericDate. An expiry of the Mandate artifact itself, distinct from the Mission's expires_at: 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. Setting mandate_exp explicitly is RECOMMENDED: the audit horizon is the issuer's retention term, which a third-party verifier cannot discover, so an absent mandate_exp leaves the evidence bound unverifiable from the artifact alone. It is deliberately not the standard exp claim, whose validity window would read as a credential lifetime.¶

minted_for:

OPTIONAL. A string. An identifier for the party this Mandate was minted for. It is attribution, not audience: it binds nothing, a verifier MUST NOT treat it as access control or reject a Mandate over its value, and its use is that a Mandate found where it should not be names its leak path (Section 12).¶

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. A verifier reads the value under the issuance profile's fail-safe rule: any value other than the exact string active, including one it does not recognize, means the Mission was not active at minting. 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 issuer 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. Whatever its shape, the minting surface MUST authenticate its requesters and MUST authorize each request under the deployment's visibility policy: a Mandate reveals a Mission's existence, principals, expiry, and optionally its full consented authority, and an unauthorized requester learns none of that, receiving the same response as for a Mission that does not exist, per the anti-oracle discipline of the family's status surfaces ([I-D.draft-mcguinness-oauth-mission-status]). 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), and SHOULD record minted_for.¶

A Mandate outlives signing-key rotation schedules. The issuer MUST keep the key that verifies each minted Mandate resolvable by its kid in the published key material for that Mandate's evidence lifetime: until mandate_exp, or for the Mission's audit horizon when mandate_exp is absent. Rotation retires a key from signing, never from resolvability within that bound.¶

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": 1793607400,
  "jti": "mnd_4Xq7vB2kR9sT1mZ6pL3n",
  "mission": {
    "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
    "issuer": "https://as.example.com",
    "authority_hash":
      "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ",
    "intent_hash":
      "sha-256:wQ7p4LHnX9Md0LqJ6sZJ8b8mZ3rN2xT5pV4lE6sQqYY",
    "expires_at": "2026-12-31T23:59:59Z"
  },
  "subject": { "iss": "https://idp.example.com",
    "sub": "user_3p2q8mN1a0kV7tR" },
  "approver": { "iss": "https://idp.example.com",
    "sub": "user_3p2q8mN1a0kV7tR" },
  "client_id": "s6BhdRkqt3",
  "policy_version": "deploy-policy:v17",
  "state_at_issuance": "active",
  "mandate_exp": 1805617000,
  "minted_for": "https://rail.example.com",
  "authority_set": [
    { "type": "mission_resource_access",
      "resource": "https://erp.example.com",
      "actions": ["invoices.read"],
      "constraints": {
        "resource_issued_after": "2026-07-01T00:00:00Z",
        "resource_issued_before": "2026-09-30T23:59:59Z"
      },
      "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": { "amount": "500.00", "currency": "USD" } } }
  ]
}

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:¶

eyJpc3MiOiJodHRwczovL2FzLmV4YW1wbGUuY29tIiwiaWF0IjoxNzkzNjA3NDAwLC
JqdGkiOiJtbmRfNFhxN3ZCMmtSOXNUMW1aNnBMM24iLCJtaXNzaW9uIjp7ImlkIjoi
bXNuXzhSZlgyTHF2OVRxTXY0ejdzQTJiTjFrMFlwRWRIYzktIiwiaXNzdWVyIjoiaH
R0cHM6Ly9hcy5leGFtcGxlLmNvbSIsImF1dGhvcml0eV9oYXNoIjoic2hhLTI1Njps
M0t2WjRtUDV4MHdRclI2dFkybkQ5Yk03c1gxY0Y4Z0gydko0a0U1cE5RIiwiaW50ZW
50X2hhc2giOiJzaGEtMjU2OndRN3A0TEhuWDlNZDBMcUo2c1pKOGI4bVozck4yeFQ1
cFY0bEU2c1FxWVkiLCJleHBpcmVzX2F0IjoiMjAyNi0xMi0zMVQyMzo1OTo1OVoifS
wic3ViamVjdCI6eyJpc3MiOiJodHRwczovL2lkcC5leGFtcGxlLmNvbSIsInN1YiI6
InVzZXJfM3AycThtTjFhMGtWN3RSIn0sImFwcHJvdmVyIjp7ImlzcyI6Imh0dHBzOi
8vaWRwLmV4YW1wbGUuY29tIiwic3ViIjoidXNlcl8zcDJxOG1OMWEwa1Y3dFIifSwi
Y2xpZW50X2lkIjoiczZCaGRSa3F0MyIsInBvbGljeV92ZXJzaW9uIjoiZGVwbG95LX
BvbGljeTp2MTciLCJzdGF0ZV9hdF9pc3N1YW5jZSI6ImFjdGl2ZSIsIm1hbmRhdGVf
ZXhwIjoxODA1NjE3MDAwLCJtaW50ZWRfZm9yIjoiaHR0cHM6Ly9yYWlsLmV4YW1wbG
UuY29tIiwiYXV0aG9yaXR5X3NldCI6W3sidHlwZSI6Im1pc3Npb25fcmVzb3VyY2Vf
YWNjZXNzIiwicmVzb3VyY2UiOiJodHRwczovL2VycC5leGFtcGxlLmNvbSIsImFjdG
lvbnMiOlsiaW52b2ljZXMucmVhZCJdLCJjb25zdHJhaW50cyI6eyJyZXNvdXJjZV9p
c3N1ZWRfYWZ0ZXIiOiIyMDI2LTA3LTAxVDAwOjAwOjAwWiIsInJlc291cmNlX2lzc3
VlZF9iZWZvcmUiOiIyMDI2LTA5LTMwVDIzOjU5OjU5WiJ9LCJkZWxlZ2F0aW9uIjp7
Im1heF9kZXB0aCI6MiwiYWxsb3dlZF9kZWxlZ2F0ZXMiOlt7InN1Yl9wcm9maWxlIj
oiYWlfYWdlbnQifV19fSx7InR5cGUiOiJtaXNzaW9uX3Jlc291cmNlX2FjY2VzcyIs
InJlc291cmNlIjoiaHR0cHM6Ly9lcnAuZXhhbXBsZS5jb20iLCJhY3Rpb25zIjpbIm
pvdXJuYWwtZW50cmllcy53cml0ZSJdLCJjb25zdHJhaW50cyI6eyJtYXhfYW1vdW50
Ijp7ImFtb3VudCI6IjUwMC4wMCIsImN1cnJlbmN5IjoiVVNEIn19fV19

JWS signing input, the two segments joined by .:¶

eyJ0eXAiOiJtaXNzaW9uLW1hbmRhdGUrand0IiwiYWxnIjoiRVMyNTYiLCJraWQiOi
Jhcy1rZXktMjAyNi1xMyJ9.eyJpc3MiOiJodHRwczovL2FzLmV4YW1wbGUuY29tIiw
iaWF0IjoxNzkzNjA3NDAwLCJqdGkiOiJtbmRfNFhxN3ZCMmtSOXNUMW1aNnBMM24iL
CJtaXNzaW9uIjp7ImlkIjoibXNuXzhSZlgyTHF2OVRxTXY0ejdzQTJiTjFrMFlwRWR
IYzktIiwiaXNzdWVyIjoiaHR0cHM6Ly9hcy5leGFtcGxlLmNvbSIsImF1dGhvcml0e
V9oYXNoIjoic2hhLTI1NjpsM0t2WjRtUDV4MHdRclI2dFkybkQ5Yk03c1gxY0Y4Z0g
ydko0a0U1cE5RIiwiaW50ZW50X2hhc2giOiJzaGEtMjU2OndRN3A0TEhuWDlNZDBMc
Uo2c1pKOGI4bVozck4yeFQ1cFY0bEU2c1FxWVkiLCJleHBpcmVzX2F0IjoiMjAyNi0
xMi0zMVQyMzo1OTo1OVoifSwic3ViamVjdCI6eyJpc3MiOiJodHRwczovL2lkcC5le
GFtcGxlLmNvbSIsInN1YiI6InVzZXJfM3AycThtTjFhMGtWN3RSIn0sImFwcHJvdmV
yIjp7ImlzcyI6Imh0dHBzOi8vaWRwLmV4YW1wbGUuY29tIiwic3ViIjoidXNlcl8zc
DJxOG1OMWEwa1Y3dFIifSwiY2xpZW50X2lkIjoiczZCaGRSa3F0MyIsInBvbGljeV9
2ZXJzaW9uIjoiZGVwbG95LXBvbGljeTp2MTciLCJzdGF0ZV9hdF9pc3N1YW5jZSI6I
mFjdGl2ZSIsIm1hbmRhdGVfZXhwIjoxODA1NjE3MDAwLCJtaW50ZWRfZm9yIjoiaHR
0cHM6Ly9yYWlsLmV4YW1wbGUuY29tIiwiYXV0aG9yaXR5X3NldCI6W3sidHlwZSI6I
m1pc3Npb25fcmVzb3VyY2VfYWNjZXNzIiwicmVzb3VyY2UiOiJodHRwczovL2VycC5
leGFtcGxlLmNvbSIsImFjdGlvbnMiOlsiaW52b2ljZXMucmVhZCJdLCJjb25zdHJha
W50cyI6eyJyZXNvdXJjZV9pc3N1ZWRfYWZ0ZXIiOiIyMDI2LTA3LTAxVDAwOjAwOjA
wWiIsInJlc291cmNlX2lzc3VlZF9iZWZvcmUiOiIyMDI2LTA5LTMwVDIzOjU5OjU5W
iJ9LCJkZWxlZ2F0aW9uIjp7Im1heF9kZXB0aCI6MiwiYWxsb3dlZF9kZWxlZ2F0ZXM
iOlt7InN1Yl9wcm9maWxlIjoiYWlfYWdlbnQifV19fSx7InR5cGUiOiJtaXNzaW9uX
3Jlc291cmNlX2FjY2VzcyIsInJlc291cmNlIjoiaHR0cHM6Ly9lcnAuZXhhbXBsZS5
jb20iLCJhY3Rpb25zIjpbImpvdXJuYWwtZW50cmllcy53cml0ZSJdLCJjb25zdHJha
W50cyI6eyJtYXhfYW1vdW50Ijp7ImFtb3VudCI6IjUwMC4wMCIsImN1cnJlbmN5Ijo
iVVNEIn19fV19

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

7.1. Failure Taxonomy

Verification failures fall into four classes, and a verifier MUST distinguish them:¶

Invalid:

The artifact fails as an artifact: signature, typ, the claim structure of step 2, iss/issuer mismatch, anchor mismatch under step 6, or an unrecognized hash prefix under step 8. 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 Mission's issuer. 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. Within a Mandate's evidence lifetime a conforming issuer keeps its verification key resolvable (Section 5.4), so a kid that no longer resolves inside that bound is itself worth recording, though still not proof of forgery.¶

Stale:

The artifact verifies, but reliance requires an active Mission and no current state was obtained within the freshness bound (step 7). The verifier MUST NOT proceed with that reliance until it obtains current state.¶

Expired:

The artifact verifies, but its evidence lifetime has passed: mandate_exp is behind the verification time (step 5). Unlike stale, expiry is not cured by a state check: the Mandate MUST NOT be relied on as evidence, though expiry is not evidence against the facts it states.¶

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

A rail deriving a durable artifact from a Mandate SHOULD record the time of its current-state check (Section 5.3) in its own artifact, and SHOULD consume Mission Status ([I-D.draft-mcguinness-oauth-mission-status]) or Lifecycle Signals ([I-D.draft-mcguinness-oauth-mission-signals]) for the Mission's lifetime, so a later revocation of the Mission does not go silently unnoticed on the rail. Where the deployment runs the audit transparency profile, the rail SHOULD register its derivation event, its own artifact's digest with the Mission reference, on the Mission's feed under that profile's extension pattern ([I-D.draft-mcguinness-mission-audit]), so the Mission's evidence shows what external artifacts it spawned, as it shows what children it delegated.¶

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

• payload-preimage-content-type: application/mission-mandate+jwt (Section 13).¶

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

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

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.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. Recording minted_for costs nothing and makes an artifact that travels beyond its recipient attributable to a leak path.¶

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.2. Subject Disclosure

Selective disclosure never hides subject (Section 6): every presentation identifies the Mission's Subject. Deployments SHOULD use opaque or pairwise Subject identifiers where the identity provider supports them, and SHOULD weigh Subject disclosure per recipient as this section weighs authority_set.¶

13.1. Media Type Registration

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

14.1. Normative References

[I-D.draft-mcguinness-oauth-mission]

McGuinness, K., "Mission-Bound Authorization for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission.html>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <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, July 2002, <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, January 2013, <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, May 2015, <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, May 2015, <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, May 2017, <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, November 2025, <https://www.rfc-editor.org/rfc/rfc9901>.

14.2. Informative References

[I-D.draft-mcguinness-mission-aauth]

McGuinness, K., "Mission-Bound Authorization for AAuth", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-aauth.html>.

[I-D.draft-mcguinness-mission-audit]

McGuinness, K., "Mission Audit Transparency", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-audit.html>.

[I-D.draft-mcguinness-mission-authority-server]

McGuinness, K., "Mission Authority Server", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-authority-server.html>.

[I-D.draft-mcguinness-mission-runtime]

McGuinness, K., "Mission-Bound Runtime Enforcement", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-runtime.html>.

[I-D.draft-mcguinness-oauth-mission-cross-domain]

McGuinness, K., "Mission Cross-Domain Projection for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-cross-domain.html>.

[I-D.draft-mcguinness-oauth-mission-issuance-grant]

McGuinness, K., "Mission Issuance Grant for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-issuance-grant.html>.

[I-D.draft-mcguinness-oauth-mission-signals]

McGuinness, K., "Mission Lifecycle Signals for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-signals.html>.

[I-D.draft-mcguinness-oauth-mission-status]

McGuinness, K., "Mission Status and Lifecycle for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-status.html>.