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 that’s better. I’ll guarantee you that developers aren’t following “token68” syntax in practice when making Bearer headers.
— Justin > On Feb 17, 2021, at 6:35 PM, Brian Campbell > <bcampbell=40pingidentity....@dmarc.ietf.org> wrote: > > 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 > <https://tools.ietf.org/html/rfc7235#section-2.1> (the draft that would > become RFC7235 is referenced by RFC6750 in > https://tools.ietf.org/html/rfc6750#section-2.1 > <https://tools.ietf.org/html/rfc6750#section-2.1> where it says basically as > much). > > Also it looks like https://github.com/httpwg/http-core/issues/733 > <https://github.com/httpwg/http-core/issues/733> was closed with no action. > > So I don't see what change would be made in OAuth 2.1 or elsewhere. Nor does > it seem like any change is needed or appropriate. > > On Mon, Feb 15, 2021 at 4:34 AM Vladimir Dzhuvinov <vladi...@connect2id.com > <mailto:vladi...@connect2id.com>> wrote: > 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 OAuth 2.1 seems like the > most sensible move. I expect OAuth 2.0 implementers who maintain their > software to pick up the 2.1 spec, sooner or later. > > Vladimir > > > > On 12/02/2021 00:01, Justin Richer wrote: >> 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 >> <https://github.com/httpwg/http-core/issues/733> >> >> As it turns out, Bearer defines a more limited character set than is allowed >> by core HTTP, and doesn’t follow the HTTP guidelines and definitions for the >> Authorization header. There were a few observations on the call: >> >> - The Bearer spec was limited because OAuth tokens were also allowed in >> HTTP URLs and form parameters (and therefore had to have a more limited >> character set) >> - In practice people don’t actually restrict the values they put into this >> field; pretty much any implementation is just going to concatenate whatever >> access token value they get to the magic word “Bearer” and send it >> - It’s not likely (or in my opinion proper) for the HTTP spec to change to >> address the oddities of RFC6750 and decisions that were made many years ago >> >> So the question is, what do we do about it? We could do a revision of 6750 >> that reflects reality better, pretty much just changing the ABNF. >> >> Or, we could update the definition of the Bearer header in the upcoming >> OAuth 2.1 specification. >> >> Are there other options? >> >> — Justin >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> > -- > Vladimir Dzhuvinov > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > > 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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
