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]
