'scope' shouldn't be defined as a <URI-Reference> (as it is in section 6.1 WWW-Auth header). That implies two 'scope' values should be compared as URIs -- by seeing if they identify the same resource (ie resolve to the same absolute URI). I don't think this was intended.
Facebook, for instance, have a 'scope' of "user_photos". I am sure they don't (and shouldn't have to) accept "./user_photos" or "user%5Fphotos" or "https://graph.facebook.com/user_photos"; as equivalent. If 'scope' in a WWW-Auth response header is a relative URI it is presumably relative to the requested URI. Hence, WWW-Auth responses for requests to https://api.example.com/123 and https://api.example.com/123/albums that both include scope="user_photos" actually indicate different scopes. There is also an important typo in 6.1: 1#URI-Reference means comma-separated values; but the text says space-separated values. Suggested solution 1: Remove the "scope" parameter from the WWW-Auth response. Remove the ABNF for <scope> and the paragraph describing it. [Note: the <user-uri> can still include a 'scope' query parameter.] Suggested solution 2: (subject to getting a answer to Torsten's question about what an OAuth2 client does with 'scope' in WWW-Auth) Change <scope> to be a list of strings, not <URI-Reference>s, and adjust the paragraph describing it accordingly. scope = "scope" "=" <"> scope-v *(" " scope-v) <"> scope-v = 1*(reserved / unreserved / pct-encoded) The "scope" attribute is a list of space-delimited strings indicating the required scope of the access token for accessing the requested resource. The order of the strings in the list does not matter. Each string can contain the characters allowed in a URI so an authorization server can choose to use URIs for scope strings. However, the strings do not have to be URIs so client apps MUST NOT assume they are URIs. In particular, individual string values MUST be compared character-for-character without any URI normalization. Consequently, an authorization server that chooses to use URIs as scope strings needs to be careful to use a consistent normalization everywhere. P.S. The spec defines 'scope' in 8 separate places: 6 definitions are identical; 1 is almost identical; and the last (in 6.1. The WWW-Authenticate Response Header) is different. Wouldn't it be better to define it just once? -- James Manger _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
