I think the issue is that the id_token “audience” restrictions require them to be the same. Otherwise the “IdP Authorization Server” (that didn’t issue the id_token) would need to reject the id_token when received because the “audience” wouldn’t match. I’m not crazy about the idea that says a bunch of different services performing different tasks are still all the same “audience”.
George Fletcher Identity Standards Architect Practical Identity LLC > On Nov 3, 2025, at 5:30 PM, Atul Tulshibagwale > <[email protected]> wrote: > > Hi Jeff, > I'm not thinking of changing anything in the draft (e.g. using Transaction > Tokens, WITs etc.) > I'm only suggesting that we should not assume that the IdP that issued the > ID-Token is the same as the "IdP Authorization Server" that issues the ID-JAG. > > Atul > > > On Mon, Nov 3, 2025 at 1:29 PM Lombardo, Jeff > <[email protected] <mailto:[email protected]>> > wrote: >> Not going against anything Aaron said, is your question @Atul Tulshibagwale >> <mailto:[email protected]> cause you are thinking ahead of: >> >> 1/ A transaction Token could be exchanged for a ID-JAG? >> 2/ A Workload Identity Token could be exchanged for an ID-JAG? >> >> >> >> Jeff >> >> >> >> Jean-François “Jeff” Lombardo | Amazon Web Services >> >> >> >> Architecte Principal de Solutions, Spécialiste de Sécurité >> Principal Solution Architect, Security Specialist >> Montréal, Canada >> >> >> Commentaires à propos de notre échange? Exprimez-vous ici >> <https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$>. >> >> >> >> Thoughts on our interaction? Provide feedback here >> <https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$>. >> >> >> >> From: Aaron Parecki <[email protected] >> <mailto:[email protected]>> >> Sent: November 3, 2025 4:17 PM >> To: Atul Tulshibagwale <[email protected] >> <mailto:[email protected]>> >> Cc: oauth <[email protected] <mailto:[email protected]>> >> Subject: [EXT] [OAUTH-WG] Re: Separating the ID-JAG issuer from the ID-Token >> issuer >> >> >> >> CAUTION: This email originated from outside of the organization. Do not >> click links or open attachments unless you can confirm the sender and know >> the content is safe. >> >> >> >> AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe. Ne >> cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne pouvez pas >> confirmer l’identité de l’expéditeur et si vous n’êtes pas certain que le >> contenu ne présente aucun risque. >> >> >> >> For some background, the reason for this draft and the ID-JAG in the first >> place is to enable an Authorization Server to issue its own access tokens in >> response to a cross-domain artifact. This is better than the other two >> alternatives which would be: >> >> >> >> 1. Client sends the IdP-issued ID Token to the Authorization Server in the >> other domain (violates ID Token "audience" policy processing) >> >> 2. Have the IdP issue an access token that the Resource Server in the other >> domain accepts (no protocol violation, but experience has shown Resource >> Server implementers do not want this) >> >> >> >> Now to your actual question, why not enable the ID-JAG issuer to be separate >> from the ID Token issuer. This would also violate the ID Token "audience" >> processing, since the ID Token would be presented to an entity different >> from the issuer of the ID Token. >> >> >> >> On Mon, Nov 3, 2025 at 3:49 PM Atul Tulshibagwale >> <[email protected] <mailto:[email protected]>> wrote: >> >> Hi all, >> >> Great to see the "Identity Assertion JWT Authorization Grant >> <https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/>" >> proposal being accepted by OAuth. I'd like to propose that we should not >> assume that the issuer of the ID-Token is the same as the issuer of the >> ID-JAG. There doesn't seem to be any reason provided for this either in the >> draft or in the short discussion we had today. >> >> >> >> It's just something that is assumed in the draft, and I feel that can be >> generalized without affecting anything in the draft. >> >> >> >> To address Aaron's response that "if you want them separate, then you return >> to the ID-Chaining draft": I feel there's a lot of value in this (ID-JAG) >> specification, and being able to apply to more use cases broadens the value >> of this specification. >> >> >> >> I'd love to know what could be potential issues if the ID-JAG issuer is not >> assumed to be the same as the ID-Token issuer. >> >> >> >> Thanks, >> >> Atul >> >> >> >> _______________________________________________ >> OAuth mailing list -- [email protected] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[email protected]>_______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
