Mission Issuance Grant for OAuth 2.0

3.1. Protocol Flow

The following figure shows the issuance join between the client, the MAS, and a consuming AS:¶

  Client                     MAS                       Consuming AS
    |                         |                              |
    |-- (A) grant request --->|                              |
    |<-- (B) grant -----------|                              |
    |                         |                              |
    |-- (C) token request with the grant ------------------->|
    |                         |<-- (D) Status, per resource -|
    |                         |--- state and Effective ----->|
    |                         |    Authority Set             |
    |<-- (E) access token (and refresh token) ---------------|
    |                         |                              |
    |-- (F) refresh request -------------------------------->|
    |                         |<-- (D) repeated -------------|
    |<-- (E) new tokens -------------------------------------|

(A) The client requests a grant from the MAS for an active Mission, naming the consuming AS as the audience (Section 5).¶

(B) The MAS returns a grant bound to that AS and to the client, and carrying a subset of the Mission's current authority (Section 4).¶

(C) The client presents the grant at the consuming AS's token endpoint as a JWT authorization grant (Section 6).¶

(D) A consuming AS with a Mission-state integration resolves the Mission's current state and Effective Authority Set, with one Mission Status request per resource the grant names (Section 6.3).¶

(E) The consuming AS issues Mission-bound tokens within the grant's authority and that set (Section 6.2).¶

(F) Each refresh repeats (D) before (E). A consuming AS without a Mission-state integration skips (D) and issues no refresh token (Section 6.3.6).¶

3.2. Trust

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 resources the MAS scopes a consuming AS's grants to (Section 5.2) are the audiences it authorizes that AS to request from Mission Status (Section 6.3.1).¶

The duties divide as follows. 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.¶

3.3. Issued Tokens

Tokens issued under this profile are Mission-bound: they carry the mission claim, their authority is a subset of the consented Authority Set, and their issuance is gated on Mission state, at grant issuance always and at redemption and every refresh where the consuming AS has a Mission-state integration.¶

Runtime enforcement reads the Mission from these tokens (credential-carried composition, [I-D.draft-mcguinness-mission-runtime]), so the Mission Join's limit does not apply to them: the join proves a credential belongs to the Mission's parties, never that it was issued for the Mission ([I-D.draft-mcguinness-mission-authority-server], Section "Mission Join"). Tokens the estate issues outside this profile are unchanged and continue to compose through the Mission Join.¶

4.1. The mission Claim

The grant's mission claim is the issuance profile's mission claim object, whose id and issuer members the issuance profile defines ([I-D.draft-mcguinness-oauth-mission], Section "The Mission Claim"). This profile requires two further members:¶

• expires_at. The issuance profile defines expires_at as a REQUIRED Mission Record member and an OPTIONAL member of the mission claim it mirrors. This profile elevates the claim mirror to REQUIRED for the credentials it governs. The Lifetime rule (Section 6.2) depends on that elevation: it caps every token issued under the grant at the mission object's expires_at.¶

• authority_hash. The mission object MUST carry authority_hash ([I-D.draft-mcguinness-oauth-mission], Section "Integrity Anchors"), reintroducing it beyond the issuance profile's baseline claim as this profile's lineage anchor: it names the approved Authority Set the grant derives from, for a consuming AS that, without a Mission-state integration, has no further channel back to the Mission Issuer once it holds the grant. The consuming AS records it with each issuance (Section 6.2) and does not verify it.¶

5.1. Grant Request

The requester POSTs an application/json object to the endpoint over TLS, authenticated as Section 5.2 requires:¶

mission_id:

REQUIRED. A string. The Mission the grant is minted for; its issuer is this MAS.¶

audience:

REQUIRED. A string. The consuming AS the grant is for, becoming the grant's aud. The MAS mints only for audiences its configuration names (Section 3.2).¶

authorization_details:

OPTIONAL. An array. A narrower subset the requester asks the grant to carry, under the issuance profile's subset rule. If it is omitted, the MAS scopes the grant to the entries the named audience serves (Section 5.2); if it is present, it MUST NOT widen beyond that scope.¶

The following is an example of a grant request:¶

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"],
      "constraints": {
        "resource_issued_after": "2026-07-01T00:00:00Z"
      }
    }
  ]
}

5.2. Grant Processing

The MAS MUST apply the following rules:¶

1. Requester. The MAS authenticates the requester as its Mission submission endpoint does ([I-D.draft-mcguinness-mission-authority-server], Section "Mission Submission"). The requester MUST be the Mission's recorded client. Any other caller, including a delegate or enforcement point that the Mission Join Assertion endpoint admits, receives not_found, which preserves the MAS's anti-oracle property.¶

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

3. Subset and audience. The grant's authorization_details MUST be a subset, under the issuance profile's subset rule ([I-D.draft-mcguinness-oauth-mission], Section "Subset Rule"), of the Mission's current Effective Authority Set ([I-D.draft-mcguinness-oauth-mission-status]). That is the consented Authority Set less what any composed narrowing companion has removed; a grant is a derivation, so a contained capability is absent from it ([I-D.draft-mcguinness-oauth-mission-containment], Section "Derivation Gating"). The grant MUST carry only the entries the named consuming AS serves. The requester MAY request a narrower subset. The MAS MUST refuse a request for a wider one.¶

4. Derivation event. Each grant minted is a derivation event. Where the Mission's established derivation_limit ([I-D.draft-mcguinness-oauth-mission-derivation-limits]) is set, the MAS MUST count grants against it atomically and refuse beyond it, which gives that ceiling a binding locus under the standalone binding. A grant counts when its minting commits. Redemption and refresh at a consuming AS do not increment this counter, so the limit bounds the grants the MAS issues, not the number of tokens consuming Authorization Servers issue from them ([I-D.draft-mcguinness-oauth-mission-derivation-limits], Section "Mission Issuance Grant Minting").¶

5. Key binding. When the MAS includes cnf, it MUST take the key from a sender constraint it verified on the grant request: the public key of the request's DPoP proof, as jkt, or the client certificate of the mutual-TLS connection, as x5t#S256 (the TLS handshake proves possession of its key whether or not the certificate also authenticated the client). The MAS MUST NOT derive cnf solely from client-assertion authentication: a private-key-JWT client assertion authenticates the client, and DPoP is not client authentication (Section 3 of [RFC9449]), so only an independent sender-constraint verification on the request supplies the binding, even where it proves the same key. A grant request with no verified sender constraint yields a grant without cnf. The redemption rules for client authentication and public clients (Section 6) apply unchanged, so a public client cannot redeem such a grant.¶

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

5.3. Grant Response

On success the endpoint returns HTTP 200 with an application/json object:¶

grant:

REQUIRED. A string. The Mission Issuance Grant JWT of Section 4. Its exp bounds redemption (Section 6.1).¶

expires_in:

REQUIRED. A JSON integer. The number of whole seconds from the generation of the response until the grant's exp, rounded down so that it never indicates a time after exp.¶

The following is an example of a grant response:¶

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

{
  "grant": "eyJ0eXAiOiJtaXNzaW9uLWlzc3VhbmNlLWdyYW50K2p3dCIs...",
  "expires_in": 180
}

5.4. Grant Errors

A failure returns the MAS error object ([I-D.draft-mcguinness-mission-authority-server]): a JSON body with a REQUIRED error string and an OPTIONAL error_description. This endpoint uses:¶

derivations_exhausted is the condition the mission_error value of that name reports at a token endpoint ([I-D.draft-mcguinness-oauth-mission-derivation-limits]). not_found covers both an unknown Mission and a requester that is not the recorded client, so the split never becomes a membership oracle; invalid_audience, mission_not_active, invalid_authorization_details, and derivations_exhausted are returned only to the authenticated recorded client, to which Mission state is already visible.¶

6.1. Grant Validation

In addition to the processing Section 3 of [RFC7523] requires, the consuming AS MUST validate the following and refuse the request if any check fails:¶

1. the typ JOSE header parameter is mission-issuance-grant+jwt, checked first so that no other artifact's validation rules are applied to the grant (Section 3.11 of [RFC8725] and Section 3.12 of [RFC8725]);¶

2. the signature, under a kid resolving in the published key material of an iss its local policy trusts for issuance joins; and the mission claim's issuer equals iss;¶

3. aud names this AS; exp is no more than 300 seconds after iat, compared exactly; iat is not after the current time and exp is after it, with the clock-skew leeway of Section 4.1.4 of [RFC7519] applied to these two comparisons with the current time only; and the jti has not been seen. The record of a seen jti is written atomically with successful issuance and retained until exp plus that leeway passes (Section 6.3.4);¶

4. the client is the grant's client_id (Section 6): the authenticated client equals it, or, for a public client, the grant carries cnf; and whenever cnf is present, the request proves possession of that key (Section 4);¶

5. sub maps to a local account under the deployment's mapping policy (Section 3.2), and the grant's authorization_details map to resources this AS serves.¶

6.2. Token Issuance

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

• mission claim. Issued tokens carry the grant's mission object as the issuance profile's mission claim, unchanged except that they need not carry authority_hash; id, issuer, and expires_at always carry over (Section 4.1). The consuming AS records authority_hash with each issuance, beside the Mission reference that joins its issuance log to the MAS record (Section 3.2).¶

• Subset. Issued authorization_details MUST be a subset of the grant's. The consuming AS's own policy can only narrow them: it MUST NOT widen, remap, or supplement them. Representing them as scope (below) is not a remapping.¶

• Token response. The token response carries the issued authorization_details as the issuance profile requires for Mission-bound issuance ([I-D.draft-mcguinness-oauth-mission], Section "Mission-Bound Access Tokens", and Section 7 of [RFC9396]), any projected scope beside them (Section 5.1 of [RFC6749]), and the mission_id and mission_expires_at parameters as the issuance profile recommends ([I-D.draft-mcguinness-oauth-mission], Section "Binding the Mission to the Grant").¶

• Scope projection. Where a target's enforcement path consumes scope, the consuming AS also projects the issued authorization_details to scope under the issuance profile's scope-projection rule ([I-D.draft-mcguinness-oauth-mission], Section "Scope Projection"): every issued scope value corresponds to authority the grant conveys, and none conveys authority, or relaxes a constraint, that the grant does not. The consuming AS therefore supports [RFC9396] even where its targets consume only scope.¶

• Lifetime. The consuming AS MUST NOT issue an access or refresh token under the grant with 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.¶

• Effective Authority Set projection. A consuming AS with a Mission-state integration gates redemption and every refresh on current Mission state and projects the issued authority through the Mission's current Effective Authority Set (Section 6.3).¶

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

The following is an example of a successful token response:¶

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

{
  "access_token": "eyJ0eXAiOiJhdCtqd3QiLCJhbGciOiJFUzI1NiJ9...",
  "token_type": "Bearer",
  "expires_in": 300,
  "authorization_details": [
    {
      "type": "mission_resource_access",
      "resource": "https://api.example.com/invoices",
      "actions": ["read"],
      "constraints": {
        "resource_issued_after": "2026-07-01T00:00:00Z"
      }
    }
  ],
  "mission_id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
  "mission_expires_at": "2026-12-31T23:59:59Z"
}

A grant redeems exactly once (Section 6.3.4). Later token needs are met by the issued refresh token (state-gated) or a fresh grant (state-gated at minting), so every path to new authority re-enters a Mission-state gate.¶

6.3. Effective Authority Set Projection

A consuming AS with a Mission-state integration applies this section at redemption and at every refresh. Section 6.3.4 applies to every consuming AS, and Section 6.3.6 states what applies to one without an integration.¶

6.4. Redemption Errors

The consuming AS responds to a failed redemption or refresh with an error response as defined in Section 5.2 of [RFC6749]. A grant that fails any check of Section 6.1 is refused with the invalid_grant error code (Section 3.1 of [RFC7523]), and failed client authentication with invalid_client. The other refusals are:¶

A client tells three cases apart:¶

• Retry. temporarily_unavailable with HTTP 503 means the authorization is intact and the same credential can be presented again, without parsing error_description. invalid_scope and invalid_authorization_details name a request the client can narrow and re-send under the same grant.¶

• Get a fresh grant. An expired or already redeemed grant is cured by obtaining a fresh one (Section 5). The other grant validation failures (an untrusted issuer, a wrong audience, an unmappable subject or authority) are configuration faults that a fresh grant does not cure.¶

• Stop. While the Mission stays out of the active state, neither a retry nor a fresh grant cures the refusal. The AS SHOULD include the issuance profile's mission_error member (mission_revoked, mission_expired, or mission_superseded; [I-D.draft-mcguinness-oauth-mission], Section "Issuance Gating"). A client that requests a fresh grant is refused at the MAS with mission_not_active (Section 5.4), the authoritative signal to stop.¶

9.1. Composite Provision

In the substrate's terms ([I-D.draft-mcguinness-mission-substrate]), a MAS alone claims neither Credential-Bound nor Lifecycle-Gated Authorization for tokens its unchanged Authorization Servers issue. Together with its consuming Authorization Servers under this profile, it supplies both, for the resources those servers serve. In the Mission Assurance Levels ([I-D.draft-mcguinness-mission-architecture]), this profile makes Baseline Issuance reachable under the standalone binding, and a consuming AS's refresh gating adds the state-aware half-step.¶

13.1. Media Type Registration

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

13.2. Mission Authority Server Metadata Registration

IANA is requested to register the following in the "Mission Authority Server Metadata" registry established by [I-D.draft-mcguinness-mission-authority-server]:¶

• Member Name: mission_issuance_grant_endpoint¶

• Change Controller: IETF¶

• Reference: Section 8 of this document¶

13.3. OAuth Authorization Request Parameter Registration

IANA is requested to register the following in the "OAuth Parameters" registry [RFC6749], for the parameter carried in Pushed Authorization Requests (Section 7):¶

• Parameter name: mission_issuance_grant¶

• Parameter usage location: authorization request¶

• Change controller: IETF¶

• Specification document(s): Section 7 of this document¶

13.4. OAuth Extensions Error Registration

IANA is requested to register the following in the "OAuth Extensions Error" registry [RFC6749]. The name is the existing OAuth error code of Section 4.1.2.1 of [RFC6749], registered only for the authorization endpoint; this entry adds its token-endpoint use (Section 6.3.3), as [RFC8628] did for access_denied.¶

• Name: temporarily_unavailable¶

• Usage Location: token error response¶

• Protocol Extension: Mission Issuance Grant¶

• Change Controller: IETF¶

• Specification Document(s): Section 6.3.3 of this document¶

13.5. OAuth Authorization Server Metadata Registration

IANA is requested to register the following in the "OAuth Authorization Server Metadata" registry [RFC8414]:¶

• Metadata Name: mission_issuance_grant_supported¶

• Metadata Description: Whether the authorization server redeems Mission Issuance Grants at its token endpoint¶

• Change Controller: IETF¶

• Specification Document(s): Section 8 of this document¶

• Metadata Name: mission_issuance_grant_par_supported¶

• Metadata Description: Whether the authorization server accepts the Mission Issuance Grant parameter in Pushed Authorization Requests¶

• Change Controller: IETF¶

• Specification Document(s): Section 8 of this document¶

14.1. Normative References

[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-oauth-mission]

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

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

McGuinness, K., "Mission Derivation Limits for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-derivation-limits.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>.

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

[RFC6749]

Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/rfc/rfc6749>.

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

[RFC7523]

Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May 2015, <https://www.rfc-editor.org/rfc/rfc7523>.

[RFC7800]

Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)", RFC 7800, DOI 10.17487/RFC7800, April 2016, <https://www.rfc-editor.org/rfc/rfc7800>.

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

[RFC8414]

Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, <https://www.rfc-editor.org/rfc/rfc8414>.

[RFC8693]

Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, <https://www.rfc-editor.org/rfc/rfc8693>.

[RFC8705]

Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", RFC 8705, DOI 10.17487/RFC8705, February 2020, <https://www.rfc-editor.org/rfc/rfc8705>.

[RFC9101]

Sakimura, N., Bradley, J., and M. Jones, "The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR)", RFC 9101, DOI 10.17487/RFC9101, August 2021, <https://www.rfc-editor.org/rfc/rfc9101>.

[RFC9126]

Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D., and F. Skokan, "OAuth 2.0 Pushed Authorization Requests", RFC 9126, DOI 10.17487/RFC9126, September 2021, <https://www.rfc-editor.org/rfc/rfc9126>.

[RFC9396]

Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, <https://www.rfc-editor.org/rfc/rfc9396>.

[RFC9449]

Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, <https://www.rfc-editor.org/rfc/rfc9449>.

14.2. Informative References

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

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

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

McGuinness, K., "Mission Mandate", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-mandate.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-mission-substrate]

McGuinness, K., "Mission Substrate Requirements", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-substrate.html>.

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

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

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

McGuinness, K., "Mission Containment for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-containment.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>.

[RFC8628]

Denniss, W., Bradley, J., Jones, M., and H. Tschofenig, "OAuth 2.0 Device Authorization Grant", RFC 8628, DOI 10.17487/RFC8628, August 2019, <https://www.rfc-editor.org/rfc/rfc8628>.

[RFC8725]

Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", BCP 225, RFC 8725, DOI 10.17487/RFC8725, February 2020, <https://www.rfc-editor.org/rfc/rfc8725>.