I agree that this is the right approach (separate parameters to well defined scope attributes). However, so far the only well-defined attribute is a protected segment name (aka realm).
EHL On 4/3/10 1:25 AM, "Torsten Lodderstedt" <tors...@lodderstedt.net> wrote: > You are right, there are different aspects of scope. Why not define one > optional parameter per scope aspect? > > Based on our experiences with implementing OAuth 1.0a at Deutsche > Telekom, I see the need for the following parameters > - resource: specification of the protected resource to be accessed > (type: URI or opaque string) > - requested permissions: permissions on this resource the client want > to get authorized by the user (comma-separated list of opaque strings). > The range of permissions is defined by the resource as part of its API > design. This could be something like "upload", "download", "sent", or > "establish connection". The set of available permissions might be > advertised by way of a WWW-Authenticate parameter (status code 401), as > part of a 403 response, or in a XRDS discovery process. > - requested duration: specification of the token duration the client > asks for > > regards, > Torsten. >> ... >> There isn't one - its service specific. >> >> The easy ones are: >> >> Duration >> List of protected resources, URI wildcard, or name of protected segment >> Read/write access or HTTP methods >> >> 3 years ago when we dropped the scope/token_attributes parameter from the >> spec we decided to bring it back when we have enough deployment experience. >> I strongly believe this rule still holds. >> >> It would be great if those with OAuth 1.0a deployments can share how they >> specify scope. >> >> 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
