Re: [OAUTH-WG] Registration: Scope Values

[Justin Richer <[e-mail]>]

I would be fine with that addendum.

  -- Justin

On 04/18/2013 01:52 PM, Mike Jones wrote:
>
> I could live with it if you expanded the text slightly as follows.  
> Otherwise people will keep asking questions that they deserve an 
> answer to, even if the answer is "see the service documentation".
>
> 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 from the Authorization Server.  The 
> semantics of this list are service specific.
>
> -- Mike
>
> *From:*Justin Richer [mailto:[e-mail]]
> *Sent:* Thursday, April 18, 2013 10:47 AM
> *To:* Mike Jones
> *Cc:* Anthony Nadalin; Tim Bray; [e-mail]
> *Subject:* Re: [OAUTH-WG] Registration: Scope Values
>
> Thing is, there's nothing normative about the enforcing statement that 
> I made below, so I don't think it's any more restrictive than RFC 6749 
> which lets the AS replace a client's requested scopes at the time of 
> token issuance with whatever it pleases. But that said, I'd be just as 
> happy to leave it like this with no further restrictions:
>
> 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 from the Authorization Server.
>
> And call it a day. This parallels the text for grant_types ("Array of 
> OAuth 2.0 grant types that the Client may use [when accessing the 
> Token Endpoint].") and response_types ("Array of the OAuth 2.0 
> response types that the Client may use [when accessing the 
> Authorization Endpoint]."), and I think this is the correct approach. 
> I only started to add the restrictive text because I thought that 
> people were making the argument that it was necessary -- I'd rather 
> not have it.
>
>   
>
> Plus, it's an optional field in the metadata, so if you've got 
> structured scopes where this doesn't make sense, don't use it. If you 
> don't do a per-client scope restriction, don't use it.
>
> The interoperability is defined in light of the interoperability of 
> scopes themselves: this is a field to request/grant a bag of strings 
> that only make sense in light of a given API. For that to make real 
> sense, I think that we need to differentiate an OAuth client as a 
> generic *library* from an OAuth client as a generic accessing 
> *application*. It's very useful for a generic *library* that handles 
> the authorization layer for an application to have a slot for 
> registering scopes and finding out what scopes the app's been 
> registered for. It's up to the app (not the library) to figure out how 
> to translate those into scopes to ask for at authorization time. 
> Sometimes that means just passing the string, and sometimes it means 
> the construction of a structured value like 
> "urn:example:channel=HBO&urn:example:rating=G,PG-13". The library 
> doesn't care, the application does, and we should focus on 
> interoperability from the library's perspective. Similarly, on the 
> server side, the libraries will tell you the bag of scopes that the 
> client was registered for, and what bag of scopes the client asked for 
> during authorization. It's up to the server *application* to harmonize 
> those two in a way that makes sense for the API that it's protecting. 
> Just like it's up to the protected resource *application* to figure 
> out what a scope means in a given context.
>
> So let's just leave it unrestricted but keep the slot for 
> communicating this piece of information with the same semantics that 
> the communication between the client and server take on for every 
> other field: client asks for a thing, server says that client actually 
> gets a thing, and it's implicitly up to the server to do the right 
> thing and enforce things in a way that makes sense for the application 
> no matter what the client does.
>
> To take Tony's example, client requests no scopes at registration, 
> server grants scope "A" at registration. Client then requests scope 
> "X" at authorization, server is free to deny the request 
> (invalid_scope error), allow authorization because it knows how "A" 
> and "X" are related, require user intervention, or really, whatever it 
> likes. The libraries, where I argue the interoperability cries really 
> matter, don't care, and shouldn't care.
>
>  -- Justin
>
> On 04/18/2013 01:04 PM, Mike Jones wrote:
>
>     Saying anything normative about "enforcing restrictions" is going
>     beyond RFC 6749 semantics.  Indeed, you'd said that "I agree that
>     we shouldn't try to "solve" scope in registration.", but talking
>     about restrictions is going down the slippery "solving it" path.
>
>     At most we can say that the two parties are making declarations to
>     one another about scopes that they may choose to use, but we can't
>     assume that this is an exclusive list and that other scope values
>     such as "urn:example:channel=HBO&urn:example:rating=G,PG-13" might
>     not be used, even if the client registers saying that it intends
>     to use the "OATC" scope value.  We could maybe even say that some
>     services may use a static set of scopes and might choose to limit
>     the scopes that a client may use to those that it declared to the
>     server or to those that the server returned to the client.  That's
>     a HINT that some services might do this.  But we can't say
>     anything normative about such possible behaviors, because it goes
>     beyond RFC 6749.
>
>     -- Mike
>
>     *From:*Richer, Justin P. [mailto:[e-mail]]
>     *Sent:* Thursday, April 18, 2013 9:26 AM
>     *To:* Anthony Nadalin
>     *Cc:* Tim Bray; Mike Jones; [e-mail] <mailto:[e-mail]>
>     *Subject:* Re: [OAUTH-WG] Registration: Scope Values
>
>     This doesn't actually break the semantics because the client MUST
>     accept what the server tells it over anything that it asks for in
>     the first place. The server has the final say. So in this case, if
>     your client asks for nothing, the server says "A B C", the client
>     now knows it can ask for "A B C" scopes.
>
>     I'm still in favor of not putting the restricting language in the
>     scope definition at all, instead have it say something like:
>
>         "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 from the
>         Authorization Server. As scope values are service specific,
>         the means of the Authorization Server enforcing this
>         restriction are outside the scope of this specification."
>
>     Couple this with the overall paragraph that says that the client
>     is requesting values that the server is potentially overriding
>     with its declarations, and I think that addresses everything
>     without getting into confusing language that doesn't add to
>     interoperability.
>
>      -- Justin
>
>     On Apr 18, 2013, at 12:13 PM, Anthony Nadalin
>     <[e-mail] <mailto:[e-mail]>> wrote:
>
>
>
>
>     If I don't specify a scope, then the server can allocate a default
>     (or default set), thus that breaks the semantics you describe
>
>     *From:*[e-mail] <mailto:[e-mail]>
>     [mailto:[e-mail] <mailto:[e-mail]>]*On
>     Behalf Of*Tim Bray
>     *Sent:*Thursday, April 18, 2013 9:04 AM
>     *To:*Mike Jones
>     *Cc:*[e-mail] <mailto:[e-mail]>
>     *Subject:*Re: [OAUTH-WG] Registration: Scope Values
>
>     I'm unconvinced, Mike.  Obviously you're right about the looseness
>     of OAuth2 scope specification, but this is a very specific
>     semantic of what happens when you register, and I don't think
>     we're bound by history here.   If we can't safely say anything
>     about what the list of scopes means, then I'm with you let's take
>     them out.  But the most obvious intended semantic is (from the
>     client) "I promise to ask only for these" and from the server
>     "These are the only ones I'll give you tokens for."  Or does
>     someone have use-cases for an alternative semantic?
>
>     To make this concrete, I propose the following:
>
>     "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 to the server that it will restrict itself to when
>     requesting access tokens, and that the server is declaring to the
>     client that it is registered to use when requesting access tokens.
>     Clients SHOULD assume that servers will refuse to grant access
>     tokens for scopes not in the list provided by the server."
>
>     On Thu, Apr 18, 2013 at 8:55 AM, Mike Jones
>     <[e-mail] <mailto:[e-mail]>>
>     wrote:
>
>         I don't think it's possible to define what it means in an
>         interoperable way because OAuth didn't specify scopes in an
>         interoperable way.  No, I don't like that either, but I think
>         that's where things are.  That's why I was advocating deleting
>         this registration feature entirely.
>
>         But understanding it might be useful in some contexts, I'm OK
>         keeping it, provided we be clear that the semantics of
>         "registered to use" are service-specific.
>
>         -- Mike
>
>         *From:*Tim Bray [mailto:[e-mail]
>         <mailto:[e-mail]>]
>         *Sent:*Thursday, April 18, 2013 8:36 AM
>         *To:*Mike Jones
>         *Cc:*Justin Richer;[e-mail] <mailto:[e-mail]>
>
>
>         *Subject:*Re: [OAUTH-WG] Registration: Scope Values
>
>         On the server-to-client side, what does "registered to use"
>         mean?  Does it mean that the client should assume that any
>         scopes not on the list WILL not be granted, MAY not be
>         granted.... or what?  Is this already covered elsewhere? -T
>
>         On Thu, Apr 18, 2013 at 8:28 AM, Mike Jones
>         <[e-mail]
>         <mailto:[e-mail]>> wrote:
>
>         Thanks, Justin.  I agree with the need for the generic
>         two-sided language.  I'd still keep this language for scope,
>         because we want to capture the "declaring" aspect in this case:
>
>         "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 is declaring to the server that it may use when
>         requesting access tokens and that the server is declaring to
>         the client that it is registered to use when requesting access
>         tokens.".
>
>         You should probably also reinforce that scope values are
>         service-specific and may not consist only of a static set of
>         string values, and that therefore, in some cases, an
>         exhaustive list of registered scope values is not possible.
>
>         -- Mike
>
>         *From:*Justin Richer [mailto:[e-mail]
>         <mailto:[e-mail]>]
>         *Sent:*Monday, April 15, 2013 12:29 PM
>
>
>         *To:*Mike Jones
>         *Cc:*Tim Bray;[e-mail] <mailto:[e-mail]>
>         *Subject:*Re: [OAUTH-WG] Registration: Scope Values
>
>         I think that because the "declaration" issue affects all
>         parameters in the list, not just scope, we should adopt this
>         in a higher level paragraph and leave it out of the individual
>         parameter descriptions. Thus, something like this inserted as
>         the second paragraph in section 2:
>
>         The client metadata values serve two parallel purposes in the
>         overall OAuth Dynamic Registration protocol:
>
>          - the Client requesting its desired values for each parameter
>         to the Authorization Server in a [register] or [update] request,
>          - the Authorization Server informing the Client of the
>         current values of each parameter that the Client has been
>         registered to use through a [client information response].
>
>         An Authorization Server MAY override any value that a Client
>         requests during the registration process (including any
>         omitted values) and replace the requested value with a
>         default. The normative indications in the following list apply
>         to the Client's declaration of its desired values.
>
>         The Authorization Server SHOULD provide documentation for any
>         fields that it requires to be filled in by the client or to
>         have particular values or formats. Extensions and profiles...
>
>
>         And then remove the sidedness-language from the scope
>         parameter and any other parameters where it might have crept
>         in inadvertently.
>
>          -- Justin
>
>         On 04/15/2013 01:29 PM, Mike Jones wrote:
>
>             We could fix the one-sided language by changing
>
>             "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 is declaring that it may use when requesting access
>             tokens."
>
>             to
>
>             "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 is declaring to the server that it may use when
>             requesting access tokens and that the server is declaring
>             to the client that it is registered to use when requesting
>             access tokens.".
>
>             Again, I chose the "registered to use" language carefully
>             -- because in the general case it's not a restriction on
>             the values that the client can use -- just a statement by
>             the server to the client that it is registered to use
>             those particular values.  In both cases, the parties are
>             making declarations to one another.
>
>             If you adopt that language (or keep the original
>             language), then yes, I'd consider this closed.
>
>             -- Mike
>
>             *From:*Justin Richer [mailto:[e-mail]]
>             *Sent:*Monday, April 15, 2013 9:57 AM
>             *To:*Mike Jones
>             *Cc:*Tim Bray;[e-mail] <mailto:[e-mail]>
>             *Subject:*Re: [OAUTH-WG] Registration: Scope Values
>
>             I absolutely do not want to delete this feature, as
>             (having implemented it) I think it's very useful. This is
>             a very established pattern in manual registration: I know
>             of many, many OAuth2 servers and clients that are set up
>             where the client must pre-register a set of scopes.
>
>             I don't like the language of "the client is declaring"
>             because it's too one-sided. The client might not have
>             declared anything, and it might be the server that's
>             declaring something to the client. Deleting the "is
>             declaring" bit removes that unintended restriction of the
>             language while keeping the original meaning intact. I
>             actually thought that I had fixed that before the last
>             draft went in but apparently I missed this one.
>
>             I will work on clarifying the intent of the whole metadata
>             set in its introductory paragraph(s) so that it's clear
>             that all of these fields are used in both of these situations:
>
>              1) The client declaring to the server its desire to use a
>             particular value
>              2) The server declaring to the client that it has been
>             registered with a particular value
>
>             This should hopefully clear up the issue in the editor's
>             note that I currently have at the top of that section
>             right now, too.
>
>             Mike, since you were the one who originally brought up the
>             issue, and you're fine with the existing text, can I take
>             this as closed now? Assuming that you agree with deleting
>             "is declaring" for reasons stated above, I'm fine with
>             leaving everything else as is and staying quiet on what
>             the server has to do with the scopes.
>
>              -- Justin
>
>             On 04/15/2013 12:44 PM, Mike Jones wrote:
>
>                 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.0Section 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]>[mailto:[e-mail]]*On
>                 Behalf Of*Justin Richer
>                 *Sent:*Monday, April 15, 2013 8:05 AM
>                 *To:*Tim Bray;[e-mail] <mailto:[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] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/oauth
>