Network Working Group K. McGuinness Internet-Draft Independent Intended status: Standards Track 4 July 2026 Expires: 5 January 2027 Mission Cross-Domain Projection for OAuth 2.0 draft-mcguinness-oauth-mission-cross-domain-latest Abstract The Mission-Bound Authorization for OAuth 2.0 profile binds issued authority to a durable, human-approved Mission held by a single Authorization Server, the Mission Issuer. This document specifies that profile's optional cross-domain projection: a single hop that lets an Authorization Server in another trust domain, a Resource AS, honor a Mission it did not issue. The Mission Issuer projects audience-scoped Mission authority in a short-lived, sender- constrained cross-domain grant of the OAuth identity chaining architecture; the Resource AS validates the grant and mints its own local tokens, preserving the Mission binding unchanged. The Identity Assertion Authorization Grant (ID-JAG) is the recommended grant profile. Single-domain deployments of the base profile are unaffected by this document. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://mcguinness.github.io/draft-mcguinness-oauth-mission/draft- mcguinness-oauth-mission-cross-domain.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft- mcguinness-oauth-mission-cross-domain/. Source for this draft and an issue tracker can be found at https://github.com/mcguinness/draft-mcguinness-oauth-mission. 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 5 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 2. Status: An OPTIONAL Extension 3. Conventions and Terminology 4. Cross-Domain Projection 5. Audience-Scoped Authority 6. Issuing the Cross-Domain Grant 7. Validation at the Resource AS 8. Introspection at a Resource AS 9. Security Considerations 9.1. Cross-Domain Revocation Latency 9.2. The Grant at the Trust Boundary 10. Privacy Considerations 11. Conformance 12. IANA Considerations 13. References 13.1. Normative References 13.2. Informative References Appendix A. End-to-End Example (Non-Normative) A.1. Stage 2: Cross-Domain Projection via ID-JAG (Between Domains) A.2. Stage 3: The Resource AS Issues a Local Access Token A.3. Stage 4: The Resource Server Enforces A.4. Stage 5: Internal Call Context via Transaction Tokens A.5. Stage 6: The Internal Service Enforces A.6. What Rode Through, and What Narrowed Author's Address 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, origin 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 origin) 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. 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. 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 origin), 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 6), 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 7). 4. Cross-Domain Projection A Mission is approved and held by one Mission Issuer (its origin). 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 origin 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 6). 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 6 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 6, Section 7). 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 origin) 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. Audience-Scoped Authority When projecting authority toward a Resource AS, the Mission Issuer includes only the Authority Set entries whose resource that Resource AS is authoritative for, under the deployment's resource-to-AS mapping. Entries for other Resource ASes MUST NOT be disclosed. 6. 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"). A Mission-bound cross- domain grant: * MUST be a JWT authorization grant issued and signed by the Mission origin, redeemable at the target Resource AS through the [RFC7523] JWT-bearer grant; * 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 9.1); * MUST have an exp that does not exceed the Mission's mission_expiry, 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 (for the ID-JAG profile, as that specification defines). 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, 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 7). 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 7, [RFC7523] Section 3); * MUST carry the mission claim ([I-D.draft-mcguinness-oauth-mission], Section "The Mission Claim") with id, origin, and authority_hash unchanged from the Mission, and the audience-scoped authorization_details (Section 5); and * MUST convey the Mission's Subject in the form the identity chaining architecture defines, so the Resource AS can resolve it locally (Section 7). 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. 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. This profile intentionally fixes the refresh-token subject mode to remove any ambiguity about which Mission authority a cross-domain grant projects: the refresh token resolves to exactly one Mission and its full authority, whereas an access token or delegated token could carry a narrowed or actor-specific subset. The cost is that this optional cross-domain binding is unavailable to a deployment that issues no refresh token; such a deployment uses the single-domain base profile, which needs no refresh token. 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. 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. This profile defines only the refresh-token subject_token mode above. Other Mission-bound subject-token modes, such as an access-token subject mode (which would have to bound the projected authority by the presenting token rather than by the full Mission Authority Set), are left to future profiles. Excluding the access-token subject mode here is a deliberate choice: it avoids propagating a narrowed or delegated authority across a trust boundary, where it could be re- widened. A deployment that does not issue the agent a Mission refresh token therefore cannot use this OPTIONAL cross-domain hop as defined here. 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 7). 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 7). 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. 7. 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.origin merely because it appears inside a signed assertion. * MUST validate the grant's signature and expiry, and verify its aud is the Resource AS's own identifier, rejecting a grant minted for a different Resource AS. * 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 6, 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, origin, and authority_hash) unchanged from the cross-domain grant. The issuing iss is the Resource AS; mission.origin 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 mission_expiry; because the grant's own exp is bounded by mission_expiry (Section 6), 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 origin 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 6), so the Resource AS's own delegation depth begins at 0. 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.origin, 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. 8. Introspection at a Resource AS The base profile's OPTIONAL token introspection ([RFC7662]) reports a mission response member, and only the Mission origin reports the Mission's lifecycle state ([I-D.draft-mcguinness-oauth-mission], Section "Mission State via Token Introspection"). This section specifies the non-origin 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, origin, 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 origin 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 origin'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"). 9. 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. 9.1. Cross-Domain Revocation Latency Single-domain revocation is prompt: the AS that issued a token also honors its revocation ([I-D.draft-mcguinness-oauth-mission], Section "Revocation"). The cross-domain case is strictly weaker. When a Mission is revoked at the originating AS, that AS can stop issuing new cross-domain grants, but it cannot revoke a token a Resource AS has already minted in another domain: that token remains valid until its own expiry. Cross-domain revocation latency is therefore the downstream token lifetime. For this reason, Resource ASes MUST issue short-lived local tokens for Mission-bound interactions; the originating AS bounds grant lifetimes by the 300-second cap of Section 6, so a revoked Mission cannot continue to seed new downstream tokens for long. The base profile's token introspection closes the revocation gap only single-domain: it requires the introspecting AS to hold the Mission, and a Resource AS has no query to the origin keyed by mission_id (Section 8), so short downstream lifetimes remain the only cross-domain control. Deployments needing tighter cross-domain revocation can add the status or event-distribution mechanisms specified separately by Mission Status [I-D.draft-mcguinness-oauth-mission-status] and Mission Lifecycle Signals [I-D.draft-mcguinness-oauth-mission-signals], which this document does not require. 9.2. The Grant at the Trust Boundary The cross-domain grant is the highest-authority credential in the chain and the only one that crosses a trust boundary. The requirements of Section 6 and Section 7 follow from that position: issuer trust is established by local policy or metadata, never inferred from a signed assertion's own mission.origin; the grant is sender-constrained and one-time-use, because the underlying grant profile provides no replay backstop of its own; and everything the Resource AS honors is bounded by the audience-scoped entries the grant conveyed, interpreted fail-closed. Downstream of the origin, authority_hash is an audit and correlation anchor, not a recomputable proof: its integrity rests on the signature chain (Section 7). 10. Privacy Considerations The cross-domain grant and every local token minted from it carry the canonical mission_id, mission.origin, and authority_hash unchanged, so a Resource AS and its Resource Servers can correlate a Mission's activity across domains, and mission.origin 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) is the minimization measure: a Resource AS never sees Authority Set entries addressed to other audiences. 11. Conformance An implementation conforms in one of two roles. An *Originating Mission Issuer with Cross-Domain* is a conforming Mission Issuer of the base profile ([I-D.draft-mcguinness-oauth-mission], Section "Conformance") that additionally issues the Mission-bound cross-domain grant per Section 6, including the audience scoping of Section 5. A *Resource AS* honors the cross-domain grant per Section 7 and, where it offers token introspection for its local tokens, follows Section 8. A Resource AS is not required to implement the base profile's Mission Issuer role; it never creates or alters a Mission (Section 4). 12. 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]. 13. References 13.1. Normative References [I-D.draft-ietf-oauth-identity-assertion-authz-grant] Parecki, A., McGuinness, K., and B. Campbell, "Identity Assertion JWT Authorization Grant", Work in Progress, Internet-Draft, draft-ietf-oauth-identity-assertion-authz- grant-04, 21 May 2026, . [I-D.draft-ietf-oauth-identity-chaining] Schwenkschuster, A., Kasselman, P., Burgin, K., Jenkins, M. J., Campbell, B., and A. Parecki, "OAuth Identity and Authorization Chaining Across Domains", Work in Progress, Internet-Draft, draft-ietf-oauth-identity-chaining-16, 26 June 2026, . [I-D.draft-mcguinness-oauth-mission] McGuinness, K., "Mission-Bound Authorization for OAuth 2.0", Work in Progress, Internet-Draft, draft-mcguinness- oauth-mission, 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May 2015, . [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, . [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- Possession Key Semantics for JSON Web Tokens (JWTs)", RFC 7800, DOI 10.17487/RFC7800, April 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, . [RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", RFC 8705, DOI 10.17487/RFC8705, February 2020, . [RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, . [RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, . 13.2. Informative References [I-D.draft-ietf-oauth-transaction-tokens] Tulshibagwale, A., Fletcher, G., and P. Kasselman, "Transaction Tokens", Work in Progress, Internet-Draft, draft-ietf-oauth-transaction-tokens-08, 2 March 2026, . [I-D.draft-mcguinness-mission-runtime] McGuinness, K., "Mission-Bound Runtime Enforcement", Work in Progress, Internet-Draft, draft-mcguinness-mission- runtime, 2026, . [I-D.draft-mcguinness-oauth-mission-signals] McGuinness, K., "Mission Lifecycle Signals for OAuth 2.0", Work in Progress, Internet-Draft, draft-mcguinness-oauth- mission-signals, 2026, . [I-D.draft-mcguinness-oauth-mission-status] McGuinness, K., "Mission Status and Lifecycle for OAuth 2.0", Work in Progress, Internet-Draft, draft-mcguinness- oauth-mission-status, 2026, . 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.origin, 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.origin 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 max_amount_usd: 500. The Mission was recorded active with authority_hash sha- 256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ and intent_hash sha- 256:wQ7p4LHnX9Md0LqJ6sZJ8b8mZ3rN2xT5pV4lE6sQqYY. 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. A.1. Stage 2: Cross-Domain Projection via ID-JAG (Between Domains) The agent needs the partner ERP, behind the Resource AS ras.partner.example.com. It presents its Mission refresh token as the subject_token of a token exchange requesting an ID-JAG (Section 6); the home AS resolves the Mission from that grant, gates on Mission active, and mints a Mission-bound ID-JAG audienced to that Resource AS, carrying the mission claim and the audience-scoped authority for the ERP: { "iss": "https://as.example.com", "aud": "https://ras.partner.example.com", "sub": "user_3p2q8mN1a0kV7tR", "client_id": "s6BhdRkqt3", "iat": 1797840000, "exp": 1797840300, "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_usd": 500 } } ], "mission": { "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-", "origin": "https://as.example.com", "authority_hash": "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ" } } The ID-JAG is short-lived (300 s) and sender-constrained to the agent. Its exp does not exceed mission_expiry (Section 6). A.2. Stage 3: The Resource AS Issues a Local Access Token ras.partner.example.com validates the ID-JAG (Section 7): it establishes issuer trust in as.example.com, verifies the signature, checks that aud is itself, checks the expiry, and verifies the sender-constraint proof. It then issues its own access token for the ERP, preserving the mission claim unchanged and capping exp at the ID-JAG's exp: { "iss": "https://ras.partner.example.com", "aud": "https://erp.partner.example.com", "sub": "partner-user_7Kp4QnZ2vR9s", "client_id": "s6BhdRkqt3", "iat": 1797840030, "exp": 1797840290, "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_usd": 500 } } ], "mission": { "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-", "origin": "https://as.example.com", "authority_hash": "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ" } } The issuing iss is now the Resource AS, but mission.origin remains the home AS. The token's exp (1797840290) is below the ID-JAG's (1797840300) and far below mission_expiry. The Resource AS-local sub is illustrative; its value is determined by the subject-resolution rules of the ID-JAG and identity chaining profiles, not by this document. Revoking the Mission now stops new ID-JAGs, but the local token the Resource AS minted stays usable until its exp (260 seconds), bounded by the 300-second ID-JAG cap (Section 9.1). Tighter cross-domain revocation is opt-in, and the two companions do different things: a Mission Status freshness lease shortens how long the partner relies on stale state by forcing a pull or per-request re-check, while a Mission Lifecycle Signal notifies the partner on a Mission transition so it can react without polling. The Resource AS holds only this audience's subset and cannot recompute authority_hash. To show its local token did not widen beyond the ID-JAG, it SHOULD record, per minted token, both sides of the derivation: the consumed ID-JAG's jti and conveyed authorization_details, and the local token's own identifier or digest (jti), iss, aud, iat, exp, and issued authorization_details. An auditor can then identify the exact local token, tie it to the grant it was minted from, and check its authority is a subset of that grant. A.3. Stage 4: The Resource Server Enforces The agent calls the ERP Resource Server (erp.partner.example.com) with that token. The Resource Server validates the JWT and the cnf binding and enforces the authorization_details whose resource it serves, permitting invoices.read and journal-entries.write up to max_amount_usd: 500 ([I-D.draft-mcguinness-oauth-mission], Section "Resource Server Enforcement"). It treats the mission claim as an audit anchor; holding only this audience's subset of the Authority Set, it does not recompute authority_hash. This is stateless enforcement from the token alone. journal- entries.write is a consequential write, so where the partner deploys the runtime profile ([I-D.draft-mcguinness-mission-runtime]) it also obtains a point-of-use PDP permit against current Mission state before executing. The baseline bounds the write only by token lifetime and max_amount_usd. A.4. Stage 5: Internal Call Context via Transaction Tokens To serve the request, the ERP Resource Server calls internal services inside the partner trust domain. Here it calls a ledger service for one invoice. The Resource Server is the entry edge of that domain: after it has validated the Mission-bound access token, it obtains a short-lived Transaction Token for the internal call. The following shows one illustrative way the Mission context could ride in that Transaction Token. This is not a Mission-derived OAuth access token, and this document does not define the Transaction Token claim names or issuance rules. The important point is that the local context can keep the Mission anchor while narrowing the internal operation: { "iss": "https://txn.partner.example.com", "aud": "https://ledger.partner.example.com", "sub": "partner-user_7Kp4QnZ2vR9s", "tid": "txn_5kQ9pX2vN7sR1tY8mZ3", "iat": 1797840060, "exp": 1797840120, "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-", "origin": "https://as.example.com", "authority_hash": "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ" } } The Transaction Token is intra-domain and the shortest-lived credential in the chain (60 s). The holder has changed: the Resource Server's workload, not the agent, possesses it. The local context has narrowed again, to one ledger lookup for one invoice, while the mission anchor is unchanged. A.5. Stage 6: The Internal Service Enforces The ledger service receives the Transaction Token, validates it under partner-domain policy, reads the Mission context and local transaction authorization, and enforces them for the internal operation. Like every consumer downstream of the home AS, it treats authority_hash as an audit and correlation anchor it cannot recompute, and it makes no call to mission.origin. A.6. What Rode Through, and What Narrowed +=================+================+============+============+ | Hop (mechanism) | Mission anchor | Authority | Expiry | | | | or context | | +=================+================+============+============+ | ID-JAG (between | unchanged | ERP: read | 1797840300 | | domains) | | + write | | +-----------------+----------------+------------+------------+ | Resource AS | unchanged | ERP: read | 1797840290 | | token | | + write | | +-----------------+----------------+------------+------------+ | Txn Token | unchanged | one ledger | 1797840120 | | (within domain) | | lookup | | +-----------------+----------------+------------+------------+ Table 1 The Mission anchor (id, origin, authority_hash) is constant end to end. OAuth authority is preserved or narrowed at the cross-domain boundary, and local transaction context narrows the internal operation inside the partner domain. The lifetime shrinks at every hop and never exceeds mission_expiry. The ID-JAG carried identity _between_ trust domains; the Transaction Token carried context _within_ one. The Mission bound both. Author's Address Karl McGuinness Independent Email: public@karlmcguinness.com