Like anything else, we need proposed text to discuss. Discussing a list of attributes is rarely practical. Discussing a concrete proposal usually works...
EHL On 4/6/10 3:23 AM, "Torsten Lodderstedt" <tors...@lodderstedt.net> wrote: 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
