Mission Transaction Authorization Profile for OAuth 2.0

Status of This Memo

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

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

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

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

An agent's Mission can carry actions whose consequence warrants more than the Mission's own approval and more than a stronger authentication context. Cross-organizational delegation sharpens the requirement: [I-D.draft-reece-wimse-cross-org-delegation] describes delegated work that must remain subject to execution-time human authorization, bound to the concrete action, parameters, resource, on-behalf-of principal, and authorized presenter, surviving delegation, and usable at most once, without a live call back to the approval authority on the execution path.¶

The Mission family already supplies the policy model: the Common Constraint requires_action_approval ([I-D.draft-mcguinness-oauth-mission]) designates an action as requiring a fresh approval and is monotonic under the subset rule, and Mission Runtime's action-bound approval ([I-D.draft-mcguinness-mission-runtime]) defines concrete-parameter binding, a maximum age, a fresh decision, and atomic consumption. What neither defines is the portable wire workflow that carries an approval across a trust boundary to a resource that must enforce locally. This document supplies that workflow as a profile of the OAuth transaction authorization challenge [I-D.draft-rosomakho-oauth-txn-challenge]. The profile keeps that protocol's challenge type, request and response parameters, capability signal, endpoint, and asynchronous polling whole; it adds the Mission-profiled challenge claims, the credential carried to the transaction endpoint, Mission and authority validation, approval as decision input, the fresh decision, and the transaction-token profile.¶

The approval is not authority. The transaction token is authority because a trusted issuer minted it after a fresh decision bounded by the Mission and the approved operation.¶

This profile is the strict-delta consumer of the upstream protocol; engagement with that protocol's own evolution proceeds through the family's coordination process, outside this document.¶

2. Status: An Optional Extension

This document is optional. A deployment that satisfies action-bound approval by another means, a synchronous local decision, a bespoke callback, or no cross-organizational case at all, is fully conformant to the issuance profile and the runtime profile and is unaffected by this document. It places no new requirement on either.¶

A deployment claims this profile only when it carries action-bound approval across a trust boundary through the transaction challenge and token defined here. The Mission, its Authority Set, the subset rule, and requires_action_approval are unchanged; this document governs only the portable wire result that a resource and a Transaction Authorization Server exchange to satisfy an action-bound approval requirement.¶

This profile tracks an in-progress substrate. It depends normatively on the OAuth transaction authorization challenge ([I-D.draft-rosomakho-oauth-txn-challenge]), an early Internet-Draft that is not ratified and whose details may change, so this profile is not yet a stable interface and will track the substrate as it evolves. It reuses, without restating, the upstream challenge type, parameters, endpoint, and polling states, and the Mission's own mission claim, requires_action_approval, parameter_digest, and act delegation chain exactly as those documents define them. Action-bound approval within a single trust domain, which needs only the runtime profile, is the stable path; deploy this profile for evaluation rather than as a stable interface. This document is Experimental for that reason, tracking its substrate and crossing to the stable tier by reclassification when the substrate does.¶

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

This document uses Mission, Authority Set, Approver, Mission Issuer, mission_resource_access, and the subset rule as the issuance profile defines them ([I-D.draft-mcguinness-oauth-mission]); action-bound approval, the Operation Profile, parameter_digest, and Mission state freshness as the runtime profile defines them ([I-D.draft-mcguinness-mission-runtime]); the envelope anchor, canonical-object digest, and raw-octet digest species of the default commitment construction as the substrate defines them ([I-D.draft-mcguinness-mission-substrate]); and the transaction authorization challenge, its claims, its endpoint, and its pending and polling states as the OAuth transaction authorization challenge defines them ([I-D.draft-rosomakho-oauth-txn-challenge]).¶

Transaction Authorization Server (TAS):

The OAuth Authorization Server acting in the role [I-D.draft-rosomakho-oauth-txn-challenge] defines for the transaction authorization endpoint: it validates the challenge, applies the Mission validation and fresh-decision rules of this profile, and mints the transaction token. A TAS instance MAY be the Mission Issuer itself or an Authorization Server deployed separately from it; this profile does not require either arrangement.¶

Challenge-Issuing Resource:

The protected resource of [I-D.draft-rosomakho-oauth-txn-challenge] in this profile: it normalizes the requested operation, computes its parameter_digest, and signs the transaction challenge with the Mission-profiled claims of Section 5.¶

Presenting Client:

The client of [I-D.draft-rosomakho-oauth-txn-challenge] in this profile: it holds the challenge's confirmation key, obtains the transaction token from the TAS, and presents the token to the Challenge-Issuing Resource for execution.¶

Transaction challenge:

The transaction_challenge of [I-D.draft-rosomakho-oauth-txn-challenge], typed txn-authz-challenge+jwt, profiled by Section 5 with the Mission-profiled claims.¶

Transaction token:

The sender-constrained, single-audience, single-use JWT the TAS mints of Section 7, typed application/mission-txn-token+jwt.¶

4. Applicability

This profile is invoked when any of these requires action-bound approval for a normalized operation:¶

• the matched Authority Set entry carries constraints.requires_action_approval: true;¶

• destination resource policy requires approval for the action or risk class; or¶

• a current local entitlement or governance rule requires it.¶

A delegated child MUST preserve requires_action_approval: true under the Common Constraints subset rule of [I-D.draft-mcguinness-oauth-mission]. false remains equivalent to omitting the member and cannot override a true ancestor. This profile defines no second approval constraint: requires_action_approval stays the only Authority Set designation this profile reads.¶

Step-up authentication is not a substitute. A step-up obligation ([RFC9470]) proves a stronger authentication context; it does not approve the transaction, and a Transaction Authorization Server MUST NOT treat a step-up context alone as satisfying an action-bound approval requirement. A durable role or relationship grant produced by a governance decision is also not an approval token: it becomes current governance state, and the fresh decision of Section 6 re-evaluates it like any other current policy input rather than consuming it as the approval itself.¶

5. Resource Challenge

After receiving an ordinary Mission-bound request for an action that falls under Section 4, the Challenge-Issuing Resource normalizes the operation under its Operation Profile and computes the runtime parameter_digest ([I-D.draft-mcguinness-mission-runtime]). When no valid transaction token is presented, the resource signals and returns a transaction authorization challenge exactly as the upstream protocol defines: the client's Accept-Txn-Challenge header gates the signal, the transaction_authorization_required error and transaction_challenge parameter carry the challenge, and the challenge is a JWT with protected header typ txn-authz-challenge+jwt ([I-D.draft-rosomakho-oauth-txn-challenge] Sections 4.1, 4.2, and 4.2.1). This document does not restate that mechanism.¶

The challenge's REQUIRED claims iss, aud, iat, exp, jti, txn, authorization_details, and reason, and its OPTIONAL act and reason_uri, are exactly as [I-D.draft-rosomakho-oauth-txn-challenge] Section 4.2.2 defines them. authorization_details carries exactly one operation-scoped mission_resource_access entry ([I-D.draft-mcguinness-oauth-mission]) or one compound-action detail whose registered semantics make the operation atomic. The Operation Profile a TAS and the resource apply resolves deterministically from the challenge's iss and that entry's type member ([RFC9396]): a resource versions its Operation Profile by versioning type, and a TAS MUST retain and recognize a superseded Operation Profile version for as long as a pending workflow still references it.¶

This profile adds the following REQUIRED challenge claims:¶

mission:

REQUIRED. Copied from the verified Mission-bound access token, unchanged, including the invariant origin principal (mission.subject) where the Origin Principal profile applies ([I-D.draft-mcguinness-oauth-mission-cross-domain]).¶

parameter_digest:

REQUIRED. Computed exactly as the runtime profile specifies ([I-D.draft-mcguinness-mission-runtime]); this document defines no second canonicalization.¶

cnf:

REQUIRED. The presenter key [RFC7800] to which the resulting transaction token must be bound.¶

The resource MUST derive mission, parameter_digest, and cnf from the request and the verified Mission-bound access token, and MUST NOT accept a client-supplied replacement for any of them.¶

Raw action parameters SHOULD remain outside the challenge when the TAS can decide from parameter_digest plus privacy-preserving attributes. Where a decision needs the normalized operation itself, this profile's one resource-controlled retrieval mechanism is the upstream reason_uri claim: dereferencing it, over a channel authenticated to the Challenge-Issuing Resource, returns the normalized operation bound to txn, the challenge jti, and parameter_digest; the party relying on the retrieved operation MUST recompute parameter_digest against it before relying on it. This document defines no second, unspecified attribute channel.¶

6. Challenge Redemption and Approval

The Presenting Client submits the challenge to the transaction_authorization_endpoint exactly as [I-D.draft-rosomakho-oauth-txn-challenge] Section 5.1 defines: client_id where required, and the signed transaction_challenge. This profile adds two REQUIRED parameters that carry the Mission-bound access token as an assertion, under [RFC8693] Sections 2.1 and 3:¶

subject_token:

REQUIRED. The Mission-bound access token.¶

subject_token_type:

REQUIRED. urn:ietf:params:oauth:token-type:access_token.¶

The request also carries proof of possession of the challenge's cnf key, using DPoP [RFC9449] or mTLS [RFC8705], the same mechanism Section 7 binds the resulting token to. A holder-mediated cross-organizational delegation Chain is not an acceptable subject_token for this version of the profile; presenting one at the transaction endpoint returns once this profile defines its own subject_token_type and presentation binding for the Chain Presentation the cross-organizational delegation profile serializes ([I-D.draft-mcguinness-oauth-mission-cross-org-delegation]).¶

The TAS authenticates the Presenting Client and validates the challenge exactly as [I-D.draft-rosomakho-oauth-txn-challenge] Sections 5.1 and 4.6 require. This profile adds, in order:¶

1. validating subject_token's audience against the challenge's iss and its cnf against the proof of possession presented on this request, establishing that the presented Mission-bound access token was issued for the challenged resource and is held by the party presenting the challenge;¶

2. requiring exact equality between the challenge's mission and subject_token's mission invariants;¶

3. establishing that the challenge's authorization_details is within subject_token's Authority Set under the subset rule ([I-D.draft-mcguinness-oauth-mission]) and applies to the challenge's iss and resource;¶

4. enforcing requires_action_approval and destination resource policy;¶

5. obtaining or resolving a governed approval from an acceptable independent Approver or policy authority, bound to txn, the operation identity, parameter_digest, the resource, the Mission, the destination-local subject and, where the Origin Principal profile applies ([I-D.draft-mcguinness-oauth-mission-cross-domain]), the issuer-qualified origin principal, and the presenter key;¶

6. verifying the approval's status, scope, grant time, maximum age, and approved_until; and¶

7. running a fresh authorization decision using the verified approval as context together with current Mission state, subject_token validity, client and key binding, resource policy, and the concrete parameter inputs or attributes; the decision consumes the destination-local subject and, where present, the issuer-qualified origin principal as distinct inputs and revalidates their current mapping and entitlement.¶

Any denial ends the flow. Completion of step 6 alone MUST NOT trigger token issuance and MUST NOT bypass step 7.¶

An approval obtained under step 5 SHOULD carry the shape of an AuthZEN Access Request and Approval Profile approval object ([ARAP]); steps 6 and 7 mirror the checks the AuthZEN binding applies to that object when it is presented as decision input, never as a bearer bypass ([I-D.draft-mcguinness-mission-authzen]). Where an Approval Governance Record backs the decision, that record is the authoritative provenance of who approved and under what authority ([I-D.draft-mcguinness-mission-approval-governance]); this document neither restates nor requires it.¶

7. Transaction Token

On permit, the Transaction Authorization Server issues a JWT with protected header typ mission-txn-token+jwt (Section 13). This is its own JWT access-token profile with the complete validation semantics below; it does not conform to [RFC9068], and a Resource Server that recognizes only at+jwt correctly rejects it as unknown. A deployment wanting RFC 9068 interoperability instead relies on the upstream txn claim carried by an ordinary JWT access token ([I-D.draft-rosomakho-oauth-txn-challenge] Section 6); that is not this profile's shape. Its claims:¶

iss, iat, exp, jti:

REQUIRED, standard JWT claims [RFC7519].¶

aud:

REQUIRED. A singleton, exactly the verified challenge's iss. Never a list and never any other value.¶

sub:

REQUIRED. The destination-local subject, derived from the verified issuer-qualified identity of the presented subject_token under the establishment and revalidation rules of Section 6.1 and the namespace contract of Section 6.1.1: the pinned subject those rules produced at admission and reconfirmed at completion, never a value derived a second way at minting time. Where the Origin Principal profile applies ([I-D.draft-mcguinness-oauth-mission-cross-domain]), the issuer-qualified origin principal travels in mission.subject, alongside the local subject and never in place of it. Never the Approver.¶

client_id:

REQUIRED. The client authenticated at the transaction endpoint ([RFC8693] Section 4.3). The upstream client and the executing agent MAY be different parties; this claim identifies the former.¶

act:

REQUIRED whenever requester or actor context existed on subject_token or the challenge; otherwise absent. Present under the same conditions and structure as the issuance profile's act chain ([I-D.draft-mcguinness-oauth-mission], Section "Delegation Within a Mission"; the OAuth Actor Profile [I-D.draft-mcguinness-oauth-actor-profile] remains the structural reference). The chain is attribution, never authority: it names who acted, for audit and as policy input, and grants nothing by itself. Actor proofs and receipts, where a deployment carries them, stay off this token; they ride subject_token or the delegation context the TAS verified at redemption (Section 6), never the transaction token itself.¶

txn:

REQUIRED. Copied unchanged from the verified challenge.¶

authorization_details:

REQUIRED. The exact permitted entry, never wider than the challenge, subject_token's Authority Set, or the fresh decision of Section 6.¶

parameter_digest:

REQUIRED. Copied only after recomputation and verification against the challenge's value.¶

mission:

REQUIRED. The Mission claim's profiled members, value-equal to the verified challenge's mission. The transaction token is a freshly signed JWT; this is value equality of the profiled members, not byte preservation of a carried artifact.¶

cnf:

REQUIRED. Bound to the verified presenter key, DPoP [RFC9449] (cnf.jkt) or mTLS [RFC8705] (cnf.x5t#S256), equal to the challenge's cnf and the proof verified at redemption.¶

The token MUST NOT carry a generic approval object, a single_use boolean, raw rendered approval text or action parameters, roles or relationships conferred by an approval workflow, or evidence objects whose lifecycle and disclosure rules belong to the evidence and audit profiles. It MUST NOT carry a refresh token, a delegation grant, or token-exchange input, and MUST NOT be accepted as a general Mission-bound access token for any purpose beyond the challenged operation.¶

The token's exp MUST be no later than the earliest of: approval freshness or approved_until; subject_token's own validity; Mission expiry; the pending workflow's remaining lifetime (Section 6.2); and deployment maximum. It is never bounded by the already-consumed challenge exp. A short token lifetime limits stale-policy and revocation exposure but does not replace the point-of-use state checks Section 8 requires.¶

8. Offline Verification and Execution

The Challenge-Issuing Resource verifies the transaction token locally, without calling the Transaction Authorization Server on the request path:¶

1. exact token typ, trusted issuer and signature, intended aud, iat and exp, and token class;¶

2. cnf proof by the current presenter;¶

3. equality of txn, the mission invariants, the operation authorization_details, and the recomputed parameter_digest with the pending operation;¶

4. origin principal, local subject, and actor consistency under the principal profile in effect ([I-D.draft-mcguinness-oauth-mission-cross-domain]);¶

5. current local policy, principal entitlement, and that the challenged operation remains within the Mission's current Effective Authority Set, observed through a full audience-scoped Mission Status Response, containment- and discharge-aware issuer token introspection, or an equivalent authenticated, versioned authority source that reflects every relevant authority_changed update, each within its declared freshness bounds; the Status List MAY serve as a lifecycle prefilter only and MUST NOT alone satisfy this step, since its two-bit reliance state does not observe containment or discharge ([I-D.draft-mcguinness-oauth-mission-status], [I-D.draft-mcguinness-oauth-mission-signals], [I-D.draft-mcguinness-mission-runtime]); and¶

6. atomic first use of the resource-scoped txn in the consumption domain; a second, distinct token jti presented for an already-consumed txn is the same replay and MUST be refused, never executed as a new attempt.¶

The Effective Authority Set belongs to the Mission and is evaluated at the point of use, not carried by the token: an active Mission observed before containment or discharge narrowed the set does not satisfy step 5. The transaction token transports a bounded, action-bound approval and never substitutes for the Mission's current authority, applicable Resource policy, or consumption state.¶

Consumption of txn MUST be linearizable across every replica capable of executing the same operation, meeting the metering companion's Exact enforcement profile ([I-D.draft-mcguinness-mission-metering]): the record commits before the irreversible effect, or atomically with it where the operation store supports that transaction. If the consumption store is unavailable, the resource MUST fail closed for this profile.¶

txn identifies the resource transaction and is the atomic consumption key; challenge jti identifies one admission into a workflow; transaction_authorization_id (or the ARAP task handle backing it) identifies one pending workflow; token jti identifies one issuance from that workflow, not the one execution; and the Operation Profile's idempotency key identifies one effect. At most one authorization result exists per accepted workflow: repeated polling after a decision returns the same token or result stably, and a TAS MUST NOT mint a second token, under a different jti, for a txn whose workflow already produced one. An ambiguous retry looks up the prior result along this chain, from txn and token jti to the workflow to the idempotency key, and the resource returns duplicate_suppressed as the runtime profile defines it ([I-D.draft-mcguinness-mission-runtime]) rather than executing again. A genuinely new attempt requires a new challenge, a new workflow, a new token, and a new idempotency key.¶

9. Evidence and Audit

This document defines no evidence object of its own. The approval service or TAS records Approval Governance and, where configured, Consent Evidence state ([I-D.draft-mcguinness-mission-approval-governance], [I-D.draft-mcguinness-oauth-mission-consent-evidence]); the fresh decision and the executing resource emit Decision Evidence and Execution Evidence under the runtime evidence profile ([I-D.draft-mcguinness-mission-runtime-evidence]), which a Mission Receipt may summarize ([I-D.draft-mcguinness-mission-runtime]); and where durable independent proof is required, the audit profile registers the relevant evidence ([I-D.draft-mcguinness-mission-audit]). These records correlate by the Mission reference, txn, the transaction token's jti, parameter_digest, and idempotency identity. None of them ride in the transaction token.¶

The Transaction Authorization Server MUST be able to show that its fresh decision relied on a valid approval. A resource's own authorization decision rests on the trusted, typed transaction token plus the current local checks of Section 8, never on parsing an arbitrary evidence blob presented at the request.¶

This profile defines no Continuation Transport and no continuity guarantee of its own ([I-D.draft-mcguinness-oauth-mission-continuation]). Its token is a bounded, single-use authorization artifact. The token carries txn, its own jti, and parameter_digest; those correlate the runtime evidence profile's execution-time evidence to this hop ([I-D.draft-mcguinness-mission-runtime-evidence]). The Operation Profile's idempotency identity correlates the effect and is not carried by the token.¶

10. Failure Semantics

The pending and polling states and errors of [I-D.draft-rosomakho-oauth-txn-challenge] Section 5.3 (authorization_pending, slow_down, access_denied, expired_token) apply unchanged; this document defines no second error vocabulary for that surface. Initial validation only admits a workflow: only the fresh decision at Section 6 completion is final, and an admitted workflow MUST still refuse there when a fresh input no longer holds.¶

No or expired action approval:

Deny. The workflow MAY return or request another approval.¶

Approval granted but current policy or entitlement denies:

Deny. The approval is not a bypass of step 7 of Section 6.¶

Parameter, resource, Mission, principal, presenter, or audience

¶

mismatch:

Terminal refusal for that token or challenge.¶

Stale or unavailable required state:

Fail closed. Retry only according to the declared state-recovery policy.¶

Consumed token:

Return the prior idempotent result via the relationship map of Section 8 when the Operation Profile allows it; otherwise duplicate_suppressed ([I-D.draft-mcguinness-mission-runtime]). Never execute again.¶

A challenge or token with an unknown typ or unrecognized

¶

authorization_details semantics:

MUST be rejected outright, never parsed on a best-effort basis.¶

11. Security Considerations

The security considerations of the issuance profile [I-D.draft-mcguinness-oauth-mission] and the runtime profile [I-D.draft-mcguinness-mission-runtime] apply.¶

Challenge and credential substitution:

A challenge is scoped to one resource, one operation, and one presenter key. Section 6's step 1 (subject_token audience and cnf), step 2 (exact mission equality), and step 3 (authority subset) together close the case of a challenge issued for one resource being redeemed for another's benefit, or a Mission-bound access token issued for a different resource or held by a different party being accepted as this profile's credential; a TAS that skips any of the three can be induced to authorize an operation the verified authority never covered.¶

Approval replay across operations:

An approval is bound to txn, the operation identity, and parameter_digest. A TAS that treats a completed approval as standing authority for a different transaction, rather than re-running step 7 fresh for each redemption, reintroduces the bearer-grant failure mode this profile exists to close.¶

Transaction Authorization Server compromise, and pending-workflow exposure:

The TAS is the component every resource on the deployment trusts to have run a genuine fresh decision. Its compromise mints tokens for operations no human or policy authority approved, and a long-lived pending workflow widens the window in which subject_token, its key, or the approval authority can be compromised before that decision runs. Deployments SHOULD isolate the TAS's signing key and decision logic from the agent's own execution environment, matching the runtime profile's mediated-custody posture, SHOULD bound the pending workflow's declared lifetime (Section 6.2) to what genuine approval latency requires, and SHOULD bound token lifetime tightly enough that a detected compromise's blast radius is the outstanding token population, not the Mission's full remaining lifetime.¶

Consumption-store availability, and the fail-closed posture generally:

The at-most-once property this profile claims exists only while the consumption store meets the Exact enforcement profile of [I-D.draft-mcguinness-mission-metering]; a deployment that degrades to a merely local cache during partition no longer has that property and MUST NOT claim it. Every failure path of Section 10 resolves to denial, refusal, or a fail-closed state, never silent pass-through; an implementation that treats an unrecognized typ, an unverifiable approval, or an unreachable consumption store as permission is nonconformant.¶

12. Privacy Considerations

Raw action parameters and approval detail stay off the transaction token by design: the token carries parameter_digest, not the parameters, and no approval object. A Transaction Authorization Server that needs more than the digest to decide or render obtains raw values through the reason_uri retrieval of Section 5, never by widening the token.¶

Digest-plus-attributes authorization lets a TAS decide without learning more than the deployment chooses to disclose over that channel; a deployment SHOULD weigh what attributes it discloses to the TAS against what the decision genuinely requires. Presenting subject_token discloses to the TAS that the Presenting Client holds Mission-bound authority at the challenged resource; the TAS already is a party the deployment trusts with the fresh decision, so this is not a disclosure beyond what Section 6 already requires it to evaluate.¶

txn and the transaction token's jti are a correlation surface: any party observing both a challenge and its redeemed token can link one resource transaction to one TAS decision. This is the profile's intended accountability property, not an incidental leak, but a deployment SHOULD scope txn values to the minimum lifetime and audience that Section 5 and Section 8 require.¶

13. IANA Considerations

14. Mission Substrate

This document is defined against the Mission model rather than against OAuth 2.0 mechanics: it is a substrate-neutral consumer, and this section is its consumption declaration under the rule of Mission Substrate Requirements ([I-D.draft-mcguinness-mission-substrate]) that a substrate-neutral profile declare the kernel functions and optional capabilities it consumes.¶

From the contextual-governance kernel it consumes the Mission identifier and issuer, the kernel's Mission Reference and Controller carried in the mission claim, and the active and non-active gate the fresh decision of Section 6 observes.¶

Its declaration against the optional capabilities:¶

Beyond the kernel, this profile also consumes companion capabilities outside the substrate contract: the metering companion's Exact enforcement profile for atomic txn consumption and the Mission Status surface for freshness-bounded state observation (both Section 8), and, conditionally, the cross-domain Origin Principal profile for the invariant origin principal (Section 5). All three are consumed, none produced.¶

These consumed capabilities join conjunctively, at the runtime decision, with the Mission's current Effective Authority Set and any applicable cumulative-consumption or stateful operational gate ([I-D.draft-mcguinness-mission-runtime], Section "The Runtime Decision"): the fresh, action-bound permit this profile mints is one more independent gate, never a substitute for the others.¶

The carrier-side dual of this declaration, what a protocol binding must provide for another substrate to host this profile's flow, is Section 15.¶

15. Carrier Binding Floor

The wire mechanics of this document are one discharge of a carrier-neutral flow: Section 14 declares what this profile consumes from the Mission kernel, and this section declares what the flow itself requires, in three layers. Section 15.1 states the invariants that make the flow safe on any substrate. Section 15.2 states the slots a protocol binding MUST provide to carry them. Section 15.3 names this document's own discharge of each slot. A binding that cannot provide a slot does not host this profile: absence is fail-closed, and there is no partial hosting.¶

16. Conformance

A Transaction Authorization Server:¶

• authenticates the Presenting Client and validates the challenge as [I-D.draft-rosomakho-oauth-txn-challenge] requires, then completes every added step of Section 6 in order and refuses on any failure;¶

• MUST NOT let completion of the approval step alone trigger token issuance or bypass the fresh decision;¶

• mints the transaction token only with the claims and MUST NOT list of Section 7; and¶

• publishes its signing keys and accepted challenge issuers as deployment and federation metadata, resolving each challenge issuer's keys through its published txn_challenge_jwks_uri and never accepting either from the request.¶

A Challenge-Issuing Resource:¶

• derives the Mission-profiled challenge claims from the request and the verified credential, never from a client-supplied value (Section 5);¶

• verifies the transaction token locally under Section 8 without a request-path call to the TAS; and¶

• consumes txn atomically and linearizably across every replica, failing closed when the consumption store is unavailable.¶

A Presenting Client:¶

• proves possession of the challenge's and token's confirmation key at redemption and at execution; and¶

• treats the transaction token, not the approval, as authority: it does not construct or assert an approval object of its own.¶

Positive and negative conformance vectors exist for: a valid challenge, subject_token presentation, approval, fresh decision, and one execution; delegated constraint preservation and an attempted removal of requires_action_approval; step-up presented without transaction approval; an approval valid for a changed amount, recipient, resource, action, Mission, destination-local subject, origin principal, actor, audience, or presenter key; an approval complete but Authority Set, entitlement, or resource policy denying; a missing or changed parameter_digest and a different canonicalization; a pending workflow that outlives its challenge and is later approved; repeated initial submission of the same challenge returning one workflow; challenge replay, single-replica token replay, and two distinct token jti values presented for one txn; an ambiguous first execution followed by an idempotent retry; an expired challenge, pending workflow, subject_token, or transaction token; a subject_token valid for a different resource audience or an unmatched cnf; an untrusted resource, TAS, or approval authority; an arbitrary signed JWT or an ordinary Mission token presented as a transaction token; a privacy projection showing raw parameters and approval detail absent from the token; and evidence correlation from challenge and decision through exactly one execution or terminal refusal.¶

Acknowledgments

This document is part of the Mission-Bound Authorization work and profiles the OAuth transaction authorization challenge for cross-organizational, execution-time approval.¶

References

Author's Address