I wouldn't characterize it as "aligned", I am trying to find a compromise.
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: > 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. > 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. 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. 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. 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. 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]
