Hi Mike, Yes, we had messages cross paths on that evening of Friday, November 7, 2025 after the last session of the Montreal meeting. The good news is that my message was a followup to the message from back in August "Re: Call for adoption for RFC8725bis <https://mailarchive.ietf.org/arch/msg/oauth/wXCAE-FcUHDcv7bsvpsiI62NpGY/>" during the adoption call, which itself mentioned the discussion in Madrid <https://datatracker.ietf.org/doc/minutes-123-oauth-202507251230/> where many of us were present, so there shouldn't have been any surprises. Unfortunately, however, there seem to have been a few surprises in all this (I count myself as one of the surprised <https://datatracker.ietf.org/doc/minutes-124-oauth-202511071930/> fwiw) and my perception is that much of the reaction has missed the mark or hasn't quite engaged with the core concerns. I'll attempt to restate those concerns here and in some subsequent messages as WGLC feedback (notwithstanding belief that WGLC was premature).
Regarding compression, as stated previously, I believe the current text around compression in JWE is a bit overreaching and lacking in useful guidance about when it is or is not reasonable to use. Section 3.6 <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rfc8725bis-02#section-3.6> has a SHOULD NOT on compressing the JWE payload because it "often reveals information about the plaintext" but nothing about when the recommendation isn't actually applicable. Section 2.4 <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rfc8725bis-02#section-2.4>, which points to that 3.6, does have some more text about "Plaintext Leakage through Analysis of Ciphertext Length" but mostly in the context of HTTPS, which is, of course, a completely different protocol with different considerations. I don't claim expertise but the conditions and problems described don't seem applicable to archetypal JW/JWT usage. I anecdotally understand there's been implementation(s) that dropped support for the zip header, at least in part due to this text in RFC8725, which doesn't seem great for interop. Some recent SDO work like OpenID4VCI do have some "negotiation" capabilities <https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#section-8.2-2.4.1> around it but that one is the exception rather than the rule, which again doesn't seem good for interop. On Mon, Dec 1, 2025 at 8:33 AM Michael Jones <[email protected]> wrote: > 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 <[email protected]> > *Sent:* Friday, November 7, 2025 3:21 PM > *To:* Rifaat Shekh-Yusef <[email protected]> > *Cc:* oauth <[email protected]> > *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 <[email protected]> > 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 < > [email protected]> 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 -- [email protected] > To unsubscribe send an email to [email protected] > > > *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.* > -- _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]
