Re: [OAUTH-WG] Registration: Scope Values

[prateek mishra <[e-mail]>]

+1
>
> I think that the existing wording is superior to the proposed changed 
> wording.  The existing wording is:
>
>    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 is 
> declaring that
>
>       it may use when requesting access tokens. If omitted, an
>
>       Authorization Server MAY register a Client with a default set of
>
>       scopes.
>
> For instance, the current "client is declaring" wording will always be 
> correct, whereas as the change to "client can use" wording implies a 
> restriction on client behavior that is not always applicable.  The 
> "client is declaring" wording was specific and purposefully chosen, 
> and I think should be retained.  In particular, we can't do anything 
> that implies that only the registered scopes values can be used.  At 
> the OAuth spec level, this is a hint as to possible future client 
> behavior -- not a restriction on future client behavior.
>
> Also, for the reasons that Tim stated, I'm strongly against any 
> "matching" or "regex" language in the spec pertaining to scopes -- as 
> it's not actionable.
>
> 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.
>
> -- 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] 
> <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
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth