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]
