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 <jric...@mitre.org> 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" <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
