While I don't disagree, what are we talking about here? * matching the auth scheme case-insensitively * handling more than one space as separator (the value for Bearer or DPop in Authorization are a single opaque token, so there's not even parsing involved here; in WWW-Authenticate, this follows RFC 9110)
Both of those come from RFC 9110, deviating from it IMO is a bad idea, and could make HTTP-compliant libraries incompatible with OAuth, requiring writing new code. As Neil Madden just said while I was typing this, OAuth could recommend/suggest using a single space (like HTTP/1.1 does for headers: https://datatracker.ietf.org/doc/html/rfc9112#name-field-line-parsing), and using the title-case name (like it's been registered at the IANA: https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml#authschemes ) On Sun, Jul 6, 2025 at 8:57 PM Warren Parad <wpa...@rhosys.ch> wrote: > Sure, but Postel's Law is actually harmful. And the "volume of LLM code" > isn't the relevant metric, but rather "What the future of generated LLM > code will look like". That is what is being generated at the moment, I > don't find relevant either, but rather what will be generated in the > future, and the implications of that. So we should be thoughtful about the > impact of the spec we write rather than seek to have the spec match only > what was a past reality. So, I generally recommend disregarding "Postal's > Law" as a long term strategy. This draft I find to be quite insightful on > the topic: > https://www.ietf.org/archive/id/draft-iab-protocol-maintenance-05.html > > On Sun, Jul 6, 2025 at 8:48 PM Dick Hardt <dick.ha...@gmail.com> wrote: > >> To be clear, lowercase or all uppercase are all valid. Many resource >> servers parse the header with code like I shared. >> >> The volume of LLM generated code is going to grow exponentially -- I was >> using Claude's latest version to get this result. >> >> Postel's Law: "Be conservative in what you send, be liberal in what you >> accept." >> >> The sample code is strict in what it accepts unfortunately. >> >> >> On Sun, Jul 6, 2025 at 6:34 PM Warren Parad <wpa...@rhosys.ch> wrote: >> >>> I think we should consider which pattern would more likely avoid >>> security-related issues in the future. >>> >>> I also would completely disregard all LLM generated code. It is an >>> interesting heuristic for "the model got that suggestion from somewhere >>> with high enough frequency", but arguably the simpler the spec, the easier >>> it will be to generate compliant code by future LLMs. And also this will >>> change as time goes on, as implementations are generated more successfully. >>> >>> We also know that most earth providers can't even follow the spec on it >>> is today, creating their own custom things. It seems like being strick here >>> in the spec is better than not. >>> >>> Just like HTTP2 has lowercase headers, I wound prefer bearer to also be >>> lowercase, but I appreciate the breaking change that would require. >>> >>> "Being as permissible as possible" is not actually a good thing. >>> >>> On Sun, Jul 6, 2025, 19:23 Dick Hardt <dick.ha...@gmail.com> wrote: >>> >>>> Which code is badly written -- the one that has two spaces? or the one >>>> that only parses a single space? >>>> >>>> On Sun, Jul 6, 2025 at 6:07 PM Thomas Broyer <t.bro...@gmail.com> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Sun, Jul 6, 2025 at 6:57 PM Dick Hardt <dick.ha...@gmail.com> >>>>> wrote: >>>>> >>>>>> Did you look at the code? (Its JavaScript) :) >>>>>> >>>>>> bearer will fail as the startsWith() is looking for 'Bearer' >>>>>> >>>>>> If there is a starting space >>>>>> >>>>> >>>>> There's no such thing as a "starting space": >>>>> https://datatracker.ietf.org/doc/html/rfc9110#name-field-values >>>>> >>>>> >>>>>> or 2 spaces between Bearer and the token it will fail >>>>>> >>>>> >>>>> So what? >>>>> Are you suggesting changing a spec to please badly written/broken code‽ >>>>> Also, what it is that you consider "widely deployed" in your first >>>>> message? >>>>> >>>> _______________________________________________ >>>> OAuth mailing list -- oauth@ietf.org >>>> To unsubscribe send an email to oauth-le...@ietf.org >>>> >>> -- Thomas Broyer /tɔ.ma.bʁwa.je/ <https://ipa-reader.com/?text=t%C9%94.ma.b%CA%81wa.je&voice=Mathieu>
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
