The issue was whether to remove the token68 portion and just use auth-param as
part of the syntax, as far as I know. Bearer goes a little off from even the
draft spec and admits as much in place. If we can improve the definition in
2.1, or at least make it clearer what’s expected, then I think
AFAIK the character set for the "Bearer" scheme in RFC6750 is what it is to
align with the token68 part of "credentials = auth-scheme [ 1*SP ( token68
/ #auth-param ) ]" from https://tools.ietf.org/html/rfc7235#section-2.1
(the draft that would become RFC7235 is referenced by RFC6750 in
Hi Justin,
Thanks for alerting us on this development.
+1 for keeping the updated HTTP semantics unencumbered by the
Authorization header formatting in RFC 6750.
IMO revising the RFC 6750 to reflect that is too late now, as few people
will notice. So updating the Bearer header definition in
The HTTP Working Group opened an issue for discussion in relation to the
updated HTTP semantics specification. The core of the issue is the format of
the “Authorization” header, which of course gets used by the “Bearer” scheme
defined in RFC6750.
https://github.com/httpwg/http-core/issues/733
