Re: [OAUTH-WG] Registration: Scope Values

[Justin Richer <[e-mail]>]

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
>