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

"Donald Coffin" <donald.coffin@reminetworks.com> Sun, 16 February 2014 03:00 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 0ACB41A0334 for <oauth@ietfa.amsl.com>; Sat, 15 Feb 2014 19:00:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.034
X-Spam-Level: *
X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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] 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 bOPRv1O_t3hi for <oauth@ietfa.amsl.com>; Sat, 15 Feb 2014 19:00:50 -0800 (PST)
Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id 12D601A0333 for <oauth@ietf.org>; Sat, 15 Feb 2014 19:00:50 -0800 (PST)
Received: (qmail 2291 invoked by uid 0); 16 Feb 2014 03:00:45 -0000
Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy2.mail.unifiedlayer.com with SMTP; 16 Feb 2014 03:00:45 -0000
Received: from host125.hostmonster.com ([74.220.207.125]) by cmgw2 with id Sr0d1n0052is6CS01r0gcA; Sat, 15 Feb 2014 20:00:44 -0700
X-Authority-Analysis: v=2.1 cv=ar4hV0pV c=1 sm=1 tr=0 a=Ux/kOkFFYyRqKxKNbwCgLQ==:117 a=Ux/kOkFFYyRqKxKNbwCgLQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=dq0SZ62CdugA:10 a=8dE94GJacnkA:10 a=UGkfVyPCAAAA:8 a=vapAUs4nhnIA:10 a=rE68L1KyjUoA:10 a=DAwyPP_o2Byb1YXLmDAA:9 a=Zr7miEi8wWIA:10 a=cKsnjEOsciEA:10 a=bWl4DpNhBsVAJclonDIA:9 a=3k4I53lu14ZK_pcp:21 a=2A3wSueGU6QEdADM:21 a=CjuIK1q_8ugA:10 a=3uZdkJafswoA:10 a=VQchPmBwTIUA:10 a=wNReZwrxAf8A:10 a=0qEjrYlnuRwA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=sZPqtPKswmdgoLt4O1AA:9 a=ZZg2_XOimAgrIQHq:21 a=V6yUaaWhD1N3yDWB:21 a=5VQqbNJaKBctPyk3:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA: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:Cc:To:From; bh=G0KSfkkDGdFOLRUDRPFWpBSoxunoV/7x5NgA+qaPxRk=; b=GVqz4eSwhfmNPHUkDx4aDPklTf3TPOsKk3k7IEF+Uz5kW8yiulwqs118wFakdagaT64E281u5jHGcdJ2YM/UL/JfQMQB+SfAvdzpVOfIgQTe92GhibyorvRCTZaglko9;
Received: from [68.5.51.152] (port=49527 helo=HPPavilionElite) by host125.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from <donald.coffin@reminetworks.com>) id 1WEryA-00028o-4N; Sat, 15 Feb 2014 20:00:38 -0700
From: Donald Coffin <donald.coffin@reminetworks.com>
To: oauth@ietf.org
Date: Sat, 15 Feb 2014 18:58:13 -0800
Organization: REMI Networks
Message-ID: <002301cf2ac2$f0053990$d00facb0$@reminetworks.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0024_01CF2A7F.E1E38030"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac8qwu4BeTwmY6ITTSW2cms7JVDlkQ==
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/-f8CDU_2FYRIB7fPqV_fyjWMcuk
Cc: greenbutton-dev <greenbutton-dev@googlegroups.com>
Subject: [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: Sun, 16 Feb 2014 03:00:53 -0000

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