Hi all,
During the shepherd review for draft-ietf-kitten-sasl-oauth-19, I noticed
an old comment from Matt back in December 2013, in
http://www.ietf.org/mail-archive/web/kitten/current/msg04488.html .
The relevant point here is that sending a scope of "" (the empty string)
during the authorization request violates the ABNF in RFC 6749. (The
other concerns seem to have been addressed by suggesting that a single
scope be used, when recommending against a space-separated list.)
In the current draft-ietf-kitten-sasl-oauth-19, in section 3.2.2 ("Server
Response to Failed Authentication"), we provide a way for the server to
tell the client what scope to use, in a custom JSON message defined in the
sasl-oauth document. This error response has no obligation to comply to
the ABNF of RFC 6749, so saying both that the scope field is optional and
that it "may be empty which implies that unscoped tokens are required, or
a scope value" does not cause any compliance issues. However, a few
paragraphs down, we furthermore say that "[i]f the resource server
provides no scope to the client then the client SHOULD presume an empty
scope (unscoped token) is required to access the resource." The phrase
"empty scope" here is concerning, and seems to suggest sending scope="",
which is disallowed by RFC 6749.
The simple fix would be to just replace "empty scope (unscoped token)"
with "unscoped token".
However, it is a bit aesthetically unpleasing to have our new JSON
structure diverge from the existing ABNF guidelines; we may wish to just
utilize the optionality of the scope field in the server's response to
failed authentication, and remove the mention of an empty value for that
field. This proposal is a change to the wire protocol, and so we would
need consensus from the working group to move forward with it -- in
particular, we would like to know if there are existing implementations
which would be affected by this change.
Please comment about the proposal to remove the option of an empty scope
in the server's response to failed authentication, both from the protocol
change standpoint and from its effects on existing implementations.
Thank you,
Ben
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
