Hi Eran,
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).
how shall we proceed in order to come to more well-defined attributes? I
already proposed some, can we discuss them?
regards,
Torsten.
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
