Hi Pieter, Tarun, and the WG,
Pieter, thanks for the Transaction Tokens pointer for the intra-domain case. Tarun, I also wanted to follow up on your question about delegation semantics since we've run into a very similar issue on the cross-domain side. The pattern you describe (A delegates to B with audience binding, scope narrowing, no credential sharing) has consistently come up in our multi-agent workflow design where agents are invoking each other across organizational trust boundaries. Section 6.4.1.2 of draft-diaconu-agents-authz-info-sharing-00<https://datatracker.ietf.org/doc/html/draft-diaconu-agents-authz-info-sharing-00> defines scope derivation for delegation chains as a four-way intersection of the delegator's delegatable scope, the delegatee's intrinsic scope, the explicit delegation grant, and the receiving domain's policy. The first three elements address the delegation mechanisms and ensure that the scope can only narrow or remain the same at each hop. The last element addresses the need for the domain hosting the resource to maintain control over its own policy and authorizations, independent of the permissions granted by the previous hops in the chain. This relates to your Section 8.3 question. The "unintentional broadening of the scope of authorization" risk could be reduced by providing an explicit definition for how scopes are intersected during derivation. If the mechanism itself enforces that scopes cannot expand at each hop, then the distinction between same-IdP vs. cross-IdP would likely become less significant from a security properties standpoint. I am interested in hearing if the WG believe that enforcing scope narrowing through formal definitions would be sufficient to relax that restriction. Lastly, another question for the group: as delegation chains grow longer (2-3 hops across organizational trust boundaries is typical in agent workflows), should there be a standardized method for expressing delegation depth limits and re-authorization checkpoints? While Transaction Tokens provide standardization around the format of authorization contexts, I think the governance aspects (how long can chains be, at which points in the chain does one re-authorize when crossing organizational trust boundaries) would benefit from some form of standardization regardless of the authorization context token format. Best, Nik Kale From: Pieter Kasselman <[email protected]> Date: Monday, February 9, 2026 at 6:54 AM To: Tarun Nanduri <[email protected]> Cc: Brian Campbell <[email protected]>, [email protected] <[email protected]> Subject: [OAUTH-WG] Re: Feedback on ID-JAG same IdP prohibition - Application to Application Delegation 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]<mailto:[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 <[email protected]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[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]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
