Re: [OAUTH-WG] Registration: Scope Values

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" <jricher@mitre.org> 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 listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>