+1 for solution 2
Regarding usage of the scope attribute: As Dick suggested, the spec
should state that the client should pass the scope attributes content to
the corresponding scope parameter in any authorization flow. Moreover, I
would suggest, clients should be allowed to combine scopes from
different resources into on authorization flow, if the tokens- and
user-uri are the same (== same authz server). The resulting scope should
be the union of all scopes, where scope equivalence is determined by a
simple string compare.
regards,
Torsten.
Am 02.06.2010 02:55, schrieb Manger, James H:
'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?
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
