Hi Tarun, for the original use case you described, you may want to consider the transaction token spec [1].
It was specifically developed to allow authorization context, including user and workload/microservice identity information, to be passed between microservices within a domain, without having to pass around access tokens. Cheers Pieter [1] https://datatracker.ietf.org/doc/draft-ietf-oauth-transaction-tokens/07/ On Sun, Feb 8, 2026 at 8:02 AM Tarun Nanduri <[email protected]> wrote: > Hi Pieter, Brian, Aaron, and the WG, > > Thanks for the feedback and for taking the time to look at this. I’ve been > thinking over the points about Section 8.3 and the general intent of ID-JAG. > > Stepping back from the specific spec for a second, it feels to me like we > have a bit of a gap in the OAuth/OIDC specifications. We’re essentially > looking for a standard way to do Directed Session Transfer, in environments > where shared cookies/SSO just aren't an option for security reasons. > > You pointed toward the Identity Chaining Across Domains draft as the > intended home for this, and I see the logic—since the AS in Domain A > generates the JWT grant, it handles the "identity proof" part of the > handover. > > But right now, if I want to move a user from App A to App B without a > fresh login, the options still feel a bit thin: > > - Standard SSO is off the table because of the "no-shared-cookie" > constraint. > - RFC 8693 is a great building block, but it’s mostly used for > service-to-service backend swaps. There isn't really a front-channel > "profile" for this (as RFC863 sends back a usable token rather than an > assertion). > - Identity Chaining, as Brian mentioned, is explicitly a specification > for cross-domain use. > > > It feels a bit ironic that the protocol makes "Cross-Domain" identity > transfers standardized via ID-JAG (as an OAuth native grant), but leaves > "Intra-Domain" delegation as a "roll-your-own" exercise. Without a standard > profile for this, people might just end up building non-standard hacks > which is exactly what we’re trying to avoid. > > I’m not trying to force a change to ID-JAG if the WG feels it’s the wrong > home, but I am curious: > > - Do we think this "Directed Session transfer" pattern is a gap worth > filling? > > It feels to me like there should be an "OAuth-native" way to do this that > has the right guardrails (audience binding, act claims, etc.) to make it > secure in a Zero Trust setup, but is as straightforward to implement as a > basic Auth Code grant. I’d love to hear if anyone else sees this gap, or if > there's a pattern I’m missing that doesn't involve a lot of custom "glue" > code. > > Best Regards, > Tarun Nanduri. > > On Thu, Feb 5, 2026 at 6:14 PM Pieter Kasselman <[email protected]> > wrote: > >> Hi Tarun >> >> I agree with Brain and Aaron that your use case can likely be addressed >> by the Identity and Authorization Chaining Across Domains draft [1]. You >> could always profile it further if needed. Is there a reason you would not >> be able to use that draft? >> >> Cheers >> >> Pieter >> >> [1] https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/ >> >> On Wed, Feb 4, 2026 at 9:31 PM Brian Campbell <bcampbell= >> [email protected]> wrote: >> >>> Hi Tarun, >>> >>> As Aaron mentioned there are less tightly profiled variations of this >>> general flow, like oauth-identity-chaining >>> <https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/> >>> or rfc8693 <https://datatracker.ietf.org/doc/html/rfc8693> + rfc7523 >>> <https://datatracker.ietf.org/doc/html/rfc7523> together directly, that >>> don't have the same constraint regarding the IDP not issuing access tokens >>> in response to an ID-JAG it issued itself. Perhaps that might meet your >>> needs? Although those are intended for cross domain as well. Honestly, much >>> of this seems like more than is needed for a same idp / same domain case. >>> >>> On Tue, Feb 3, 2026 at 8:13 PM Tarun Nanduri <[email protected]> >>> wrote: >>> >>>> Dear Aaron, >>>> >>>> I am awaiting your feedback on this. To summarize, >>>> >>>> When an Identity Provider (IdP) does not support Single Sign-On (SSO) >>>> due to the nature of the systems involved, and a user needs to transfer >>>> their session to another application without re-logging in, I feel ID-JAG >>>> offers a secure and seamless solution, providing a smooth user experience. >>>> >>>> The RFC, as stated in previous emails, explicitly prohibits using the >>>> specification within the same IdP. Considering the zero-trust model >>>> typically applied within the same IdP, are we open to modifying the >>>> specification to allow its implementation within such environments? >>>> >>>> Best Regards, >>>> Tarun Nanduri. >>>> >>>> On Fri, Dec 5, 2025 at 8:46 AM Tarun Nanduri <[email protected]> >>>> wrote: >>>> >>>>> Hi Aaron, >>>>> >>>>> Thanks for the response, and pointing me to the Identity Chaining >>>>> draft. However, after looking at it, I don't think it applies to the >>>>> use-case I shared above (please feel free to correct here). It looks like >>>>> it's designed for cross-domain scenarios* whereas the use-case I >>>>> shared above has*, >>>>> >>>>> - Both the clients are in same trust domain >>>>> - We have single authorization server (it's the IdP too) >>>>> >>>>> The challenge we are trying to solve is, >>>>> >>>>> - Client A needs to transfer user session to client B >>>>> - WITHOUT Client A sharing its access token with client B >>>>> (security risk due to token exposure, invalid audience, unnecessary >>>>> privileges etc.) >>>>> - Both clients trust the same IdP >>>>> >>>>> This is why we're intending to use RFC8693, but it still requires >>>>> client A to send access token (after token exchange) to client B which >>>>> creates exposure we're trying to avoid. The ID-JAG pattern (cryptographic >>>>> proof of identity, not a usable token) would be perfect, except the >>>>> prohibition defined in section 8.3 of Identity Assertion draft: >>>>> 8.3. >>>>> <https://www.ietf.org/archive/id/draft-parecki-oauth-identity-assertion-authz-grant-05.html#section-8.3>Cross-Domain >>>>> Use >>>>> <https://www.ietf.org/archive/id/draft-parecki-oauth-identity-assertion-authz-grant-05.html#name-cross-domain-use> >>>>> >>>>> This specification is intended for cross-domain uses where the Client, >>>>> Resource App, and Identity Provider are all in different trust domains. In >>>>> particular, the Identity Provider MUST NOT issue access tokens in >>>>> response to an ID-JAG it issued itself. Doing so could lead to >>>>> unintentional broadening of the scope of authorization. >>>>> My question remains, Can the section 8.3 prohibition be satisfied with >>>>> enough security controls (scope validation, replay prevention etc.) for >>>>> same IdP scenarios, or is it a hard limitation? >>>>> >>>>> Thanks and Regards, >>>>> Tarun Nanduri. >>>>> >>>>> >>>>> On Fri, Dec 5, 2025 at 1:53 AM Aaron Parecki <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi Tarun, >>>>>> >>>>>> It sounds like what you are looking for is the parent draft of this >>>>>> draft, Identity and Authorization Chaining Across Domains: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/ >>>>>> >>>>>> The document that defines the ID-JAG, Identity Assertion >>>>>> Authorization Grant, is a special case of Identity Chaining where both >>>>>> the >>>>>> client and resource have a pre-existing relationship with the same IdP. >>>>>> So >>>>>> I don't view it as a limitation, it's actually an optimization when there >>>>>> is a common IdP. The Identity Chaining draft is the same as this draft >>>>>> except it doesn't specify the input token format or the reason why the >>>>>> client and resource trust the cross-domain JWT issuer. >>>>>> >>>>>> Aaron >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Dec 1, 2025 at 8:11 AM Tarun Nanduri <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Dear OAuth Working Group & Aaron, >>>>>>> >>>>>>> I would like to provide feedback on the OAuth Identity Assertion >>>>>>> Authorization Grant (ID-JAG) specification, specifically regarding >>>>>>> the prohibition against same-IdP usage. >>>>>>> >>>>>>> Use Case: >>>>>>> >>>>>>> In microservices architectures using the same IdP, there is a >>>>>>> legitimate need for service-to-service identity delegation WITHOUT >>>>>>> sharing access tokens directly: >>>>>>> >>>>>>> - Application A has a user-scoped token >>>>>>> - Application A needs to invoke Application B on behalf of user >>>>>>> - Sharing Token A with Application B creates security risks: >>>>>>> * Token exposure between services >>>>>>> * Replay attacks >>>>>>> * Over-privileged access >>>>>>> * Audience mismatch >>>>>>> >>>>>>> The Gap: >>>>>>> >>>>>>> ID-JAG's assertion pattern solves this perfectly: >>>>>>> - Application A creates a cryptographic identity assertion >>>>>>> - Assertion is audience-bound to Application B >>>>>>> - Application B exchanges assertion for its own token >>>>>>> - No credential sharing between services >>>>>>> >>>>>>> However, the same-IdP prohibition prevents this legitimate use case. >>>>>>> >>>>>>> Suggestion: >>>>>>> >>>>>>> Consider either: >>>>>>> 1. Removing the same-IdP prohibition with appropriate security >>>>>>> guidance >>>>>>> 2. Adding an exception for service-to-service delegation scenarios >>>>>>> 3. Providing guidance on how to achieve this pattern within the same >>>>>>> IdP >>>>>>> >>>>>>> RFC 8693 (Token Exchange) doesn't fully address this use case as it >>>>>>> requires sending the actual token (subject_token), which is what >>>>>>> we're >>>>>>> trying to avoid. >>>>>>> >>>>>>> Security Considerations: >>>>>>> >>>>>>> With zero-trust validation, same-IdP assertions can be just as secure >>>>>>> as cross-IdP: >>>>>>> - Validate assertion issuer is authorized >>>>>>> - Apply fresh authorization policy evaluation >>>>>>> - Enforce audience restrictions >>>>>>> - Use short-lived assertions >>>>>>> - Implement scope intersection, not broadening >>>>>>> >>>>>>> Would appreciate the working group's consideration of this use case. >>>>>>> >>>>>>> Best regards, >>>>>>> Tarun Nanduri. >>>>>>> >>>>>> _______________________________________________ >>>> OAuth mailing list -- [email protected] >>>> To unsubscribe send an email to [email protected] >>>> >>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibited. >>> If you have received this communication in error, please notify the sender >>> immediately by e-mail and delete the message and any file attachments from >>> your computer. Thank you.* >>> _______________________________________________ >>> OAuth mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> >>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
