[OAUTH-WG] Re: New I-D: Identity Continuation Assertion for OAuth 2.0 Token Exchange (request for review)

[Karl McGuinness <[e-mail]>]

Mohamad,

Thank you for this, and no rush on the revision. I'm glad George connected
the threads. Your two questions draw the boundary more sharply than my
draft currently does.

The short version first: identity continuity is in scope for ICA.
Authorization continuity, carrying the decision itself forward, is out of
scope by design. Execution-time evidence was never in ICA's frame at all.
Each belongs in its own artifact. I'll make that boundary explicit in the
next revision so there is something stable to cite.

On your first question, the answer depends on which artifact you mean. The
Identity Continuation Assertion, the artifact a service presents at the
mint, carries no scopes, action classes, or constraint sets. The ID-JAGs on
either side of it can carry scopes and authorization_details, both the
grant that starts a chain and the one each mint produces, but those are the
identity provider's fresh per-hop decisions, not authorization state
carried forward from the upstream domain. That's the choice behind "a mint
rather than an attenuation": there is nothing in the assertion to
attenuate, so every hop is a fresh mint. Section 4 of the draft says it
directly. The mint is still bounded by the grant the chain roots in, the
identity provider's policy on who may continue, and revocation.

On your second question, I keep coming back to SSO, because it is the core
model behind ID-JAG and Cross App Access (XAA). Federation has always made
this split: the assertion carries who the user is into a new domain,
sometimes with attributes that inform the local decision, and the receiving
domain decides what the user may do there. The assertion is an input to
that decision, not the decision itself. ICA extends that split to the hops
a redirect cannot reach. Chains literally root in a grant or session the
identity provider already holds, the OIDC or SAML session itself among
them, and each mint continues the identity, with permissions decided fresh
at every hop. The identity provider is still not a bystander: it gates each
mint and shapes what may be requested of the next domain, while the
receiving authorization server makes the final decision for its own domain.
Two authorities, each deciding what is theirs to decide.

The comparison breaks in one important place, which is where working-group
discussion is most valuable. Classic SSO made its split with the human
present at each new domain, consenting at a screen. ICA extends it to the
hops where the human is absent by construction, so what the split leaves to
local policy carries more weight than it ever did in browser SSO. The draft
answers half of it: the root-chain envelope, whose every dimension is an
establishment-time ceiling that later policy may narrow but never broaden.
The other half is open item 9 in Appendix C, whether the envelope should
expose a testable representation of the authorization ceiling, and whether
that representation is scopes, an authorization detail, or something
policy-bound. If you read the open items, that one is closest to your
territory.

Your four-hop agent is a good test of what that leaves open. The identity
provider polices who may continue the chain and for how long, and it can
end the chain at the next mint. What nothing in the chain checks is whether
the fourth hop still matches what the human agreed to at the start. The
chain carries who is acting and what each domain may be asked. It does not
carry what the human approved to be done, which I think is the seam you
were pointing at.

Your agent-mandate-problem draft names that missing layer at T0: the
constraint set a human signs before the agent acts. To your closing
question: ICA does not carry constraint information across the mint, and
does not already answer what your draft states. That layer needs its own
artifact. Mission-Bound Authorization
<https://github.com/mcguinness/mission-bound-authorization> is one
approach: it governs the approved work itself, carrying the constraints,
approval evidence, and lifecycle independently of the identity chain.

PSEA sits at a third point. Where a mandate captures what was approved at
T0, PSEA produces evidence that a particular execution was authorized at
the moment it occurred. And you said it yourself with the offline user:
PSEA covers the hop where the human is present to prove it, ICA the hop
where they are not. Correct me if I have any of that wrong.

So I don't see competing approaches. I see three layers that compose:

   - identity continuity (ICA, issuing ID-JAGs): who is acting, and how
   that identity legitimately continues across domains,
   - authorization continuity (your mandate layer, with
   draft-mcguinness-oauth-mission
   <https://datatracker.ietf.org/doc/draft-mcguinness-oauth-mission/> as
   one proposed mechanism): what work remains authorized, under which
   constraints, on whose approval, and
   - execution-time evidence (PSEA): proof a specific action was authorized
   when it happened.

Each answers a question the others don't, and one artifact trying to carry
all three would do each job worse.

-Karl