Call chaining across domains: directed sub re-expression and iss:sub ↔ iss:sub mapping

[dickhardt]

Background

In call chaining (§Call Chaining / §Multi-Hop), a resource acts as an agent to access a downstream resource. The spec explicitly preserves the act delegation chain across the hop (Upstream Token Verification step 4: "nesting the upstream token's act claim inside a new act object… preserves the complete delegation chain") and uses the upstream iss for routing/trust. But it is silent on sub across a domain boundary.

The gap

sub in AAuth is directed and namespaced by issuer:

• "the same sub value from a different PS is a different subject" (§PS-asserted access)
• the PS provides "a directed sub identifier for the resource" (§AS Response, requirement=claims)

When chaining crosses domains, the downstream auth token is issued by a different iss and should carry a different directed sub for the same user. The chaining narrative never states this, nor how the downstream issuer obtains the right sub. A reader is left to infer it from the directed-sub rules in other sections.

Surfaced during review of #23 (sub-agents), via this worked example: across booking@domain1 → payments@domain2, the act chain carries through (agent identifiers are global) but sub must be re-expressed as domain-2's directed identifier for the same user.

What needs discussion

1. State the behavior: across a domain boundary the downstream token carries a new iss (the downstream issuer) and a new directed sub for the same user, while the act chain is preserved.

2. The mapping problem — how does one (iss, sub) map to another (iss, sub) for the same human?

   • The PS is the cross-domain identity anchor (it knows alice@domain1 ≡ alice@domain2). By what mechanism does it perform/assert the mapping?
   • Governed path (mission present): the PS brokers both hops and can supply the directed sub for the downstream resource via the claims flow. Spell this out.
   • Ungoverned four-party path (no mission, iss is an AS): there is no PS in the loop — the downstream AS receives only the upstream_token + the intermediary's agent token. How does it determine the user's directed sub in its own domain? Does it get a user sub at all, or only the agent act chain (i.e., agent-identity access with no user subject)?

3. Privacy: directed/pairwise sub means resources cannot correlate the user across domains. Confirm this property holds through chains and that nothing in the upstream token leaks a correlatable identifier downstream.

4. Should the upstream sub ever travel downstream at all, or only the downstream-issuer-asserted directed sub?

Related

• Add sub-agents — single-level depth, parent-mediated authorization #23 (sub-agents) — where this surfaced.