Re: [OAUTH-WG] Registration: Scope Values

[Tim Bray <[e-mail]>]

On Mon, Apr 15, 2013 at 9:44 AM, Mike Jones <[e-mail]>wrote:

>  So I’d propose that we leave the existing scope wording in place.
> Alternatively, I’d also be fine with deleting this feature entirely, as I
> don’t think it’s useful in the general case.
>

I think we might well have a use for this, so that’s something of an
existence proof.  So I’d prefer if we could leave it in. -T



>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *From:* [e-mail] [mailto:[e-mail]] *On Behalf
> Of *Justin Richer
> *Sent:* Monday, April 15, 2013 8:05 AM
> *To:* Tim Bray; [e-mail]
>
> *Subject:* Re: [OAUTH-WG] Registration: Scope Values****
>
>  ** **
>
> 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]> 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]> 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 list****
>
> [e-mail]****
>
> https://www.ietf.org/mailman/listinfo/oauth****
>
>  ** **
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>