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
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
