I read over the document It took me a while to figure out what exactly an ID-JAG that is shown in the sequence diagram but not defined until later The roles in the sequence diagram include the Resource Application AS -- but that role is not in Table 1 In section 4 the initial redirect to the IdP is described and then the post to the token endpoint, but they are not explicit in the sequence diagram
Given that the specification starts with exchanging a SAML or ID Token for an ID-JAG -- the document could start describing the protocol given a SAML or ID Token? This spec requires a client to have credentials registered at the IdP for the ID Token exchange for an ID-JAG exchange. Would the key binding doc in discussion in OpenID Connect WG allow the client to not have to have credentials? https://dickhardt.github.io/openid-key-binding/main.html Or perhaps mandate DPoP for the ID Token -> ID-JAG exchange? Is the intermediate token: Identity Assertion Authorization Grant JWT or a JWT Authorization Grant It seems that both terms refer to the same thing - an ID-JAG The term "Resource Application's token endpoint" is confusing -- this is the token endpoint of the AS of the Resource Application -- not the resource The token exchange at the resource AS requires another set of credentials for the client that are registered at the AS of the resource. Could we not use keys the client controls again here? > 8.1 Client Authentication > This specification SHOULD only be supported for confidential clients. Public clients SHOULD redirect the user with an OAuth 2.0 Authorization Request. Which AS are the public clients redirecting the user? How would this work? If this works, then why are needing this specification? On Mon, Aug 25, 2025 at 1:39 PM Rifaat Shekh-Yusef via Datatracker < nore...@ietf.org> wrote: > > Subject: Call for adoption: > draft-parecki-oauth-identity-assertion-authz-grant-05 (Ends 2025-09-08) > > This message starts a 2-week Call for Adoption for this document. > > Abstract: > This specification provides a mechanism for an application to use an > identity assertion to obtain an access token for a third-party API by > coordinating through a common enterprise identity provider using > Token Exchange [RFC8693] and JWT Profile for OAuth 2.0 Authorization > Grants [RFC7523]. > > File can be retrieved from: > > https://datatracker.ietf.org/doc/draft-parecki-oauth-identity-assertion-authz-grant/ > > Please reply to this message keeping oauth@ietf.org in copy by indicating > whether you support or not the adoption of this draft as a WG document. > Comments to motivate your preference are highly appreciated. > > Authors, and WG participants in general, are reminded of the Intellectual > Property Rights (IPR) disclosure obligations described in BCP 79 [2]. > Appropriate IPR disclosures required for full conformance with the > provisions > of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any. > Sanctions available for application to violators of IETF IPR Policy can be > found at [3]. > > Thank you. > [1] https://datatracker.ietf.org/doc/bcp78/ > [2] https://datatracker.ietf.org/doc/bcp79/ > [3] https://datatracker.ietf.org/doc/rfc6701/ > > > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
