Hi Karl, My comments below. Thank you for your patience with my suggestions and questions, Atul
On Mon, Nov 3, 2025 at 7:51 PM Karl McGuinness <[email protected]> wrote: > 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. > > I'm not sure the ID-JAG is required to have the same `iss` or the same `sub` as the ID-Token. Perhaps the resource authorization server uses a separate identifier format and value for users than the IdP, and the ID-JAG Authorization Server (which in my proposal is separate from the IdP) does that mapping before it issues the ID-JAG. The resource authorization server can be configured to trust the ID-JAG Authorization Server instead of the IdP for the ID-JAG. > > - 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. > > It's an architectural question for organizations about how the IdP issued identifiers should be mapped to the identifiers that the application recognizes. So if we are able to propose a standard that doesn't preclude the possibility that there may be a separate authorization server, then it makes the standard more valuable. I think there is sufficient evidence that many large organizations choose to have separation between the authenticating party and the authorizing party, so as a standards body, we should permit and encourage both possibilities. > - The Resource Authorization Server can trust multiple IdPs and > therefore multiple ID-JAG issuers (assuming the secure account resolution > of multiple federation identifiers) > > I'm not sure if it matters whether the party that a resource authorization server trusts for an ID-JAG is a combined "ID Token Issuer + Authorization Server", or just an "Authorization Server". Am I missing something? > -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]
