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

[Tarun Nanduri <[e-mail]>]

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]
>>
>