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 t
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
https://too
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 OAut
