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

[Karl McGuinness <[e-mail]>]

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: <[e-mail]>
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 <[e-mail]>


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