Mission-Bound Authorization for GNAP

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

The Grant Negotiation and Authorization Protocol (GNAP) [RFC9635] is a full redesign of delegated authorization around one continuable object: a client instance posts a grant request to the authorization server's grant endpoint, the server negotiates interaction with the resource owner as needed, and the client continues the same grant through an opaque continuation reference until authority is issued, modified, or the grant is finalized. Its companion [RFC9767] standardizes the resource server's contract with that authorization server: RS-facing discovery, token introspection, and a registry of structured token formats.¶

What GNAP deliberately does not standardize is the object at the center of the negotiation. How the authorization server assesses a request, what the resource owner approved, in what bounds, with what durable record, under what lifecycle: all of it is unspecified policy behind the grant endpoint. The Mission model of [I-D.draft-mcguinness-oauth-mission] (the "issuance profile") is a specification of exactly that interior: a durable Mission record created by an explicit approval event, integrity anchors committing the approved task and its derived authority, a lifecycle whose only-active rule gates issuance, and evidence surfaces built on the record. The issuance profile's own Relationship to GNAP names this document's premise: the Mission model is the OAuth-native instantiation of a binding-neutral contextual-governance kernel, and a deployment that starts from GNAP admits a candidate binding onto that substrate. This document is that binding.¶

Four mechanics the OAuth binding assembles from parts are native here. The grant request is delivered by direct post by construction, the property the OAuth binding retrofits with pushed authorization requests. Structured authority proposals ride the grant request's native access rights, the intake role Rich Authorization Requests play (Section 5 defines their projection into the family's Authority Set), and every request is signed with the client instance's key, so the proposal is cryptographically attributable. Asynchronous approval is the pending grant state with continuation under the server's declared wait interval, the surface the OAuth binding reaches through the Mission Deferred Approval companion ([I-D.draft-mcguinness-oauth-mission-approval]) over an unratified substrate. And the resource server's contract with the Mission Issuer is standardized by [RFC9767] rather than assembled per deployment. The family has already met this shape once: the Mission Authority Server's lifecycle surfaces follow a reference-plus-continuation pattern that its specification notes parallels GNAP's grant continuation ([I-D.draft-mcguinness-mission-authority-server]); here the parallel is the substrate itself.¶

This is the fifth binding of the Mission model: the issuance profile binds it to the OAuth Authorization Server, the Mission Authority Server to a standalone service beside an unchanged AS, the AAuth binding to the AAuth Person Server ([I-D.draft-mcguinness-mission-aauth]), the UMA binding to the UMA 2.0 authorization server ([I-D.draft-mcguinness-mission-uma]), and this document to the GNAP authorization server. Like the AAuth and UMA bindings, it provides issuance gating structurally: no access token exists without passing the authorization server. It is the second binding authored against the Mission Substrate Requirements contract ([I-D.draft-mcguinness-mission-substrate]); its Mission Substrate Statement (Section 10) is written to that document's conformance rules, and it is the first Statement written in the contract's supplied/not-supplied form with activation conditions.¶

2. Mission Roles

The Subject is not a wire role. It is the issuer-qualified principal on whose behalf the Mission runs, established by the authorization server under the issuance profile's authority-source rules and recorded with the Mission: often the resource owner, and in GNAP's cross-user flows (an operator working a client on a customer's behalf) it follows the authority source, not the operator. The grant request's user member is an unauthenticated hint and never establishes it (Section 6).¶

Two properties of this mapping are structural in GNAP rather than profile rules. First, the proposer is never the approver on the wire: the client instance can only request, and every grant of authority is decided at the authorization server. Second, the pending grant with continuation makes the human Approver's asynchronous decision native rather than a companion overlay (Section 6).¶

In the agent deployments this profile targets, one natural person commonly operates the client, owns the resources, and is the principal the Mission serves: operator, Approver, and Subject coincide, the OAuth binding's default geometry. The table's role assignments, not that coincidence, are normative.¶

3. Mission Flow

This section is informative. An agent holds the task "reconcile Q3 invoices at the finance service and file the summary at the document service" for Alice, whose resources at both services are governed by the authorization server at https://as.example.com/gnap.¶

1. The agent posts a grant request to the grant endpoint, signed with its instance key: a mission_intent member carrying the whole task (Section 4), access token requests whose access arrays name both services (the authority proposal), and an interact member offering redirect start with a redirect finish.¶

2. The authorization server validates the Intent as untrusted input, derives the full Authority Set, and returns a pending response: a continue object with a continuation access token bound to the agent's key, and interaction instructions for Alice.¶

3. Alice authenticates at the authorization server's interaction surface, reviews the rendered task and derived Authority Set, and approves. The Mission record is created active, the anchors are committed, and Consent Evidence is recorded (Section 6).¶

4. The interaction finish returns Alice's browser to the agent's callback with an interaction reference, integrity-bound by the finish hash. The agent continues the grant with interact_ref; the grant reaches approved, and the response carries the finance-service access token, the first drawdown of the approved ceiling, plus the Mission Reference in the mission response member (Section 9.1).¶

5. Later the agent needs the document service. It modifies the grant with a request for that service's access. The requested rights are within the Authority Set, so the authorization server approves by policy without waking Alice and issues the second token: a drawdown, not a new approval (Section 9.3).¶

6. Each resource server introspects tokens per [RFC9767], or validates the structured token's mission claim offline. Revoking the Mission at the authorization server finalizes the grant and takes effect at the next introspection everywhere: one Mission, compiled once, drawn down per service, killed in one place.¶

4. Mission Intent

The Mission Intent reaches the authorization server inside the grant request: a mission_intent top-level member, registered for the GNAP Grant Request Parameters registry (Section 15). This binding defines no new endpoint; the grant endpoint is the intake.¶

The mission_intent value is a Mission Intent Submission envelope as the issuance profile defines it, intent plus OPTIONAL evidence, under that profile's syntactic and Intent Submission Evidence rules (the envelope and the Intent are both closed at the top level, the authorization server MUST bound size, array lengths, evidence entry count, and evidence verification cost, presented evidence is dispatched by type and refused when unsupported or failing, and the submission is untrusted client input, never authority). The grant request's signature attributes the submission to the client instance's key; attribution confers no authority.¶

The access rights of the grant request's access token requests are this binding's authority proposal, replacing the issuance profile's PAR-only carriage rule. GNAP rights are not an OAuth authorization_details array: Section 5 defines the normative projection that resolves, normalizes, and aggregates them before the issuance profile's recording and hashing semantics apply (a proposal, never authority; the Intent itself carries no authority members).¶

A Mission-Bound GNAP Client Instance MUST carry the Mission Intent on the first grant request it makes under a prospective Mission, and the Intent MUST describe the whole task, not the slice the request's access rights name. The authorization server derives the Authority Set from the Intent, and from the authority proposal, bounded by the issuance profile's Mission Authority rules; the requested access locates the first drawdown, not the Mission's extent (Section 1.1). The mission_intent member is valid only on the grant request that opens the negotiation (Section 6.2). A grant request with no mission_intent and no Mission association is plain GNAP, outside this profile's scope.¶

The Subject arrives through GNAP's own channels: interaction at the authorization server, or subject assertions the server verifies. The authorization server MUST NOT take the Subject from the grant request's user member or from the Mission Intent, which are unauthenticated client input (Section 6).¶

The proposal is the shaping profile's Mission Intent proposal, and a deployment that shapes free-text instructions into structured Intents composes here unchanged ([I-D.draft-mcguinness-mission-shaping]).¶

5. Mission Authority Adapter

GNAP access rights are strings or type-defined objects whose semantics belong to each type, per [RFC9635]; a grant request may carry several labeled access token requests; and nothing makes two rights comparable because their members share names. The family's proposed_authority is specifically an array of authorization details objects. This section is the normative bridge between the two.¶

A Mission-Bound GNAP Authorization Server MUST project the grant request's access rights into the family representation as follows:¶

1. Resolve. Every reference string resolves to the authorization-server-defined access-right object it names, pinned as an immutable, versioned value for the Mission's retention period. An unresolvable reference refuses intake.¶

2. Type contract. For each access-right type the deployment supports, the authorization server defines: normalization to a canonical form, audience and location interpretation, conversion to an authorization details object, equality, and, where the type admits one, a subset relation in the type's value space. An unsupported type refuses intake; nothing is inferred from member-name coincidence.¶

3. Aggregate. Rights are aggregated across all of the grant request's access token requests and deduplicated under type-defined equality. Token labels are issuance metadata, never authority.¶

4. Record. The resulting canonical authorization details array is recorded as proposed_authority and hashed as proposal_hash under the issuance profile's rules. The raw GNAP request MAY be retained as transaction evidence; it is not the record field.¶

A type that defines equality but no subset relation is an exact-carry type: its rights enter the Authority Set and later comparisons only as exact values at their original audience, and a modification touching them classifies as exact drawdown or refusal, never as attenuation (Section 9.2, Section 9.3). The derived Authority Set remains bounded by the issuance profile's Mission Authority rules; the adapter governs the proposal input, not the derivation.¶

6. Mission Approval

GNAP's grant processing is this binding's approval surface. Where processing concludes that a new Mission is proposed, it executes the issuance profile's approval steps:¶

1. Authenticate the Approver: the resource owner or other accountable principal at the authorization server's interaction surface, or establish the standing basis of an adopted companion profile (Section 6.1). When the Intent carries controls.acr, the authentication MUST be one the deployment's policy maps as satisfying the named class.¶

2. Establish the Subject: the issuer-qualified principal on whose behalf the Mission runs, per the deployment's authority-source policy (Section 2), from interaction the authorization server itself conducted or from subject assertions it verified, never from the grant request's user member, the Mission Intent, or other unauthenticated client input.¶

3. Derive the Authority Set from the Intent and the authority proposal (Section 4), and render it for consent on the interaction surface under the issuance profile's rendering rules (Section 13.3).¶

4. Compute the integrity anchors with the authorization server's grant endpoint URI as the envelope iss (Section 7).¶

5. Create the Mission record in the active state atomically with the approval decision. The grant request MUST NOT reach the approved state under the Mission before the record is active.¶

7. Mission Record

GNAP has no native artifact for what was approved; the grant request is mutable and the states carry no content. The Mission record supplies it. A Mission-Bound GNAP Authorization Server MUST create a Mission record, as the issuance profile's Mission Record section defines it, for every Mission it approves, with issuer its grant endpoint URI (the value [RFC9635] defines as the identifier of the AS) and client_id the client instance's instance identifier where the authorization server registers one, or a stable approval-time identifier it derives from the instance's key where none is registered. That value is the Actor identity; token presenter keys are credential bindings recorded separately (Section 13.4). expires_at is REQUIRED, in RFC 3339 [RFC3339] date-time form; when the proposal's Intent carries none, the authorization server MUST set one by policy.¶

Like the UMA binding and unlike the AAuth binding, this substrate carries no wire-native mission artifact to commit. The record is held at the authorization server, mission_id and issuer name the Mission, and consumers meet the reference in the mission grant response member, the token's mission claim, or the introspection response (Section 9). No substrate-native commitment exists beside the anchors, and nothing substitutes for them.¶

8. Mission Lifecycle

The Mission lifecycle is the issuance profile's state space, extended by the status profile where the deployment adopts it ([I-D.draft-mcguinness-oauth-mission-status]), with the only-active rule governing every authorization-server surface and unrecognized states fail-safe non-active.¶

The projection is fail-safe: every non-active state projects to a non-permitting native signal. The introspection projection is binary: a response for a token under a non-active Mission is active: false with every other member omitted, per [RFC9767], the mission member appears only in active responses (Section 9.1), and the lifecycle reason is obtained from the family state surfaces (Section 8.2). This binding adds to GNAP's model:¶

• Revocation. The authorization server MUST provide an authenticated means for the Subject, the Approver, or an administrator to revoke a Mission by mission_id, independent of any token and of the grant's continuation, per the issuance profile. On revocation the authorization server finalizes the grant and treats the Mission's outstanding tokens as inactive at introspection; a deployment that validates structured tokens without introspection needs the state surfaces below.¶

• Expiry. When the record's expires_at passes, the Mission transitions to expired without a request.¶

• Completion. The client instance's DELETE of the continuation URI is grant cancellation: it always finalizes the grant, per [RFC9635]. A Mission-Bound GNAP Authorization Server MAY additionally treat it as a completion proposal, adjudicated under the Issuer's lifecycle policy with the semantics of the status profile's complete operation; a rejected or unauthorized proposal leaves the grant finalized without changing Mission state. A deployment MAY also serve completion as a family surface for parties other than the client.¶

• Suspension. A deployment that adopts the status profile's suspended state defers rather than denies: continuation responses carry continue with wait and no new tokens, so the client instance waits under GNAP's own retry discipline rather than treating the Mission as dead.¶

The grant and the Mission have distinct lifetimes. A Mission-Bound GNAP Authorization Server SHOULD keep the grant continuable (returning a continue object) while the Mission is active, so the negotiation surface tracks the Mission; a grant the server finalizes early ends negotiation but not governance of tokens already issued. Re-attaching a new grant request to an existing Mission is deferred work.¶

9. Mission-Bound Credential

The GNAP access token is this binding's Mission-bound credential. It is bound to the client instance's key by default under [RFC9635]; a deployment that sets the bearer flag on a Mission-bound token weakens the holder guarantee and MUST declare that mode in its Mission Deployment Profile.¶

{
  "active": true,
  "iss": "https://as.example.com/gnap",
  "access": [
    {
      "type": "finance-ledger",
      "actions": ["read", "post-adjustments"],
      "locations": ["https://finance.example.com/q3"]
    }
  ],
  "key": {
    "proof": "httpsig",
    "jwk": {
      "kty": "OKP",
      "crv": "Ed25519",
      "x": "JrQLj5P_89iXES9-vFgrIy29clF9CC_oPPsw3c5D0bs"
    }
  },
  "exp": 1793610000,
  "mission": {
    "id": "msn_9Fk2WqLp0Vd5Jh8xTc4nB7r1",
    "issuer": "https://as.example.com/gnap",
    "authority_hash":
      "sha-256:x8FvWqLp0Vd5Jh2mTc4nB7r1KdYzQw6aA3f5EMkRb60",
    "expires_at": "2026-12-31T23:59:59Z",
    "state": "active"
  }
}

10. Mission Substrate Statement

This section is this binding's Mission Substrate Statement ([I-D.draft-mcguinness-mission-substrate]). It applies to this revision of the binding in token-carried, introspection-carried, and mixed credential modes.¶

The contextual-governance kernel maps as follows:¶

1. Mission Reference: the tuple (issuer, mission_id) names one record. issuer is the grant endpoint URI, the identifier of the AS under [RFC9635]; mission_id follows the issuance profile's uniqueness, retention, comparison, non-reassignment, and entropy rules (Section 7).¶

2. Controller: the GNAP authorization server controls approval, state, assessment, and token issuance. Relying components establish it from the configured trust in its grant endpoint URI; resource servers locate its introspection surface through RS-facing discovery ([RFC9767]), and verification keys for signed family artifacts are deployment-distributed (Section 8.2).¶

3. Actor binding: the Actor is the client instance, identified by its instance identifier where the authorization server registers one, otherwise by a stable approval-time identifier the Controller derives from the instance's key. Instance requests are proved by the key proofing method on every signed request; at approval the Controller binds the instance that signed the negotiation-opening request. Access-token presenter keys are credential bindings recorded separately: token key rotation is a credential event, never Actor succession, and client-instance identity migration is outside [RFC9635], requiring a deployment-authenticated rule or a fresh approval. Delegation is not defined by this binding (Section 2, Section 7, Section 13.4).¶

4. Approved Context: the immutable Mission Intent, the recorded authority proposal (the adapter's canonical array, Section 5), and the derived Authority Set in the Mission record are the Approved Context. The family intent_hash, authority_hash, and proposal_hash commit them under the issuance profile's canonicalization; they are this binding's chosen mechanism, not a substrate-kernel requirement. The mutable grant request is never the approved value, and modification never revises the record behind its reference: approved widening yields a successor Mission (Section 1.1, Section 7, Section 9.3).¶

5. Approval ceremony: grant processing performs the five approval steps in the interactive or deferred mode, or under a companion-supplied standing basis, binding one proposal revision, and creates the record active atomically with approval; the grant does not reach approved before the record does (Section 6, Section 6.2).¶

6. Governance gate: only the issuance profile's active state is active. Every other or unrecognized value fails closed at continuation, issuance, rotation, and the introspection projection. The Subject, Approver, and administrator have an authenticated revocation path (Section 8, Section 8.1).¶

7. Reliance bound: issuance, modification, and rotation establish active at the authorization server. An opaque token is bounded by authenticated per-use introspection; a structured token without a state check remains usable only for its bounded lifetime, capped at the Mission's expires_at, after a transition (Section 8.1, Section 8.2).¶

8. Context propagation: the protected mission claim in a structured token proves issuance under the Mission and verifies offline; the mission member of the introspection response (on active responses only) is the Controller's authenticated per-use assertion of the same fact and current state; the mission grant response member is correlation for the client instance only. The continuation access token carries continuity and never establishes Mission governance or authority (Section 9.1, Section 9.4).¶

9. Governance record: the assessment log is the ordered governance record. The authorization server MUST append approval, positive and negative Mission-dependent decisions (issuance, modification, rotation, introspection projections it relies on), and lifecycle transitions in per-Mission append order; MUST protect the log under the same integrity and access controls as the Mission record; and MUST retain both for the deployment-declared audit horizon.¶

The binding declares these capabilities:¶

Each supplied row's temporal elements inherit the reliance floor of Section 8.1 unless stated: freshness at use is established at the gated operation or at introspection, artifact lifetime is the token's expiry capped by the Mission's expires_at, and the residual interval after the Mission becomes non-active is the remaining lifetime of structured tokens or the declared introspection cache bound. Failure behavior is uniformly fail-closed: absent, stale, unknown, incomparable, invalid, or unavailable input refuses the gated operation. The Portable Evidence row is supplied only while its activation profile ([I-D.draft-mcguinness-oauth-mission-consent-evidence], [I-D.draft-mcguinness-mission-mandate], [I-D.draft-mcguinness-mission-audit]) is adopted; the referenced profile defines the portable artifact and verification procedure.¶

The composition consequences:¶

• The runtime profile and its AuthZEN binding compose against either credential surface: the Mission reference arrives through token validation (structured token claims, or the issuer's introspection response that validates the opaque token), so binding establishment is credential-carried in both (Section 9.1).¶

• Shaping, consent evidence, status and signals, the Mandate, and audit transparency ([I-D.draft-mcguinness-mission-audit]) compose unchanged, with the authorization server as the Mission Issuer, committing issuer, minter, and transmitter those profiles name.¶

• Child delegation does not apply as profiled: its request wire is OAuth-bound ([I-D.draft-mcguinness-oauth-mission-child-delegation]), and this binding defines no actor chain. A sub-agent operates as its own client instance under its own grant requests; GNAP-native Child Mission creation is deferred work.¶

• Offline attenuation does not apply as profiled: every token is issuer-minted ([I-D.draft-mcguinness-oauth-mission-attenuation]). A deployment issuing attenuable token formats from the [RFC9767] registry (macaroon, biscuit, zcap) takes on that companion's obligations; profiling that composition is deferred work.¶

• Cross-domain projection is not provided: GNAP federates a resource server to an authorization server, not one Mission Issuer to another, so projecting a Mission into a foreign issuer remains the cross-domain companion's OAuth-bound mechanism ([I-D.draft-mcguinness-oauth-mission-cross-domain]). One Mission natively governs many resource servers within the authorization server's own trust domain, the multi-service case the flow shows (Section 3).¶

• Mission Containment composes at issuance, modification, rotation refusal, and per-use introspection filtering ([I-D.draft-mcguinness-oauth-mission-containment], Section 8.1, Section 8.2).¶

• The family's Mission Assurance Levels layer on top unchanged ([I-D.draft-mcguinness-mission-architecture]); a deployment states its level, binding, state sources, and staleness bounds in its Mission Deployment Profile.¶

11. Limitations

Deployed base. Both substrate documents are Proposed Standard RFCs, so this binding is the family's only one whose entire substrate is IETF-ratified. What GNAP lacks is deployed breadth. The issuance profile's Relationship to GNAP states the composition posture this document inherits: the family composes with deployed grant protocols rather than requiring new ones, so this binding governs estates that already run GNAP; it does not create them, and a deployment without a GNAP substrate has no reason to adopt one for the Mission's sake, since the OAuth binding exists.¶

Mutability discipline. The grant request is mutable by design, and this binding's drawdown/expansion split (Section 9.3) is the load-bearing rule that keeps the Approved Context immutable behind it. An implementation that lets policy adjudication of a modification widen authority, or that treats the negotiated grant as the approved value, has silently replaced the approval; the Mission record and its anchors, never the grant, are what was approved.¶

Deferred wire work. Beyond test vectors and the error taxonomy, this sketch defers: carriage of the containment profile's denial reason on GNAP's error object; registration of the family discovery members for both GNAP discovery surfaces; re-attaching a new grant request to an existing Mission after finalization; client-instance identity migration; GNAP-native Child Missions; and the attenuable-token-format composition (Section 10).¶

12. Conformance

An implementation conforms in one of two roles. Resource servers participate through unmodified [RFC9767] or structured-token validation and have no role to claim.¶

A Mission-Bound GNAP Authorization Server:¶

• accepts the mission_intent grant request member on negotiation-opening requests only, and bounds it as untrusted input (Section 4, Section 6.2);¶

• projects access rights into the family representation through the authority adapter: resolves references, refuses unsupported types, aggregates and deduplicates across token requests, and records the canonical array as proposed_authority (Section 5);¶

• executes the approval event on its grant processing surface in the interactive and deferred modes, and in the standing-basis mode only where an adopted profile supplies the complete approval basis, binding one proposal revision, creating the record active atomically with the decision, and computing the anchors (Section 6, Section 6.2, Section 7);¶

• operates the lifecycle of Section 8: authenticated revocation by mission_id, expiry, completion adjudicated on grant revocation, fail-safe projection onto continuation and token-management outcomes, and the only-active gate atomic with every issuance, modification, and rotation (Section 8.1);¶

• issues access tokens as Mission-bound credentials on a declared carriage surface, applies the subset rule at every issuance and modification, and routes out-of-set modifications to the Approver, realizing approved widening as a successor Mission (Section 9, Section 9.3);¶

• where it adopts Mission Containment, intersects every issued token's rights with the Effective Authority Set at access-right grain at every issuance and modification, refuses a result with no surviving right (request_denied), refuses rotation of a token whose rights the set no longer covers (invalid_rotation), and filters per-use introspection the same way, reporting active: false where a named minimum access is no longer satisfied and the filtered access array otherwise (Section 8.1, Section 8.2);¶

• treats token key rotation as a credential event, never Actor succession (Section 13.4);¶

• keeps continuation and token management access tokens confined to their surfaces, as continuity, never authority (Section 9.4);¶

• serves Mission state with a declared staleness bound per Section 8.2, and retains the record and assessment log for the audit horizon; and¶

• advertises its Mission surfaces in its discovery responses (Section 8.2).¶

A Mission-Bound GNAP Client Instance:¶

• carries a whole-task Mission Intent on the first grant request under a prospective Mission, and treats every proposal as a proposal, never as authority (Section 4);¶

• follows GNAP's continuation discipline: respects wait, verifies the interaction finish hash before continuing, and stops on a finalized grant;¶

• holds the continuation access token as continuity and never treats it, the token management token, or mission_id as a credential (Section 9.4); and¶

• proposes completion by revoking the grant request when the task is done, understanding that revocation finalizes the grant and completion is the Issuer's adjudication (Section 8).¶

13. Security Considerations

14. Privacy Considerations

The task concentrates at the authorization server. The whole-task Intent rule sends the full task description to the authorization server in the first grant request, earlier and more completely than per-service negotiation would. That is deliberate, and it is the concentration the issuance profile's record already implies; the shaping profile's minimization guidance applies to what the Intent says.¶

Resource servers see little. Introspection returns a resource server only the token's access rights and the mission members; the Intent, the constraints, and the rest of the Authority Set stay at the authorization server, and [RFC9767] already prohibits echoing the token value. Subject information is released only in the formats and identifiers requested and authorized, per [RFC9635].¶

mission_id is a correlation handle. The mission members correlate one Mission's activity across resource servers and across tokens, the issuance profile's deliberate stable-anchor property; that profile's guidance applies. The mission grant response member adds correlation at the client instance only, and nothing new crosses to resource servers.¶

15. IANA Considerations

This document registers two GNAP extension members and one introspection response member; the behavior fixed here is the registration content.¶

GNAP Grant Request Parameters registry ([RFC9635]):¶

• Name: mission_intent. Type: object. Reference: Section 4 of this document. Behavior by grant state: valid only in the grant request that opens a negotiation; a continuation or modification request carrying it is rejected with invalid_request in every state (Section 6.2). It never appears in responses.¶

GNAP Grant Response Parameters registry ([RFC9635]):¶

• Name: mission. Type: object. Reference: Section 9.1 of this document. Behavior by grant state: returned in responses for a grant governed by a Mission once the approval event has created the record, in the approved state and in pending or processing rounds that follow it; absent before approval.¶

Token introspection response registry ([RFC9767]):¶

• Name: mission. Type: object. Reference: Section 9.1 and Section 8.2 of this document. Returned only in active introspection responses for tokens issued under a Mission.¶

The family discovery members of Section 8.2 remain to be registered in the GNAP Authorization Server Discovery Fields registry of [RFC9635] and the RS-facing discovery registry of [RFC9767] in a later revision (Section 11). The mission JWT claim is registered by the issuance profile.¶

16. References

Acknowledgments

This document is part of the Mission-Bound Authorization work. It binds the Mission model to the GNAP authorization server, and builds on the Mission Substrate Requirements, Mission Status and Lifecycle, and Mission-Bound Runtime Enforcement companions. GNAP's continuable grant, key-bound client instances, native pending state, and structured access rights anticipated the geometry agents now present; this binding supplies the governed object those mechanics were built to negotiate.¶

Author's Address