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