Re: [OAUTH-WG] Authorization Header Encoding

[Vladimir Dzhuvinov <[e-mail]>]

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
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Vladimir Dzhuvinov