Hi all, I would love to know what everyone thinks too. I am wholeheartedly in support of option #2, which I think provides the most flexibility, wherein an IdP could be the ID-JAG issuer, or an independent service (e.g. an Enterprise Authorization Server) could be the ID-JAG issuer.
Thanks Karl, for sharing these options on the list. Please see the conversation in Aaron's PR <https://github.com/oauth-wg/oauth-identity-assertion-authz-grant/pull/64> for more context. Atul On Sat, Nov 8, 2025 at 2:18 PM Karl McGuinness <[email protected]> wrote: > Would love to get broader feedback as this is a pretty significant change > to the spec and each option has its own side effects. The PR lists some > for Option 2 > > The menu is currently > > 1) Allow ID Tokens to be used with Token Exchange for ID-JAG where the > Enterprise Authorization Server isn't the issuer or the audience of the ID > Token (uses a very broad definition of EAS as a component of the same > system vs cross-domain). > 2) Allow Access Tokens to be used with Token Exchange for ID-JAG > instead of an ID Token where the audience of the Access Token is the > Enterprise Authorization Server > 3) Collapse the JAG to an cross-domain Access Token with an audience of > the Resource AS vs a Resource Server since the Resource AS already needs to > support a custom issuer and the claims between JAG and Access Token are > similar with similar need for mappings/etc for cross-domain use cases. > > Interested to hear your thoughts if there is another path or what option > is preferred and why. > > -Karl > > On Sat, Nov 8, 2025 at 1:49 PM Aaron Parecki <[email protected]> wrote: > >> Here's the PR I mentioned during the DPoP session on Friday. >> >> https://github.com/oauth-wg/oauth-identity-assertion-authz-grant/pull/64 >> >> This provides the option to split out the role of the server that issues >> the ID-JAG. There are still some details to work out, feel free to add >> additional thoughts in the PR. >> >> I'd like to resolve this sooner than later if we do decide to add this >> option. >> >> >> >> On Sat, Nov 8, 2025 at 1:46 PM Atul Tulshibagwale <atul= >> [email protected]> wrote: >> >>> Hi Karl and Aaron, >>> As discussed in Montreal, I'd love to preview Aaron's PR in this regard. >>> >>> Thanks, >>> Atul >>> >>> On Wed, Nov 5, 2025 at 12:15 PM Karl McGuinness <[email protected]> >>> wrote: >>> >>>> Hi Atul, >>>> >>>> The server / service that issues the ID-JAG doesn't need to be an IDP. >>>>> It could just be an "Authorization Management Platform" (as Gartner has >>>>> recently named these things). The AMP is not really in the business of >>>>> authenticating users, it only provides a way for organizations to define >>>>> and enforce policies. >>>> >>>> >>>> The IdP is already a Policy Enforcement Point (PEP) for Zero-Trust >>>> Policy for the enterprise. ID Tokens already commingle some authorization >>>> concerns and may include claims used for RP authorization (e.g. roles, >>>> groups, etc). Many Enterprise IdPs are often OAuth 2.0 Authorization >>>> Servers for Resource Servers managed by the enterprise and have centralized >>>> client & resource lifecycle management with access policies. IdPs in >>>> practice are not just authenticating users for SSO but also granting access >>>> to clients to act on behalf of enterprise users. TL;DR I think the >>>> problem already exists today for SSO and API Access Management outcomes. >>>> This spec extends what the IdP is already doing for 1st party >>>> resources with API Access Management to 3rd party Authorization Server. If >>>> it was viable to issue an Access Token directly to the 3P Resource Server >>>> (e.g JWT Access Token Profile) in another trust domain then customers would >>>> just use their existing IdP/AS infrastructure for this. >>>> >>>> This spec also isn't just vanilla service to service but more >>>> specifically when can a service act as an enterprise managed user to >>>> another service in another trust domain. It's a proxy for the resource >>>> owner role in OAuth 2.0. The IdP already understands the different trust >>>> domains for the resource applications, manages trust keys, and brokers >>>> access across the domains. It's a federation problem and not just an >>>> authentication problem. >>>> >>>> I would expect customers that have invested in a "Authorization >>>> Management Platform" to push the IdP vendors to integrate with their AMP as >>>> a PDP vs trying to make it to an "Issuer". My understanding is this is >>>> what is being proposed by the OpenID AuthZen WG >>>> https://hackmd.io/@oidf-wg-authzen/idp-integration. This would >>>> address not just this use case but also the broader set of challenges with >>>> SSO and API Access Management. >>>> >>>> -Karl >>>> >>>> On Wed, Nov 5, 2025 at 7:10 AM Atul Tulshibagwale <[email protected]> wrote: >>>> >>>>> Hi Aaron, >>>>> Thanks for the clarification. Please see my comments below: >>>>> >>>>> On Tue, Nov 4, 2025 at 5:38 PM Aaron Parecki <aaron= >>>>> [email protected]> wrote: >>>>> >>>>>> I wouldn't characterize it as "aligned", I am trying to find a >>>>>> compromise. >>>>>> >>>>> Understood. I appreciate your flexibility. >>>>> >>>>> >>>>>> >>>>>> I don't think you have the steps quite right. Assuming you are >>>>>> referring to the steps in Section 4.1, then the steps are: >>>>>> >>>>> Yes, those are the steps I was referring to. >>>>> >>>>> >>>>>> >>>>>> > 1. User authenticates with the IdP Authorization Server, the Client >>>>>> obtains an Identity Assertion. >>>>>> >>>>>> Yes, this requires that the client uses the IdP's token endpoint when >>>>>> using the authorization code flow. Nothing is changed compared with >>>>>> standard OpenID Connect in this draft with this step of the flow. It >>>>>> arguably shouldn't even be mentioned in the draft, but early feedback we >>>>>> got was that it was confusing to not mention it because it wasn't clear >>>>>> where the identity assertion came from otherwise. >>>>>> >>>>> I would be in favor of leaving this out, since nothing really changes >>>>> about this part. >>>>> >>>>> >>>>>> > 2. Client uses the Identity Assertion to request an Identity >>>>>> Assertion JWT Authorization Grant for the Resource Authorization Server >>>>>> from the IdP Authorization Server >>>>>> >>>>>> This is the step that could be rephrased to "...from the ID-JAG >>>>>> endpoint" or some such, so that you have the carve-out to be able to run >>>>>> this on a separate server from the IdP. >>>>>> >>>>> >>>>> This would work. I'm just a bit concerned though that the AS metadata >>>>> is used to specify the ID-JAG authorization endpoint. As long as that part >>>>> is kept optional (i.e. A client MAY discover the ID-JAG endpoint using the >>>>> AS metadata), I'm good with this proposal. >>>>> >>>>> >>>>>> >>>>>> Again, I don't actually think this is a good idea for the reasons >>>>>> mentioned in this thread above. Like George said, it's really a stretch >>>>>> to >>>>>> define this other ID-JAG-issuing service to be in the same domain that is >>>>>> able to validate ID tokens that have the audience of the IdP that's from >>>>>> a >>>>>> separate domain. Technically if you squint hard enough you can justify >>>>>> it, >>>>>> but it's really a stretch. >>>>>> >>>>> >>>>> I would have to disagree here, since I am seeing a number of >>>>> enterprises adopt authorization servers that are completely independent of >>>>> the IdP. I feel that to arrive at consensus, we can just use your proposal >>>>> above of separating the ID-JAG authorization endpoint. >>>>> >>>>> >>>>>> Stepping back, it sounds like what you are actually trying to ask for >>>>>> is the ability to have the policies enabled by this flow run on an IdP >>>>>> that >>>>>> is different from where the actual user accounts live. >>>>>> >>>>> >>>>> You are kind of right, except I'm trying to separate the part that >>>>> issues the ID-Token, which I'm calling the authentication flow, from the >>>>> part that issues the ID-JAG, which I'm calling the authorization flow. The >>>>> server / service that issues the ID-JAG doesn't need to be an IDP. It >>>>> could >>>>> just be an "Authorization Management Platform" (as Gartner has recently >>>>> named these things). The AMP is not really in the business of >>>>> authenticating users, it only provides a way for organizations to define >>>>> and enforce policies. >>>>> >>>>> >>>>> >>>>>> I would say the better solution to that is to keep the clients >>>>>> requesting the ID Token and ID-JAG from the same IdP, but that IdP >>>>>> actually >>>>>> federates user authentication to another IdP. The other IdP would be >>>>>> unaware of the ID-JAG flow entirely, as it would only be responsible for >>>>>> user authentication. That seems like a totally valid architecture, and a >>>>>> way to roll this out in an enterprise that is using an IdP that doesn't >>>>>> support this new flow. >>>>>> >>>>> Based on my answer above, this does not really apply in my line of >>>>> thinking. >>>>> >>>>> >>>>>> >>>>>> Aaron >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Nov 4, 2025 at 8:20 PM Atul Tulshibagwale <atul= >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Hi Aaron, >>>>>>> It's great that we are aligned on the fact that the ID-JAG >>>>>>> Authorization Server can be separate from the ID-Token Issuer. >>>>>>> >>>>>>> However the change you are proposing, i.e. the AS metadata can point >>>>>>> to two totally different URLs for the token endpoint and the >>>>>>> authorization >>>>>>> endpoint, is still limited as follows: >>>>>>> >>>>>>> In Step 1 of the draft, the result of the exchange is an ID-Token, >>>>>>> which (if using the code flow) involves using the IDP's token endpoint. >>>>>>> This will need to be the IdP's own token endpoint, whereas the >>>>>>> functionality required for the token exchange in step 2 of the draft is >>>>>>> totally different. That requires the server to authorize the use of that >>>>>>> ID-Token for a specific application. >>>>>>> >>>>>>> Thanks, >>>>>>> Atul >>>>>>> >>>>>>> >>>>>>> On Tue, Nov 4, 2025 at 3:33 PM Aaron Parecki <aaron= >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> I think this is the same question as "can't your token endpoint be >>>>>>>> on a different system than your authorization endpoint?" >>>>>>>> >>>>>>>> The answer is technically yes, because how the token endpoint >>>>>>>> validates authorization codes isn't needed to be described in the spec >>>>>>>> because it's an implementation detail. What enables the possibility of >>>>>>>> that >>>>>>>> split is an explicit definition of both endpoints in the AS metadata. >>>>>>>> So >>>>>>>> the AS metadata can point to two totally different URLs for the two. >>>>>>>> >>>>>>>> So the equivalent for this draft would be possible without any spec >>>>>>>> changes if the endpoint that issues the ID-JAG were called out as a >>>>>>>> separate endpoint in the AS metadata, instead of the current definition >>>>>>>> which is that it's the same token endpoint. How this theoretical >>>>>>>> separate >>>>>>>> system validates the ID token And maps user IDs would be out of scope. >>>>>>>> >>>>>>>> I'm not sure I actually like this idea but it would at least enable >>>>>>>> the possibility. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Nov 4, 2025 at 6:08 PM Atul Tulshibagwale <atul= >>>>>>>> [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] >>>>>>>>> >>>>>>>>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
