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

[Pieter Kasselman <[e-mail]>]

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