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 <jeffsec= [email protected]> wrote: > Not going against anything Aaron said, is your question @Atul > Tulshibagwale <[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 <atul= > [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] > To unsubscribe send an email to [email protected] > >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
