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]
