I agree that we should align with http for the reasons mentioned elsewhere in the thread, and also because OAuth 2.1 should only consolidate existing specifications without introducing new behavior.
I also agree that the existing examples seem sufficient. It would be problematic to pick which capitalization of bearer to suggest as the best way to deal with non-conforming RS implementations. Surely there are implementations that incorrectly require "Bearer" and others "bearer"? Joe On Sun, Jul 13, 2025 at 2:51 PM Justin Richer <[email protected]> wrote: > We should absolutely align with http. I believe this is already addressed > in the language and examples of OAuth 2.1, yes? > > This would hardly be the first example of an AI powered tool creating > extremely fragile code, anyway. Coddling it won't help it get better. > > - Justin > ------------------------------ > *From:* Dick Hardt <[email protected]> > *Sent:* Sunday, July 6, 2025 8:22 AM > *To:* [email protected] <[email protected]> > *Subject:* [OAUTH-WG] coding agents don't follow the spec for parsing > Authorization header > > Hey > > I was working with Claude on an MCP server which requires authorization, > and it generated this code, > const authHeader = request.headers.authorization > if (authHeader && authHeader.startsWith('Bearer ')) { > const token = authHeader.split(' ')[1] > > which is likely based on patterns in the wild. In the OAuth 2.1 draft we > are making it clear that "Bearer" is case insensitive and that the > separator can be multiple spaces. A client sending > > Authorization: bearer ey-access-token > > > would of course fail in this validation. Do we as a WG want to be aligned > with the HTTP spec, or align with what is widely deployed? > > /Dick > > > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
