Re: [OAUTH-WG] Scope parameter values for "authorization_code" and "client_credentials" based access tokens

"Donald Coffin" <donald.coffin@reminetworks.com> Mon, 17 February 2014 01:15 UTC

Return-Path: <donald.coffin@reminetworks.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9CFD1A02C3 for <oauth@ietfa.amsl.com>; Sun, 16 Feb 2014 17:15:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.656
X-Spam-Level:
X-Spam-Status: No, score=-1.656 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyFEeW4C3-WN for <oauth@ietfa.amsl.com>; Sun, 16 Feb 2014 17:15:04 -0800 (PST)
Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 5B92C1A0294 for <oauth@ietf.org>; Sun, 16 Feb 2014 17:15:03 -0800 (PST)
Received: (qmail 28170 invoked by uid 0); 17 Feb 2014 01:13:55 -0000
Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy5.mail.unifiedlayer.com with SMTP; 17 Feb 2014 01:13:55 -0000
Received: from host125.hostmonster.com ([74.220.207.125]) by cmgw3 with id TLDm1n00D2is6CS01LDpkx; Mon, 17 Feb 2014 01:13:54 -0700
X-Authority-Analysis: v=2.1 cv=RodWckWK c=1 sm=1 tr=0 a=Ux/kOkFFYyRqKxKNbwCgLQ==:117 a=Ux/kOkFFYyRqKxKNbwCgLQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=d-K1uXnm4cMA:10 a=8dE94GJacnkA:10 a=UGkfVyPCAAAA:8 a=S71PjDr2FGoA:10 a=rE68L1KyjUoA:10 a=DAwyPP_o2Byb1YXLmDAA:9 a=Zr7miEi8wWIA:10 a=cKsnjEOsciEA:10 a=CjxXgO3LAAAA:8 a=48vgC7mUAAAA:8 a=oKP0rcp2K9NtoCZRy2sA:9 a=-NCC91e-xOn4sofj:21 a=kiL_TTvjLwVjxmus:21 a=QEXdDO2ut3YA:10 a=3uZdkJafswoA:10 a=VQchPmBwTIUA:10 a=wNReZwrxAf8A:10 a=0qEjrYlnuRwA:10 a=rC2wZJ5BpNYA:10 a=lZB815dzVvQA:10 a=M6Kqmjw4cQ4A:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=1XiioecUQsFQGx-2:21 a=X5kVEmVc7fyQJbv8:21 a=-JZyIkZ5rYmbY9m7:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=tXsnliwV7b4A:10
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=u3fDgPNuHa5/7QDf2asG+EoVeDKCxGytIhQe+RZl+8o=; b=AurCGSukeB5jbgg127z36XR1+9b131Ki8L/oF3tGWYBil93d4E6qq2+PeNPzHHjzFikFROrMV8AAXhgeXM6XDf7UoQXKQMhDBwqa/IrPs8NoCRydIi2CGQ8emvvRdvSU;
Received: from [68.5.51.152] (port=49500 helo=HPPavilionElite) by host125.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from <donald.coffin@reminetworks.com>) id 1WFCmK-0005P7-4s; Sun, 16 Feb 2014 18:13:48 -0700
From: Donald Coffin <donald.coffin@reminetworks.com>
To: 'Bill Mills' <wmills_92105@yahoo.com>, oauth@ietf.org
References: <002301cf2ac2$f0053990$d00facb0$@reminetworks.com> <1392525020.7390.YahooMailNeo@web142801.mail.bf1.yahoo.com>
In-Reply-To: <1392525020.7390.YahooMailNeo@web142801.mail.bf1.yahoo.com>
Date: Sun, 16 Feb 2014 17:13:30 -0800
Organization: REMI Networks
Message-ID: <000e01cf2b7d$79a66c90$6cf345b0$@reminetworks.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01CF2B3A.6B8660E0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQEnOl+8JZU1HiFwOiLE96BHahHifwH2C3usm/jVJHA=
Content-Language: en-us
X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 68.5.51.152 authed with donald.coffin@reminetworks.com}
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/o31Ld2jFwYtohrMD5ejZiOmliIk
Cc: 'greenbutton-dev' <greenbutton-dev@googlegroups.com>
Subject: Re: [OAUTH-WG] Scope parameter values for "authorization_code" and "client_credentials" based access tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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, 17 Feb 2014 01:15:12 -0000

Bill,

 

Thanks for your reply, but I’m not sure you fully understand the situation I am attempting to resolve.

 

For example, does an access token obtained via the “client_credentials” request with the following SCOPE parameter:

                        BulkID=04

allow a client to ask for resources when the individual access token contained the following SCOPE parameter:

                        FB=4_5_15;IntervalDuration=900;BlockDuration=monthly;HistoryLength=13

 

The question is what individual access token authorization should be covered by the “client_credentials” based access token?

 

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: Bill Mills [mailto:wmills_92105@yahoo.com] 
Sent: Saturday, February 15, 2014 8:30 PM
To: Donald Coffin; oauth@ietf.org
Cc: greenbutton-dev
Subject: Re: [OAUTH-WG] Scope parameter values for "authorization_code" and "client_credentials" based access tokens

 

To tokens themselves don't differ based on how they are obtained unless you want them to.  No requirement to match scope to the client ID either, but again it's up to you.

 

You do want to get this right.  The challenge here is that your resource servers have to get updated to support new scopes.  If they support auto-updates then it's not quite as big a deal but it's still non-trivial.

 

-bill

 

 

 

On Saturday, February 15, 2014 7:01 PM, Donald Coffin <donald.coffin@reminetworks.com> wrote:

I would like to get the views and comments of the OAuth 2.0 IETF WG on the following design and implementation question:

 

I have an application that supports both “authorization_code” and “client_credentials” based access tokens.  The application allows a client to obtain data on a nightly basis for resource owners who have granted the application access to their data.  The client application retrieves energy usage information and can potentially need to retrieve data from a few accounts to several million accounts.  In order to eliminate the need for the client application to request the data from the resource server one account at a time, the client application has been designed to support “client_credentials” based access tokens.  Per [RFC 6749 Section 4.4 – “Client Credentials Grant”] The use of the “client_credentials” based access token will allow the client application to obtain access to the data with a single request, thus significantly reducing the amount of network traffic for both the client and the resource server.

 

The question the design team is struggling with is what should the Scope string be for the “client_credentials” based access token and should there be a single access token or can there be multiple “client_credentials” based access tokens?

 

The client application currently supports the following Scope definitions:

 

·         FB=4_5_15;IntervalDuration=900;BlockDuration=monthly;HistoryLength=13

·         FB=4_5_16;IntervalDuration=900;BlockDuration=monthly;HistoryLength=13

 

There are several allowable values for the FB=, IntervalDuration=, BlockDuration=, and HistoryLength= values.  At the moment, there are only two defined Scope values, but as you can see, there could easily be many more potential possibilities.  

 

The question being discussed, is does the “client_credentials” access token request Scope parameter need to match either of the above two strings or can it be something altogether different?  In the event the “client_credentials” access token request Scope parameter needs to match a defined Scope string, does that mean that there MUST be multiple “client_credentials” based access tokens?

 

Thanks in advance for helping clarify our understanding of the relationship between “authorization_code” and “client_credentials” based access tokens.

 

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:       donald.coffin@reminetworks.com

 


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