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]
