Some of my comments are aimed at improving comprehension as a reader. Some are around lack of support for public clients.
But there are also a number of inconsistencies in what things are called, and the Tenant URL is undefined. On Tue, Aug 26, 2025 at 4:34 PM Aaron Parecki <aa...@parecki.com> wrote: > Just for clarity, in case you missed it in the previous IETF discussions > on this document, most of the mechanism described in this draft is actually > just the Identity and Authorization Chaining draft that just went to WGLC. > This document defines the JWT that moves across domains for this specific > context, whereas the Identity Chaining draft leaves that as an extension > point. > > I wanted this document to be able to be read mostly as a standalone > document, but one other option is to remove the redundant text from the > Identity Chaining draft and keep the text in this document specifically > about the cross-domain JWT claims. > > In any case, I will wait for broader feedback before making any changes. > > > > On Tue, Aug 26, 2025 at 8:15 AM Dick Hardt <dick.ha...@gmail.com> wrote: > >> 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
