Re: [OAUTH-WG] Registration: Scope Values

"Donald F Coffin" <donald.coffin@reminetworks.com> Fri, 12 April 2013 19:41 UTC

Return-Path: <donald.coffin@reminetworks.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 4312C21F8EC9 for <oauth@ietfa.amsl.com>; Fri, 12 Apr 2013 12:41:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.264
X-Spam-Level:
X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334]
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 jO51dgfXDc-Q for <oauth@ietfa.amsl.com>; Fri, 12 Apr 2013 12:41:06 -0700 (PDT)
Received: from oproxy13-pub.unifiedlayer.com (oproxy13-pub.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id 35D5D21F8E9A for <oauth@ietf.org>; Fri, 12 Apr 2013 12:41:06 -0700 (PDT)
Received: (qmail 5050 invoked by uid 0); 12 Apr 2013 19:40:41 -0000
Received: from unknown (HELO host125.hostmonster.com) (74.220.207.125) by oproxy13.unifiedlayer.com with SMTP; 12 Apr 2013 19:40:41 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=fRBKYHtZkZvW+ImswnZlHYT9WHrC1MKHbLq0t6/wjPg=; b=o+wKyjyXOuTpYzd8RJU4LPJApKuZly6652XDCGLa0l7zb0yzKpb5FLrgonjjGvgcZUb+uyGEHzcFOQIdNfzWSilSsvjqCqgn/13j5DGjRO5mtEN3NZWYMqs7OAujtVoY;
Received: from [68.4.207.246] (port=2517 helo=HPPavilionElite) by host125.hostmonster.com with esmtpa (Exim 4.80) (envelope-from <donald.coffin@reminetworks.com>) id 1UQjpx-00007s-AK; Fri, 12 Apr 2013 13:40:41 -0600
From: Donald F Coffin <donald.coffin@reminetworks.com>
To: 'Tim Bray' <twbray@google.com>, 'Justin Richer' <jricher@mitre.org>
References: <51685177.8060603@mitre.org> <CA+ZpN24B2ZouMFYqRE4ST6qCP6SeTRabBm6xBsjoUHgr+r+Jrw@mail.gmail.com>
In-Reply-To: <CA+ZpN24B2ZouMFYqRE4ST6qCP6SeTRabBm6xBsjoUHgr+r+Jrw@mail.gmail.com>
Date: Fri, 12 Apr 2013 12:39:05 -0700
Message-ID: <00ce01ce37b5$64829210$2d87b630$@reminetworks.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CF_01CE377A.B8260400"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKhIF8eX/RIXMm9kgogxQzt5YcUwgJZhmb4lxpdzdA=
Content-Language: en-us
X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 68.4.207.246 authed with donald.coffin@reminetworks.com}
Cc: 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: Fri, 12 Apr 2013 19:41:07 -0000

+1

 

Best regards,

Don

Donald F. Coffin

Founder/CTO

 

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

 

Phone:      (949) 636-8571

Email:        <mailto:donald.coffin@reminetworks.com> donald.coffin@reminetworks.com

 

From: Tim Bray [mailto:twbray@google.com] 
Sent: Friday, April 12, 2013 11:31 AM
To: Justin Richer
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: Scope Values

 

Speaking for myself, I have considerable concern about Turing-complete programming languages starting to emerge inside scope strings, which I think is probably a symptom of bad engineering.  I really like the idea of specifying the scopes you’re going to ask for at registration time, and if that also gets in the way of what I’ll call “scope creep” (snicker), that feels like a feature not a bug.  Anyhow, in practical terms, I can’t see how you could extend this specify-at-registration-time feature much without stepping on a very slippery complexity slope.

 

-T

 

On Fri, Apr 12, 2013 at 11:24 AM, Justin Richer <jricher@mitre.org> wrote:

Currently, the Dynamic Registration draft defines a "scope" value as part of the client metadata table, with the following definition:

   scope
      OPTIONAL.  Space separated list of scope values (as described in
      OAuth 2.0 Section <http://tools.ietf.org/html/rfc6749#section-3.3>  3.3 [RFC6749]) 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.


The idea here is that a client can request a particular set of available scopes from the AS (analogous as to what's available from many/most manual registration pages today), and the AS can communicate back to the client what scopes it's allowed to ask for at authz time. In a strictly-enforced implementation, the client wouldn't be able to ask for any scopes that it wasn't registered for in the first place.

However, it's been brought up in some side conversations that the language as found in the DynReg spec might get in the way of people using the "scope" field as an expression language. That is to say, you could have a scope like  <mailto:send_email_to:myaddress@email.com> "send_email_to:myaddress@email.com" where the email address portion is variable, or something like "read:*" which stands in for any scopes starting with "read:" like "read:profile", "read:lists", etc. Precluding this behavior wasn't my intent, and a liberal interpretation of the text as-written would (I believe) lead to this being perfectly OK. Namely:

Client requests and is granted a service specific scope value like "send_email_to" in registration. At runtime, the client knows how to turn "send_email_to" into  <mailto:send_email_to:myaddress@email.com> "send_email_to:myaddress@email.com", and the AS knows that a client that's been granted "send_email_to" can ask for  <mailto:send_email_to:myaddress@email.com> "send_email_to:myaddress@email.com". The fact that "send_email_to" expands into an expression language is something specific to the service, and I personally think it's up to the service to document "register for this" and "ask for this at authn time" for clients, since this is all part of the API more than it is part of the underlying OAuth protocol. OAuth merely provides a handy place to communicate these values in an interoperable way, the values themselves aren't intended to be interoperable. 


But my question to the group is simple: how can we rework the "scope" metadata claim such that it works in both the simple "bag of discreet strings" approach to scope as well as the "list of expressions" approach? Does the language need to change at all?

 -- Justin


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth