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]> Sent: November 3, 2025 4:17 PM To: Atul Tulshibagwale <[email protected]> Cc: oauth <[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]
