[OAUTH-WG] Re: Separating the ID-JAG issuer from the ID-Token issuer

[Atul Tulshibagwale <[e-mail]>]

Hi Karl,
BTW The "dark mode" cut and paste in your email made it a little hard to
read (I had to paste it elsewhere to read it!).
To address your points:

   -  There is no concern if the subject claim doesn't have to change
   between the ID-JAG and the ID-Token. I thought the discussion started
   because you thought it needed to change between the two.
   - I agree on the identifier mapping to applications being an
   architectural question.
   - ID-JAGs are "authorization grants", so they are different from
   ID-Tokens, which are authentication tokens.
   - What I'm advocating for is that I love the benefits of having ID-JAGs,
   I just don't want their issuer to be required to be the IdP that issues the
   ID-Tokens.

Thanks,
Atul

On Tue, Nov 4, 2025 at 3:47 PM Karl McGuinness <[e-mail]>
wrote:

> Perhaps the resource authorization server uses a separate identifier
> format and value for users than the IdP
>
>
> I wouldn’t expect this to be a subject claim in a cross-domain (federated)
> assertion. Subject claims are scoped to issuer
> in a federation.
>
> This profile is reusing the same claims as the ID Token. In a normal
> authorization code flow the Resource AS would redirect to the IDP if there
> wasn’t a session and get back an ID Token that it would use the claims to
> perform account resolution to a local user and prompt for consent to issue
> an authorization code. ID-JAG is providing the same claims and identifiers
> for account resolution. This keeps the same trust relationship for the
> resource owner, improves interoperability (no claims mapping needed) and
> enables the Resource AS to include authentication context into token
> issuance decisions (eg amr, auth_time, etc).
>
> It's an architectural question for organizations about how the IdP issued
> identifiers should be mapped to the identifiers that the application
> recognizes.
>
>
> How is this different than ID Tokens? This profile is allowing the same
> flexibility as SSO which has both brown and greenfield deployments and
> supports JIT or provisioned accounts.
>
> It sounds like what you are advocating for can be solved with vanilla JWT
> Authorization Grant and ID Chaining Spec. You don’t want to use an ID Token
> to obtain the grant (audience issue, AS isn’t the IdP or Client) and you
> want to have Resource AS specific claims in the assertion for identifying
> the resource owner.
>
>
> On Nov 4, 2025, at 3:07 PM, Atul Tulshibagwale <[e-mail]> 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 <[e-mail]>
> 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 <[e-mail]> 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=
>>> [e-mail]> 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=
>>> [e-mail]> wrote:
>>>
>>>> Not going against anything Aaron said, is your question @Atul
>>>> Tulshibagwale <atul=[e-mail]> 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 <aaron=[e-mail]>
>>>> *Sent:* November 3, 2025 4:17 PM
>>>> *To:* Atul Tulshibagwale <atul=[e-mail]>
>>>> *Cc:* oauth <[e-mail]>
>>>> *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=
>>>> [e-mail]> 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 -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>>>
>>>> _______________________________________________
>>> OAuth mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>>