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
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
