Mission Cross-Domain Projection 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 9 January 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

The issuance profile [I-D.draft-mcguinness-oauth-mission] makes a Mission a durable, human-approved, integrity-bound OAuth authorization artifact: one Authorization Server, the Mission Issuer, approves it, records it, and derives every token under it. That profile is deliberately single-domain: the AS that holds the Mission is the AS that issues for it.¶

Real tasks cross trust domains. An agent reconciling invoices may need a partner's ERP, behind a partner Authorization Server the home AS does not control and whose accounts it does not manage. This document specifies cross-domain projection: the originating Mission Issuer projects a Mission's authority, audience-scoped and integrity-anchored, to an Authorization Server in another trust domain, which honors it by minting local tokens for its own resources. The projection is a single hop, issuer to Resource AS; chaining a Mission across more than one trust-domain boundary remains future work ([I-D.draft-mcguinness-oauth-mission], Section "Non-Goals").¶

Two roles carry the model. The Mission Issuer (the Mission's issuer) remains the only party that creates, holds, and gates the Mission. A Resource AS honors a Mission it did not issue: it validates the projected grant, applies its own local policy, and mints its own tokens, preserving the Mission binding unchanged. A Resource AS is never the Mission Issuer.¶

Three properties define the projection. The Mission does not cross: the record, the Mission Intent, the full Authority Set, and lifecycle authority stay with the Mission Issuer, and the Resource AS receives only claim-shape facts and the entries scoped to it (Section 5). Authority never widens: the projection carries the agent's authority preserved and scoped to the audience, and nothing the Resource AS mints may widen it (Section 9). Honoring is session-less: the Resource AS verifies pre-established issuer trust and a signature, so the Mission Issuer is never on the partner's request path; the cost of that independence is a bounded revocation lease (Section 13.1).¶

2. Status: An OPTIONAL Extension

This document is the Cross-Domain capability named by the base profile's conformance model ([I-D.draft-mcguinness-oauth-mission], Section "Conformance"). The capability is OPTIONAL: a deployment whose Missions never leave their issuing AS does not implement this document, and the base profile is complete without it.¶

Two external dependencies set its deployment posture. The OAuth identity chaining architecture [I-D.draft-ietf-oauth-identity-chaining] is approved for publication and in the RFC Editor queue; the Identity Assertion Authorization Grant [I-D.draft-ietf-oauth-identity-assertion-authz-grant] is a working-group document. This document profiles them and cannot advance ahead of them; confining them here keeps the base profile free of in-progress cross-domain dependencies.¶

The capability is orthogonal to the family's Mission Assurance Levels ([I-D.draft-mcguinness-mission-architecture]): projection changes where a Mission is honored, not the strength at which either domain enforces it. Each trust domain runs at its own level.¶

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 the terms of the base profile [I-D.draft-mcguinness-oauth-mission]: Mission, Mission Issuer (the Mission's issuer), Mission Intent, Authority Set, Subject, mission claim, derived token, derivation, the subset rule, and lifecycle gating. Authority Set entries are [RFC9396] authorization_details objects. All JSON shown in this document is non-normative and illustrative; the member definitions in the surrounding text are authoritative.¶

Resource AS:

An Authorization Server in another trust domain that honors a Mission it did not issue, minting its own tokens for its resources from a cross-domain grant. A Resource AS is never the Mission Issuer.¶

Cross-domain grant:

The short-lived JWT authorization grant the Mission Issuer issues toward a Resource AS (Section 8), carrying audience-scoped Mission authority and the mission claim. It is a Mission-bound token in the sense of the base profile.¶

Local token:

An access token a Resource AS mints for its own resources from a cross-domain grant (Section 9).¶

4. Cross-Domain Projection

A Mission is approved and held by one Mission Issuer (its issuer). This document lets a single Mission be honored by Authorization Servers in other trust domains, so a Mission can span more than one AS, using the cross-domain authorization grant of the OAuth identity chaining architecture [I-D.draft-ietf-oauth-identity-chaining]: the issuer AS issues, through an [RFC8693] token exchange, a short-lived JWT authorization grant audienced to the target Authorization Server, which the client redeems there with the [RFC7523] JWT-bearer grant.¶

This document calls that artifact the cross-domain grant and attaches Mission context to it (Section 8). The Identity Assertion Authorization Grant (ID-JAG) [I-D.draft-ietf-oauth-identity-assertion-authz-grant] is the RECOMMENDED profile of the cross-domain grant, and every example in this document uses it; another identity-chaining JWT authorization grant profile that meets the requirements of Section 8 MAY be used instead. Where a requirement elsewhere in this document names the ID-JAG, it is illustrating with the recommended profile and applies equally to any conforming cross-domain grant.¶

This document is a thin Mission-bound profile of the cross-domain grant, not merely mission-claim carriage: beyond attaching and validating Mission context, it imposes two security requirements on the grant for Mission-bound use, proof-of-possession and single use (Section 8, Section 9). The grant's own format, signing, and token-exchange envelope remain defined by the cross-domain grant profile (ID-JAG in the recommended case) and its underlying [RFC8693] and [RFC7523]; this document does not redefine them. The two added requirements are a floor: the cross-domain grant is the highest-authority credential crossing a trust boundary, and its profile does not by itself guarantee them.¶

In this model there is exactly one Mission Issuer per Mission (the issuer) and one or more Resource ASes in other domains that mint their own tokens for their resources. A Resource AS is never the Mission Issuer and MUST NOT create or alter a Mission.¶

5. What Crosses the Trust Boundary

The projection is exact about what leaves the issuing domain.¶

Three values cross unchanged: mission.id, mission.issuer, and authority_hash, the claim-shape Mission binding every downstream token preserves (Section 9). They are audit and correlation anchors, not credentials.¶

Two things cross scoped: the audience-scoped Authority Set entries (Section 5.1), and the Mission's Subject in the form the identity chaining architecture defines (Section 8).¶

Everything else stays home. The Mission record, the Mission Intent, the full Authority Set, and lifecycle authority remain with the Mission Issuer; a Resource AS never creates or alters a Mission (Section 4). The grant is not refreshable and confers no standing authority in the partner domain: when it expires, the client returns to the issuer for a new one, which is how the issuer's lifecycle gate keeps reaching across the boundary.¶

Nothing returns across the boundary at validation time. The Resource AS honors the grant from pre-established trust (Section 7) and the signature alone; its assurance that the Mission was active is a lease bounded by the grant lifetime (Section 13.1).¶

6. Relationship to Transaction Token Chaining

This section is informative. The Transaction Token chaining profile ([I-D.draft-fletcher-transaction-token-chaining-profile]) is a sibling of this document: the same identity-chaining framework, the same exchange-then-redeem shape at the same boundary, the same short-grant discipline, a distinct typ (txn-chain+jwt). What crosses differs. Its grant carries the in-flight transaction's context, minted from a Transaction Token ([I-D.draft-ietf-oauth-transaction-tokens]) that never leaves its domain; this document's grant carries the durable approved task. A hop between the same two domains may legitimately need both facts, and a deployment MAY run both profiles on one hop. They compose as follows:¶

• The Mission reference may ride the transaction chain as evidence, never as authority. The mission claim object (id, issuer, authority_hash) MAY be carried inside that profile's minimized txn_claims, exactly as it rides an intra-domain Transaction Token in this document's end-to-end example. It is inert there: a consumer MUST NOT derive, widen, or gate authority from it, and a partner that needs the committed facts verifies a Mission Mandate ([I-D.draft-mcguinness-mission-mandate]). Mission-scoped authority reaches another domain only through this document's grant.¶

• The transaction identifier may ride this document's evidence. A Resource AS that redeems a Mission-bound grant while participating in a transaction chain MAY record the transaction identifier with its redemption and derivation evidence, so the transaction chain and the Mission projection correlate in audit across both domains.¶

• Recursion does not extend projection. That profile permits recursive chaining: the second domain repeats the pattern toward a third. A Mission's projection is single-hop by design (Section 5); a recursive transaction chain carries the Mission reference onward as evidence only, and a third domain that must honor the Mission needs its own projection from the originating issuer.¶

7. Pre-Established Trust

Projection is configured, not negotiated: nothing in the protocol establishes trust between the domains, and every trust input below exists before the first grant is issued.¶

• Issuer trust: which Mission Issuers the Resource AS accepts, by local policy or issuer metadata (Section 9). The identity-assertion trust framework and its domain-authorized-issuer method ([I-D.draft-mcguinness-oauth-id-assertion-framework], [I-D.draft-mcguinness-oauth-domain-authorized-issuer]) are concrete ways to publish and evaluate this policy instead of hand-maintaining a list.¶

• The resource-to-AS mapping: which Resource AS is authoritative for which resource values, the mapping audience scoping is computed under (Section 5.1).¶

• The grant profile in use (the ID-JAG in the RECOMMENDED case) and, where that profile defines no proof-of-possession, the sender-constraint mechanism (Section 8); binding and verification interoperate only if both domains fix the same one.¶

• Client registration: the presenting client is registered with and authenticates to the Resource AS's token endpoint, as the grant profile requires.¶

• Subject resolution: the account-linking policy by which the Resource AS resolves the conveyed Subject in its own namespace (Section 9).¶

A deployment that publishes a Mission Deployment Profile ([I-D.draft-mcguinness-mission-architecture]) records its projection posture in these terms, and the accepted cross-domain revocation window (Section 13.1) among its residual risks.¶

8. Issuing the Cross-Domain Grant

Issuing a cross-domain grant is a derivation event and is gated like any other derivation ([I-D.draft-mcguinness-oauth-mission], Section "Mission Lifecycle and Gating"). It counts once against the Mission's derivation budget, however many local tokens the partner domain later mints: the issuer cannot observe those tokens and does not count them, and the Resource AS bounds its own minting by the grant and by local policy (Section 9). Because each grant lives at most 300 seconds, steady-state partner work re-issues grants on a lease cadence and consumes at least 12 derivations per hour per audience; a deployment sizes the Mission's max_derivations control ([I-D.draft-mcguinness-oauth-mission]) as a function of that cadence times the projected audiences times the Mission's duration. A Mission-bound cross-domain grant:¶

• MUST be a JWT authorization grant issued and signed by the Mission issuer, redeemable at the target Resource AS through the [RFC7523] JWT-bearer grant;¶

• MUST be explicitly typed with the JWT typ its grant profile defines (oauth-id-jag+jwt for the RECOMMENDED profile), so the grant is mechanically distinguishable from every other issuer-signed Mission artifact; a Mission Mandate ([I-D.draft-mcguinness-mission-mandate]) is never redeemable as a grant, and the typ is what a token endpoint separates them by;¶

• MUST be audienced to the target Resource AS, and MUST NOT have a lifetime exceeding 300 seconds (a short lifetime bounds cross-domain revocation latency; see Section 13.1);¶

• MUST have an exp that does not exceed the Mission's expires_at, per the base profile's expiry rule ([I-D.draft-mcguinness-oauth-mission], Section "Mission-Bound Access Tokens");¶

• MUST be sender-constrained ([RFC7800]) to the presenting client by the proof-of-possession mechanism the cross-domain grant profile defines, where it defines one. This document does not define a new PoP mechanism; the originating AS and the Resource AS MUST use the mechanism of the profile in use, so that binding and verification interoperate. When the grant profile in use defines no proof-of-possession, as the ID-JAG profile does not (the ID-JAG is a bearer authorization grant, protected by audience restriction, short lifetime, and client authentication at redemption), the grant carries a cnf claim ([RFC7800]) binding the presenting client's DPoP key (jkt, [RFC9449]) or mTLS certificate (x5t#S256, [RFC8705]), and the Resource AS MUST verify possession at redemption (Section 9). Binding and verification MUST use the same mechanism;¶

• MUST carry a jti for one-time use, so the bound party cannot replay it within its lifetime (Section 9, [RFC7523] Section 3);¶

• MUST carry the mission claim ([I-D.draft-mcguinness-oauth-mission], Section "The Mission Claim") with id, issuer, and authority_hash unchanged from the Mission, and the audience-scoped authorization_details (Section 5.1); and¶

• MUST convey the Mission's Subject in the form the identity chaining architecture defines, so the Resource AS can resolve it locally (Section 9).¶

The ID-JAG profile meets these requirements and is RECOMMENDED; in it the artifact is the ID-JAG and the issuance request carries a requested_token_type of urn:ietf:params:oauth:token-type:id-jag.¶

The client obtains the grant with an [RFC8693] token exchange. The subject_token MUST be the Mission's refresh token, with subject_token_type of urn:ietf:params:oauth:token-type:refresh_token, and the audience identifies the target Resource AS. The refresh-token subject is this profile's deviation from the ID-JAG issuance request, which that specification defines over an identity-assertion subject_token (id_token or saml2); a Mission-bound deployment substitutes the Mission's grant so the exchange resolves a Mission rather than a bare subject assertion. This refresh-token mode is what binds the request to a Mission: the AS resolves the Mission from the presented grant per the base profile's grant binding ([I-D.draft-mcguinness-oauth-mission], Section "Binding the Mission to the Grant"), exactly as on any other refresh, and the grant therefore projects the agent's full Mission authority (audience-scoped), never a narrowed delegate's.¶

The refresh-token subject mode is the only mode this profile defines, and fixing it is deliberate: the refresh token resolves to exactly one Mission and its full authority, where an access token or delegated token could carry a narrowed or actor-specific subset that a trust-boundary crossing could re-widen. Other Mission-bound subject-token modes, such as an access-token mode bounding the projection by the presenting token, are left to future profiles. The cost is that this OPTIONAL capability is unavailable to a deployment that issues no refresh token; such a deployment uses the single-domain base profile, which needs none.¶

The AS MUST reject an access token or a delegated token presented as subject_token for cross-domain issuance. The AS MUST NOT resolve the Mission from a client-supplied mission_id, nor from an identity assertion that carries no Mission binding (Section 10).¶

Before issuing, the AS MUST verify the Mission is active (failing otherwise with invalid_grant) and that the target Resource AS is authorized for the requested resources under the Mission's Authority Set (failing otherwise with invalid_target, [RFC8693]). The token-exchange response carries issued_token_type of urn:ietf:params:oauth:token-type:id-jag (for the RECOMMENDED profile) and token_type of N_A, per [RFC8693] Section 2.2.1.¶

A delegate, rather than the agent, crossing a trust domain directly and carrying its own narrowed authority into another domain is out of scope for this document and deferred to future work. Cross-domain issuance here always projects the agent's Mission authority; delegation within the target domain is performed by the Resource AS (Section 9). A sub-agent that must act in a different trust domain under its own narrowed authority is therefore not covered by a single hop; distributed multi-agent work across domains composes only through the agent's projected authority or through separate Missions per domain. A delegate-carries-its-own-authority mode is future work.¶

Two roles MUST NOT be conflated. The grant the client presents to obtain the cross-domain grant (the Mission's refresh token) is the input to the exchange and selects the Mission; the Mission-bound access token plays no part here. The identity the issued grant conveys to the Resource AS is the Mission's Subject, which the AS populates from the Mission's recorded subject and which the Resource AS resolves locally per the identity chaining rules (this document defines no cross-domain subject mapping, Section 9).¶

Sender-constraining is REQUIRED for the cross-domain grant, stronger than the RECOMMENDED level the base profile sets for the primary access token ([I-D.draft-mcguinness-oauth-mission], Section "Mission-Bound Access Tokens"): it is the highest-authority credential in the chain and the only one that crosses a trust boundary, and the underlying grant provides no replay backstop of its own.¶

9. Validation at the Resource AS

A Resource AS consuming a Mission-bound cross-domain grant:¶

• MUST establish issuer trust in the originating AS by local policy or issuer metadata before accepting any Mission reference. It MUST NOT trust a mission.issuer merely because it appears inside a signed assertion.¶

• MUST validate the grant's explicit typ (per the grant profile in use; oauth-id-jag+jwt for the RECOMMENDED profile), signature, and expiry, and verify its aud is the Resource AS's own identifier: it rejects a grant minted for a different Resource AS, and rejects a JWT of any other type presented as this grant, whatever Mission facts it carries.¶

• MUST verify the grant's sender-constraint by the proof-of-possession mechanism the cross-domain grant profile defines (for the ID-JAG profile, as that specification defines), and MUST reject with invalid_grant a cross-domain grant that is not sender-constrained or whose proof-of-possession does not verify. When the grant profile defines no proof-of-possession and the grant carries a cnf claim per Section 8, the Resource AS MUST verify possession of that key at redemption: a DPoP proof ([RFC9449]) for its own token endpoint for a jkt binding, or the mTLS connection certificate ([RFC8705]) for an x5t#S256 binding. Binding and verification MUST use the same mechanism. A bearer grant MUST NOT be accepted: it is the highest-authority credential crossing the trust boundary, so accepting one unbound would let any party that captured it mint a local token.¶

  • Because this document defines no cross-domain status query, freshness is the Resource AS's only check that the Mission was active at issuance; the short grant lifetime bounds the staleness.¶

• MUST reject a replayed cross-domain grant: it MUST track the grant's jti for the grant's validity window and refuse a second presentation with invalid_grant ([RFC7523] Section 3), so a grant cannot be replayed even by the party it is bound to.¶

• When issuing local access tokens for its resources, the Resource AS uses the subject-resolution rules of the underlying cross-domain grant and identity chaining specifications. The local token preserves the mission claim (id, issuer, and authority_hash) unchanged from the cross-domain grant. The issuing iss is the Resource AS; mission.issuer remains the originating AS. Such a local token:¶

  • has an exp that MUST NOT exceed the grant's exp. The Resource AS does not hold the Mission's expires_at; because the grant's own exp is bounded by it (Section 8), the local token is bounded transitively;¶

  • MUST be sender-constrained ([RFC7800]), like the grant it derives from, and MUST NOT be issued as a bearer token; and¶

  • if it preserves the issuer's client_id, does so only as an audit reference, not a local identity: that value is in the originating AS's namespace, and a partner Resource Server MUST NOT resolve or authorize on it as a local client, for the same portability reason that applies to a sub matcher in allowed_delegates (see below).¶

• MUST bound the issued authorization_details by what the cross-domain grant conveyed, and MUST apply its own local authorization policy in addition: honoring a Mission does not obligate it to authorize any particular request. Because the conveyed entries were derived under the originating AS's local policy, the Resource AS does not re-derive them; it interprets and enforces them by their structure and vocabulary. It MUST fail closed on a conveyed actions identifier or constraints key it does not recognize for the resource in question, exactly as a Resource Server does ([I-D.draft-mcguinness-oauth-mission], Section "Resource Server Enforcement"), so authority it cannot interpret is never honored across the trust boundary rather than enforced by guess.¶

• MUST, when it issues delegated tokens of its own, enforce each entry's delegation policy as the base profile specifies ([I-D.draft-mcguinness-oauth-mission], Section "Delegation Constraints"); the policy travels on the conveyed entries. The cross-domain grant carries no act chain (Section 8), so the Resource AS's own delegation depth begins at 0.¶

• SHOULD record, per minted local token, both sides of the derivation: the consumed grant's jti and conveyed authorization_details, and the local token's own identifier or digest (jti), iss, aud, iat, exp, and issued authorization_details. The issuer cannot observe local tokens (Section 13.1), so this record is the only evidence tying a local token to the grant it was minted from and showing its authority did not widen.¶

A grant that carries no mission claim is outside this profile: the Resource AS processes it, or refuses it, under plain identity chaining, and MUST NOT grant Mission-scoped resources on it. Where the deployment's pre-established trust (Section 7) requires Mission binding for the requested resources, the Resource AS refuses such a grant with invalid_grant; a mission claim that is present but malformed is always invalid_grant (Section 10).¶

A { "sub": ... } matcher in a conveyed entry's delegation.allowed_delegates is a client identifier in the originating AS's namespace and is not portable across the trust domain. When a Resource AS evaluates a conveyed entry, it MUST fail closed, narrowing the entry out, for any sub matcher it cannot resolve against the delegate it authenticated in its own namespace. Portable cross-domain matching SHOULD therefore use a sub_profile matcher, an actor-type class rather than a domain-relative identifier ([I-D.draft-mcguinness-oauth-mission], Section "Delegation Constraints").¶

This document does not define cross-domain subject mapping. A Resource AS consuming a Mission-bound cross-domain grant resolves the subject of any local token according to the cross-domain grant profile in use (the Identity Assertion Authorization Grant profile in the recommended case), the OAuth identity chaining architecture, and its local trust and account-linking policy. This document only requires that the Mission binding (mission.id, mission.issuer, and authority_hash) and the audience-scoped authorization_details remain bounded as described here.¶

Downstream, authority_hash is an immutable audit and correlation anchor to the originating AS's consent commitment. A Resource AS and its Resource Servers hold only the audience-scoped subset, never the full Authority Set, so they cannot recompute authority_hash ([I-D.draft-mcguinness-oauth-mission], Section "Integrity Anchors"); its integrity rests on the signature chain (the originating AS signs the ID-JAG; the Resource AS validates issuer trust and signs its local token). It is verifiable only against the originating AS, which this document does not require to be exposed. A Resource AS or auditor that needs to verify the conveyed entries against the approved commitment MAY obtain a Mission Mandate ([I-D.draft-mcguinness-mission-mandate]) and recompute authority_hash per that profile.¶

10. Error Responses

This document defines no new error codes; it binds the standard codes of [RFC8693], [RFC7523], and OAuth 2.0 to this profile's failure conditions so both surfaces fail uniformly.¶

At issuance (the token exchange at the Mission Issuer, Section 8):¶

At redemption (the JWT-bearer grant at the Resource AS, Section 9):¶

A Resource AS rejecting a grant reveals no Mission state it does not hold: invalid_grant at redemption speaks to the presented grant, not to the Mission's current lifecycle state, which the Resource AS cannot know (Section 11).¶

11. Introspection at a Resource AS

The base profile's OPTIONAL token introspection ([RFC7662]) reports a mission response member, and only the Mission issuer reports the Mission's lifecycle state ([I-D.draft-mcguinness-oauth-mission], Section "Mission State via Token Introspection"). This section specifies the non-issuer half of that rule.¶

A Resource AS that supports introspection for a local token it minted from a cross-domain grant returns the claim-shape members only: id, issuer, and authority_hash. It holds the token, not the Mission: it knows the Mission state only as of grant validation and has no query to the issuer keyed by mission_id (neither this document nor the base profile defines one). It MUST omit mission.state rather than report a stale value as current. authority_hash, when included, is the issuer's commitment carried through the grant, not a value the Resource AS recomputes from its audience-scoped subset ([I-D.draft-mcguinness-oauth-mission], Section "Consent Binding").¶

12. Authorization Server Metadata

Discovery uses existing metadata; this document defines no new parameters. A Mission Issuer supporting this capability advertises the [RFC8693] token-exchange grant type in grant_types_supported, the base profile's signal for cross-domain grant issuance ([I-D.draft-mcguinness-oauth-mission], Section "Authorization Server Metadata"). A Resource AS advertises the [RFC7523] JWT-bearer grant type the grant is redeemed through; support for a specific grant profile is discovered as that profile specifies, or out of band. The bilateral inputs of Section 7 are not discoverable and exist before first use.¶

13. Security Considerations

The security considerations of the base profile [I-D.draft-mcguinness-oauth-mission] and of the identity chaining architecture [I-D.draft-ietf-oauth-identity-chaining] apply.¶

14. Privacy Considerations

The cross-domain grant and every local token minted from it carry the canonical mission_id, mission.issuer, and authority_hash unchanged, so a Resource AS and its Resource Servers can correlate a Mission's activity across domains, and mission.issuer identifies the issuing AS to the partner domain. This is the deliberate correlation property of the base profile ([I-D.draft-mcguinness-oauth-mission], Section "Mission Identifier Correlation"), extended across the trust boundary. Audience scoping (Section 5.1) is the minimization measure: a Resource AS never sees Authority Set entries addressed to other audiences.¶

15. Conformance

An implementation conforms in one of two roles and names the capability as the base profile's conformance model directs (for example, "Mission Issuer with Cross-Domain"; [I-D.draft-mcguinness-oauth-mission], Section "Conformance").¶

An Originating Mission Issuer with Cross-Domain is a conforming Mission Issuer of the base profile that additionally:¶

• issues the Mission-bound cross-domain grant per Section 8, gated and counted as a derivation;¶

• scopes every projection by audience (Section 5.1);¶

• fails issuance with the codes of Section 10; and¶

• advertises cross-domain grant issuance per Section 12.¶

A Resource AS:¶

• honors the cross-domain grant per Section 9, including issuer trust by local policy, explicit typing, sender-constraint and one-time-use verification, and fail-closed interpretation of conveyed authority;¶

• bounds every local token by the grant that seeded it and issues it sender-constrained and short-lived (Section 9, Section 13.1);¶

• fails redemption with the codes of Section 10;¶

• where it offers token introspection for its local tokens, follows Section 11; and¶

• never creates or alters a Mission (Section 4).¶

A Resource AS is not required to implement the base profile's Mission Issuer role.¶

16. IANA Considerations

This document has no IANA actions. The mission JWT claim, the mission introspection response member, and the mission_resource_access authorization details type it carries are registered by the base profile [I-D.draft-mcguinness-oauth-mission].¶

17. References

Appendix A. End-to-End Example (Non-Normative)

This appendix continues the end-to-end example of the base profile's appendix across a trust boundary: from the home domain (as.example.com) into a partner domain, and then into the partner's internal microservice call chain. It is illustrative and adds no normative requirements. The final intra-domain hop shows one deployment-local way to carry Mission context in a Transaction Token [I-D.draft-ietf-oauth-transaction-tokens]. Identifiers and hash values are illustrative and are not computed from the displayed JSON.¶

The chain crosses boundaries in two distinct ways, and seeing why is the point of the example:¶

• The Identity Assertion Authorization Grant (ID-JAG) crosses between trust domains: from the home domain (as.example.com) to the partner domain (ras.partner.example.com).¶

• Transaction Tokens propagate within the partner trust domain: from the partner's Resource Server through its internal services.¶

The Mission is the durable anchor across both: mission.id, mission.issuer, and authority_hash ride unchanged through every hop. OAuth authority is audience-scoped by the Mission Issuer and Resource AS; deployment-local transaction context then narrows the operation for internal services. In this baseline walkthrough no hop calls back to mission.issuer for state; each enforces from the credential it holds. The OPTIONAL companion profiles layer on this baseline, and the stages note where: Stage 4 gains a runtime point-of-use check, and Stage 3 gains prompt cross-domain revocation from Status or Signals.¶

Scenario: agent s6BhdRkqt3, acting for alice (user_3p2q8mN1a0kV7tR), reconciles Q3 invoices in a partner ERP under Mission msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-. Stage 0 (agent identity) and Stage 1 (Mission creation at the home AS) are the base profile's single-domain walkthrough, extended here in one way: the Mission Intent's resources also names the partner ERP https://erp.partner.example.com, so the approved Authority Set additionally carries, for that resource, an invoices.read entry (delegable to ai_agent actors at depth 1) and a journal-entries.write entry capped at a max_amount of 500.00 USD. The Mission was recorded active with authority_hash sha-256:Gv2nD9bM7sX1cF8gH0pVl3KvZ4mP5x0wQrR6tY2jE5kQ and intent_hash sha-256:Zb8mR3nX5pV4lE6sQqYwQ7p4LHnX9Md0LqJ6sZJ2xT5f (illustrative; this Mission's Intent and Authority Set extend the single-domain walkthrough's, so its anchors differ from that example's). The partner ERP is behind the Resource AS ras.partner.example.com, so the agent's next step is a cross-domain projection rather than a home-domain access token.¶

{
  "iss": "https://as.example.com",
  "aud": "https://ras.partner.example.com",
  "sub": "user_3p2q8mN1a0kV7tR",
  "client_id": "s6BhdRkqt3",
  "iat": 1793606400,
  "exp": 1793606700,
  "cnf": { "jkt": "0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I" },
  "authorization_details": [
    { "type": "mission_resource_access",
      "resource": "https://erp.partner.example.com",
      "actions": ["invoices.read"],
      "delegation": {
        "max_depth": 1,
        "allowed_delegates": [{ "sub_profile": "ai_agent" }]
      } },
    { "type": "mission_resource_access",
      "resource": "https://erp.partner.example.com",
      "actions": ["journal-entries.write"],
      "constraints": { "max_amount":
        { "amount": "500.00", "currency": "USD" } } }
  ],
  "mission": {
    "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
    "issuer": "https://as.example.com",
    "authority_hash":
      "sha-256:Gv2nD9bM7sX1cF8gH0pVl3KvZ4mP5x0wQrR6tY2jE5kQ"
  }
}

{
  "iss": "https://ras.partner.example.com",
  "aud": "https://erp.partner.example.com",
  "sub": "partner-user_7Kp4QnZ2vR9s",
  "client_id": "s6BhdRkqt3",
  "iat": 1793606430,
  "exp": 1793606690,
  "jti": "at_7Kp4QnZ2vR9sT1mX8b3N",
  "cnf": { "jkt": "0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I" },
  "authorization_details": [
    { "type": "mission_resource_access",
      "resource": "https://erp.partner.example.com",
      "actions": ["invoices.read"],
      "delegation": {
        "max_depth": 1,
        "allowed_delegates": [{ "sub_profile": "ai_agent" }]
      } },
    { "type": "mission_resource_access",
      "resource": "https://erp.partner.example.com",
      "actions": ["journal-entries.write"],
      "constraints": { "max_amount":
        { "amount": "500.00", "currency": "USD" } } }
  ],
  "mission": {
    "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
    "issuer": "https://as.example.com",
    "authority_hash":
      "sha-256:Gv2nD9bM7sX1cF8gH0pVl3KvZ4mP5x0wQrR6tY2jE5kQ"
  }
}

{
  "iss": "https://txn.partner.example.com",
  "aud": "https://ledger.partner.example.com",
  "sub": "partner-user_7Kp4QnZ2vR9s",
  "tid": "txn_5kQ9pX2vN7sR1tY8mZ3",
  "iat": 1793606460,
  "exp": 1793606520,
  "txn_authorization": {
    "source_resource": "https://erp.partner.example.com",
    "source_actions": ["invoices.read"],
    "internal_operation": "ledger.lookup_invoice",
    "constraints": { "invoice_id": "inv_2026Q3_1042" }
  },
  "mission": {
    "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
    "issuer": "https://as.example.com",
    "authority_hash":
      "sha-256:Gv2nD9bM7sX1cF8gH0pVl3KvZ4mP5x0wQrR6tY2jE5kQ"
  }
}

Author's Address