Mission Cross-Organizational Delegation for OAuth 2.0

Status of This Memo

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

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

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

This Internet-Draft will expire on 23 February 2027.¶

Copyright Notice

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

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

Table of Contents

1. Introduction

The Mission family separates two verbs that cross-organizational deployments need together. Project makes Mission authority consumable in a resource domain: single-hop, issuer-mediated, audience-scoped ([I-D.draft-mcguinness-oauth-mission-cross-domain]). Delegate gives a different actor a narrowed slice it may exercise or further narrow. Within one domain, delegation is Authorization-Server-mediated Token Exchange or holder-mediated offline attenuation ([I-D.draft-mcguinness-oauth-mission-attenuation]). What no family document previously covered is the recursive cross-organizational case identified by workload-identity delegation work ([I-D.ietf-wimse-arch]): agent A in organization 1 delegates a narrowed slice to agent B in organization 2, B delegates further, and the final relying party verifies every narrowing without a callback.¶

This document defines that case as a profile of Mission Offline Attenuation. The attenuation chain already carries the complete parent chain and verifies signature, capability monotonicity, audience, expiry, depth, proof of possession, and an unchanged Mission binding; this profile carries it across organizational trust boundaries, adds the actor-identity and origin-principal rules those boundaries require, and defines how a destination consumes the verified chain.¶

2. Status: An Experimental Extension

This profile is experimental, and it profiles an experimental substrate: it inherits the maturity of Mission Offline Attenuation and the attenuating-agent-token substrate that document profiles ([I-D.draft-niyikiza-oauth-attenuating-agent-tokens]). The issuer-mediated alternative, a chain of Token Exchange re-issuances whose evidence layer is the actor-suite companions (issuer-signed hop receipts, actor-signed hop proofs, and recorded authority bounds), is documented as related work and is not defined here; maintaining two wire formats in a first revision would make interoperability worse. A family profiling of Actor Chain Authority Bounds is constrained ahead of time: every in-Mission basis-reset or widening mechanism, including a domain-transition reset, is prohibited; a new authority basis is an Expansion successor or another fresh approval ([I-D.draft-mcguinness-oauth-mission-expansion]).¶

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 Mission family's terms from the issuance profile ([I-D.draft-mcguinness-oauth-mission]) and the chain terms of Mission Offline Attenuation ([I-D.draft-mcguinness-oauth-mission-attenuation]).¶

Cross-Organizational Mission Delegation Chain (the Chain):

a Mission-bound attenuation root plus zero or more attenuation children, presented in root-to-leaf order using the attenuation substrate's chain serialization and token-type identifier.¶

Chain-verifying consumer:

a relying party that receives and verifies the complete Chain.¶

AS-mediated consumer:

a Resource Server that trusts a local token its Resource Authorization Server minted after verifying a Chain, and does not claim to have independently verified the Chain.¶

4. The Delegation Chain

A Chain's signed hops carry the semantics; no addition to mission_intent and no new PAR parameter collection is introduced. authority_hash remains a commitment to the complete approved Authority Set and an audit correlator: it does not prove that a narrowed entry was a member of that set. The signed root and the verified per-hop subset relations provide that proof.¶

5. Root Issuance

The originating Mission Issuer MAY issue a cross-organizational attenuation root only when all of the following hold:¶

1. the Mission is active;¶

2. the root's authorization_details is exactly the mapped attenuating-agent-token capability entry produced by the attenuation profile's root mapping ([I-D.draft-mcguinness-oauth-mission-attenuation]) from Authority Set entries within the Mission Authority Set; a generic authorization-details entry does not transfer, and support for another type requires a registered, deterministic per-type mapping and subset algorithm;¶

3. the mapping profile and its version are recorded in the issuance derivation record;¶

4. every mapped entry is delegable and the root depth does not exceed its approved delegation.max_depth;¶

5. the root aud is an approved destination or audience set;¶

6. the root is sender-constrained to the approved agent's workload key;¶

7. deployment policy permits the named authority and subject class to cross the named trust boundary; and¶

8. the root carries the issuer-asserted act naming the approved agent under the resolution procedure of Section 4.3, the root presenter's public key as cnf.jwk, and the mission claim including subject.¶

An entry with a deployment-private action, constraint, matcher, or resource identifier whose meaning the destination cannot resolve MUST be omitted. It MUST NOT cross under a promise that the destination will interpret prose or issuer-local policy.¶

6. Per-Hop Derivation

A holder creates a child exactly as Mission Offline Attenuation specifies, with these profile rules:¶

1. sign the child with the key bound by the parent's cnf;¶

2. bind the child to the exact parent through par_hash;¶

3. narrow or preserve the mapped capability entry under the attenuation substrate's tool and constraint subset model; no other authorization-details entry is added;¶

4. keep aud equal to or narrower than the parent's;¶

5. set exp no later than the parent's and no later than the destination trust policy permits;¶

6. increment del_depth without resetting it at any organizational boundary, and preserve del_max_depth;¶

7. keep the mission claim value-invariant, including subject;¶

8. set this hop's act to the actor receiving the delegation; and¶

9. bind the child to the recipient workload's own proof-of-possession key, carried as the child's public cnf.jwk.¶

The recipient proves possession of the leaf key at redemption or direct resource access.¶

7. Trust Model

"No interaction-specific bilateral agreement" does not mean "trust any issuer." A conforming deployment MUST hold a federation or administrative policy that maps:¶

• trust-domain identifiers to accepted workload-identity trust anchors;¶

• Mission Issuers to accepted signing keys and key-status sources;¶

• actor-identity attestation sources: the anchors that bind an issuer-qualified (act.iss, act.sub) to a workload key (Section 4.3);¶

• resource identifiers to the Resource AS or RS authorized to consume them;¶

• authorization-details types and constraint registries to supported versions; and¶

• freshness ceilings for issuer metadata, key status, and Mission state.¶

The secure mapping from a trust-domain name to anchors is an explicit deployment dependency the workload-identity architecture leaves out of scope ([I-D.ietf-wimse-arch]). Cached issuer metadata, key status, and Mission state follow the substrate's Bounded Reliance floor ([I-D.draft-mcguinness-mission-substrate]): maximum age declared, missing or stale required state failing closed. This meets "no callback to the origin on the request path"; it does not claim instantaneous revocation.¶

8. Destination Verification

A Resource AS or chain-verifying Resource Server MUST perform the following, in order:¶

1. resolve the origin Mission Issuer to an accepted trust domain and verification keys through the trust model, never because the Chain names it;¶

2. validate the root: substrate type, signature, time bounds, Mission-Issuer equality, the issuer-asserted root act, and the mission claim including subject;¶

3. validate every par_hash link and every child signature through the leaf, verifying each child with the public key carried in its parent's cnf.jwk;¶

4. verify the mission invariants unchanged across all hops: value equality of id, issuer, authority_hash, and subject;¶

5. verify monotonic del_depth, the preserved del_max_depth, nested aud and exp, and the mapped capability entry's subset relation at every hop under the attenuation substrate's tool and constraint model; an authorization-details entry of an unknown or unmapped type MUST NOT be treated as conferred authority, and its presence beyond the mapped entry refuses the Chain;¶

6. classify each hop as named (act present with its aligned credential validated per Section 4.4) or key-only (act absent), refusing a named hop whose credential is missing, misaligned, or invalid, and failing closed where policy requires a named actor and the hop is key-only;¶

7. reconstruct the ordered actor history from the validated artifacts, rejecting conflicting or duplicated representations;¶

8. verify the leaf presenter's proof of possession; identity verification never substitutes for the authority-chain checks;¶

9. establish that the Mission is active from a locally available state source within the deployment's declared freshness bound ([I-D.draft-mcguinness-oauth-mission-status]; Bounded Reliance, Section 7); and¶

10. authorize dual-axis under the Origin Principal profile ([I-D.draft-mcguinness-oauth-mission-cross-domain]): the verified delegated authority, the current entitlement of the mapped origin principal, and local resource policy are independent requirements, each within its declared freshness.¶

In the substrate's transition classification ([I-D.draft-mcguinness-mission-substrate]), every verified hop is attenuate; the destination's own decisions under local policy are decide_anew.¶

9. Local Projection

When a Resource AS mints a conventional local token from a verified Chain, it MUST:¶

• carry only the locally permitted subset;¶

• preserve the mission claim invariants, including subject;¶

• restart the local act chain at the local delegate (the cross-domain rule; [I-D.draft-mcguinness-oauth-mission-cross-domain]);¶

• bind the token to the local presenter;¶

• cap its expiry by the leaf and local policy; and¶

• record in derivation evidence: the Chain digest, the leaf jti, the input and output authority, the reconstructed actor lineage, the policy version, and the principal_mapping object ([I-D.draft-mcguinness-mission-runtime-evidence]).¶

A local access token is not a new portable delegation root. Recursive cross-organizational delegation continues from the verified attenuation Chain, never from a locally projected token that has lost the parent proof.¶

10. Provenance for AS-Mediated Consumption

An AS-mediated consumer needing provenance of the upstream hops uses one of:¶

• the validated Chain carried alongside the local token; or¶

• the destination AS's introspection or evidence resolution over its recorded derivation evidence (the chain digest, reconstructed actor lineage, and principal_mapping of Section 9).¶

Issuer-signed hop receipts belong to the issuer-mediated lane: a destination AS MUST NOT manufacture receipts for holder-created hops. A signed chain-verification attestation, an AS statement that it verified a Chain and survives the local token's expiry, is deferred to a companion until a consumer demonstrates that these two modes are insufficient.¶

11. Capability and Discovery

This profile defines no runtime discovery. The attenuation substrate's issuer discovery advertises root issuance only; it does not advertise Chain acceptance, projection support, or consumption class. A deployment declares the cross_org_delegation capability, its consumption class (Section 12), and its accepted trust domains explicitly in its deployment profile and federation agreements, and consumes the capability under the family's declared-consumption rule.¶

12. Conformance

A deployment claims one or both consumption classes:¶

• Chain-verifying: the relying party receives and verifies the complete Chain per Section 8.¶

• AS-mediated: an RS trusts its Resource AS's locally issued token and does not claim independent verification of the Chain; provenance uses Section 10.¶

Positive and negative vectors cover, at minimum: a valid three-domain A to B to C chain; action, resource, amount, audience, or expiry widening at either hop; constraint removal, including requires_action_approval: true; parent-hash substitution, a reordered or missing hop, a changed Mission binding including subject, and an untrusted root; a root missing the issuer-asserted actor; a named-actor hop without a validated binding influencing authorization (it must not); a duplicated or conflicting actor representation (a nested history smuggled onto a hop); depth reset at an organizational boundary and depth overflow; a wrong leaf proof-of-possession key; an unknown authorization-details type, action, constraint, or subset algorithm; a revoked or expired Mission, a compromised signing key, and stale or unavailable state; a locally projected token offered as the parent of a new hop; a Presentation with an unknown top-level member, an unknown actor-credential type, a misaligned hop index, or an over-bound size; a chain whose hops carry thumbprint-only confirmations; a named hop whose credential subject differs from its act, whose bound key differs from the hop cnf.jwk, or whose credential issuer is untrusted, expired, or revoked; an unmapped authorization-details entry beyond the mapped capability entry; and valid delegated authority denied by local entitlement or local policy.¶

13. End-to-End Example (Non-Normative)

Organization 1's Mission Issuer resolves approved client agent-a to the canonical actor {"iss": "https://id.org1.example", "sub": "wl-agent-a"}, records the mapping and version, and mints the root: typ per the substrate, iss the Mission Issuer, aud ["https://api.org3.example"], cnf.jwk agent A's public key, the mapped capability entry, del_depth 0, del_max_depth 2, act naming agent A, and the mission claim with id, issuer, authority_hash, and subject.¶

Agent A delegates to organization 2's agent B: it signs a child with its own key (the pair of the root's cnf.jwk), par_hash over the root, the capability entry narrowed, aud unchanged, exp shortened, del_depth 1, cnf.jwk agent B's public key, and act naming B. Agent B delegates once more to its worker C the same way, key-only: the second child carries no act.¶

The worker presents the Chain at organization 3's Resource AS:¶

POST /token
grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&subject_token=<base64url({"chain":[root,hop1,hop2],
  "actor_credentials":[{"hop":1,"type":"wimse-wit",
  "credential":"..."}]})>
&subject_token_type=
  urn:ietf:params:oauth:token-type:mission-delegation-chain
&requested_token_type=urn:ietf:params:oauth:token-type:access_token
&audience=https://api.org3.example

with DPoP proving possession of C's key, the leaf cnf.jwk. The Resource AS runs Section 8: trust resolution; root validation including the issuer-asserted act and mission.subject; both par_hash links and child signatures under the carried public keys; invariants, depth, audience, expiry, and the mapped-capability subset at each hop; hop classification (hop 1 named and credential-validated, hop 2 key-only); leaf proof of possession; Mission state within its declared freshness; and the dual-axis rule over the mapped origin principal. It then mints a local token: iss the Resource AS, sub the mapped local principal, client_id the presenting client, a local act naming the worker's local registration, the mission claim unchanged including subject, authority the locally permitted subset, and expiry capped by the leaf. Its derivation evidence records the chain digest, the leaf jti, the input and output authority, the reconstructed lineage A to B to C, the policy version, and the principal_mapping object.¶

14. Security Considerations

The attenuation profile's security considerations apply in full. Its kill-switch conditions apply as that document specifies them; this document's own mandatory state check is step 9 of Section 8, whose state source ([I-D.draft-mcguinness-oauth-mission-status]) is a normative dependency. Every JWT this profile handles follows the JWT best current practices ([RFC8725]): explicit typing, algorithm allow-lists, and no unverified pass-through. This profile adds the cross-organizational surface.¶

• Compromised delegation keys. A compromised hop key mints narrower children offline. Depth and lifetime ceilings, the audience funnel, conservative del_max_depth, and leaf or key deny lists bound the blast radius; whole-Mission revocation stops the Chain at every state-checking consumer but does not selectively revoke a branch. No instantaneous branch revocation exists in this revision.¶

• Holder-asserted identity. Without the binding rule of Section 4.3, a holder could name any actor and have policy trust it. The rule makes unverified names inert; the failure mode is attribution loss, never authority gain.¶

• Origin non-observability. The origin cannot observe offline fan-out. Deployments requiring fan-out observability use issuer-mediated delegation or the runtime profile's enforcement surfaces ([I-D.draft-mcguinness-mission-runtime]).¶

• Chain-size exhaustion. Chains grow linearly with depth and verification cost is linear in hops. A verifier declares and enforces maximum hops, maximum artifact size, and a verification-cost ceiling, refusing above them.¶

• State staleness. Cached state substitutes bounded staleness for a synchronous origin dependency; the bound is declared and exceeded state fails closed (Section 7).¶

15. Privacy Considerations

The Chain discloses issuer-qualified actor identifiers and the origin principal along its path. Actor identifiers are correlation handles: the pairwise and pseudonym guidance the Origin Principal profile states for mission.subject applies to actor identifiers alike, and the origin principal's own disclosure, minimization, and evidence rules apply unchanged ([I-D.draft-mcguinness-oauth-mission-cross-domain]). A Chain is audience-narrowed by construction; a hop's aud never widens, so disclosure is bounded by the root's audience set.¶

16. IANA Considerations

17. References

Acknowledgments

The cross-organizational deployment class and its verification requirements were articulated by the WIMSE cross-organization delegation work, whose problem statement this profile answers with the Mission family's existing attenuation substrate.¶

Author's Address