A couple of other points to add - The ID-JAG has the same `iss`+`sub` as the SSO ID Token for the Resource Authorization Server as RP. This ensures the same account linking/resolution logic for SSO can be reused for ID-JAG processing reducing surface area and security issues of generic claims mappings needed for something like vanilla JWT Authorization Grant in a federation. For example, the Resource Authorization Server as RP stores the IdP's iss+sub during JIT from SSO then matches the `iss`+`sub in the ID-JAG. - The Resource Authorization Server can trust multiple IdPs and therefore multiple ID-JAG issuers (assuming the secure account resolution of multiple federation identifiers)
-Karl On Mon, Nov 3, 2025 at 7:00 PM <[email protected]> wrote: > 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 <atul= > [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 <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] > > > _______________________________________________ > 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]
