Re: [OAUTH-WG] Registration: Scope Values

Tim Bray <twbray@google.com> Mon, 15 April 2013 14:14 UTC

Return-Path: <twbray@google.com>
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 5114C21F9322 for <oauth@ietfa.amsl.com>; Mon, 15 Apr 2013 07:14:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.977
X-Spam-Level:
X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
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 6OPvlCTQXLbm for <oauth@ietfa.amsl.com>; Mon, 15 Apr 2013 07:14:00 -0700 (PDT)
Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 71A5321F9350 for <oauth@ietf.org>; Mon, 15 Apr 2013 07:14:00 -0700 (PDT)
Received: by mail-ie0-f173.google.com with SMTP id k13so2799015iea.18 for <oauth@ietf.org>; Mon, 15 Apr 2013 07:14:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=wFUhpjYHS6SzlEkbOVMUoyttBGRV9Bce0mzzie5/PWw=; b=COPlytnudjqmEtaA0z85qsEvCHnvw5DlIIi3dPUvYMe5dgpsVIzSoP6QAazWWFywqH A55ujFhL6FAVDqmEy3L/Co6i8+YVYDJ+JApvTKK0ExWr1lSIWEHH+p4HArGPg2zt0DES mbHO2+XHxW79YsJ+in7vXcZpxGoozkff21lPJVdAlrEt7AgjQK3tZMQGIUfXyZyo5TMn 0IZY7tBO4Ggm+3C3AvbCbdkAW8BFQU5ml6Y5MUDVXP3NgNRUihIrzAONUkG75qLvFCH9 MGOUcVjwgfgZk4vuspZ4wvep2XiPqp9kh682t6jOiboX+kR+ha5+6awJCg+04yEipBO0 T1mA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=wFUhpjYHS6SzlEkbOVMUoyttBGRV9Bce0mzzie5/PWw=; b=LwvW8PbTfbqF7PdF0LihY9/1vsa0ZVNB7ic0KmjIqZQGiJ4Oy7ZTG2cO6HS1xGY8EL vb5A+H+9q+wh8caTSVonVZpS+pt6jYamXt8NW88uRkkGsUIGR2feIB8W4T8g7BcevpYI mt65EL31N79pssyTeJAg0cIG8wH8zkeSEL6WyUK4W/xWUrxCfJZ66qYTWhRiAWazjrTi i0TIPbzgYQ2B8kS9bQou/uIrnJhMcnZ9c6qdbsoUFNY0vcs5u8r6LPZpOJT+whjqwL4j DVLeBbbPEoDqF9UhOYHWmyXMYo0lXgQ5bV/Uda9okzQhKvPIB9pRNqLvFPswek9kyGB0 VqXA==
MIME-Version: 1.0
X-Received: by 10.43.72.133 with SMTP id yo5mr12002863icb.28.1366035239857; Mon, 15 Apr 2013 07:13:59 -0700 (PDT)
Received: by 10.64.31.35 with HTTP; Mon, 15 Apr 2013 07:13:59 -0700 (PDT)
Received: by 10.64.31.35 with HTTP; Mon, 15 Apr 2013 07:13:59 -0700 (PDT)
In-Reply-To: <516C069F.9090308@mitre.org>
References: <255B9BB34FB7D647A506DC292726F6E1150C74DADA@WSMSG3153V.srv.dir.telstra.com> <516C069F.9090308@mitre.org>
Date: Mon, 15 Apr 2013 07:13:59 -0700
Message-ID: <CA+ZpN26NJj7T8V0WYNnVi2O1EhwKqDbk3zBcJoNkgk5PM6N5+Q@mail.gmail.com>
From: Tim Bray <twbray@google.com>
To: "Justin P. Richer" <jricher@mitre.org>
Content-Type: multipart/alternative; boundary="001a11c1e89c39139e04da66dd7c"
X-Gm-Message-State: ALoCoQn100i0orYsysqLDeMDAF1s6H1HfLrBQEwH7sKrg8G7c3NpbWCQmXIHAOfJlbvZz7UpIyz7m1V4gxutRyqjhzHONsAmxvfK3r+XHl+sBFIvk6RxK8VcREl7puXKnERlINKP6qMDyHZI4jpQSNdgbqYOfLsY/B4gLG9XJYZ1FR21mbuZkNv3fH1g6nIk/ViS3qCRPeV6
Cc: "oauth@ietf.org WG" <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 14:14:01 -0000

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> 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
>
>