Hi all, I've posted a new individual Internet-Draft, Identity Continuation Assertion <https://datatracker.ietf.org/doc/draft-mcguinness-oauth-id-continuation-assertion/> (ICA), and would welcome the group's review.
Agents and long-running jobs increasingly keep working on a user's behalf, calling one service after another across trust domains. Often the user is not present at the hop to authorize the next step. Sometimes they have gone offline. Other times they are online, but a downstream service-to-service call has no user-agent in the path. Either way, redirecting the user's browser to the identity provider for a fresh grant is not an option. This came up in the ID-JAG discussion of public agents behind an API gateway or proxy (issue #114 <https://github.com/oauth-wg/oauth-identity-assertion-authz-grant/issues/114>). I had sketched the idea earlier, framing re-subjecting across a boundary as a mint rather than an attenuation <https://notes.karlmcguinness.com/notes/the-identity-continuation-assertion/>, and that discussion suggested writing it up. At such a hop, the service continuing the work holds none of the user's credentials. Worse, where the identity provider gives each service its own pairwise identifier for the user, a downstream service cannot even name the user to the next one. The tempting shortcut is to keep a token and replay it, or to hand an intermediary a broad, long-lived credential. Both recreate the classic confused-deputy problem. A shared or public component now holds standing authority it can be tricked into using for the wrong user, the wrong resource, or beyond its task. The receiving service, seeing a valid token, cannot tell legitimate continuation from misuse. Instead of carrying a token forward, ICA has each boundary ask the identity provider to mint a fresh one. A service presents a short-lived, sender-constrained (DPoP-bound) assertion as the subject_token in an RFC 8693 token exchange. The identity provider validates it and issues the next token, an audience-scoped ID-JAG <https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/>, for the downstream service. The link between hops is a non-bearer handle that the receiving service binds to its own authorization state, so a copied handle is useless to anyone else. Chains root in a grant the identity provider already holds for the user, such as a refresh token or an OIDC or SAML session. Each hop is then a fresh authorization decision, bounded by what was authorized up front, not an inherited standing permission. For the client that starts a chain, nothing changes. It obtains an ordinary first ID-JAG, with no ICA-specific machinery. The new work falls on the identity provider and any receiving service that chooses to support continuation, so adoption is incremental. ICA is meant to complement related efforts, not compete with them. draft-zhu-oauth-async-delegation <https://datatracker.ietf.org/doc/draft-zhu-oauth-async-delegation/> (Delegated Refresh Tokens) keeps one authorization server minting for the same user from a stored, rotating refresh token. ICA handles the different case where the user is unchanged but the audience changes. The two compose, because a delegated refresh token can be the grant a continuation chain roots in. Several drafts already describe how to represent and verify the chain of actors a delegated request passes through. These include draft-mcguinness-oauth-actor-profile <https://datatracker.ietf.org/doc/draft-mcguinness-oauth-actor-profile/> with its actor receipts and actor proofs companions, and draft-mw-oauth-actor-chain <https://datatracker.ietf.org/doc/draft-mw-oauth-actor-chain/>. They build on RFC 8693's act claim. But act, and the actor_token that produces it, convey the actor's identity as a bearer assertion, so AFAIK none defines how the actor making a request proves possession of its own key. ICA has to take a position on that, since it binds each assertion to the calling actor's own key. These efforts would benefit from a shared approach rather than each solving it separately, and I would welcome discussion on whether that is worth doing and where it should live. I would value the group's input on a few specific questions. - Is a fresh mint at the identity provider at every boundary the right model, or is that per-hop round-trip too costly for some deployments? - Acceptance of a hop is attested within the accepting domain rather than verified by the identity provider, so is that trust boundary acceptable, and how should it be hardened? - And do others see this same cross-domain continuation gap in agentic or multi-hop deployments, or are they solving it another way? Thanks, Karl McGuinness ---------- Forwarded message --------- From: <[email protected]> Date: Mon, Aug 3, 2026 at 10:23 AM Subject: New Version Notification for draft-mcguinness-oauth-id-continuation-assertion-00.txt To: Karl McGuinness <[email protected]> A new version of Internet-Draft draft-mcguinness-oauth-id-continuation-assertion-00.txt has been successfully submitted by Karl McGuinness and posted to the IETF repository. Name: draft-mcguinness-oauth-id-continuation-assertion Revision: 00 Title: Identity Continuation Assertion for OAuth 2.0 Token Exchange Date: 2026-08-03 Group: Individual Submission Pages: 60 URL: https://www.ietf.org/archive/id/draft-mcguinness-oauth-id-continuation-assertion-00.txt Status: https://datatracker.ietf.org/doc/draft-mcguinness-oauth-id-continuation-assertion/ HTML: https://www.ietf.org/archive/id/draft-mcguinness-oauth-id-continuation-assertion-00.html HTMLized: https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-id-continuation-assertion Abstract: This document defines the Identity Continuation Assertion, a short- lived, sender-constrained JWT used as an OAuth 2.0 Token Exchange subject token. It lets an Identity Provider (IdP) issue an onward Identity Assertion JWT Authorization Grant (ID-JAG) when a user's request crosses service boundaries after the user is no longer present. The profile targets deployments in which several Resource Authorization Servers trust one IdP and use audience-local subject identifiers that only the IdP can resolve. It complements offline attenuation for intra-domain fan-out that does not change the subject. The IETF Secretariat
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
