Re: [OAUTH-WG] Scope parameter values for "authorization_code" and "client_credentials" based access tokens
Marty Burns <marty@hypertek.us> Mon, 17 February 2014 14:20 UTC
Return-Path: <marty@hypertek.us>
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 5D9281A04E1 for <oauth@ietfa.amsl.com>; Mon, 17 Feb 2014 06:20:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.967
X-Spam-Level:
X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham
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 z0MCRBCfBZXv for <oauth@ietfa.amsl.com>; Mon, 17 Feb 2014 06:20:39 -0800 (PST)
Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com [209.85.216.177]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7D61A04DB for <oauth@ietf.org>; Mon, 17 Feb 2014 06:20:39 -0800 (PST)
Received: by mail-qc0-f177.google.com with SMTP id i8so23395634qcq.8 for <oauth@ietf.org>; Mon, 17 Feb 2014 06:20:36 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type; bh=3bd2Cf7futs+p5n70J5P/iSjwhTCnawkee085QuWJ5w=; b=CsjmpCQlhJxZAPp3WllI0fXj2A2HLHGN+29ssAejjQyPoW6DBzSk0TIKLhZLj5oNxm yrNiWvpRyCmfa8RPKayo1Mky/h/odJk6s+yOfzk3dhIyI35Qu7aIMCJ99Okyy7G62Zph 0/BfARciJQJt+xXpYMbdmwhyn0rjeFuU5ksU72frH9kExKbkkZzbitXC2VQNEbjG5ZNc HjMg2sLB9MGUOg8LWBwGqu6kTnWZhQpm3kABo+riqcEF1ePCoC1pWbTh3YGNDKs+ZHw2 WuJ1g7WYmukxn1MIj/y6f6wzw7Io4VRLQRDpynY2/R/O62bGZf5ZT3TxXrf94ENy9iY7 HqKw==
X-Gm-Message-State: ALoCoQlRckxg/mD4Jk3dzSgayUQDeUP/OVRx2WmDG35LX8Fl5y2wNyuCOkaUiHb7oEa2q7SevHrr
X-Received: by 10.140.20.17 with SMTP id 17mr33186796qgi.28.1392646836553; Mon, 17 Feb 2014 06:20:36 -0800 (PST)
From: Marty Burns <marty@hypertek.us>
References: <002301cf2ac2$f0053990$d00facb0$@reminetworks.com> <1392525020.7390.YahooMailNeo@web142801.mail.bf1.yahoo.com> <000e01cf2b7d$79a66c90$6cf345b0$@reminetworks.com> <0e9117b9bb80c29d3e3a53ab64392e94@mail.gmail.com> <CF277A1D.351F7%john.teeter@nist.gov>
In-Reply-To: <CF277A1D.351F7%john.teeter@nist.gov>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQEnOl+8JZU1HiFwOiLE96BHahHifwH2C3usAiM9j6kCwG9IxgIvFMcvm8EXRGA=
Date: Mon, 17 Feb 2014 09:18:43 -0500
Message-ID: <76ed1104de52640d8052ca596136ca6a@mail.gmail.com>
To: "Teeter, John" <john.teeter@nist.gov>, Donald Coffin <donald.coffin@reminetworks.com>, Bill Mills <wmills_92105@yahoo.com>, oauth@ietf.org
Content-Type: multipart/alternative; boundary="001a11c124f6fd9a1404f29adb99"
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/YY44sY0KQ8mUAMf-EOKuF0ZJjJU
X-Mailman-Approved-At: Fri, 21 Feb 2014 12:21:28 -0800
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 14:22:54 -0000
Don's email describes why we changed from space to comma for separator between Scopes. The reason we don't use space inside a scope string is that we wanted the OAuth layer to treat a scope string as an atomic thing, rather than a list of independent parameters. The use of space delimits independent scopes in OAuth. So we wanted to keep each Scope string as a separate "scope-token" (see definition below). Each data custodian will support a small finite set of permutations of the Scope string (often only one). It is the set that describes the scope. BTW, here is the full description of the Scope parameter from RFC 6749: *3.3*<file:///C:\_Project\NIST\NISTGreenButton\Work\GreenButton\GreenButtonCMDWorkshop\references\rfc6749.htm#section-3.3>*. Access Token Scope* The authorization and token endpoints allow the client to specify the scope of the access request using the "scope" request parameter. In turn, the authorization server uses the "scope" response parameter to inform the client of the scope of the access token issued. The value of the scope parameter is expressed as a list of space- delimited, case-sensitive strings. The strings are defined by the authorization server. If the value contains multiple space-delimited strings, their order does not matter, and each string adds an additional access range to the requested scope. scope = scope-token *( SP scope-token ) scope-token = 1*( %x21 / %x23-5B / %x5D-7E ) The authorization server MAY fully or partially ignore the scope requested by the client, based on the authorization server policy or the resource owner's instructions. If the issued access token scope is different from the one requested by the client, the authorization server MUST include the "scope" response parameter to inform the client of the actual scope granted. If the client omits the scope parameter when requesting authorization, the authorization server MUST either process the request using a pre-defined default value or fail the request indicating an invalid scope. The authorization server SHOULD document its scope requirements and default value (if defined). HTH, Marty *From:* Teeter, John [mailto:john.teeter@nist.gov] *Sent:* Monday, February 17, 2014 8:41 AM *To:* Marty Burns; Donald Coffin; Bill Mills; oauth@ietf.org *Cc:* greenbutton-dev *Subject:* Re: [OAUTH-WG] Scope parameter values for "authorization_code" and "client_credentials" based access tokens Remind be again please why we still do not use "space" as a separator in our Scope? Seem so me the appropriate scope for the example below should be: "FB=4_*5_*15 IntervalDuration=900 BlockDuration=monthly HistoryLength=13 BR=04" If we do use "space' as a separator, I can understand the way that the BR value can be mixed in to the non BR scopes. So why do we not use the "space" separator? jt *From: *Marty Burns <marty@hypertek.us> *Date: *Sunday, February 16, 2014 8:34 PM *To: *Donald Coffin <donald.coffin@reminetworks.com>, Bill Mills < wmills_92105@yahoo.com>, "oauth@ietf.org" <oauth@ietf.org> *Cc: *greenbutton-dev <greenbutton-dev@googlegroups.com> *Subject: *RE: [OAUTH-WG] Scope parameter values for "authorization_code" and "client_credentials" based access tokens Don, Good comment. One point - the authorizations covered by BulkId=04 would have Scopes of: FB=4_5_15;IntervalDuration=900;BlockDuration=monthly;HistoryLength=13;BR=04 Marty *From:*greenbutton-dev@googlegroups.com [mailto: greenbutton-dev@googlegroups.com] *On Behalf Of *Donald Coffin *Sent:* Sunday, February 16, 2014 8:14 PM *To:* 'Bill Mills'; oauth@ietf.org *Cc:* 'greenbutton-dev' *Subject:* RE: [OAUTH-WG] Scope parameter values for "authorization_code" and "client_credentials" based access tokens 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: donald.coffin@reminetworks.com *From:* Bill Mills [mailto:wmills_92105@yahoo.com <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 -- You received this message because you are subscribed to the Google Groups "greenbutton-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to greenbutton-dev+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "greenbutton-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to greenbutton-dev+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
- [OAUTH-WG] Scope parameter values for "authorizat… Donald Coffin
- Re: [OAUTH-WG] Scope parameter values for "author… Bill Mills
- Re: [OAUTH-WG] Scope parameter values for "author… Donald Coffin
- Re: [OAUTH-WG] Scope parameter values for "author… Bill Mills
- Re: [OAUTH-WG] Scope parameter values for "author… Donald Coffin
- Re: [OAUTH-WG] Scope parameter values for "author… Bill Mills
- Re: [OAUTH-WG] Scope parameter values for "author… Donald Coffin
- Re: [OAUTH-WG] Scope parameter values for "author… Bill Mills
- Re: [OAUTH-WG] Scope parameter values for "author… Donald Coffin
- Re: [OAUTH-WG] Scope parameter values for "author… Marty Burns