Mission-Bound Authorization for UMA 2.0

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 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

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

2. Mission Roles

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

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

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

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

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

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

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 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 4), and render it for consent on the owner surface under the issuance profile's rendering rules (Section 12.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 12.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.¶

6. 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 8). No substrate-native commitment exists beside the anchors, and nothing substitutes for them.¶

7. 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 family surfaces report the distinct state, and the introspection response's mission.state member carries it verbatim (Section 8.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.¶

8. Mission-Bound Credential

The RPT is this binding's Mission-bound credential.¶

{
  "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"
  }
}

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

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 7.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 2, Section 5, Section 8).¶

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

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

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 7, Section 7.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 7.1, Section 8.1, Section 7.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 8.1, Section 8.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]):¶

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 8.1). The constraint grain UMA cannot carry is exactly what they enforce (Section 8.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 3).¶

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

10. 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 8.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 4) 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.¶

11. 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 4);¶

• 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 5, Section 6);¶

• operates the lifecycle of Section 7: 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 7.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 8);¶

• 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 7.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 7.2);¶

• associates PCTs with Missions as continuity, never authority (Section 8.4);¶

• serves Mission state with a declared staleness bound per Section 7.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 4);¶

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

12. Security Considerations

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

14. 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 4 is under this document's control.¶

15. References

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