[OAUTH-WG] Re: Feedback on ID-JAG same IdP prohibition - Application to Application Delegation

[Pieter Kasselman <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]>
> 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=
>> [e-mail]> 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 <[e-mail]>
>>> 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 <[e-mail]>
>>>> 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 <[e-mail]>
>>>>> 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 <[e-mail]>
>>>>>> 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 -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>>>
>>>
>>> *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 -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>>