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

[Tarun Nanduri <[e-mail]>]

copying Oauth WG, apologies for another reply over!

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