On Apr 19, 2010, at 6:17 PM, Eran Hammer-Lahav wrote: [...]
>>> >> >> I think that there is much that is unspecified in this model and thus it >> doesn't >> provide much interoperability. If we don't tell the client what to do with >> the >> scope, and we don't specify what a server means by supplying a scope, I'm >> not sure what the point is to specifying this at all as clients will still >> need some >> documentation or be hard-coded (which token service do I get such a token >> from?) > > Why? > > The server tells the client what scope is needed for each resource. It can be > a single scope id or multiple. The client checks to see if it has an access > token issued with that scope combination. If it doesn't it goes and request > an access token, and includes the required scope in the request. We can also > allow the server to tell the client what scope an issued token includes in > the token reply. > > The client doesn't need to understand the internal structure of the scope > identifiers. It just need to know what to ask for when trying to access an > unfamiliar resource. No documentation is needed. Which server does the client ask to get a token with the particular scope which was asked for? How does the client determine that it's OK to ask server B for a token with scope X at server A? > > Client: I want to get an address book record with the latest email to that > person. > Server: You need an access token scoped for "Contact" and "Email". > Client: Can I get an access token for scope=contact,email? To whom does the client address the above question? How does the client know that server's URL without it either being available in documentation or hard-coded inside the client? I'm just questioning whether the "amount of interoperability" you get (client still needs to read some documentation in order to participate) is sufficient to make the specification of 'scope' worthwhile on its own, unless we supply it with some more shared semantics. - johnk _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
