---
title: "Re-Subjecting Is a Mint, Not an Attenuation"
date: "2026-06-08T09:00:00-07:00"
lastmod: "2026-06-08T09:00:00-07:00"
description: "Attenuation can narrow authority already represented by an artifact. It cannot create an authoritative binding to a target-local subject identifier. When a downstream domain names the user differently, an authority trusted for that mapping must mint new identity evidence."
summary: "In Cross-App Access, a single signed-in user\u0026rsquo;s identity has to cross applications that each name them under a different subject. Workload identity proves which service is calling, not which user delegated the work, and offline attenuation can narrow authority it already holds but cannot create a binding to a name it was never given. So crossing a subject namespace is a mint, not an attenuation: only the IdP or broker that owns the mapping can issue new audience-scoped identity evidence, while the destination Authorization Server still applies its own policy and mints the access token. The same shape holds on the authorization axis, where a different scope or policy model forces a non-amplifying re-mint rather than a narrowing. The open question is not whether that mapping authority is in the loop but how it is invoked: caller-pushed continuation, resource-pulled resolution, or another profile that preserves the trust invariant."
slug: "re-subjecting-is-a-mint-not-an-attenuation"
tags:
  - "Agentic Identity"
  - "ID-JAG"
  - "Identity Chaining"
  - "Transaction Tokens"
  - "OAuth"
  - "Delegated Authority"
  - "IAM"
  - "XAA"
  - "Standards"
---


A user signs into a travel app and books a trip. Filing the trip makes the travel app call the expense app, and submitting the expense makes the expense app call the corporate card ledger. One human, one sign-in, three applications, each behind its own Authorization Server, all federated to the same enterprise identity provider (IdP). The IdP is the common trust anchor for SSO and user subject resolution. This is the pattern now emerging as Cross-App Access.

It looks solved. The user is authenticated, the apps are federated, and OAuth has Token Exchange and assertion grants for crossing authorization domains. But the hard part is not merely getting a token from one domain to another. It is preserving the user when the next domain identifies that user in a different namespace. The two things you would reach for first, passing the calling service's own identity or narrowing a token you already hold, both fail at that, for the same structural reason.

That distinction matters because two operations are easy to conflate:

- **Attenuation** restricts authority already represented by an artifact.
- **Re-subjecting** creates an authoritative binding between the same person and a target-local subject identifier.

The first can sometimes happen offline. The second requires an authority trusted to make the identity binding.

Agents make the distinction urgent. A person used to click through each app and sign in again when a chain crossed a boundary. An assistant acting for the user now triggers these chains at machine speed, fans out to applications nobody enumerated when the task began, and cannot stop for a new browser flow at every hop. The system needs a non-interactive way to preserve both the user and the acting workload without letting either substitute for the other.

# The Problem

**Applications may name the same user differently.** In OpenID Connect, a pairwise Subject Identifier is unique per Sector Identifier, which may represent one relying party or a group of related relying parties. Other deployments use tenant-local identifiers, SAML NameIDs scoped to a Service Provider, or product-local account IDs. The travel app might know the user as `trav-9f2a`, the expense app as `exp-4a17`, and the ledger as `led-c7e0`. Nothing in those strings proves that they identify the same person.

The important boundary is therefore not "a new resource" by itself. It is a new **subject namespace**. The Resource Authorization Server for the ledger needs the identifier that its established SSO relationship uses for that user. Only an IdP or broker trusted for that relationship can authoritatively supply or validate the mapping.

**After the first hop, the interactive sign-in is no longer present.** The expense app received a service call from the travel app, not a browser session established directly with the IdP. It may have valid inbound user context, but it does not necessarily possess a reusable IdP identity assertion, know the ledger's subject identifier, or have authority to perform that translation itself.

**Workload identity alone is insufficient.** The expense service must authenticate as itself, with its SPIFFE or workload identity. That answers which software is making the request. It does not, by itself, answer which user delegated the work or which target-local account the ledger should use. A secure chain needs both:

- the authenticated workload or client, including delegated actor context where applicable; and
- the end-user context, translated into a subject namespace the target authorization domain understands.

The workload cannot stand in for the user, and the user context should not erase the workload. In OAuth terms these are distinct claims, not one blended identity. RFC 8693 Token Exchange makes the distinction explicit: in delegation, the token carries the user as its subject and the chain of acting workloads in the `act` actor claim; in impersonation, a party simply becomes the subject. Re-subjecting changes the subject for the next audience, while the actor chain carries the workload lineage forward.

Skip this and one of two things happens. Either the ledger cannot resolve the user and the call fails, or the expense service falls back to acting as itself and the charge posts under a service identity with no human behind it. The second is the dangerous one, because it looks like it worked. That is the confused deputy: a chain that should have stayed delegation silently downgrades to impersonation, and nothing in the protocol forces it to fail loudly.

# Why Attenuation Cannot Create the Next Subject

Offline attenuation takes an artifact and adds restrictions: fewer resources, fewer actions, a shorter lifetime, more caveats, or a narrower delegation. It is the model behind Macaroons, Biscuit, and the stacked delegation tokens now proposed for workload and agent chains. That is useful within one authorization model and can remain useful across domains when the receiving domain accepts the issuer, subject, and restriction semantics.

But attenuation cannot establish a fact the artifact does not already contain or authorize its holder to derive.

> Attenuation can narrow authority already represented by an artifact. It cannot authoritatively create a target-local identity binding that the artifact's issuer never supplied.

Suppose the expense app holds authority for the user identified as `exp-4a17`. Adding caveats can restrict what that authority permits. It cannot prove that `exp-4a17` corresponds to `led-c7e0`, because the ledger's identifier belongs to another namespace. That correspondence is an identity assertion, not a subset relation. You cannot narrow your way into a subject you were never given.

Which gives the narrower principle:

> Crossing a subject namespace is a **mint, not an attenuation**. An authority trusted for the mapping must issue new identity evidence for the target context.

This does not mean the IdP unilaterally grants access. Two different parties mint two different artifacts:

1. The IdP or mapping authority issues audience-scoped identity evidence using the subject identifier the target authorization domain expects.
2. The destination Authorization Server validates that evidence, applies its own authorization policy, and decides whether to mint an access token.

That separation is central to [ID-JAG Beyond the Enterprise IdP](/notes/id-jag-beyond-the-enterprise-idp/). The immediate IdP trusted by the Resource Authorization Server is authoritative for SSO subject resolution. The Resource Authorization Server remains authoritative for the local access decision.

# When Translation Is Not Required

Not every trust-domain crossing changes the subject.

Two applications may share a Sector Identifier, use the same public enterprise subject, or accept the same upstream subject namespace by agreement. In that case no subject translation is required. Offline attenuation may be possible if the destination also accepts the upstream issuer and understands the artifact's authority and restriction semantics.

That last condition matters. A shared subject does not eliminate every mint. The destination may still require:

- a grant addressed to its Authorization Server;
- a locally trusted issuer;
- destination-specific client and tenant binding;
- local scope or `authorization_details` evaluation; and
- a locally issued access token.

So there are two independent questions:

| Question | Consequence |
| --- | --- |
| Does the destination require a different subject namespace? | A trusted mapping authority must participate in subject translation. |
| Does the destination require a new locally trusted grant or access token? | An Authorization Server must perform destination-specific issuance. |

Pairwise subjects force the first operation when the target is in another sector or subject namespace. Crossing an authorization domain commonly forces the second. They often occur together, but they are not the same requirement.

The first question has a one-line test: does the next service name the user differently than the artifact you hold? If yes, no caveat you add gets you there, and someone has to mint.

Pairwise identifiers therefore create a deliberate tradeoff. They reduce direct cross-context correlation, but the mapping authority must remain available when an authorized workflow needs to bridge those contexts. The cost is not necessarily a user interaction. It is authoritative participation in the translation.

The second question deserves the same look, because it is also a mint, in a different dimension. The destination's Authorization Server may speak a different authorization language than the calling domain: different scope names, a different `authorization_details` schema, role and entitlement models that do not line up. The holder of the source grant cannot narrow its way into that language any more than into the target's subject namespace, because it cannot assert scopes it was never issued. A trusted Authorization Server has to mint a fresh grant that re-expresses the authority in the target's terms.

Attenuation does not vanish here; it changes role. On the subject axis it is simply the wrong operation. On the authorization axis it survives as a constraint on the mint: the re-expressed grant MUST be no broader than the source authority, never amplified. Call it a non-amplifying translation. The minting is what carries the authority across the vocabulary gap, and the no-broader-than rule is the ceiling that minting must respect. On either axis, what you cannot do is hand the destination your own token and expect it to narrow into something it can use.

# Why the Mapping Cannot Be Delegated Casually

Pairwise identifiers may be generated from a protected derivation key rather than stored in a literal lookup table. That does not change the trust model. The derivation capability is functionally part of the map.

Giving the expense app a key that can compute the user's identifier for arbitrary relying parties would let it link the user across those parties. It would also make the expense app another authority capable of asserting target-local subject bindings. That relocates the trust anchor and weakens the unlinkability that pairwise identifiers were intended to provide.

A deployment can deliberately establish multiple mapping authorities, federation brokers, or pre-provisioned bilateral mappings. But each of those is an explicit trust arrangement. None turns subject translation into ordinary attenuation performed by an otherwise untrusted token holder.

# Where Translation Can Occur

The current [OAuth Identity and Authorization Chaining Across Domains](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/) framework permits claims, including the subject identifier, to be translated during issuance of the cross-domain JWT authorization grant or when the destination Authorization Server issues its access token. In either placement, an Authorization Server trusted for the mapping performs the translation.

This is already taking shape as two sibling profiles of that framework, and both translate the subject rather than narrow it. The ID-JAG profile roots the chain in a human end-user's ID Token or SAML assertion under a pre-existing SSO relationship. The [Transaction Token Authorization Grant Profile](https://datatracker.ietf.org/doc/draft-fletcher-transaction-token-chaining-profile/) roots it in a Transaction Token, where the initiating principal may be a human, a system, or a workload, and crosses domains under a bilateral Cross-Domain Trust Agreement. That profile is explicit about the invariant: before it mints the cross-domain grant, the originating Authorization Server MUST translate the subject into a form meaningful and authorized in the destination domain. That is re-subjecting as a normative requirement, performed by the party trusted for the mapping.

Under the same-IdP SaaS assumption, two useful topologies are:

## Caller-pushed continuation

When the expense app needs to call the ledger, it returns to the IdP with fresh, sender-constrained evidence of the inbound delegated context and requests an audience-scoped assertion for the ledger's Resource Authorization Server. The IdP verifies that the chain may continue, resolves the target subject, and mints the assertion. The expense app presents that assertion to the ledger's Resource Authorization Server as a JWT authorization grant (RFC 7523), which applies local policy and mints the access token.

The current [ID-JAG](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/) draft accepts an OpenID Connect ID Token, SAML assertion, or optionally an IdP refresh token as the Token Exchange `subject_token`. It does not yet define the downstream continuation evidence needed when an intermediate SaaS has none of those artifacts.

The [Identity Continuation Assertion](https://mcguinness.github.io/draft-mcguinness-oauth-id-continuation-assertion/draft-mcguinness-oauth-id-continuation-assertion.html) fills that specific gap: a short-lived, sender-constrained assertion presented to the IdP only to request an onward ID-JAG. It is not itself an ID-JAG and does not grant API access.

This topology gives the IdP a fresh policy point at each continuation. Revocation, delegation state, actor authority, requested audience, and requested scope can all be evaluated before new identity evidence is issued.

## Resource-pulled resolution

The caller can instead present a sender-constrained continuation reference to the destination, and the destination can resolve it through a trusted broker or an introspection endpoint (RFC 7662). The broker still owns the mapping and the destination still makes the local authorization decision. The network direction changes; the trust invariant does not.

This topology can simplify the caller, but its privacy properties depend on the reference design. A universal reference visible to every application becomes a cross-context correlator. Audience-pairwise references avoid that direct linkage, but require the broker to maintain and resolve the projections.

These are not the only possible deployment topologies. Federation brokers, pre-provisioned target grants, and bilateral mappings can place the work differently. They remain valid only when the party performing subject translation is trusted to make that binding.

# Privacy Is an Artifact Property

Push is not automatically private, and pull is not automatically correlating. Privacy depends on which identifiers each artifact reveals to which party.

An ID-JAG is visible to the client that presents it. Depending on the deployment, it may carry the subject as `sub`, a target-audience-scoped subject identifier, a structured `sub_id` (RFC 9493), email, tenant information, or other subject-resolution claims. The IdP should include only the identifiers required by the target Resource Authorization Server and should avoid exposing a target-local identifier to intermediaries that do not need it.

The same rule applies to continuation references:

> Every intermediary-visible artifact should be audience-minimized and should avoid identifiers that let the intermediary link subject namespaces it was not already authorized to correlate.

The cleanest design keeps the canonical mapping inside the identity control plane and exposes only audience-specific projections. That principle applies whether the continuation request is pushed by the caller or pulled by the destination.

# Takeaway

Crossing a trust boundary and crossing a subject namespace are related, but they are not identical.

A destination Authorization Server may need to mint a new grant or access token because it owns local authorization. When the destination also names the user differently, an IdP or broker trusted for subject resolution must mint or validate new target-scoped identity evidence. Offline attenuation can narrow authority; it cannot manufacture that identity binding.

Design the chain around that invariant. Authenticate the workload, preserve the delegated user context, keep subject translation with an authority trusted for the target namespace, and let the destination Authorization Server make the final access decision.

The test is simple. If the next hop renames the user, you are minting, not narrowing, and you cannot narrow your way into a subject you were never given. Design for the mint.