Re: [OAUTH-WG] Registration: Scope Values

Justin Richer <jricher@mitre.org> Mon, 15 April 2013 19:29 UTC

Return-Path: <jricher@mitre.org>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE6721F944A for <oauth@ietfa.amsl.com>; Mon, 15 Apr 2013 12:29:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEInyRQVke9q for <oauth@ietfa.amsl.com>; Mon, 15 Apr 2013 12:29:00 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id C5F5221F940C for <oauth@ietf.org>; Mon, 15 Apr 2013 12:28:59 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 69A841F07CA; Mon, 15 Apr 2013 15:28:59 -0400 (EDT)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 4F55F1F069A; Mon, 15 Apr 2013 15:28:59 -0400 (EDT)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.342.3; Mon, 15 Apr 2013 15:28:58 -0400
Message-ID: <516C54F2.8040708@mitre.org>
Date: Mon, 15 Apr 2013 15:28:50 -0400
From: Justin Richer <jricher@mitre.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: Mike Jones <Michael.Jones@microsoft.com>
References: <255B9BB34FB7D647A506DC292726F6E1150C74DADA@WSMSG3153V.srv.dir.telstra.com> <516C069F.9090308@mitre.org> <CA+ZpN26NJj7T8V0WYNnVi2O1EhwKqDbk3zBcJoNkgk5PM6N5+Q@mail.gmail.com> <516C0B9D.6000402@mitre.org> <CA+ZpN27UCw=MpD+CPGTEaGFaQe5qFJm00jRVeW5FuB0MAk8D0A@mail.gmail.com> <516C101F.2090706@mitre.org> <CA+ZpN27KNr0TLsAjt29PCQXqfFYkzP7Fr7y_2wibHfVu3R=UMA@mail.gmail.com> <516C1714.8070503@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641A87@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C3152.9070603@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641FAB@TK5EX14MBXC283.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367641FAB@TK5EX14MBXC283.redmond.corp.microsoft.com>
Content-Type: multipart/alternative; boundary="------------080503000000080807060703"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Registration: Scope Values
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Apr 2013 19:29:02 -0000

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.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.”
>
> to
>
> “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 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:jricher@mitre.org]
> *Sent:* Monday, April 15, 2013 9:57 AM
> *To:* Mike Jones
> *Cc:* Tim Bray; oauth@ietf.org
> *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.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:*oauth-bounces@ietf.org <mailto:oauth-bounces@ietf.org>
>     [mailto:oauth-bounces@ietf.org] *On Behalf Of *Justin Richer
>     *Sent:* Monday, April 15, 2013 8:05 AM
>     *To:* Tim Bray; oauth@ietf.org <mailto:oauth@ietf.org>
>     *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 <jricher@mitre.org
>     <mailto:jricher@mitre.org>> 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
>         <jricher@mitre.org <mailto:jricher@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"
>             <jricher@mitre.org <mailto:jricher@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.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
>
>                 OAuth@ietf.org  <mailto:OAuth@ietf.org>
>
>                 https://www.ietf.org/mailman/listinfo/oauth
>
>
>             _______________________________________________
>             OAuth mailing list
>             OAuth@ietf.org <mailto:OAuth@ietf.org>
>             https://www.ietf.org/mailman/listinfo/oauth
>