[OAUTH-WG] Re: Call for adoption for RFC8725bis

[Yaron Sheffer <[e-mail]>]

Adding to Mike’s response: the BCP, already in the published RFC8725, includes a SHOULD NOT for RSA-PKCS1 v1.5. And it was published 4 years before the “deprecate” draft.

Thanks,
      Yaron

From: Michael Jones <[e-mail]>
Date: Monday, 1 December 2025 at 17:33
To: Brian Campbell <bcampbell=[e-mail]>, Rifaat Shekh-Yusef <[e-mail]>
Cc: oauth <[e-mail]>
Subject: [OAUTH-WG] Re: Call for adoption for RFC8725bis

Hi Brian,

Your message was sent about the same time as I was sending the “Next steps for draft-ietf-oauth-rfc8725bis<https://mailarchive.ietf.org/arch/msg/oauth/pz9Frw1P5t8nndEkPhVC3ApkZ8c/>” message summarizing what we’d achieved to date with the RFC8725bis draft.  Now that working group last call has started, I wanted to also explicitly reply to your message saying what the authors have done as a result of your feedback, which we appreciate.

I’ll reply to the rest of the points in your note inline below, with my responses prefixed by “Mike>”.

From: Brian Campbell <bcampbell=[e-mail]>
Sent: Friday, November 7, 2025 3:21 PM
To: Rifaat Shekh-Yusef <[e-mail]>
Cc: oauth <[e-mail]>
Subject: [OAUTH-WG] Re: Call for adoption for RFC8725bis

The acknowledgements updates did happen and a changes from RFC8725 part was added but I don't believe anything in the first paragraph has been addressed or acknowledged.

On Fri, Aug 8, 2025 at 5:39 PM Brian Campbell <[e-mail]<mailto:[e-mail]>> wrote:
As I said during the meeting, I am supportive of doing this work but do hope the authors have appetite for what they might be signing up for. Aaron's review points to some of the work needed.

Mike> Aaron’s review comments were addressed in draft-ietf-oauth-rfc8725bis-02 in a PR that he approved.

The https://datatracker.ietf.org/doc/draft-ietf-jose-deprecate-none-rsa15/ work should almost certainly be referred to.

Mike> First, I’ll observe that RFC 8725 already included substantial treatment of “alg”: “none”, which was retained in this draft, so I believe this topic is already well covered in the specification.  Next, I’ll note that the draft you cite has not reached WGLC and is still subject to change.  As I wrote in my next steps message “There’s precedent in OAuth for not holding up publishing a BCP because other developments may update the BCP later.  In particular, we decided not to hold the OAuth Security BCP [RFC 9700] until we’d addressed already known vulnerabilities, including the one being addressed in rfc7523bis.  Our logic was that it is better to publish the BCP in a timely fashion to get a set of useful information out to people and that the BCP will be updated when the mitigations for additional vulnerabilities are settled.  As an individual I’ll say that I think that precedent should also apply here.”

I believe the current text around compression in JWE is a bit overreaching and lacking in subtlety about when it's reasonable to use.

Mike> As asked on the OAuth office hours call on Monday, November 17, 2025, are there new JWT best practices that have emerged on this topic since RFC 8725 was published that you can cite that you believe should be included in the draft, Brian?  If so, please provide proposed text.

I'm not terribly thrilled about the way explicit typing has worked in practice but I'm admittedly not sure how it could be improved at this point. I'm sure there's more once the box is opened.

Mike> As asked on the OAuth office hours call on Monday, November 17, 2025, are there new JWT best practices that have emerged on this topic since RFC 8725 was published that you can cite that you believe should be included in the draft, Brian?  If so, please provide proposed text.

It seems the draft is largely a rehash of RFC8725 with some additions and likely other updates. It should probably explicitly obsolete RFC8725 and indicate that it updates BCP 225 by replacing 8725.

Mike> The specification does both of these things (and says so in the Abstract).

A more formal section that describes the changes from RFC8725 would also be nice and is AFAIK common practice in such a document.

Mike> Appendix A does this.

Similarly it'd be good etiquette to, in the acknowledgements, distinguish between contributors to the original document and those that have contributed to the updates. I know from some github interactions, for one example, that ⁨Filip Skokan⁩ has helped guide some of the updated text but he's not mentioned at present.

Mike> Section 6.1 is the acknowledgements from RFC 8725.  Section 6.2 is the acknowledgements for this specification.

As also somewhat gratuitously mentioned at the meeting, a few years back I did a talk a few times on JWT vulnerabilities and tried to take a balanced look at many of the criticisms. I don't think there's anything novel or unknown in it, but I think it might provide some useful perspective. If anyone is interested in seeing that, or just helping drive the meager view count up, a recording of one instance of the talk is here https://www.youtube.com/watch?v=IgKRGS6cQWw

Mike> Again, if there are additional JWT best current practices that have emerged since RFC 8725 was published that you believe should be included, please cite them and provide proposed text for the draft.

                                                           Thanks,
                                                           -- Mike

On Wed, Aug 6, 2025 at 11:03 AM Rifaat Shekh-Yusef <[e-mail]<mailto:[e-mail]>> wrote:
All,

This is a call for adoption for the RFC8725bis draft that was discussed during the last IETF meeting in Madrid:
https://datatracker.ietf.org/doc/draft-sheffer-oauth-rfc8725bis/

Remember that adoption does not mean a document is finished, only that it is an acceptable starting point.

Please, reply on the mailing list and let us know if you are in favor or against adopting this draft as WG document, by August 22nd.

Regards,
 Rifaat & Hannes
_______________________________________________
OAuth mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>

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.