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

[Brian Campbell <[e-mail]>]

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._