Re: [OAUTH-WG] Registration: Scope Values

[Justin Richer <[e-mail]>]

On 04/15/2013 10:52 AM, Tim Bray wrote:
> I’d use the existing wording; it’s perfectly clear.  Failing that, if 
> there’s strong demand for registration of structured scopes, bless the 
> use of regexes, either PCREs or some careful subset.

Thanks for the feedback -- Of these two choices, I'd rather leave it as-is.

>
> However, I’d subtract the sentence “If omitted, an Authorization 
> Server MAY register a Client with a default set of  scopes.”  It adds 
> no value; if the client doesn’t declare scopes, the client doesn’t 
> declare scopes, that’s all.  -T

Remember, all of these fields aren't just for the client *request*, 
they're also for the server's *response* to either a POST, PUT, or GET 
request. (I didn't realize it, but perhaps the wording as stated right 
now doesn't make that clear -- I need to fix that.) The value that it 
adds is if the client doesn't ask for any particular scopes, the server 
can still assign it scopes and the client can do something smart with 
that. Dumb clients are allowed to ignore it if it doesn't mean anything 
to them.

This is how our server implementation actually works right now. If the 
client doesn't ask for anything specific at registration, the server 
hands it a bag of "default" scopes. Same thing happens at auth time -- 
if the client doesn't ask for any particular scopes, the server hands it 
all of its registered scopes as a default. Granted, on our server, 
scopes are just simple strings right now, so they get compared at the 
auth endpoint with an exact string-match metric and set-based logic.

  -- Justin

>
>
> On Mon, Apr 15, 2013 at 7:35 AM, Justin Richer <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     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
>>>
>>
>>
>
>