Thanks John. I tend to agree that realm comes with a lot of baggage and is probably not going to work given people's expectations. After all, they are not likely to study 2617 before implementing OAuth.
The point of my proposal was to show one aspect of scope in which the client is being told what kind of access it should ask for. The client treats this as an opaque string, and it remains the an opaque string (i.e. No higher level handling by the client). In this scenario, if the client has an access token for "photos,contact", it will not use it for "contact,photos". There seems to be high demand for scope parameter support, but very little actual use cases (provided). EHL On 4/4/10 2:34 PM, "John Kemp" <j...@jkemp.net> wrote: Hi Eran, On Apr 2, 2010, at 12:18 PM, Eran Hammer-Lahav wrote: > This is half baked but I wanted to get people's reaction: > > Clients tries accessing a resource with or without an access token: > > GET /resource/1 HTTP/1.1 > Host: server.example.com > > The server replies with: > > HTTP/1.1 401 Unauthorized > WWW-Authenticate: OAuth realm='example' >From RFC 2617 (http://www.ietf.org/rfc/rfc2617.txt): "The realm value (case-sensitive), in combination with the canonical root URL (the absoluteURI for the server whose abs_path is empty; see section 5.1.2 of [2]) of the server being accessed, defines the protection space. These realms allow the protected resources on a server to be partitioned into a set of protection spaces, each with its own authentication scheme and/or authorization database. The realm value is a string, generally assigned by the origin server, which may have additional semantics specific to the authentication scheme. Note that there may be multiple challenges with the same auth-scheme but different realms." and: realm A string to be displayed to users so they know which username and password to use. This string should contain at least the name of the host performing the authentication and might additionally indicate the collection of users who might have access. An example might be "registered_us...@gotham.news.com". Leading me to conclude: i) Realm is supposed to contain a hint for users as to which username/password to use (ie. a client cannot by default assume it to be machine-readable) ii) The "protection space" defined by a realm may be as small as one resource, or as big as an entire site. RFC2617 tells clients what they can assume if they receive a challenge: "A client SHOULD assume that all paths at or deeper than the depth of the last symbolic element in the path field of the Request-URI also are within the protection space specified by the Basic realm value of the current challenge. A client MAY preemptively send the corresponding Authorization header with requests for resources in that space without receipt of another challenge from the server." > > Clients requests an access token (using the client credentials flow) and > includes the requested realm (line breaks for display purposes): > > POST /access_token HTTP/1.1 > Host: server.example.com > > client_id=s6BhdRkqt3&client_secret=8eSEIpnqmM& > mode=flow_client&realm=example > > The server issues a access token capable of accessing the resource realm. > > This means one new parameter on the request side which is already baked into > the 401 response in a standard way. > > Thoughts? I think that RFC2617 realms are similar in concept to the 'scope' you're looking for, but have some differences in use for the HTTP basic/digest protocol. In order to be sure you don't confuse clients which already know HTTP Basic/Digest, you may want to place some further restrictions on the values that can be in the realm parameter when a WWW-Authenticate challenge is issued (it's just a string in RFC2617). If a client receives an OAuth WWW-Authenticate challenge, I would assume that OAuth should anyway tell the client whether/what to present the user in order to have the client get an appropriate token to access the protected resource. Some care is needed to specify this in a way that is compatible with the expected behaviour of user agents already familiar with RFC2617. Regards, - johnk
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
