Thanks for the review Dick. I look forward to addressing your comments after the document is adopted.
On Tue, Aug 26, 2025 at 2:37 AM Dick Hardt <[email protected]> wrote: > 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 < > [email protected]> 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 [email protected] 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 -- [email protected] >> To unsubscribe send an email to [email protected] >> >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
