I think you should clean up the document before adoption so that it is clear what is being adopted. I'm not going to oppose adoption, but I'm not in favor of adoption as currently written.
Another confusing point I saw but did not mention: In table 1 there is a column "Tenant URL" -- but the term is not defined or used from what I can understand. There are some implementation notes further down in the document that talk about a tenant -- but that seems unrelated. On Tue, Aug 26, 2025 at 3:01 PM Aaron Parecki <aa...@parecki.com> wrote: > 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 <dick.ha...@gmail.com> 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 < >> 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
