Mission Issuance Grant for OAuth 2.0

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 11 February 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

Mission-Bound Authorization for OAuth 2.0 [I-D.draft-mcguinness-oauth-mission] (the "issuance profile", here "the core") binds issued authority to a durable, human-approved Mission, with the Authorization Server (AS) as the Mission Issuer. The Mission Authority Server (MAS, [I-D.draft-mcguinness-mission-authority-server]) hosts the same object without touching the AS: it validates Mission Intents, runs approval, records Missions, and operates the lifecycle, while tokens remain ordinary and a Policy Decision Point joins them to Missions at the point of use. Between those two integrations there was none: an estate either changed its AS completely or not at all.¶

This document defines the middle integration, the issuance join. The MAS remains the Mission Issuer; the estate's AS consumes the approved Mission at its token endpoint. The carrier is the Mission Issuance Grant, a short-lived assertion the MAS mints for an active Mission and the AS redeems under the JWT authorization grant [RFC7523] to issue tokens that carry the mission claim and are bounded by the Mission's derived authority. Because every grant is minted against current Mission state and refresh is gated on that state, the possession-independent kill switch returns to the issuance gate, the property the MAS-only mode structurally lacks.¶

The Authorization Server's obligations are deliberately small: validate the grant, mint within its bounds, gate refresh on Mission state. It implements none of the core's intake, approval ceremony, derivation, record, or lifecycle surfaces; those stay at the MAS. The integration ladder is then: record-only governance, the runtime join, the issuance join, and native Mission-awareness, each adopted where its cost is warranted ([I-D.draft-mcguinness-mission-authority-server]).¶

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

This document uses Mission, Mission Intent, Authority Set, Mission Issuer, the mission claim, the subset rule, and the integrity anchors (intent_hash, authority_hash) as the core defines them, and Mission Authority Server (MAS), Mission Join, and the Enterprise Mapping Contract as [I-D.draft-mcguinness-mission-authority-server] defines them. It additionally uses:¶

Issuance join:

The integration this document defines: a MAS-approved Mission consumed at an Authorization Server's token endpoint.¶

Mission Issuance Grant (grant):

The signed assertion of Section 4, minted by the Mission Issuer and redeemed for Mission-bound tokens.¶

Grant Minter:

The standalone Mission Issuer minting grants; conformance role of Section 9.¶

Consuming Authorization Server (consuming AS):

An OAuth Authorization Server [RFC6749] that redeems Mission Issuance Grants at its token endpoint; conformance role of Section 9.¶

3. The Issuance Join

Trust is pre-established and bilateral. A consuming AS accepts grants only from Mission Issuers its local policy names, resolving their signing keys through the MAS's published key material (its discovery jwks_uri, [I-D.draft-mcguinness-mission-authority-server]); a MAS mints grants only for Authorization Servers named as audiences by deployment configuration. Subject and client correspondence between the Mission record and the consuming AS's accounts is governed by the deployment's mapping policy; where the Enterprise Mission Authority Profile is claimed, its mapping contract governs ([I-D.draft-mcguinness-mission-authority-server]).¶

The division of duties is fixed. The MAS holds the approval event, the record and its anchors, the lifecycle, and grant minting. The consuming AS holds client authentication, token minting bounded by the grant, refresh, and its ordinary token-plane obligations. An auditor attributes what was approved to the MAS record and what was issued to the consuming AS's log, joined by the Mission reference the grant carries.¶

Tokens issued under this profile are Mission-bound in the core's sense: they carry the mission claim, their authority is a subset of the consented Authority Set, and issuance and refresh are gated on Mission state. Runtime enforcement ([I-D.draft-mcguinness-mission-runtime]) composes credential-carried for these tokens; the MAS-only mode's join caveat (the credential's membership is mapped, not issued) does not apply to them. Tokens the estate issues outside this profile are unchanged and continue to compose through the Mission Join.¶

4. The Mission Issuance Grant

A Mission Issuance Grant is a JWT [RFC7519] signed as a JWS [RFC7515] by the Mission Issuer. Its JOSE header MUST carry typ mission-issuance-grant+jwt (Section 12), alg, and a kid that resolves in the Mission Issuer's published key material. A consumer MUST reject as a Mission Issuance Grant any JWT whose typ differs; in particular a Mission Mandate ([I-D.draft-mcguinness-mission-mandate]) is evidence, authorizes nothing, and MUST NOT redeem.¶

Claims:¶

iss:

REQUIRED. The Mission's issuer: the MAS issuer URL.¶

sub:

REQUIRED. The Mission's recorded Subject identifier (subject.sub), interpreted at the consuming AS under the deployment's mapping policy (Section 3).¶

aud:

REQUIRED. The consuming AS's issuer identifier. A consuming AS MUST reject a grant whose aud does not name it.¶

iat, exp:

REQUIRED. The grant MUST NOT be valid longer than 300 seconds.¶

jti:

REQUIRED. Unique per grant; single use (Section 6).¶

client_id:

REQUIRED. The Mission's recorded agent client identifier at the consuming AS. Only this authenticated client redeems the grant.¶

mission:

REQUIRED. The core's mission claim object (id, issuer, authority_hash), exactly as recorded, extended with the expires_at member of Section 4.1.¶

authorization_details:

REQUIRED. The mission_resource_access entries [RFC9396] the consuming AS may mint against: a subset of the Mission's consented Authority Set, scoped to the resources this AS serves.¶

cnf:

OPTIONAL. A proof-of-possession key binding [RFC7800] for redemption; when present, the consuming AS MUST require proof of possession of the bound key at redemption, demonstrated with DPoP [RFC9449] or mutual TLS [RFC8705] as the deployment configures.¶

An illustrative decoded grant (this Mission and its anchors are not the core walkthrough's):¶

{
  "iss": "https://mas.example.com",
  "sub": "user_3p2q8mN1a0kV7tR",
  "aud": "https://as.example.com",
  "iat": 1793606400,
  "exp": 1793606580,
  "jti": "mig_7Kq2Rv9Lp4xW1nT8",
  "client_id": "s6BhdRkqt3",
  "mission": {
    "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
    "issuer": "https://mas.example.com",
    "authority_hash":
      "sha-256:R6tY2nD9bM7sX1cF8gH2vJ4kE5pNQl3KvZ4mP5x0wQr",
    "expires_at": "2026-12-31T23:59:59Z"
  },
  "authorization_details": [
    {
      "type": "mission_resource_access",
      "resource": "https://api.example.com/invoices",
      "actions": ["read"],
      "constraints": { "resource_issued_after": "2026-07-01" }
    }
  ]
}

5. Obtaining a Grant

A MAS implementing this profile serves a Mission Issuance Grant endpoint, published as mission_issuance_grant_endpoint in its discovery metadata (Section 12). The Grant Minter MUST observe:¶

1. Requester. The endpoint requires authentication. The requester MUST be the Mission's recorded client; any other caller receives the MAS's not_found anti-oracle response, under the same visibility rules as the Mission Join Assertion ([I-D.draft-mcguinness-mission-authority-server]).¶

2. State gate. A grant is minted only while the Mission is active, established from the MAS's own record at minting. Any other state refuses.¶

3. Subset and audience. The grant's authorization_details MUST be a subset of the Mission's consented Authority Set under the core's subset rule. The grant SHOULD carry only the entries the named consuming AS serves. The requester MAY request a narrower subset. The requester MUST NOT obtain a wider one.¶

4. Derivation event. Each grant minted is a derivation event. Where the Mission carries a consented controls.max_derivations, the MAS MUST count grants against it atomically and refuse beyond it, which gives that control a binding locus under the standalone binding.¶

5. Evidence. Each minting is recorded with the Mission record: the jti, audience, requested and granted entries, and time.¶

POST /mas/mission/issuance-grant HTTP/1.1
Host: mas.example.com
Content-Type: application/json
Authorization: DPoP eyJhbGciOiJFUzI1NiIsImtpZCI6...
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2Iiwi...

{
  "mission_id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
  "audience": "https://as.example.com",
  "authorization_details": [
    {
      "type": "mission_resource_access",
      "resource": "https://api.example.com/invoices",
      "actions": ["read"]
    }
  ]
}

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{
  "grant": "eyJ0eXAiOiJtaXNzaW9uLWlzc3VhbmNlLWdyYW50K2p3dCIs..."
}

6. Redemption

The client presents the grant to the consuming AS's token endpoint as a JWT authorization grant [RFC7523]:¶

POST /token HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
&assertion=eyJ0eXAiOiJtaXNzaW9uLWlzc3VhbmNlLWdyYW50K2p3dCIs...

The grant is an authorization, not a client credential: redemption still requires the requester to prove it is the grant's client_id, either by authenticating to this AS as it ordinarily does or, where the grant carries cnf, by proving possession of the bound key. A public client that can do neither cannot redeem, since nothing then binds the redemption to the grant's client_id. The consuming AS MUST validate, in an order that fails closed:¶

1. the JOSE typ is mission-issuance-grant+jwt; any other type is not this profile (Section 7);¶

2. the signature, under a kid resolving in the published key material of an iss its local policy trusts for issuance joins;¶

3. aud names this AS; exp and iat are within the 300-second bound; the jti has not been seen, and is recorded until exp passes (single use);¶

4. the requester is the grant's client_id: the authenticated client equals it, or, where cnf is present, the proof of possession of step 5 binds the redemption to the key the grant was minted for;¶

5. when cnf is present, proof of possession of the bound key with DPoP [RFC9449] or mutual TLS [RFC8705].¶

On success the consuming AS mints tokens under these rules:¶

• The claim rides unchanged. Issued tokens carry the grant's mission object verbatim as the core's mission claim, including the expires_at member (Section 4.1).¶

• Subset. Issued authorization_details MUST be a subset of the grant's. The consuming AS MUST NOT widen, remap, or supplement them from its own policy except to narrow.¶

• Echo. The token response SHOULD echo the issued authorization_details as the core specifies for Mission-bound issuance.¶

• Scope projection. Carrying authorization_details at all requires [RFC9396] support at the consuming AS. An AS that models authority as scope instead projects the grant's authorization_details to scope under the core's scope-projection rule ([I-D.draft-mcguinness-oauth-mission]): every issued scope value corresponds to authority the grant conveys, and none conveys authority, or relaxes a constraint, that the grant does not.¶

• Lifetime. No access or refresh token issued under the grant may have an expiry later than the mission object's expires_at. That ceiling is the Mission horizon, not a liveness bound, so access tokens issued under a grant SHOULD be short-lived: absent a redemption-time state check, an issued access token's own lifetime is the window in which a revoked Mission's token keeps working at the token layer.¶

• State at redemption. A consuming AS that has a Mission-state integration (the one its refresh gating uses) SHOULD re-check Mission state at redemption and refuse when the Mission is not established active, so a Mission revoked between minting and redemption yields no fresh access token; an AS with no state integration relies on the grant's active-at-minting gate and the short access-token lifetime above.¶

• Refresh is state-gated. A consuming AS MUST NOT issue refresh tokens unless it gates each refresh on current Mission state. That gate resolves state through the Mission Status operation ([I-D.draft-mcguinness-oauth-mission-status]) or the MAS's state surface within a published staleness bound, and refuses when the Mission is not established as active. A consuming AS without a state integration MUST NOT issue refresh tokens under a grant.¶

• No re-approval. The approval event already occurred at the Mission Issuer. The consuming AS MUST NOT prompt the Subject or any user for consent at redemption.¶

A grant redeems exactly once. Subsequent token needs are met by the issued refresh token (state-gated) or a fresh grant (state-gated at minting); either way, every path to new authority re-enters a Mission-state gate, which is the issuance-gate kill switch this profile restores.¶

7. Relationship to Other Artifacts

The Mandate is evidence; this grant authorizes. Both are issuer-signed statements about a Mission; the typ values keep them apart mechanically, and a verifier of either MUST reject the other ([I-D.draft-mcguinness-mission-mandate]).¶

The cross-domain grant is this shape across a trust boundary. Cross-domain projection ([I-D.draft-mcguinness-oauth-mission-cross-domain]) carries a Mission to a Resource AS in another domain, with trust established by federation agreement and identity chaining. The issuance join is the same-estate case: bilateral, pre-configured trust between a MAS and its own Authorization Servers, no identity-chaining substrate required. A deployment does not use this profile across domains; projection exists for that.¶

The core is the destination, not a competitor. An AS that becomes natively Mission-aware implements the core and mints without grants for its own resources; the record, anchors, and lifecycle it consumes are the same ones the MAS already operates, so nothing is re-approved in migration. Until then, the issuance join gives the estate Mission-bound tokens at a fraction of the core's implementation surface.¶

The runtime join remains for everything else. Tokens minted under this profile compose credential-carried at the PDP; ordinary tokens continue to compose through the Mission Join. The two joins coexist per resource and per AS.¶

8. Composite Provision

In the substrate's terms ([I-D.draft-mcguinness-mission-substrate]) the MAS alone is a partial-provision binding: everything but the Mission-bound credential and issuance gating. A MAS composed with its consuming Authorization Servers under this profile provides both, jointly: a composite full provision for the resources those ASs serve. In the Mission Assurance Levels ([I-D.draft-mcguinness-mission-architecture]), Baseline Issuance and its issuance-gate kill switch become reachable under the standalone binding through this profile, and the state-aware half-step arrives with the consuming AS's refresh gating.¶

9. Conformance

Grant Minter (the MAS) implements Section 5 in full:¶

• the authenticated, visibility-guarded endpoint;¶

• the active-only gate;¶

• subset and audience scoping;¶

• derivation counting where consented;¶

• minting evidence; and¶

• grants shaped exactly as Section 4 requires.¶

Consuming Authorization Server implements Section 6 in full:¶

• typ, signature, audience, lifetime, single-use, and client binding validation;¶

• verbatim mission claim carriage;¶

• subset-bounded minting;¶

• expires_at capping;¶

• state-gated refresh or no refresh;¶

• no re-approval; and¶

• the redemption error mapping of Section 6.1.¶

The PAR carriage of Section 6.2 is OPTIONAL.¶

A deployment claiming this profile states, alongside its Enforcement Scope Statement, which Authorization Servers consume grants, the staleness bound of each one's refresh gating, and its reconciliation posture (Section 10): the window within which minting and redemption logs are reconciled, or that they are not. A consuming AS advertises its support with the mission_issuance_grant_supported metadata member, and its PAR carriage with mission_issuance_grant_par_supported (Section 12).¶

10. Security Considerations

Grant theft. The grant authorizes issuance, so it is defended in depth: 300-second lifetime, single-use jti, audience binding to one AS, redemption bound to the Mission's authenticated client_id, and optional cnf key binding. A stolen grant is useless to any party that cannot also authenticate as the recorded client at the named AS within the window; deployments whose client credentials are weak SHOULD require cnf (DPoP [RFC9449] or mTLS [RFC8705] bindings serve).¶

Mission Issuer compromise reaches issuance. In MAS-only deployment, MAS compromise corrupts records and state. Under this profile it additionally mints grants every consuming AS honors: compromise reaches token issuance across the estate. The consuming ASs' audit logs of redeemed grants (each with jti and Mission reference) are the independent record that bounds and exposes such minting.¶

A deployment SHOULD reconcile MAS minting evidence against consuming-AS redemption logs. A deployment SHOULD treat a redemption with no matching minting record as a security event. A deployment states its reconciliation posture in its conformance statement (Section 9). A deployment operating under the Enterprise Mission Authority Profile ([I-D.draft-mcguinness-mission-authority-server]) MUST reconcile within the window its statement declares; at estate scale, reconciliation is the only check on this compromise class.¶

Trust inversion. The consuming AS accepts externally derived authority. Its exposure is bounded by the profile's own rules: it mints only within the grant's authorization_details, only for the grant's client, never longer than the Mission's expires_at, and its local policy MAY narrow further. The AS remains free to refuse any grant its policy distrusts; nothing obliges issuance.¶

Type confusion. Three issuer-signed JWT artifacts about Missions now exist: the Mandate (evidence), the cross-domain grant (foreign domain), and this grant (same estate). The typ discipline is the defense; every consumer checks it first, and none accepts another's type.¶

Revocation latency. New grants stop at the MAS active gate at the moment of state commit. Outstanding tokens end at the earlier of their own expiry and the consuming AS's next state-gated refresh; where the runtime layer is deployed, the PDP's re-check bounds outstanding-token use independently. A deployment states the refresh staleness bound it publishes (Section 9).¶

Consent integrity. The approval the grant rests on was rendered and committed at the Mission Issuer under the core's rules and, where deployed, Consent Evidence. The consuming AS relies on that event; it MUST NOT substitute a weaker consent of its own, and its non-prompting duty (Section 6) prevents consent-surface confusion where the Subject holds accounts at both.¶

11. Privacy Considerations

The grant carries the Mission reference and an authority subset to the consuming AS, which may be operated by a different organizational unit than the MAS. Minimization is structural: the MAS scopes authorization_details to what the audience serves (Section 5), and nothing else of the record (no purpose text, no Intent, no full Authority Set) travels. The Mission identifier is a correlator across MAS and AS logs by design; that correlation is the audit trail, and deployments that need to limit broader correlation apply the issuance profile's identifier guidance.¶

12. IANA Considerations

13. References

Acknowledgments

This document profiles the JWT authorization grant of RFC 7523 and composes the Mission Authority Server with the issuance profile it already mirrors; it defines no cryptography of its own.¶

Author's Address