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]
