Re: [OAUTH-WG] 'Scope' parameter proposal

[Chasen Le Hara <[e-mail]>]

Your original proposal seems like it would do the trick, although I would
make the allowed scope values as flexible as possible while allowing
multiple scope values to be separated by commas or spaces.

If the scope values were opaque to the client, then a server could use
values such as "accounts", "read:accounts", or "GET:accounts". This would
fit my needs for Iron Money.

As proposed, the server could respond to unauthorized requests with the
minimum scope values required to make the client’s next request successful.

Hopefully this is the kind of feedback you were looking for.
-Chasen

On Wed, Apr 21, 2010 at 2:41 PM, Eran Hammer-Lahav <[e-mail]>wrote:

> How about review the proposals?
>
>
>
> EHL
>
>
>
> *From:* [e-mail] [mailto:[e-mail]] *On Behalf
> Of *Chasen Le Hara
> *Sent:* Wednesday, April 21, 2010 1:23 PM
> *To:* Eve Maler
> *Cc:* [e-mail]; OAuth WG
>
> *Subject:* Re: [OAUTH-WG] 'Scope' parameter proposal
>
>
>
> Hi all,
>
>
>
> On Tue, Apr 20, 2010 at 6:05 PM, Eve Maler <[e-mail]> wrote:
>
> It seems like this proposal "goes there" in terms of getting as expressive
> as Eran fears, though the addition of the wildcard takes away a good deal of
> the pain depending on the particular interface at the endpoint(s). Is there
> any wider interest in "going there"?
>
>
>
> Yes. A couple months ago Iron Money implemented a permissions system[1]
> that includes read_permissions and write_permissions as parameters when
> getting a request token. Those two parameters take a comma-separated list of
> pre-defined resource values (such as "write_permissions=accounts" for read
> and write permissions for the /accounts/ resource).
>
>
>
> If what is specified by OAuth 2.0 doesn’t meet Iron Money’s needs, that’s
> fine, but I wanted to raise my hand high as one of the people interested in
> a high level of expressiveness.
>
> -Chasen
>
>
>
> [1] https://ironmoney.com/api/permissions/
>