[OAUTH-WG] Re: draft-ietf-oauth-rfc7523bis-07 ietf last call Artart review

[Brian Campbell <[e-mail]>]

Thanks Jim.

Despite my lack of prowess with a surfboard, we did indeed have a wonderful
spring break.

See inline below and this new PR
https://github.com/oauth-wg/draft-ietf-oauth-rfc7523bis/pull/33



On Thu, Apr 16, 2026 at 2:43 PM Jim Fenton <[e-mail]> wrote:

> Thanks, Brian, for the updates and hope your family had a good spring
> break. The update addresses the majority of my comments, and thanks
> especially for taking care of the self-referential text updates. A few
> remaining comments inline below.
>
> On 16 Apr 2026, at 11:09, Brian Campbell wrote:
>
> > Hey Jim, draft -08 has the indicated changes
> > https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-rfc7523bis-08
> >
> > If there's more you'd like to see based on the unresolved questions or
> > answers, please let us know and we'll work towards further resolution.
> >
> > On Wed, Apr 15, 2026 at 10:03 AM Brian Campbell <
> [e-mail]>
> > wrote:
> >
> >> On Fri, Apr 3, 2026 at 1:32 PM Jim Fenton via Datatracker <
> >> [e-mail]> wrote:
> >>
> >>
> >> 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?
>
> I prefer "metadata values cannot be directly validated" as that makes the
> reason for non-validation clearer.
>

Done!



> >>>
> >>> 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.
>
> Probably fine as-is, but I do prefer the more clearly normative MUST.
>

I'm gonna take the offered out of "fine as-is" on this one.



> >>> [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.
>
> Maybe someone with more editorial expertise than me should weigh in here,
> but I wonder if this document should reference the same document as RFC
> 9126, even though it isn’t the latest revision any more.
>

I genuinely don't think it makes any practical difference, but I'm happy to
do either. Who among us has that editorial expertise? I suspect that Mike,
who originally put the errata set 2 reference there, would claim
such expertise. But I don't know if you'd find that convincing. I know that
I only find it convincing when it fits my agenda:)



>
> >>>
> >>> 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.
>
> I’m not 100% positive that I understand the compatibility issue (even with
> the new Section 6) but I think that the “be conservative in what you send”
> position would be that the use of explicit typing is REQUIRED for clients.
> The “be liberal in what you accept” is correctly addressed by not
> recommending servers reject JWTs lacking explicit types.


That makes sense. I think I previously balked at that because some of the
wording around RECOMMENDED->REQUIRED would also need adjustments to avoid
being conceptually awkward. But it's already kind of awkward and maybe is
an opportunity for improvement in a couple of respects.

-- 
_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._