Re: [OAUTH-WG] Registration: Scope Values

[Tim Bray <[e-mail]>]

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]> 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]> 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.0 Section 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 [e-mail]://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>