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 <[email protected]> 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 -- [email protected] To unsubscribe send an email to [email protected]
