The scope requested does not have to match the scope granted.  

Also note that space is the scope separator per the spec, so BR=04 is not equal 
to FB=4_5_15;IntervalDuration=900;BlockDuration=monthly;HistoryLength=13;BR=04 
but it's your implementation of how you want to interpret scopes.



On Sunday, February 16, 2014 5:36 PM, Marty Burns <[email protected]> wrote:
 
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:[email protected] [mailto:[email protected]] 
On Behalf Of Donald Coffin
Sent: Sunday, February 16, 2014 8:14 PM
To: 'Bill Mills'; [email protected]
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:       [email protected]
 
From:Bill Mills [mailto:[email protected]] 
Sent: Saturday, February 15, 2014 8:30 PM
To: Donald Coffin; [email protected]
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 
<[email protected]> 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:       [email protected]
 

_______________________________________________
OAuth mailing list
[email protected]
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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to