Gmail always returns a non-empty scope value in our error response, so the proposed protocol change would not affect our implementation.
On Sun, Mar 22, 2015 at 10:26 PM, Benjamin Kaduk <ka...@mit.edu> wrote: > 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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
