Hi, I tried to bring this issue to your attention before, but maybe chances are better if I frame my question in a review of a specific version :-)
So, I reviewed https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-08. Here's my question about section 5.2.3 ( https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-08#section-5.2.3 ): All challenges for this token type MUST use the auth-scheme value Bearer. This scheme MUST be followed by one or more auth-param values. What is the purpose of requiring at least one auth-param (MUST)? The mentioned auth-params realm, scope (MAY), error (SHOULD), error_description, error_uri (MAY) are all optional on their own. Consider the following situation: A resource request lacking a bearer token; so no error, error_description, error_uri (SHOULD NOT per https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-08#section-5.2.4 ) There are no separate realms; so realm is not necessary IMO. The scope auth-param doesn't seem applicable either. Is WWW-Authenticate: Bearer realm="default" or WWW-Authenticate: Bearer realm="" or WWW-Authenticate: Bearer foo="bar" better than having no auth-param at all? Maybe this is a legacy from good old HTTP/1.1. When "Bearer Token Usage" became RFC 6750 in 2012, WWW-Authenticate was still defined by RFC 2616, and RFC 2617 defined challenge as challenge = auth-scheme 1*SP 1#auth-param , thus requiring at least one auth-param. However, things changed: RFC 7235 (2014, https://www.rfc-editor.org/rfc/rfc7235#section-2.1) and RFC 9110 (2022, https://www.rfc-editor.org/rfc/rfc9110#section-11.3) do not have this requirement anymore: challenge = auth-scheme [ 1*SP ( token68 / #auth-param ) ] So I propose to change the MUST (regarding the "one or more auth-param values") into (at least) a SHOULD. See issue 108 in the github repo ( https://github.com/oauth-wg/oauth-v2-1/issues/108). -- Johannes Koch
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
