Thanks Jim. Appreciate the review and apologies for the slow response. I can only blame spring break vacations, lackluster coordination among co-authors, and generally not being able to keep up with things.
Anyway, my attempts at responding to individual items are inline below along with a few questions. This PR incorporates the items below that I mentioned I would do: https://github.com/oauth-wg/draft-ietf-oauth-rfc7523bis/pull/29 On Fri, Apr 3, 2026 at 1:32 PM Jim Fenton via Datatracker <[email protected]> wrote: > Document: draft-ietf-oauth-rfc7523bis > Title: Updates to OAuth 2.0 JSON Web Token (JWT) Client Authentication and > Assertion-Based Authorization Grants Reviewer: Jim Fenton Review result: > Ready > with Nits > > I am the assigned ARTART reviewer for this draft. While I have some > familiarity > with OAuth, I am not qualified to evaluate the security aspects of the > protocol. > > The document is generally clear and well written. > Thank you sir! Miscellaneous comments: > > Section 1 paragraph 3: "values of the metadata are not directly validated": > Perhaps "are not required to be validated" to make it clear that > validation is > permitted? > The issue there is that there's not a meaningful way to validate those values (beyond basic format type checks). And saying "not required to" kinda suggests otherwise. Maybe "metadata values cannot be directly validated"? Or leave it? Or? > > Section 2 last paragraph: "can be used to indicate": perhaps "MUST be used > to > indicate" (or is this just an optional capability)? > It's a bit tricky because that text is updating some text from the "Assertion Metamodel" of RFC 7521, which applies more broadly to several different cases of general direct assertion presentation to the authorization server. And a hard MUST is applicable in only one of those cases. > > Section 3, item 2 of section 3 replacement text: "is responsible for > ensuring": > Should this be stated normatively, i.e., "MUST ensure"? > Honestly, this could be done either way but in the context/situation here, I felt like avoiding the big 2119 words in this part was appropriate. > > Perhaps I'm taking the text replacements too literally in the following > comments: > > Section 4 section 3 replacement text, paragraph (b): "the aud value > specified > in [RFC7523]" refers to the document and section that the replacement text > is > going into. It seems like this sentence and perhaps others belong outside > the > indented (replacement text) part of this section. > I think that "Unlike the aud value specified in [RFC7523]" text was intended to draw attention to the contrast with the prior behavior allowed by RFC7523 but you are right that it is strange when considered as text replacing text in that very RFC that it's replacing. I'll adjust the wording slightly to remove the infinite recursion thing going on. > > Section 4.1, in the example claims set the iss and sub claims have a > trailing > slash that doesn't show up elsewhere. It probably doesn't matter, but it > looks > inconsistent. > It does look inconsistent, doesn't it? The trailing slash was intentional and meant to show a client identifer that'd be compliant with https://datatracker.ietf.org/doc/html/draft-ietf-oauth-client-id-metadata-document-01#section-3 where that draft says that that kind of client identifier "MUST contain a path component". But that was just me trying to get things to be matchy matchy (as our responsible AD likes to say) in a place where there's not really a good reason for it. Especially given that draft might not keep that point. I'll update sec 4.1 to drop the trailing slash. > Section 5, the indented replacement text isn't worded like it would in that > document. Specifically, "This update resolves..." would be out of context > there. Agreed, yeah, I'll try to rephrase things so they don't sound out of context. > [OpenID.Core] references a newer revision of the OIDC specification than > RFC 9126 uses; is it intended to use this revision in this context only or > throughout 9126? That's an unintended (I think) artifact of the way the OIDC specification dates errata publications. Which, assuming is just what you'd expect from errata, i.e., non-breaking kinds of changes, should mean there's not a meaningful difference. > Again, the reference to [RFC9126] here is self-referential in > the replacement text so perhaps it belongs outside the intented section. > Yeah, I'll fix that one too. > > Section 5, replacement text paragraph 3: Strong typing alone does not > prevent > the attacks so it is RECOMMENDED. But it seems like it should be > RECOMMENDED > only if the audience restrictions alone are sufficient to prevent the > attacks. > Also, while I'm generally a fan of strong typing, if the audience > restrictions > are sufficient, I'm wondering how it fits with the vulnerability > identified in > the abstract. Perhaps it's just being used as a signaling mechanism to > indicate > that the vulnerability has been addressed, but as you point out it's not a > signal that can be acted upon for interoperablity reasons. > > This text admittedly isn't masterfully lucid verse but I'm not really sure what to do with it. It was originally put in there as full MUSTs/REQUIREDs but later softened to RECOMMENDED level for those insufficentcy and interoperability reasons. Basically, it now says that applying the strong type is recommended as a generally polite thing to do but that enforcing the presence of the type should only be done with with careful consideration. Do you think the normative language there should be further softened to MAY/OPTIONALish or maybe to just use non 2119 wording? Or am I missing the point of your point? Note too that there've been some other xdir reviewes asking for better descriptions of interop and compatibility considerations (like https://github.com/oauth-wg/draft-ietf-oauth-rfc7523bis/issues/28 and https://mailarchive.ietf.org/arch/msg/oauth/hqZ4DcUWmjg1EQ0d5cXv0DpwQJY/ ) so there's likely to be some additional treatment of the topic in general. Which maybe could inform or be informed by this disussion. -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
