Regarding explicit typing, splitting topics as per this message <https://mailarchive.ietf.org/arch/msg/oauth/9iDsDNx8kkpBR4Gib5UbRNNiSZ4/>, I did say in the message to the list back in *August* <https://mailarchive.ietf.org/arch/msg/oauth/wXCAE-FcUHDcv7bsvpsiI62NpGY/> that I wasn't sure how it could be improved at this point. But that's different from doing nothing. At a minimum, there should be some additional treatment around the limitations of applying it to existing protocols/profiles (in most cases doing so would either be a breaking change or forgo much of the value of it). Two open issues on OIDC (2162 <https://bitbucket.org/openid/connect/issues/2162/recommendation-to-the-use-of-explicit> / 2185 <https://bitbucket.org/openid/connect/issues/2185/id-tokens-should-have-an-associated-media>), recent work in rfc7523bis <https://github.com/oauth-wg/draft-ietf-oauth-rfc7523bis/issues/8>, this in openid-key-binding <https://github.com/dickhardt/openid-key-binding/issues/5>, parts of whatever happened here <https://github.com/oauth-wg/draft-ietf-oauth-rfc8725bis/issues/15>, a WIMSE discussion Yaron and I were in just last week, and more that I don't have reference to offhand certainly suggest there's need for more guidance and clarity in an update to the BCP.
As mentioned here <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/327> and probably elsewhere, I'm not convinced that the use of the 'typ' header and media types has proven to be the best or even a good vehicle for explicit typing. So I am not a fan of continued advocacy of it as a best practice. But it is largely ingrained current practice that would likely be untenable to change now. I won't be so presumptuous as to suggest a major change there but having this in the mailing list archive will hopefully prove useful down the road somehow though. Some treatment of "typ":"JWT" would also be worthwhile in an update to the BCP. If the construct provides any meaningly useful value, it'd be nice for the BCP update to explain it, otherwise the document should discourage its use. 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._
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
