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

Reply via email to