There are times when a resource may have different scope for different kinds of access. realm != scope
On 2010-04-02, at 2:45 PM, Igor Faynberg wrote: > > > I don't see any problem at all. > > Igor > > David Recordon wrote: >> Assuming that this is mean to replace the scope parameter? >> >> On Fri, Apr 2, 2010 at 9:18 AM, Eran Hammer-Lahav <e...@hueniverse.com> >> 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' >>> >>> 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? >>> >>> EHL >>> >>> _______________________________________________ >>> 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 >> > _______________________________________________ > 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
