Re: [OAUTH-WG] Registration: Scope Values

[Justin Richer <[e-mail]>]

What would you suggest for wording here, then? Keeping in mind that we 
cannot (and don't want to) prohibit expression-based scopes.

  -- Justin

On 04/15/2013 10:33 AM, Tim Bray wrote:
> No, I mean it’s not interoperable at the software-developer level.  I 
> can’t register scopes at authorization time with any predictable 
> effect that I can write code to support, either client or server side, 
> without out-of-line non-interoperable knowledge about the behavior of 
> the server.
>
> I guess I’m just not used to OAuth’s culture of having no expectation 
> that things will be specified tightly enough that I can write code to 
> implement as specified.  -T
>
>
> On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Scopes aren't meant to be interoperable between services since
>     they're necessarily API-specific. The only interoperable bit is
>     that there's *some* place to put the values and that it's
>     expressed as a bag of space-separated strings. How those strings
>     get interpreted and enforced (which is really what's at stake
>     here) is up to the AS and PR (or a higher-level protocol like UMA).
>
>      -- Justin
>
>
>     On 04/15/2013 10:13 AM, Tim Bray wrote:
>>
>>     This, as written, has zero interoperability.  I think this
>>     feature can really only be made useful in the case where scopes
>>     are fixed strings.
>>
>>     -T
>>
>>     On Apr 15, 2013 6:54 AM, "Justin Richer" <[e-mail]
>>     <mailto:[e-mail]>> wrote:
>>
>>         You are correct that the idea behind the "scope" parameter at
>>         registration is a constraint on authorization-time scopes
>>         that are made available. It's both a means for the client to
>>         request a set of valid scopes and for the server to provision
>>         (and echo back to the client) a set of valid scopes.
>>
>>         I *really* don't want to try to define a matching language
>>         for scope expressions. For that to work, all servers would
>>         need to be able to process the regular expressions for all
>>         clients, even if the servers themselves only support
>>         simple-string scope values. Any regular expression syntax we
>>         pick here is guaranteed to be incompatible with something,
>>         and I think the complexity doesn't buy much. Also, I think
>>         you suddenly have a potential security issue if you have a
>>         bad regex in place on either end.
>>
>>         As it stands today, the server can interpret the incoming
>>         registration scopes and enforce them however it wants to. The
>>         real trick comes not from assigning the values to a
>>         particular client but to enforcing them, and I think that's
>>         always going to be service-specific. We're just not as clear
>>         on that as we could be.
>>
>>         After looking over everyone's comments so far, I'd like to
>>         propose the following text for that section:
>>
>>
>>             scope
>>                OPTIONAL.  Space separated list of scope values (as described in
>>                OAuth 2.0Section 3.3 [RFC6749]  <http://tools.ietf.org/html/rfc6749#section-3.3>) that the client can use when
>>                requesting access tokens.  As scope values are service-specific,
>>                the Authorization Server MAY define its own matching rules when
>>                determining if a scope value used during an authorization request
>>                is valid according to the scope values assigned during
>>                registration. Possible matching rules include wildcard patterns,
>>                regular expressions, or exactly matching the string. If omitted,
>>                an Authorization Server MAY register a Client with a default
>>                set of scopes.
>>
>>
>>         Comments? Improvements?
>>
>>          -- Justin
>>
>>
>>         On 04/14/2013 08:23 PM, Manger, James H wrote:
>>>         Presumably at app registration time any scope specification is really a constraint on the scope values that can be requested in an authorization flow.
>>>
>>>         So ideally registration should accept rules for matching scopes, as opposed to actual scope values.
>>>
>>>         You can try to use scope values as their own matching rules. That is fine for a small set of "static" scopes. It starts to fail when there are a large number of scopes, or scopes that can include parameters (resource paths? email addresses?). You can try to patch those failures by allowing services to define service-specific special "wildcard" scope values that can only be used during registration (eg "read:*").
>>>
>>>         Alternatively, replace 'scope' in registration with 'scope_regex' that holds a regular expression that all scope values in an authorization flow must match.
>>>
>>>         --
>>>         James Manger
>>>         _______________________________________________
>>>         OAuth mailing list
>>>         [e-mail]  <mailto:[e-mail]>
>>>         https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>         _______________________________________________
>>         OAuth mailing list
>>         [e-mail] <mailto:[e-mail]>
>>         https://www.ietf.org/mailman/listinfo/oauth
>>
>
>