Hi Karl, BTW The "dark mode" cut and paste in your email made it a little hard to read (I had to paste it elsewhere to read it!). To address your points:
- There is no concern if the subject claim doesn't have to change between the ID-JAG and the ID-Token. I thought the discussion started because you thought it needed to change between the two. - I agree on the identifier mapping to applications being an architectural question. - ID-JAGs are "authorization grants", so they are different from ID-Tokens, which are authentication tokens. - What I'm advocating for is that I love the benefits of having ID-JAGs, I just don't want their issuer to be required to be the IdP that issues the ID-Tokens. Thanks, Atul On Tue, Nov 4, 2025 at 3:47 PM Karl McGuinness <[email protected]> wrote: > Perhaps the resource authorization server uses a separate identifier > format and value for users than the IdP > > > I wouldn’t expect this to be a subject claim in a cross-domain (federated) > assertion. Subject claims are scoped to issuer > in a federation. > > This profile is reusing the same claims as the ID Token. In a normal > authorization code flow the Resource AS would redirect to the IDP if there > wasn’t a session and get back an ID Token that it would use the claims to > perform account resolution to a local user and prompt for consent to issue > an authorization code. ID-JAG is providing the same claims and identifiers > for account resolution. This keeps the same trust relationship for the > resource owner, improves interoperability (no claims mapping needed) and > enables the Resource AS to include authentication context into token > issuance decisions (eg amr, auth_time, etc). > > It's an architectural question for organizations about how the IdP issued > identifiers should be mapped to the identifiers that the application > recognizes. > > > How is this different than ID Tokens? This profile is allowing the same > flexibility as SSO which has both brown and greenfield deployments and > supports JIT or provisioned accounts. > > It sounds like what you are advocating for can be solved with vanilla JWT > Authorization Grant and ID Chaining Spec. You don’t want to use an ID Token > to obtain the grant (audience issue, AS isn’t the IdP or Client) and you > want to have Resource AS specific claims in the assertion for identifying > the resource owner. > > > On Nov 4, 2025, at 3:07 PM, Atul Tulshibagwale <[email protected]> wrote: > > > 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]
