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 22 February 2027.¶

Copyright Notice

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

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

Table of Contents

1. Introduction

The 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 10). 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 16.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 issuance 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 issuance 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 issuance 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 9), carrying audience-scoped Mission authority and the mission claim. It is a Mission-bound token in the sense of the issuance profile.¶

Local token:

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

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

The grant shape this document profiles is already deployed: the Model Context Protocol's Enterprise-Managed Authorization extension carries the same Identity Assertion JWT Authorization Grant between enterprise identity providers and MCP applications ([MCP-EMA]), a shipped surface for the pattern this profile attaches Mission context to.¶

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 (by requiring the grant profile's own mechanism, which the ID-JAG profile leaves OPTIONAL) and single use (Section 9, Section 10). 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 grant's position at the trust boundary demands them (Section 16.2), 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 10). 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 9).¶

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 8) and the signature alone; its assurance that the Mission was active is a lease bounded by the grant lifetime (Section 16.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.¶

The same composition extends to the proposed agent profile of Transaction Tokens ([I-D.draft-araut-oauth-transaction-tokens-for-agents]), whose agentic_ctx member carries roles, intent, and constraints along the call chain. The mission claim object is the natural anchor to carry there, inert as evidence exactly as in the chaining profile above, so call-chain intent context stays joined to the committed record instead of growing an unanchored twin of it.¶

7. Relationship to Mission Continuation

This section is informative. Mission Continuation ([I-D.draft-mcguinness-oauth-mission-continuation]) is the authorization-continuity profile: it defines how a Mission's authorization continues, under the same approval and constraints, while an identity-continuity transport re-establishes who is acting. This document's cross-domain grant is one of those transports, the one that carries a continuation ACROSS a trust boundary the origin does not control; Identity Continuation ([I-D.draft-mcguinness-oauth-id-continuation-assertion]) and async delegation ([I-D.draft-zhu-oauth-async-delegation]) are the intra-domain transports. What the profile adds over this document is the Mission binding common to every transport: a continuation handle grants nothing, each continued grant derives a subset of the Mission's authority and re-passes its active gate, so continuity is never authority. This document remains complete on its own: an issuer MAY project a Mission cross-domain without adopting the continuation profile, and a partner Resource AS honors the projected authority and resolves an audience-local subject exactly as specified here. Projection stays single-hop (Section 5) regardless of how many intra-domain hops continue the Mission on either side.¶

8. 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 10). 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. OpenID Federation for OpenID Connect 1.1 ([OIDF-FED]) is one possible mechanism for establishing and publishing this trust; nothing here requires or profiles it.¶

• 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 its proof-of-possession mechanism (Section 9); 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 10).¶

• Derivation records: whether the Resource AS keeps the per-token derivation record of Section 10. An originating AS MAY condition projection on it.¶

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 16.1) among its residual risks.¶

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

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

• MUST NOT have a lifetime exceeding 300 seconds (a short lifetime bounds cross-domain revocation latency; see Section 16.1);¶

• MUST have an exp that does not exceed the Mission's expires_at, per the issuance 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; this document defines no new PoP mechanism. For the RECOMMENDED profile that mechanism is the ID-JAG's own proof-of-possession ([I-D.draft-ietf-oauth-identity-assertion-authz-grant]): a cnf claim ([RFC7800]) carrying the jkt thumbprint ([RFC9449]) of the presenting client's key, control of which the client proves with a DPoP proof. That cnf is OPTIONAL in the ID-JAG profile; for Mission-bound cross-domain use it is REQUIRED, so the grant is never a bearer credential at the trust boundary (Section 16.2). A deployment MAY additionally sender-constrain the grant to a client certificate, a Mission profile of certificate-bound key confirmation aligning with the mTLS support ID-JAG is expected to add: for such a grant the cnf carries the certificate's x5t#S256 thumbprint ([RFC8705]) in place of a jkt, and the client proves control over an mTLS session. 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 10, [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 10).¶

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

ID-JAG defines the refresh-token subject mode ([I-D.draft-ietf-oauth-identity-assertion-authz-grant]) alongside its identity-assertion subject_token modes (id_token or saml2); this profile REQUIRES the refresh-token mode and restricts Mission cross-domain projection to it, 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 issuance 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 permits, 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 issuance 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 12).¶

Before issuing, the AS MUST verify:¶

• that 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, except through the cross-organizational delegation companion's verified attenuation chain ([I-D.draft-mcguinness-oauth-mission-cross-org-delegation]). Cross-domain issuance here always projects the agent's Mission authority; delegation within the target domain is performed by the Resource AS (Section 10). A sub-agent acting in a different trust domain under its own narrowed authority uses that companion's chain; this document's single hop does not cover it.¶

Two roles are distinct and easily 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 (Section 10; account linking stays local, and the Origin Principal profile standardizes the mapping input and its invariants, Section 11).¶

Sender-constraining is REQUIRED for the cross-domain grant, stronger than the RECOMMENDED level the issuance profile sets for the primary access token ([I-D.draft-mcguinness-oauth-mission], Section "Mission-Bound Access Tokens"): the grant's position at the trust boundary demands it (Section 16.2), and the underlying grant provides no replay backstop of its own.¶

10. 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 reject, with invalid_grant, a cross-domain grant whose signing iss does not equal its mission.issuer. The party that signs the grant MUST be the Mission's issuer; a trusted issuer that signs a grant carrying another issuer's mission.issuer is refused. This operationalizes the rule above: the Mission binding is honored only when the grant's own signer is the Mission Issuer named by mission.issuer, and that issuer is trusted. This applies to the cross-domain grant presented for redemption, not to the local token the Resource AS later mints, whose iss is the Resource AS while mission.issuer remains the originating AS.¶

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

  • 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 verify the grant's sender-constraint by the proof-of-possession mechanism the cross-domain grant profile defines. For the ID-JAG profile this is a DPoP proof ([RFC9449]) for the Resource AS's own token endpoint, presenting the key whose jkt thumbprint the grant's cnf claim ([RFC7800]) carries ([I-D.draft-ietf-oauth-identity-assertion-authz-grant]). Where the deployment uses the certificate-bound option of Section 9, the cnf carries an x5t#S256 thumbprint instead, and the Resource AS verifies that the presented mTLS client certificate's x5t#S256 ([RFC8705]) matches it. It MUST reject with invalid_grant a cross-domain grant that is not sender-constrained or whose proof-of-possession does not verify. A bearer grant MUST NOT be accepted: accepting one unbound would let any party that captured it mint a local token (Section 16.2).¶

  • Binding and verification MUST use the same mechanism.¶

• 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 9), the local token is bounded transitively;¶

  • MUST be sender-constrained ([RFC7800]), like the grant it derives from;¶

  • MUST NOT be issued as a bearer token; and¶

  • sets client_id to the client that requested this local token, the party that authenticated at redemption in the Resource AS's own namespace, per [RFC8693] Section 4.3 and [RFC9068] Section 2.2. It MUST NOT set client_id to the Mission's approved agent from the originating domain. The approved agent is not carried directly on this local token: it remains recoverable at the originating AS from the Mission Record identified by mission.id and mission.issuer. A Resource Server MAY impose stronger actor-chain requirements but MUST NOT reinterpret client_id.¶

• MUST bound the issued authorization_details by what the cross-domain grant conveyed. It 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 issuance 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 9), so the Resource AS's own delegation depth begins at 0. Such a delegated token's client_id is the local delegate, with that delegate as the outermost act, per the issuance profile's delegate model ([I-D.draft-mcguinness-oauth-mission], Section "Delegation Within a Mission"); that chain identifies delegates within this domain only. The Mission's originating approved agent is recoverable from the Mission Record, not from client_id or this domain's act chain.¶

• 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 16.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; without it, cross-domain minting is unaccountable to both domains. Whether the Resource AS keeps this record is a pre-established trust input (Section 8).¶

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

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 defines no universal account-linking protocol. 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. The Origin Principal profile (Section 11) standardizes the mapping input, the continuity invariant, and the authorization rule while leaving the mapping itself local. This document requires that the Mission binding (mission.id, mission.issuer, and authority_hash) and the audience-scoped authorization_details remain bounded as described here.¶

In the substrate's transition classification ([I-D.draft-mcguinness-mission-substrate]), the origin's audience-scoped projection is attenuate (a provable no-broader-than relation to the approved set) and the Resource AS's local re-mint is decide_anew (a fresh decision under local policy): local issuance is never a silent attenuation of the origin's authority.¶

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

11. The Origin Principal Profile

This OPTIONAL profile preserves the on-behalf-of principal across organizational boundaries and makes authorization at every point of use dual-axis: the agent's delegated authority and that principal's current entitlement are independent requirements. A deployment that does not claim it keeps this document's baseline unchanged.¶

Three identity roles are deliberately separate. The roles remain semantically distinct even when two identifiers happen to be equal, as with an identity-preserving mapping, a shared origin and destination issuer, or a service principal acting for itself:¶

"mission": {
  "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
  "issuer": "https://as.origin.example",
  "authority_hash": "sha-256:5bIi6JURtxBtod8WtezufytnypnNE86se44ndaL6-W0",
  "subject": { "iss": "https://id.origin.example", "sub": "p-7QxT2m" }
}

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

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

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

13. Introspection at a Resource AS

The issuance 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 MUST omit mission.state rather than report a stale value as current. 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 issuance profile defines one).¶

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

A Resource AS claiming the Origin Principal profile additionally reports mission.subject on this response, under that profile's disclosure rule (Section 11.6).¶

14. 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 issuance 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 8 are not discoverable and exist before first use.¶

15. Conformance

An implementation conforms in one of two roles and names the capability as the issuance 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 issuance profile that additionally:¶

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

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

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

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

A Resource AS:¶

• honors the cross-domain grant per Section 10, 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 10, Section 16.1);¶

• sets each local token's client_id to the redeeming client, never the Mission's approved agent (Section 10);¶

• fails redemption with the codes of Section 12;¶

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

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

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

Either role MAY additionally claim the Origin Principal profile (Section 11). The claim is per-deployment, independent of the base role, and covers each of the following as a distinct conformance item:¶

• identity-grant subject consistency at issuance and redemption (Section 11.2, Section 11.3);¶

• value invariance of mission.subject across every hop, projection, and response (Section 11.1);¶

• the origin-to-local mapping rules, including refusal on a stale, ambiguous, disabled, or tenant-wrong mapping (Section 11.3, Section 11.4);¶

• dual-axis authorization with a declared entitlement-freshness bound, failing closed (Section 11.5);¶

• the origin_principal introspection disclosure privilege, pinning both privileged disclosure and omission for an audience-authorized but unprivileged caller (Section 11.6);¶

• evidence mapping binding through the runtime evidence companion's principal_mapping object ([I-D.draft-mcguinness-mission-runtime-evidence]); and¶

• omission of the member from tokens for unrelated audiences (Section 11.6).¶

16. Security Considerations

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

17. Privacy Considerations

The Origin Principal profile makes an otherwise origin-local identity visible across audiences (Section 11): its linkability property is fixed at Mission creation (pairwise-at-origin by default, a per-Mission pseudonym for stronger unlinkability), participants in one Mission necessarily correlate within it, and the member never carries human-readable PII. Logs and evidence keep digests where the raw value is not needed (Section 11.6).¶

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

18. 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 issuance profile [I-D.draft-mcguinness-oauth-mission].¶

19. References

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

This appendix continues the end-to-end example of the issuance 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,
  "jti": "idjag_4Kp9sT2vN7xR1mZ8bQ",
  "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": "partner-agent-042",
  "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