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

From: "Donald Coffin" <[email-masked]>
Date: Sat, 15 Feb 2014 18:58:13 -0800

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-masked]

---

From: Bill Mills <[email-masked]>
Date: Sat, 15 Feb 2014 20:30:20 -0800 (PST)

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-masked]> 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?

·         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
 
Phone:      (949) 636-8571
 
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: "Donald Coffin" <[email-masked]>
Date: Sun, 16 Feb 2014 17:13:30 -0800

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:

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

Phone:      (949) 636-8571

Email:        <mailto:[email-masked]> [email-masked]

From: Bill Mills [mailto:[email-masked]] 
Sent: Saturday, February 15, 2014 8:30 PM
To: Donald Coffin; [email-masked]
Cc: greenbutton-dev
Subject: Re: [OAUTH-WG] Scope parameter values for "authorization_code" and "client_credentials" based access tokens

-bill

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

Phone:      (949) 636-8571

---

From: Bill Mills <[email-masked]>
Date: Sun, 16 Feb 2014 22:01:40 -0800 (PST)

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-masked]> 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-masked] [mailto:[email-masked]] On Behalf Of Donald Coffin
Sent: Sunday, February 16, 2014 8:14 PM
To: 'Bill Mills'; [email-masked]
Cc: 'greenbutton-dev'
Subject: RE: [OAUTH-WG] Scope parameter values for "authorization_code" and "client_credentials" based access tokens
 
Bill,

                        BulkID=04

 
 
Best regards,
Don
Donald F. Coffin
Founder/CTO
 
REMI Networks
 
Phone:      (949) 636-8571
 
From:Bill Mills [mailto:[email-masked]] 
Sent: Saturday, February 15, 2014 8:30 PM
To: Donald Coffin; [email-masked]
Cc: greenbutton-dev
Subject: Re: [OAUTH-WG] Scope parameter values for "authorization_code" and "client_credentials" based access tokens

 
-bill

 

 

 
 
Best regards,
Don
Donald F. Coffin
Founder/CTO
 
REMI Networks
 
Phone:      (949) 636-8571

_______________________________________________
OAuth mailing list
[email-masked]
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-masked].
For more options, visit https://groups.google.com/groups/opt_out.

---

From: "Donald Coffin" <[email-masked]>
Date: Sun, 16 Feb 2014 22:53:32 -0800

Bill,

We understand, per [RFC 6749], the granted SCOPE does not have to match the requested SCOPE, however, in our application a client does an exchange of supported Authorization Server Scopes to ensure the resource owner is NOT asked by the client to select a SCOPE parameter the Authorization Server will be forced to override.

We also understand, per [RFC 6740], the SCOPE parameter is a space delimited list.  Therefore, the following two examples are not the same:

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

·         FB=4_5_15 IntervalDuration=900 BlockDuration=monthly HistoryLength=13 BR=04

The first string represents a single SCOPE parameter, but the second string represents five (5) different SCOPE parameters.  Our original definition of the SCOPE string used commas (“,”) where the first example has semi-colons (“;”), however, we found the Spring Security OAuth 2.0 framework treats commas as blanks to support a Facebook SCOPE implementation.  This has recently been refactored to support the [RFC 6749] SCOPE definition, as it was found that though Facebook’s documentation calls for commas as SCOPE parameter separators, this was never implemented by Facebook.

The following table defines a potential table of access tokens based on granted SCOPE strings:

Owner

SCOPE

Grant Type

Access Token

Accessible by Access Token

Client

FB=4_5_16;IntervalDuration=900;BlockDuration=monthly;HistoryLength=13;BR=05

Client_credentials

Token 1

NA**

RO 1

Code

Token 2

Token 2

RO 1

FB=4_5_16;IntervalDuration=900;BlockDuration=monthly;HistoryLength=13;BR=04

Code

Token 3

Token 3

RO 2

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

Code

Token 4

Token 4

RO 3

FB=4_5_16;IntervalDuration=900;BlockDuration=monthly;HistoryLength=13;BR=05

Code

Token 5

Token 5 & Token 1

RO 4

FB=4_5_16;IntervalDuration=900;BlockDuration=monthly;HistoryLength=13;BR=05

Code

Token 6

Token 6 & Token 1

** Token 1 is owned by the client and therefore does NOT own any resources for which access can be authorized.

The question we are attempting to resolve is which resources can the owner of Token 1 access given the above table?  If the owner of Token 1 is allowed to access ALL resources represented by Tokens 2 – 6, then we do not need to worry about identifying which resources can be accessed by using Token 1.  However, if Token 1 can only be used to access the resources authorized by resource owner (RO) 3 and 4, then what is the criteria that must be used to validate that Token 1, when used, is able to access the requested resource?

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

Phone:      (949) 636-8571

From: Bill Mills [mailto:[email-masked]] 
Sent: Sunday, February 16, 2014 10:02 PM
To: Marty Burns; Donald Coffin; [email-masked]
Cc: greenbutton-dev
Subject: Re: [OAUTH-WG] Scope parameter values for "authorization_code" and "client_credentials" based access tokens

Don,

Marty

From: [email-masked] [mailto:[email-masked]] On Behalf Of Donald Coffin
Sent: Sunday, February 16, 2014 8:14 PM
To: 'Bill Mills'; [email-masked]
Cc: 'greenbutton-dev'
Subject: RE: [OAUTH-WG] Scope parameter values for "authorization_code" and "client_credentials" based access tokens

Bill,

                        BulkID=04

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

Phone:      (949) 636-8571

-bill

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

Phone:      (949) 636-8571

---

From: Bill Mills <[email-masked]>
Date: Mon, 17 Feb 2014 09:09:36 -0800 (PST)

Yes, token #1 with that scope could only access resource #3 and #4 in your example, the other resources don't allow that scope. The only solution in spec is to have the other resource owners allow a scope that token #1 has.

You're apparently overloading a bunch of stuff in the scope that most would put in the access token.  Are you trying to give a hint to the client about the token?

On Sunday, February 16, 2014 10:54 PM, Donald Coffin <[email-masked]> wrote:
 
Bill,

 

 
 
Owner SCOPE Grant Type Access Token Accessible by Access Token 
Client FB=4_5_16;IntervalDuration=900;BlockDuration=monthly;HistoryLength=13;BR=05 Client_credentials Token 1 NA** 
RO 1 FB=4_5_15;IntervalDuration=900;BlockDuration=monthly;HistoryLength=13;BR=04 Code Token 2 Token 2 
RO 1 FB=4_5_16;IntervalDuration=900;BlockDuration=monthly;HistoryLength=13;BR=04 Code Token 3 Token 3 
RO 2 FB=4_5_15;IntervalDuration=900;BlockDuration=monthly;HistoryLength=13;BR=05 Code Token 4 Token 4 
RO 3 FB=4_5_16;IntervalDuration=900;BlockDuration=monthly;HistoryLength=13;BR=05 Code Token 5 Token 5 & Token 1 
RO 4 FB=4_5_16;IntervalDuration=900;BlockDuration=monthly;HistoryLength=13;BR=05 Code Token 6 Token 6 & Token 1 

Best regards,
Don
Donald F. Coffin
Founder/CTO
 
REMI Networks
 
Phone:      (949) 636-8571

 

 
Bill,

                        BulkID=04

 
 
Best regards,
Don
Donald F. Coffin
Founder/CTO
 
REMI Networks
 
Phone:      (949) 636-8571

 
 
-bill

 

 

 
 
Best regards,
Don
Donald F. Coffin
Founder/CTO
 
REMI Networks
 
Phone:      (949) 636-8571

---

From: "Donald Coffin" <[email-masked]>
Date: Mon, 17 Feb 2014 09:59:08 -0800

Bill,

Our design does not include any identifiable information be passed within the token, as the standard being implemented (Energy Service Provider Interface) has the requirement that no personal identifiable information be exchanged between Third Parties (i.e. clients) and Data Custodians (i.e. authorization and resource servers).  Therefore, the tokens being generated are ubiquitous values with no direct information the recipient can use to access resource information.

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

Phone:      (949) 636-8571

From: Bill Mills [mailto:[email-masked]] 
Sent: Monday, February 17, 2014 9:10 AM
To: Donald Coffin; 'Marty Burns'; [email-masked]
Cc: 'greenbutton-dev'
Subject: Re: [OAUTH-WG] Scope parameter values for "authorization_code" and "client_credentials" based access tokens

Bill,

Owner

SCOPE

Grant Type

Access Token

Client

Client_credentials

Token 1

NA**

RO 1

Code

Token 2

Token 2

RO 1

Code

Token 3

Token 3

RO 2

Code

Token 4

Token 4

RO 3

Code

Token 5

Token 5 & Token 1

RO 4

Code

Token 6

Token 6 & Token 1

 

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

Phone:      (949) 636-8571

Don,

Marty

Bill,

                        BulkID=04

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

Phone:      (949) 636-8571

-bill

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

Phone:      (949) 636-8571

---

From: Bill Mills <[email-masked]>
Date: Mon, 17 Feb 2014 10:22:40 -0800 (PST)

And how exactly does that apply to scope name, expiry, or max allowable records fetched?

On Monday, February 17, 2014 9:59 AM, Donald Coffin <[email-masked]> wrote:
 
Bill,

Best regards,
Don
Donald F. Coffin
Founder/CTO
 
REMI Networks
 
Phone:      (949) 636-8571

 

 

 

 

Best regards,
Don
Donald F. Coffin
Founder/CTO
 
REMI Networks
 
Phone:      (949) 636-8571

 

 
Bill,

                        BulkID=04

 
 
Best regards,
Don
Donald F. Coffin
Founder/CTO
 
REMI Networks
 
Phone:      (949) 636-8571

 
 
-bill

 

 

 
 
Best regards,
Don
Donald F. Coffin
Founder/CTO
 
REMI Networks
 
Phone:      (949) 636-8571

---

From: "Donald Coffin" <[email-masked]>
Date: Mon, 17 Feb 2014 10:53:31 -0800

Bill,

Expiration of the access token is defined by the authorization server and returned to the client as part of the access token JSON response.  I’m not sure I understand the “scope name” and “max allowable records” portion of your question.  Can you clarify?

Some of the group believe the contents of the SCOPE parameter is a suggestion to the client of the data available from the resource server and NOT a limiting value of the data a client may access.  Can you comment on your interpretation of the meaning of the SCOPE parameter?

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

Phone:      (949) 636-8571

From: Bill Mills [mailto:[email-masked]] 
Sent: Monday, February 17, 2014 10:23 AM
To: Donald Coffin; 'Marty Burns'; [email-masked]
Cc: 'greenbutton-dev'
Subject: Re: [OAUTH-WG] Scope parameter values for "authorization_code" and "client_credentials" based access tokens

Bill,

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

Phone:      (949) 636-8571

Bill,

Owner

SCOPE

Grant Type

Access Token

Client

Client_credentials

Token 1

NA**

RO 1

Code

Token 2

Token 2

RO 1

Code

Token 3

Token 3

RO 2

Code

Token 4

Token 4

RO 3

Code

Token 5

Token 5 & Token 1

RO 4

Code

Token 6

Token 6 & Token 1

 

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

Phone:      (949) 636-8571

Don,

Marty

Bill,

                        BulkID=04

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

Phone:      (949) 636-8571

-bill

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

Phone:      (949) 636-8571

---

From: Marty Burns <[email-masked]>
Date: Mon, 17 Feb 2014 09:18:43 -0500

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:[email-masked]]
*Sent:* Monday, February 17, 2014 8:41 AM
*To:* Marty Burns; Donald Coffin; Bill Mills; [email-masked]
*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 <[email-masked]>
*Date: *Sunday, February 16, 2014 8:34 PM
*To: *Donald Coffin <[email-masked]>, Bill Mills <
[email-masked]>, "[email-masked]" <[email-masked]>
*Cc: *greenbutton-dev <[email-masked]>
*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:

Marty

*From:[email-masked] [mailto:
[email-masked]] *On Behalf Of *Donald Coffin
*Sent:* Sunday, February 16, 2014 8:14 PM
*To:* 'Bill Mills'; [email-masked]
*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:

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

Phone:      (949) 636-8571

*From:* Bill Mills [mailto:[email-masked] <[email-masked]>]
*Sent:* Saturday, February 15, 2014 8:30 PM
*To:* Donald Coffin; [email-masked]
*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-masked]> wrote:

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 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?

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

Phone:      (949) 636-8571

-- 
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-masked].
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 [email-masked].
For more options, visit https://groups.google.com/groups/opt_out.