Network Working Group K. McGuinness Internet-Draft Independent Intended status: Experimental 23 August 2026 Expires: 24 February 2027 Mission-Bound Authorization for UMA 2.0 draft-mcguinness-mission-uma-latest Abstract User-Managed Access (UMA) 2.0 standardized the plumbing of asynchronous, party-asymmetric authorization: a requesting party and client that can only request, a resource owner who approves at the authorization server on their own schedule, a rotating permission ticket carrying the pending request, claims pushing at the token endpoint, a persisted claims token that carries continuity but grants nothing, and per-use introspection at the resource server. It deliberately left the object of that plumbing unspecified: the authorization assessment is a black box, with no artifact of what was approved, why, or within what bounds. This document supplies that interior from the Mission model of Mission-Bound Authorization for OAuth 2.0. The Mission Intent rides UMA claims pushing as a claim token, the resource owner's decision is the approval event that creates the Mission record with its integrity anchors, the Mission lifecycle gates every RPT issuance and upgrade, the RPT is the Mission-bound credential, and the persisted claims token is profiled as Mission continuity that is never authority. This is the fourth binding of the Mission model and the first authored against the Mission Substrate Requirements contract. It is an experimental sketch: the binding's shape and its Mission Substrate Statement are fixed here, and wire-level completeness is deferred. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://mcguinness.github.io/mission-bound-authorization/draft- mcguinness-mission-uma.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-mcguinness- mission-uma/. Source for this draft and an issue tracker can be found at https://github.com/mcguinness/mission-bound-authorization. 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 24 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 1.1. Attempt-First Operation 1.2. Applicability 2. Status: An Experimental Sketch 3. Conventions and Terminology 4. Mission Roles 5. Mission Flow 6. Mission Intent 7. Mission Approval 8. Mission Record 9. Mission Lifecycle 9.1. Issuance Gating 9.2. Mission State Surfaces 10. Mission-Bound Credential 10.1. The Mission Claim 10.2. Authority Subset and Grain 10.3. Drawdown and Upgrade 10.4. Mission Continuity: the PCT 10.5. Worked Example 11. Mission Substrate Statement 12. Limitations 13. Conformance 14. Security Considerations 14.1. The Ticket as Deferral Handle 14.2. Rendering the Proposal 14.3. The PCT Is Not Authority 14.4. Authorization Server Compromise 14.5. Introspection as the State Channel 15. Privacy Considerations 16. IANA Considerations 17. References 17.1. Normative References 17.2. Informative References Acknowledgments Author's Address 1. Introduction User-Managed Access (UMA) 2.0 comprises two Kantara Initiative Recommendations. The UMA grant [UMA-GRANT] extends OAuth 2.0 with a party asymmetry OAuth does not have: the requesting party, on whose behalf a client seeks access, is distinct from the resource owner, who sets policy and decides submitted requests at the authorization server, on the authorization server's own surface and schedule. Federated authorization [UMA-FEDAUTHZ] standardizes the resource server's contract with that authorization server: resource registration, the permission endpoint, and extended token introspection, under a protection API access token. Between them the two documents standardize the plumbing of asynchronous, party- asymmetric authorization: the tokenless first attempt, the rotating permission ticket, claims pushing and interactive claims gathering, the request_submitted deferral, the requesting party token (RPT), and the persisted claims token (PCT). What UMA deliberately does not standardize is the object at the center. 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 token endpoint. The Mission model, first specified in its OAuth binding ([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. This document binds the Mission model to the UMA 2.0 authorization server by filling UMA's assessment with the Mission. Three mechanics the OAuth binding assembles from parts are native here. The pushed Mission Intent rides UMA claims pushing at the token endpoint rather than pushed authorization requests. The asynchronous approval the OAuth binding reaches through the Mission Deferred Approval companion, over the unratified OAuth Deferred Token Response ([I-D.draft-mcguinness-oauth-mission-approval]), is UMA's request_submitted with its rotating ticket, a ratified surface. And the resource server's contract with the Mission Issuer is the protection API, standardized by [UMA-FEDAUTHZ] rather than assembled per deployment. This is the fourth 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 ([I-D.draft-mcguinness-mission-authority-server]), the AAuth binding to the AAuth Person Server ([I-D.draft-mcguinness-mission-aauth]), and this document to the UMA 2.0 authorization server. Like the AAuth binding, it provides issuance gating structurally: no RPT exists without passing the authorization server's token endpoint. It is also the first binding authored against the Mission Substrate Requirements contract ([I-D.draft-mcguinness-mission-substrate]) rather than one the contract was extracted from; its Mission Substrate Statement (Section 11) is written to that document's conformance rules, and exercising the checklist on a substrate none of its source bindings resemble is part of this sketch's purpose. 1.1. Attempt-First Operation UMA inverts the OAuth binding's flow. The OAuth binding is intent- first: the client submits the Mission Intent, approval happens, and tokens follow. UMA is attempt-first: the client's first move is a tokenless request at a resource server, and everything else (the ticket, the claims, the approval) hangs off that attempt. This binding preserves the model's compile-once property across the inversion with one rule: the first ticket exchanged under a prospective Mission carries the whole task as a pushed Mission Intent, and the authorization server derives and obtains approval for the full Authority Set, not the ticketed slice (Section 6). Without that rule the Approver would meet the Mission one resource-server slice at a time, which is the consent-fatigue failure the model exists to prevent. The approved set is then a ceiling, and each subsequent ticket a drawdown adjudicated by policy within it, the shape the progressive companion names ([I-D.draft-mcguinness-oauth-mission-progressive]). 1.2. Applicability This profile targets deployments that operate a UMA 2.0 authorization server implementing [UMA-GRANT] and [UMA-FEDAUTHZ] and that route an agent's access through the UMA grant. The agent is the UMA client; the accountable person is the resource owner. Resource servers participate through plain UMA: registration, permission requests, and introspection are unchanged, and a resource server needs no Mission awareness beyond what introspection already returns (Section 10). Both substrate documents are final Kantara Initiative Recommendations; Section 12 discusses what that dependency choice trades. This document is an experimental sketch. It fixes the binding's shape and its Mission Substrate Statement; worked test vectors and a per-endpoint error taxonomy are deferred to a later revision. 2. Status: An Experimental Sketch Maturity: sketch. Maintenance: lab-best-effort. Adopt when: Evaluating a UMA 2.0 deployment only. Requires: Mission Substrate Requirements. Also requires, conditionally: Mission Issuance Grant for OAuth 2.0 (when the expires_at member is adopted). 3. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. All JSON and HTTP shown in this document is non-normative and illustrative; the member definitions in the surrounding text are authoritative. This document uses Mission, Mission Intent, Mission Issuer, Authority Set, Approver, Subject, mission_id, the integrity anchors (intent_hash, authority_hash, and, where the Mission records an authority proposal, proposal_hash), the subset rule, the only-active rule, and the audit horizon as defined by [I-D.draft-mcguinness-oauth-mission], and Effective Authority Set as defined by [I-D.draft-mcguinness-oauth-mission-status]. It uses resource owner, requesting party, client, permission ticket, claims pushing, claim token, claims interaction endpoint, requesting party token (RPT), persisted claims token (PCT), and the need_info, request_submitted, and request_denied outcomes as defined by [UMA-GRANT], and resource server, protection API, protection API access token (PAT), resource registration, permission endpoint, and token introspection as defined by [UMA-FEDAUTHZ] and [RFC7662]. It additionally uses: Mission-Bound UMA Authorization Server: A UMA 2.0 authorization server conforming to this profile: it implements the Mission Issuer role behind its token endpoint and owner surfaces (Section 13). Mission-Bound UMA Client: A UMA client that proposes structured intent on its first ticket exchange under a prospective Mission and respects the Mission lifecycle (Section 13). 4. Mission Roles +===============+======================================+ | UMA role | Mission model role | +===============+======================================+ | Authorization | Mission Issuer: runs the assessment, | | server | holds the Mission record, gates RPT | | | issuance, serves Mission state | +---------------+--------------------------------------+ | Resource | Approver: sets policy and decides | | owner | submitted requests | +---------------+--------------------------------------+ | Requesting | Subject: the party on whose behalf | | party | the client acts | +---------------+--------------------------------------+ | Client | Agent: its OAuth client identifier | | | is the Mission's client_id | +---------------+--------------------------------------+ | Resource | Resource Server: protection API | | server | participant, no Mission awareness | | | required | +---------------+--------------------------------------+ Table 1 Two properties of this mapping are structural in UMA rather than profile rules. First, the proposer is never the approver on the wire: the client and the requesting party can only request, and every grant of authority is made at the authorization server by the resource owner or the owner's pre-registered policy. The issuance profile's rule that the proposing party never approves is the substrate's own geometry here. Second, both of the issuance profile's approval modes are native UMA modes: pre-registered owner policy at the authorization server is the authorized-policy approver deciding at machine speed, and request_submitted is the human Approver deciding asynchronously (Section 7). UMA permits the requesting party and the resource owner to be the same natural person, and in the agent deployments this profile targets they usually are: the person's agent is the client, and the person is both Subject and Approver, the OAuth binding's default geometry. Nothing in this binding requires them to differ. 5. 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 resource servers are protected by the authorization server https://as.example.com. 1. The agent attempts a tokenless request at the finance resource server. The resource server registers the needed permissions at the authorization server's permission endpoint under its PAT and returns the permission ticket with the authorization server's location, per [UMA-GRANT]. 2. The agent presents the ticket at the token endpoint under grant_type urn:ietf:params:oauth:grant-type:uma-ticket, pushing the Mission Intent for the whole task, both services, as a claim token (Section 6). 3. The authorization server gathers the requesting party's identity claims through UMA's ordinary channels (a pushed identity claim token, or interactive claims gathering at the claims interaction endpoint), accumulating across ticket rotations. 4. The authorization server derives the full Authority Set from the Intent, renders it for consent on its owner surface, and returns request_submitted with a rotated ticket: the decision is deferred to Alice (Section 7). 5. Alice approves on the owner surface. The Mission record is created active, the anchors are committed, and Consent Evidence is recorded. 6. The agent retries the ticket and receives an RPT carrying the finance permissions, the first drawdown of the approved ceiling, plus a PCT (Section 10.4). 7. Later the agent attempts the document service. The new ticket goes to the token endpoint with the PCT and the existing RPT for upgrading; the authorization server resolves the Mission through the PCT, checks the requested permissions against the Authority Set, and approves by policy without waking Alice (Section 10.3). The upgraded RPT carries both services' permissions. 8. Each resource server introspects the RPT per use. Revoking the Mission at the authorization server takes effect at the next introspection everywhere: one Mission, compiled once, projected per resource server, killed in one place. 6. Mission Intent The Mission Intent reaches the authorization server through claims pushing: it rides the existing claim_token parameter of the token endpoint's UMA grant, and this binding defines no new endpoint or parameter. A Mission Intent claim token is a JWT whose payload carries a mission_intent claim: 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 payload MAY additionally carry an authorization_details claim: the client's authority proposal, an array of authorization_details objects. This claim is this binding's proposal carriage, replacing the issuance profile's PAR-only carriage rule; that profile's validation, derivation, recording, and hashing semantics apply unchanged (a proposal, never authority; the Intent itself carries no authority members). A Mission created from a push carrying one records proposed_authority and proposal_hash as the issuance profile's Mission record defines them. The JWT MAY be signed by the client for attribution; a signature confers no authority. Its claim_token_format identifier is: https://mcguinness.github.io/mission-bound-authorization/uma-intent-jwt A Mission-Bound UMA Client MUST push the Mission Intent on the first ticket exchange it performs under a prospective Mission, and the Intent MUST describe the whole task, not the slice the ticket's registered permissions name. The authorization server derives the Authority Set from the Intent, and from the authority proposal where one was pushed, bounded by the issuance profile's Mission Authority rules; the ticket's permissions locate the first drawdown, not the Mission's extent (Section 1.1). A ticket exchange with no pushed and no PCT-resolved Mission context is plain UMA, outside this profile's scope. The Intent is one claim token among UMA's ordinary ones. The requesting party's identity claims arrive through their own channels (a pushed identity token or interactive claims gathering), in the same or other rounds of the need_info rotation loop; the authorization server MUST NOT take the Subject from the Mission Intent claim token, which is unauthenticated client input (Section 7). 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]). 7. Mission Approval UMA's authorization assessment is this binding's approval surface. Where the assessment concludes that a new Mission is proposed, it executes the issuance profile's approval steps: 1. Authenticate the Approver: the resource owner at the authorization server, or the principal whose pre-registered policy the deployment authorizes to decide. 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 requesting party, from claims the authorization server itself gathered and verified (pushed identity claim tokens, interactive claims gathering, or a PCT it previously issued), never from the Mission Intent claim token or other unauthenticated client input. 3. Derive the Authority Set from the Intent, and from the authority proposal where one was pushed (Section 6), and render it for consent on the owner surface under the issuance profile's rendering rules (Section 14.2). 4. Compute the integrity anchors with the authorization server's issuer identifier as the envelope iss. 5. Create the Mission record in the active state atomically with the approval decision. The token endpoint MUST NOT complete a ticket exchange under the Mission before the record is active. Both native assessment outcomes realize the approval event: *Deferred owner decision.* The authorization server returns request_submitted with a rotated permission ticket, and the resource owner decides on the owner surface asynchronously; the client retries under UMA's own discipline. The rotating ticket is the deferral handle (Section 14.1). This is the surface the OAuth binding needs the Mission Deferred Approval companion for ([I-D.draft-mcguinness-oauth-mission-approval]); here it is the substrate's ratified machinery, and that companion does not apply. *Pre-registered policy.* Where the resource owner's standing policy at the authorization server covers the proposal, that policy is the issuance profile's authorized-policy approver: the approval event records the policy identity and version as the Approver context, and the anchors commit as in the interactive case. A deployment SHOULD reserve policy approval for Missions within bounds the owner has expressly pre-consented and route everything else to request_submitted. The need_info rotation loop is the clarification and narrowing surface: the authorization server may require further claims, and the owner or the authorization server may narrow the proposal across rounds while the rotating ticket persists the pending state. That loop is most of the state machine the approval-revision companion defines, native to the substrate ([I-D.draft-mcguinness-oauth-mission-approval-revision]); where a deployment adopts that companion's semantics, the rotated ticket is its revision handle. If the derived Authority Set changes between rendering and consent, the authorization server MUST recompute the anchors and re-obtain consent, per the issuance profile. Mission Consent Evidence composes unchanged, with the authorization server as the committing issuer ([I-D.draft-mcguinness-oauth-mission-consent-evidence]): the owner surface is where the disclosure is rendered, and what was shown is what the evidence commits. 8. Mission Record UMA has no native artifact for what was approved; the Mission record supplies it. A Mission-Bound UMA 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 own issuer identifier (the issuer of its UMA discovery document) and client_id the client's OAuth client identifier. 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. Unlike the AAuth binding, whose substrate carries a native (approver, s256) reference ([I-D.draft-mcguinness-mission-aauth]), UMA has 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 RPT's mission claim or the introspection response (Section 10). No substrate-native commitment exists beside the anchors, and nothing substitutes for them. 9. 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. +==============+================================================+ | Family state | UMA surface | +==============+================================================+ | active | token endpoint serves ticket exchanges and | | | upgrades; introspection reports the RPT active | +--------------+------------------------------------------------+ | completed | token endpoint refuses (request_denied); | | | introspection reports inactive | +--------------+------------------------------------------------+ | revoked | token endpoint refuses (request_denied); | | | introspection reports inactive | +--------------+------------------------------------------------+ | expired | token endpoint refuses (request_denied); | | | introspection reports inactive | +--------------+------------------------------------------------+ | suspended | token endpoint defers (request_submitted); | | | introspection reports inactive | +--------------+------------------------------------------------+ Table 2 The projection is fail-safe: every non-active state projects to a non-permitting native signal. The family surfaces report the distinct state, and the introspection response's mission.state member carries it verbatim (Section 10.1). This binding adds to UMA'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, per the issuance profile. Because resource servers introspect RPTs per use ([UMA-FEDAUTHZ]), revocation takes effect at the next introspection with no further plumbing; a deployment that validates RPTs 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 authorization server commits the Mission to completed with the semantics of the status profile's complete operation. UMA has no native completion wire, so the operation is a family surface. * *Suspension.* A deployment that adopts the status profile's suspended state defers rather than denies: the token endpoint returns request_submitted, so the client waits under UMA's own retry discipline rather than treating the Mission as dead. 9.1. Issuance Gating No RPT exists without the authorization server's token endpoint, so issuance gating is structural, as it is at the AAuth Person Server. On that precondition the authorization server MUST NOT complete a ticket exchange, upgrade an RPT, or otherwise extend authority under a Mission that is not active, and the active check MUST be atomic with issuance. Each RPT issuance and each upgrade counts as one derivation under the Mission; where the Intent's controls.max_derivations is present, the authorization server MUST refuse the derivation that would exceed it, per the issuance profile's count-and-gate rule. An RPT issued under a Mission MUST NOT expire later than the Mission's expires_at, and the exp of each permission within it is likewise capped, so no credential outlives the Mission. Where the deployment adopts Mission Containment ([I-D.draft-mcguinness-oauth-mission-containment]), the authorization server MUST intersect the entire resulting RPT, including any permission carried forward from before a contain transition, with the Mission's current Effective Authority Set ([I-D.draft-mcguinness-oauth-mission-status]) at every ticket exchange and every upgrade. A UMA permission is a resource and its scopes, so the intersection runs at scope grain: the authorization server removes from each permission every scope the Effective Authority Set no longer grants at that resource, and omits the permission only when no scope survives. A result with a surviving scope on any permission issues the RPT with any contained scope removed; a result with no surviving scope on any permission MUST NOT be issued: the authorization server refuses the request, the OAuth error member carrying request_denied accompanied by authority_contained in the mission_denial_reason member, the containment profile's registered denial carrier. 9.2. Mission State Surfaces Per-use introspection is this binding's native state source: a response for an RPT under a Mission carries the mission member with its state (Section 10.1), so a resource server that introspects per [UMA-FEDAUTHZ] learns of revocation at the next access. Its staleness bound is the introspection caching the deployment permits, which the deployment MUST state; with caching disabled the bound is effectively zero. Where the deployment adopts Mission Containment, introspection of an RPT issued or upgraded before a contain transition applies the same scope-grain intersection: for each entry of the introspection response's permissions, the authorization server removes every scope the Effective Authority Set no longer grants at that resource, and omits the entry only when no scope survives. An omitted permission, or a scope removed from a surviving one, is authority the resource server cannot rely on, the same result as an RPT that never carried it. mission.state continues to report active: containment narrows authority without changing Mission state, and per Section 9's active- Mission projection the response's top-level active member ([RFC7662]) MUST remain true while the RPT is otherwise active, whether or not any permission survives intersection: an empty permissions array reports narrowed authority, not a token that has ceased to be valid. Introspection is this binding's continued-reliance surface for containment, and closes the residual a self-contained RPT without a state check cannot ([I-D.draft-mcguinness-oauth-mission-containment]). A deployment whose RPTs are self-contained and validated without introspection loses that source, and MUST either cap RPT lifetime at its declared staleness bound (lifetime-bounded reliance) or serve an active state surface. A Mission-Bound UMA Authorization Server SHOULD serve the Mission Status operation of [I-D.draft-mcguinness-oauth-mission-status], with its signed responses, authentication, anti-oracle property, and caching rules, and MAY emit Mission Lifecycle Signals ([I-D.draft-mcguinness-oauth-mission-signals]) as the transmitting Mission Issuer. A deployment claiming runtime enforcement of the high-consequence classes MUST provide an active freshness source with a published staleness bound ([I-D.draft-mcguinness-mission-runtime]); per-use introspection with a stated cache bound satisfies it, and token lifetime alone does not. An authorization server that serves these surfaces publishes the corresponding members (mission_status_endpoint, mission_status_signing_alg_values_supported, mission_lifecycle_endpoint, mission_event_stream_endpoint, mission_max_stale_seconds) in its UMA discovery document, with the semantics those profiles define; its existing jwks_uri is the published key material for its signed artifacts. 10. Mission-Bound Credential The RPT is this binding's Mission-bound credential. 10.1. The Mission Claim An RPT issued under a Mission names it through the mission claim: the family members id, issuer, and authority_hash as the issuance profile defines them, and it SHOULD carry the expires_at member as the issuance-grant profile defines it ([I-D.draft-mcguinness-oauth-mission-issuance-grant]), a bounding commitment with no liveness. The claim is delivered on one of two carriage surfaces: * *Token-carried*: a deployment issuing JWT-format RPTs carries the claim in the token per the issuance profile. * *Introspection-carried*: a deployment issuing opaque RPTs carries the same object in the mission member of the introspection response, the member the issuance profile registers for [RFC7662], with the state member per that profile's introspection section. FedAuthz's extended introspection object carries it beside permissions unchanged. Both surfaces satisfy the credential primitive; they differ in who verifies what. A token-carried claim verifies offline under the authorization server's published keys; an introspection-carried claim is asserted by the authorization server over the authenticated protection API channel at each use. In both, the Mission reference arrives through token validation itself, so the runtime profile's binding establishment composes credential-carried with no join (Section 11). A consumer MUST NOT use any mission member to grant or widen authority, per the issuance profile. 10.2. Authority Subset and Grain The permissions an RPT carries MUST be a subset of the Mission's Authority Set under the issuance profile's subset rule, projected onto UMA's grain: a permission is a resource and its scopes, so every scope a permission grants MUST correspond to authority the set grants at that resource, and no permission may convey authority, or relaxation of a constraint, that the set does not. Where the deployment adopts Mission Containment, Section 9.1 states the set an RPT is gated against at issuance and upgrade ([I-D.draft-mcguinness-oauth-mission-containment]). The projection is coarse, and this binding does not pretend otherwise. A UMA permission carries no parameter bounds and no consumption bounds: an amount cap on a payment action, argument constraints on a tool call, and the metering companion's cumulative bounds ([I-D.draft-mcguinness-mission-metering]) do not fit a resource_scopes array. Those constraints bind at the runtime layer, where the PDP evaluates each consequential action against the full Authority Set ([I-D.draft-mcguinness-mission-runtime], [I-D.draft-mcguinness-mission-authzen]); the substrate swap leaves that layer untouched (Section 12). An RPT MAY additionally carry Mission-derived authorization details entries per the issuance profile where the deployment's RPT format admits them, under the same subset rule. 10.3. Drawdown and Upgrade The approved Authority Set is a pre-consented ceiling, and each RPT issuance or upgrade is a drawdown within it: the model the progressive companion defines for the OAuth binding ([I-D.draft-mcguinness-oauth-mission-progressive]), which this substrate runs natively. When the client presents a new ticket with its existing RPT and PCT, the authorization server resolves the Mission, checks the requested permissions against the Authority Set, and where they are within it MAY approve by policy without waking the Approver: that adjudication is a drawdown, not a new approval, and the anchors do not change. The upgraded RPT replaces the prior one and stays bounded per Section 9.1. A requested permission outside the Authority Set is an expansion, not a drawdown. The authorization server MUST NOT widen by policy: it routes the request to the Approver (request_submitted), and an approval revises the Mission under the expansion companion's semantics, recomputed anchors included ([I-D.draft-mcguinness-oauth-mission-expansion]). The wire needs nothing new: widening is another ticket the owner must decide. 10.4. Mission Continuity: the PCT The persisted claims token is UMA's continuity artifact: it persists the requesting party's claims across authorization processes and grants nothing; every RPT still passes fresh assessment. That is the family's session-continuity discipline (continuity is never authority, as the harness profile enforces for agent sessions ([I-D.draft-mcguinness-mission-harness])), pre-enforced by the substrate's own design. This binding leans on it: the authorization server SHOULD associate a PCT it issues under a Mission with the mission_id, so a later ticket presented with the PCT resolves the Mission without the client re-pushing the Intent. The PCT is the Mission continuation handle. Continuity is never authority. PCT possession MUST NOT substitute for Mission state, for the subset check, or for any approval; a PCT presented under a non-active Mission yields request_denied (or request_submitted under suspension), and a PCT never widens what assessment would grant without it (Section 14.3). 10.5. Worked Example The introspection response for the upgraded RPT of Section 5, after the document-service drawdown: { "active": true, "exp": 1793610000, "permissions": [ { "resource_id": "finance-q3-ledger", "resource_scopes": ["invoices.read", "adjustments.post"], "exp": 1793610000 }, { "resource_id": "board-reports", "resource_scopes": ["documents.write"], "exp": 1793610000 } ], "mission": { "id": "msn_4Xq7NvR2pTb8Kd1zYw6mA3f5", "issuer": "https://as.example.com", "authority_hash": "sha-256:Qm4dSrX0kJc2uJ9pVzWfY7hTgD1eN8oLxCAiRb63EMk", "expires_at": "2026-12-31T23:59:59Z", "state": "active" } } The permissions member is FedAuthz's, unchanged; the mission member is the issuance profile's registered introspection member. The two permissions are the scope-grain projection of the Mission's Authority Set entries at each resource server; the amount bound on adjustments.post does not appear, because UMA's grain cannot carry it, and it binds at the runtime layer instead (Section 10.2). 11. 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 both token-carried and introspection- carried RPT modes. The contextual-governance kernel maps as follows: 1. *Mission Reference*: the tuple (issuer, mission_id) names one record. issuer is the authorization server issuer from UMA discovery; mission_id follows the issuance profile's uniqueness, retention, comparison, and non-reassignment rules (Section 8). 2. *Controller*: the UMA authorization server controls approval, state, assessment, and RPT issuance. Consumers establish it from the UMA discovery document and its configured trust relationship; jwks_uri publishes verification keys for signed artifacts (Section 9.2). 3. *Actor binding*: the UMA client is the Actor and its authenticated OAuth client identifier is recorded as client_id. The token endpoint establishes it from client authentication, not the pushed Intent. Later RPT issuance and validation use UMA's ordinary client binding; the separately established requesting party is the Mission Subject (Section 4, Section 7, Section 10). 4. *Approved Context*: the immutable Mission Intent, the recorded authority proposal where one was pushed, and the derived Authority Set in the Mission record are the Approved Context. The family intent_hash and authority_hash, plus proposal_hash where a proposal was pushed, commit them under the issuance profile's canonicalization; they are this binding's chosen mechanism, not a substrate-kernel requirement (Section 8). 5. *Approval ceremony*: UMA authorization assessment performs the five approval steps in either the deferred owner-decision or pre- registered-policy mode and creates the record active atomically with approval (Section 7). 6. *Governance gate*: only the issuance profile's active state is active. Every other or unrecognized value fails closed at the token endpoint and introspection projection. The Subject, Approver, and administrator have an authenticated revocation path (Section 9, Section 9.1). 7. *Reliance bound*: RPT issuance and upgrade establish active at the token endpoint. An opaque RPT is bounded by authenticated per-use introspection; a self-contained RPT without a state check remains usable only for its bounded lifetime after a transition (Section 9.1, Section 10.1, Section 9.2). 8. *Context propagation*: the protected mission claim in a self- contained RPT, or the authenticated introspection response for an opaque RPT, carries the Mission Reference and credential association. The PCT carries continuity only and never establishes Mission governance or authority (Section 10.1, Section 10.4). 9. *Governance record*: the assessment log is the ordered governance record. The authorization server MUST append approval, positive and negative Mission-dependent token decisions, 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 Statement's capability table follows, one row per capability; every supplied row states its activation conditions, and its temporal and failure elements in its cells or by express inheritance of the Bounded Reliance floor ([I-D.draft-mcguinness-mission-substrate]): +=============+========+=============+================+=============+ |Capability |Claim |Activation |Scope and |Limitations | | | | |defining | | | | | |sections | | +=============+========+=============+================+=============+ |Lifecycle- |supplied|always |RPT issuance |A self- | |Gated | | |and upgrade are |contained RPT| |Authorization| | |state-gated; |without a | | | | |introspection |state check | | | | |gates continued |remains | | | | |reliance |usable only | | | | |(Section 9.1, |for its | | | | |Section 9.2) |bounded | | | | | |lifetime | +-------------+--------+-------------+----------------+-------------+ |State- |supplied|authenticated|Those surfaces, |A self- | |Observable | |per-use |within their |contained RPT| | | |introspection|declared bounds |validated | | | |with a | |only to its | | | |deployment- | |exp is not | | | |declared | |state | | | |cache bound, | |observation; | | | |or Mission | |token | | | |Status active| |lifetime | | | |(Section 9.2)| |alone is not | | | | | |observation | +-------------+--------+-------------+----------------+-------------+ |Structured |supplied|always |The Authority |UMA | |Authority | | |Set is the |permissions | | | | |approved |cannot carry | | | | |representation; |parameter or | | | | |UMA permissions |consumption | | | | |are its |constraints | | | | |resource/scope | | | | | |projection | | | | | |(Section 10.2) | | +-------------+--------+-------------+----------------+-------------+ |Monotonic |supplied|always |The token |Applies to | |Derivation | | |endpoint |the declared | | | | |applies the |Authority Set| | | | |issuance |projection, | | | | |profile's no- |not arbitrary| | | | |broader-than |UMA policy | | | | |relation at RPT |values | | | | |issuance and | | | | | |upgrade | | | | | |(Section 10.2, | | | | | |Section 10.3) | | +-------------+--------+-------------+----------------+-------------+ |Credential- |supplied|a protected |One RPT, Actor, |Introspection| |Bound | |RPT claim, or|and Mission |carriage is | | | |authenticated|Reference |an online | | | |introspection|associated at |issuer | | | |(Section |issuance; fact |assertion, | | | |10.1) |semantics: |not offline | | | | |issuance under |proof | | | | |the Mission | | +-------------+--------+-------------+----------------+-------------+ |Authorized |not |-- |-- |The | |Context |supplied| | |authorization| |Correlation | | | |server co- | | | | | |establishes | | | | | |the RPT, | | | | | |Actor, and | | | | | |Mission | | | | | |Reference at | | | | | |issuance; no | | | | | |authoritative| | | | | |join of | | | | | |independently| | | | | |established | | | | | |facts is | | | | | |defined | +-------------+--------+-------------+----------------+-------------+ |Independently|supplied|self- |A signed self- |Signed Status| |Verifiable | |contained |contained RPT |alone proves | | | |signed RPTs, |proves issuance |nothing about| | | |or signed |under the |any | | | |Mission |Mission, |particular | | | |Status |offline; a |RPT's | | | |(Section |signed Mission |issuance; | | | |10.1, |Status response |opaque RPT | | | |Section 9.2) |proves record |introspection| | | | |and state |is online | | | | |properties as | | | | | |of its | | | | | |observation | | | | | |window; each | | | | | |activation | | | | | |supplies | | | | | |exactly its own | | | | | |half | | +-------------+--------+-------------+----------------+-------------+ |Portable |supplied|Consent |The adopted |The base | |Evidence | |Evidence, a |profile's |assessment | | | |Mission |artifact and |log is | | | |Mandate, or |verification |Controller- | | | |Audit |procedure |local and is | | | |Transparency | |not portable | | | |adopted | |evidence | +-------------+--------+-------------+----------------+-------------+ Table 3: UMA Mission substrate capabilities Each supplied row's temporal elements inherit the gating contract unless stated: freshness is established at the state-gated operation or at introspection within its declared cache bound, artifact lifetime is the RPT's expiry capped by the Mission's expires_at, and the residual after non-active is the remaining self-contained RPT lifetime or the introspection cache bound. Failure behavior is uniformly fail-closed: an unavailable or invalid introspection or Status surface refuses the rows that activate on it (an opaque RPT whose introspection is unavailable is denied, never extended); an incomparable permission projection refuses issuance or upgrade; a stale observation past its window is no observation. The Portable Evidence condition is supplied only when the deployment adopts Consent Evidence ([I-D.draft-mcguinness-oauth-mission-consent-evidence]), a Mission Mandate ([I-D.draft-mcguinness-mission-mandate]), or Audit Transparency ([I-D.draft-mcguinness-mission-audit]); the referenced profile defines the portable artifact and verification procedure. The composition consequences: * The runtime profile and its AuthZEN binding compose against either carriage surface: the Mission reference arrives through token validation (JWT claims, or the issuer's introspection response that validates the opaque RPT), so binding establishment is credential-carried in both (Section 10.1). The constraint grain UMA cannot carry is exactly what they enforce (Section 10.2). * 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 UMA has no actor chain. A sub-agent operates as its own UMA client under its own ticket exchanges; UMA-native Child Mission creation is deferred work. * Offline attenuation does not apply: every RPT is issuer-minted, and UMA defines no offline mint ([I-D.draft-mcguinness-oauth-mission-attenuation]). * Cross-domain projection is not provided: FedAuthz 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]). FedAuthz's federation does mean one Mission natively governs many resource servers within the authorization server's own trust domain, the multi-resource-server case the flow shows (Section 5). * Mission Containment composes at the token endpoint: RPT issuance and upgrade gate on the Effective Authority Set, and per-use introspection applies the same filtering to an RPT issued or upgraded before a contain transition ([I-D.draft-mcguinness-oauth-mission-containment], Section 9.1, Section 10.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. 12. Limitations *Authority grain.* UMA's unit of authority is the permission, a resource and its scopes. The Authority Set's parameter-bound actions and consumption bounds cannot ride it, so the RPT is always a coarse projection, and the runtime layer carries the constraint enforcement this family treats as load-bearing (Section 10.2). The substrate swap replaces approval and issuance plumbing; it does not move the action chokepoint. *Attempt-triggered approval.* The approval moment is the first ticket exchange, not a moment the client chooses before acting. The whole- task Intent rule (Section 6) preserves compile-once, but the Approver decides when the agent first collides with a protected resource. A deployment that wants approval before the run starts fronts the flow with a deliberate first attempt, or uses an intent-first binding. *Substrate reach.* Both UMA documents are final Kantara Initiative Recommendations, so this binding adds no unratified dependency: the trade is the reverse of the AAuth binding's, which tracks an unratified individual draft with an active community ([I-D.draft-mcguinness-mission-aauth]). What UMA lacks is deployed breadth. This binding governs estates that already run UMA; it does not create them, and a deployment without a UMA substrate has no reason to adopt one for the Mission's sake, since the OAuth binding exists. 13. Conformance An implementation conforms in one of two roles. Resource servers participate through unmodified [UMA-FEDAUTHZ] and have no role to claim. A *Mission-Bound UMA Authorization Server*: * accepts the Mission Intent claim token format and bounds it as untrusted input (Section 6); * executes the approval event on its assessment surface in both native decision modes, creating the record active atomically with the decision and computing the anchors (Section 7, Section 8); * operates the lifecycle of Section 9: authenticated revocation by mission_id, expiry, completion, fail-safe projection onto token- endpoint outcomes, and the only-active gate atomic with every issuance and upgrade (Section 9.1); * issues RPTs as Mission-bound credentials on a declared carriage surface, applies the subset rule at every issuance and upgrade, and routes out-of-set requests to the Approver (Section 10); * where it adopts Mission Containment, intersects the entire resulting RPT, including permissions carried forward from before a contain transition, with the Effective Authority Set at every issuance and upgrade, at scope grain: removes from each permission every scope the set no longer grants and omits the permission only when no scope survives; and refuses a result with no surviving scope on any permission, the OAuth error member carrying request_denied accompanied by authority_contained in the mission_denial_reason member ([I-D.draft-mcguinness-oauth-mission-containment], Section 9.1); * applies the same scope-grain filtering to per-use introspection of an RPT issued or upgraded before a contain transition, and reports the introspection response's top-level active member true while the RPT is otherwise active regardless of whether any permission survives (Section 9.2); * associates PCTs with Missions as continuity, never authority (Section 10.4); * serves Mission state with a declared staleness bound per Section 9.2, and retains the record and assessment log for the audit horizon; and * publishes its Mission surfaces in its UMA discovery document. A *Mission-Bound UMA Client*: * pushes a whole-task Mission Intent on the first ticket exchange under a prospective Mission, and treats every proposal as a proposal, never as authority (Section 6); * follows UMA's retry discipline under request_submitted and need_info, and stops on request_denied; * presents the PCT for continuity and never treats it, the ticket, or mission_id as a credential; and * proposes completion when the task is done, where the deployment serves the completion operation. 14. Security Considerations 14.1. The Ticket as Deferral Handle Between request_submitted and the owner's decision, the rotating permission ticket is the only artifact binding the client to the pending approval: the role the deferral code plays in the Mission Deferred Approval companion ([I-D.draft-mcguinness-oauth-mission-approval]). UMA's ticket properties (single-use, unguessable, rotated on every response) are load-bearing for the approval's integrity, and an authorization server MUST maintain them across the rotation loop. A replayed or long-lived ticket would let a stale or hijacked exchange complete against a decision the owner made about a different pending state. 14.2. Rendering the Proposal The Mission Intent, its goal text, and every justification are attacker-influenceable input rendered on the owner surface. The issuance profile's rendering rules apply unchanged: render client text inert and sanitized, mitigate direction-override and confusable- character presentation, and keep the derived Authority Set visually distinct from client-supplied narrative, so crafted text cannot pass as derived authority. 14.3. The PCT Is Not Authority The PCT is a bearer continuity artifact held by the client. Its theft replays claims continuity, not authority: assessment still runs, state still gates, and the subset rule still bounds. An authorization server MUST keep it that way; an optimization that lets a PCT skip state evaluation or the subset check converts a continuity token into a credential and breaks the family's continuity discipline (Section 10.4). UMA's own PCT rules on client binding and rotation apply. 14.4. Authorization Server Compromise A compromised authorization server is a compromised Mission Issuer: forged approvals, arbitrary RPTs, false state ([I-D.draft-mcguinness-mission-security-model]). UMA concentrates approval, issuance, introspection, and the owner surface in one service, so the security model's concentration analysis for the OAuth binding applies in full. Consent evidence and audit transparency make forgery detectable after the fact; they do not prevent it. 14.5. Introspection as the State Channel Where opaque RPTs make introspection the Mission and state channel, the channel's authentication (the PAT) and its caching policy carry this binding's freshness claims. A resource server that caches introspection responses beyond the deployment's declared staleness bound turns fail-closed rules fail-open in effect; a deployment MUST size PAT protection and cache bounds to what its Mission Deployment Profile claims. Self-contained RPTs move the same weight onto token lifetime (Section 9.2). 15. Privacy Considerations *The task concentrates at the authorization server.* The whole-task Intent rule sends the full task description to the authorization server at the first exchange, earlier and more completely than per- slice operation 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.* An opaque RPT shows a resource server only the permissions relevant to it plus the mission introspection members; the Intent, the constraints, and the rest of the Authority Set stay at the authorization server. This is the minimization property the AAuth binding notes for its blob, achieved here by UMA's own architecture. *The PCT is a correlation handle.* UMA already names the PCT a correlation surface across authorization processes; associating it with a mission_id (Section 10.4) adds Mission correlation at the authorization server only, and nothing new crosses to resource servers. mission_id itself correlates the Mission's activity across resource servers through introspection responses, the issuance profile's deliberate stable-anchor property; that profile's guidance applies. 16. IANA Considerations This document has no IANA actions. The mission introspection response member and the mission JWT claim are registered by the issuance profile; UMA claim_token_format identifiers are URIs with no registry, and the identifier of Section 6 is under this document's control. 17. References 17.1. Normative References [I-D.draft-mcguinness-mission-substrate] McGuinness, K., "Mission Substrate Requirements", 2026, . [I-D.draft-mcguinness-oauth-mission] McGuinness, K., "Mission-Bound Authorization for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-issuance-grant] McGuinness, K., "Mission Issuance Grant for OAuth 2.0", 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [UMA-FEDAUTHZ] Maler, E., Machulak, M., and J. Richer, "Federated Authorization for User-Managed Access (UMA) 2.0", Kantara Initiative Recommendation, 2018, . [UMA-GRANT] Maler, E., Machulak, M., and J. Richer, "User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization", Kantara Initiative Recommendation, 2018, . 17.2. Informative References [I-D.draft-mcguinness-mission-aauth] McGuinness, K., "Mission Context Binding for AAuth", 2026, . [I-D.draft-mcguinness-mission-architecture] McGuinness, K., "An Architecture for Mission-Bound Authorization", 2026, . [I-D.draft-mcguinness-mission-audit] McGuinness, K., "Mission Audit Transparency", 2026, . [I-D.draft-mcguinness-mission-authority-server] McGuinness, K., "Mission Authority Server", 2026, . [I-D.draft-mcguinness-mission-authzen] McGuinness, K., "Mission-Bound Runtime Enforcement: AuthZEN Profile", 2026, . [I-D.draft-mcguinness-mission-harness] McGuinness, K., "Mission-Aware Agent Harnesses", 2026, . [I-D.draft-mcguinness-mission-mandate] McGuinness, K., "Mission Mandate", 2026, . [I-D.draft-mcguinness-mission-metering] McGuinness, K., "Mission Consumption Metering", 2026, . [I-D.draft-mcguinness-mission-runtime] McGuinness, K., "Mission-Bound Runtime Enforcement", 2026, . [I-D.draft-mcguinness-mission-security-model] McGuinness, K., "Mission Security Model", 2026, . [I-D.draft-mcguinness-mission-shaping] McGuinness, K., "Mission Intent Shaping", 2026, . [I-D.draft-mcguinness-oauth-mission-approval] McGuinness, K., "Mission Deferred Approval for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-approval-revision] McGuinness, K., "Mission Approval Revision for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-attenuation] McGuinness, K., "Mission Offline Attenuation for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-child-delegation] McGuinness, K., "Mission Child Delegation for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-consent-evidence] McGuinness, K., "Mission Consent Evidence for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-containment] McGuinness, K., "Mission Containment for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-cross-domain] McGuinness, K., "Mission Cross-Domain Projection for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-expansion] McGuinness, K., "Mission Expansion for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-progressive] McGuinness, K., "Mission Progressive Authorization for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-signals] McGuinness, K., "Mission Lifecycle Signals for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-status] McGuinness, K., "Mission Status and Lifecycle for OAuth 2.0", 2026, . Acknowledgments This document is part of the Mission-Bound Authorization work. It binds the Mission model to the User-Managed Access 2.0 authorization server, and builds on the Mission Substrate Requirements, Mission Status and Lifecycle, and Mission-Bound Runtime Enforcement companions. UMA's requesting-party asymmetry, deferred owner decisions, and continuity-without-authority anticipated the geometry agents now present; this binding supplies the approved object those mechanics were built to move. Author's Address Karl McGuinness Independent Email: public@karlmcguinness.com