Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 3 Feb 2013 10:41:50 +0100

Hi Donald,

thanks for your interest in OAuth and specifically the revocation draft. I have added my comments inline.

@George: thanks for answering Donald's questions in the first place. I'm obviously to occupied with my day time work right now to react quickly.

regards,
Torsten.

Am 30.01.2013 um 01:29 schrieb "Donald F Coffin" <[email-masked]>:

> George,
>  
> Thanks for the quick response.  I’ve added my comments after your responses below.
>  
> 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: George Fletcher [mailto:[email-masked]] 
> Sent: Tuesday, January 29, 2013 3:29 PM
> To: Donald F Coffin
> Cc: Torsten Lodderstedt; John Adkins; Scott Crowder; Dave Robin; John Teeter; [email-masked]; Edward Denson; Marty Burns; Uday Verma; Ray Perlner; Anne Hendry; Lynne Rodoni; [email-masked]
> Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04
>  
> First, just want to say this is a great write up of the situation. Thanks!
> 
> A couple of additional thoughts regarding token management and processing...
> 
> 1. If all tokens being revoked are tokens issued by the same Authorization Server (AS) then it can easily mark which are refresh and which are access such that I'm not sure an additional parameter is needed. If the issue is integrating with legacy tokens, then I can see a short term need as an optimization while the tokens rotate through. The question is whether the short term need of the parameter justifies it if long term it's not needed. Maybe an option is for the ESPI profile to specify an additional parameter that is not required by this spec.
> 
> [Don] A few utilities have launched “Connect My Data” programs with Third Party applications, but these are using Certificates as a means of identifying Third Party applications.  There are no utilities, to my knowledge, with “Connect My Data” programs that have implemented OAuth 2.0.  The current ESPI Standard requires the implementation of OAuth 1.0.  Therefore, there should not be a legacy token issue.  As a result of the work our group is doing, we will shortly submit a request to NAESB to revise the existing standard to reflect the migration from OAuth 1.0 to OAuth 2.0.
> 
> Your suggestion to “mark which are refresh and which are access” tokens while providing a method to identify what type of token was issued after it has been found, still poses a processing problem if the only parameter on the Token Revocation request is the Token.  Even implementing your suggestion it will still be necessary to scan the entire set of Tokens to locate and identify what type of Token is being revoked.  If a token_type parameter is provided with the Token Revocation request the only Tokens that need to be scanned are those matching the type being revoked.  This will significantly reduce the size of the dataset and therefore expedite the search.  I realize assigning the Token value as an index key would also improve the retrieval time.  Since that is an implementation feature, it is beyond the scope of the activity our group is chartered to perform.

The effort needed directly depends on your token design. If, for example, access and refresh tokens could be distinguished by the first byte (like magic bytes in data files), things are evenly easy than having the additional parameter. If your need to issue a database lookup, things get more processing intensive.

I'm not against adding the parameter (again). We had this discussion for quite a while and decided against adding it again because of the current stage of the draft.

see also http://www.ietf.org/mail-archive/web/oauth/current/msg10211.html for the options we had discussed.

> 
> 
> 2. I don't think you can always revoke the refresh_token if an access_token is revoked. I can see a use case where a client gets a refresh_token and an access_token. The client uses the access_token for 5 minutes but the access_token is good for an hour. So the client revokes the access_token to ensure it can't be used again. The client will just use it's refresh_token when it needs another access_token. In this case, revoking the refresh_token would "break" the client. In addition, unless you add audience style checking to the token processing rules, you open up the AS to a denial of service attack. Basically, if the AS revokes the refresh_token when an access_token is revoked, I can steal an access_token and send it to the revocation endpoint causing the real client's refresh_token to be revoked. To prevent this, the tokens should be bound to the client_id to which they were issued, and should only be revocable from that client_id.
>  
> [Don] The focus of the ESPI Standard is to provide Retail Customer’s with access to a single UsagePoint (i.e. their Smart Meter).  Therefore an access and refresh token will be tightly correlated with the type and frequency of data the Smart Meter provides.  There are only a few reasons defined within the ESPI Standard list of use cases that will require the Token Revocation request to be issued.  The following summarizes the situations that require a Token Revocation request:
> 
> ·         A Third Party application wishes to terminate their relationship with a Retail Customer.
> 
> ·         A Third Party application wishes to terminate their relationship with a Data Custodian.
> 
> ·         A Retail Customer wishes to terminate their relationship with a Third Party application.
> 
> ·         A Retail Customer wishes to change the data (i.e. scope) a Third Party application has permission to access.
> 
> In none of the above situations will it be valid to retain a refresh token, which I realize is implementation dependent, due to the nature of the ESPI Standard.
> 
> Perhaps the section on the Server’s Revocation Policy should address a few of the reasons why a client may want or need to revoke a token.  The current description provides no consideration for the relationship between tokens and scope, although there clearly is a relationship.
> 
I'm confident client or resource owner would revoke refresh (and not access) tokens in all use cases you listed above. In my opinion, access tokens are revoked only if the authorization server does not support refresh tokens and therefore uses long term access tokens or in high-security applications.

I would also like to hear the opinion of other WG members on this topic.

> 3. If the standard OAuth spec does not provide enough control, your profile of OAuth2 for the ESPI can tighten it to provide the protections desired.
> 
> [Don] I am aware we can provide additional parameters required to integrate OAuth 2.0 with the ESPI Standard by submitting those parameter values to the OAuth Parameters registry. I would prefer not to do that, given the large amount of work being done on RFC-drafts to resolve many of the issues we are facing to integrate OAuth 2.0 with the ESPI Standard, since the need to use those extensions will most likely be short lived.
> 

Hmmm, if the need is only short lived, why do you want to make it part of the long living revocation RFC?

> Thanks,
> George
> 
> On 1/29/13 3:28 PM, Donald F Coffin wrote:
> Hi Thorsten,
>  
> I am working with the OpenADE Task Force to document how the “Energy Service Provider Interface (ESPI) Standard ” published by the North American Energy Standards Board (NAESB) in October of 2011 should be implemented.  The ESPI Standard defines how Retail Customers, Third Party applications, and Data Custodians (i.e. electrical, gas, or water utility) must interface to each other and the data format used to exchange energy information.   The interface between the Retail Customer and the Data Custodian is known as “Download My Data”, which defines how a Retail Customer receives their energy information in an XML file downloaded to them by the Data Custodian.  The interface between the Third Party application and the Data Custodian is known as “Connect My Data”, which defines the message exchanges between the Third Party application and the Data Custodian to allow the Third Party to access data at the Data Custodian after a Retail Customer has granted the Third Party application access.
>  
> It is my responsibility within the OpenADE Task Force to document the integration of the OAuth 2.0 protocol with the ESPI Standard.  Since the ESPI Standard requires Retail Customers, Third Party applications, and Data Custodians to revoke Tokens (i.e. Access and Refresh Tokens) I am very interested in the “Token Revocation (draft-ietf-oath-revocation-xx)” work being done by you and your working group.
>  
> Token Revocation Request
>  
> The Token Revocation request has only the “token” parameter with the description that the authorization server is supposed to detect the token type automatically.  I would like to request that an addition parameter “token_type” be added to the request.  The “token_type” parameter could be optional and would define the type of token being revoked (i.e. “access”, “refresh”, “registration access”, etc.).
>  
> The ESPI Standard was developed to support the Advanced Meter Interface (AMI) which is the interface used by “Smart Meters” to provide automated energy usage collection and other operational information about a Retail Customer’s residence to their Data Custodian.  Third Party applications will be required to obtain the approval if each Retail Customer that has had a “Smart Meter” installed before they will be able to access the data provided by their “Smart Meter”.  The number of “Smart Meters” currently installed at the three largest California utilities (Pacific Gas & Electric, Southern California Edison, and San Diego Gas & Electric) is in excess of 10.0 M and growing.  The following table indicates the number of “Smart Meters” each of the three utilities had installed as of May 2012:
>  
> Utility
> “Smart Meters” Installed
> Pacific Gas & Electric (PG&E)
> 4,696,000
> San Diego Gas & Electric (SDG&E)
> 1,364,000
> Southern California Edison (SCE)
> 3,900,000
>  
> The numbers in the chart were taken from the “Utility-Scale Smart Meter Deployments, Plans, & Proposals -- IEE Report” published May 2012 by The Edison Foundation Institute for Electric Efficiency” which I have attached.  The number of “Smart Meters” currently installed are even larger than shown in the report as I compose this email.  Assuming 10% of Pacific Gas & Electric’s Retail Customers decide to utilize a Third Party application (3 Third Party applications are currently supported and are 3 more Third Party applications are preparing to be supported) in order to support the ability to revoke a token they would be required to track 500,000 access tokens and 500,000 refresh tokens.  Requiring PG&E’s authorization server to “automatically” determine the type of Token being revoked begins to negatively impact their processing capability.  If the Token Revocation request was capable of indicating the type of Token to be revoked, the amount of time it will take PG&E’s authorization server would show a significant time savings to process the request.
>  
> Authorization Server Revocation Policy
>  
>  
>       6.       Does the revocation of the access token also revoke the refresh token (if it was provided) ? Or is this a revocation policy decision ?
>  
> - if the token passed to the request is a refresh token and the server supports access token revocation, the server SHOULD also revoke them.
> - if the token passed to the request is an access token, the server may decide to revoke the respective refresh token as well.
>  
> I believe that if the token passed in the request is an access token, the server MUST revoke any respective refresh token.  Otherwise, their exist a potential security risk of the respective refresh token being used to gain access to the resources for which the access token was issued.  It also means the authorization server will have potential “junk” in the refresh token file to search through for any additional Token Revocation request.
>  
> I look forward to receiving your response.
>  
> 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]
>  
> 
> 
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: "Donald F Coffin" <[email-masked]>
Date: Sun, 3 Feb 2013 03:57:59 -0800

Hi Torsten,

Thanks for your additional comments.  I have added my comments inline.

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

Phone:      (949) 636-8571

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

From: Torsten Lodderstedt [mailto:[email-masked]] 
Sent: Sunday, February 03, 2013 1:42 AM
To: Donald F Coffin
Cc: George Fletcher; John Adkins; Scott Crowder; Dave Robin; John Teeter; <[email-masked]>; Edward Denson; Marty Burns; Uday Verma; Ray Perlner; Anne Hendry; Lynne Rodoni; <[email-masked]>
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04

Hi Donald,

regards,

Torsten.

George,

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

Phone:      (949) 636-8571

[Don] Thanks for the suggestion the format of the token could be distinguished by the first byte.  Since this is an implementation decision, it is beyond the scope of the work of the OpenESPI and OpenADE Task Force and therefore is something we could recommend in an implementation note only.  The creation of an implementation document has not been discussed within the group but is something we could look into providing after we complete the architectural task of integrating OAuth 2.0 with the ESPI standard.  However, using a data format solution with tokens seems to be a short term solution, given the additional number of tokens being created by the “OAuth Dynamic Client Registration Protocol” and “User-Managed Access (UMA) Profile of OAuth 2.0” drafts.  Since the management of an embedded marker could itself become very challenging, especially given any additional future RFC could in theory add even more token types, as the new proposed RFCs seem to be closing OAuth 2.0 implementation concerns or capabilities not covered in the core document.

[Don] A typical Third Party application built to use the ESPI Standard will interact with a Retail Customer and their energy provider.  The nature of interaction with the Retail Customer will utilize short interactive sessions.  However, the interaction with their energy provider will require the application obtain new energy information for the previous 24-hours once a day.  Therefore, I anticipate access_tokens will be granted for long periods of time as well as any supporting refresh_tokens.  Because of the amount of data being exchanged between the Third Party application and the energy provider, both in number of retail customers and the amount of energy meter data, it will be necessary to minimize the amount of “administrative” traffic required in the exchange.  Therefore, although I understand the use case you described, I anticipate such an implementation would be rare.  

The need to perform an audience style check to prevent exposure of the AS to a denial of service attack, appears primarily due to the fact the Revocation RFC requires an access_token and refresh_token to be revoked independently.  Should a client need to revoke both Tokens the sequence of the revocation request is extremely significant.  A simple solution to this problem would be to provide a method that allows a request to revoke both tokens simultaneously, as stated in one of the responses you referenced in the archives.  

The example you gave in your response demonstrating how a denial of service attack might occur is incorrect.  You said “if the AS revokes the refresh_token when an access_token is revoked, I can steal an access_token and send it to the revocation endpoint causing the real client’s refresh_token to be revoked”.  I fail to see how that could occur, since the AS revoked both the access_token and the refresh_token when it received the request to revoke the access_token.  Rather than explaining why a refresh_token shouldn’t be revoked concurrently when an access_token is revoked, your example does the exact opposite.  It shows why a refresh_token should be revoked concurrently when an access_token is revoked.

[Don] Based on the above statement it would appear you assume an access token is only valid for a short period of time.  However, as I explained in my last response, due to the nature of the access required by the client and the manner in which the RS provides that data, access token durations will typically be in days not minutes.   Therefore, merely revoking a refresh_token will expose the data to access that the resource owner meant to prevent unless the access_token is also revoked.

[Don] My response was to the suggestion that if the OAuth specification does not provide enough control then the ESPI profile of OAuth 2.0 could tighten it to provide the protections desired.  I assumed George meant we could add additional “company” based parameters, which requires us to register them with the “OAuth Parameter Registry”.  I meant the usage of such “company” parameters would be short termed.

I do not view the need to identify the type of token being revoked as “short term”.  Even the previous exchanges on the topic within the WG indicates it feels there may be a need to add an additional parameter to the request.  However, because the draft is too far along, the WG seems to prefer releasing an RFC they “suspect” will need to be adjusted and let the implementers confirm their suspicions.   This seems to be a very selfish and rather foolish attitude given we are discussing a security protocol.  Not to mention it would seem easier and faster to add an additional “optional” parameter now, rather than requiring another RFC cycle.  A parameter I sensed in reading the archives the WG feels will very likely need to be added in the future.

Thanks,
George

Hi Thorsten,

Token Revocation Request

Utility

“Smart Meters” Installed

4,696,000

1,364,000

3,900,000

 

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

Phone:      (949) 636-8571

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 03 Feb 2013 13:20:26 +0100

Hi Donald,

Am 03.02.2013 12:57, schrieb Donald F Coffin:
> <snip>
>
> [Don] A typical Third Party application built to use the ESPI Standard 
> will interact with a Retail Customer and their energy provider.  The 
> nature of interaction with the Retail Customer will utilize short 
> interactive sessions. However, the interaction with their energy 
> provider will require the application obtain new energy information 
> for the previous 24-hours once a day.  Therefore, I anticipate 
> access_tokens will be granted for long periods of time as well as any 
> supporting refresh_tokens.  Because of the amount of data being 
> exchanged between the Third Party application and the energy provider, 
> both in number of retail customers and the amount of energy meter 
> data, it will be necessary to minimize the amount of “administrative” 
> traffic required in the exchange. Therefore, although I understand the 
> use case you described, I anticipate such an implementation would be 
> rare.
>
> The need to perform an audience style check to prevent exposure of the 
> AS to a denial of service attack, appears primarily due to the fact 
> the Revocation RFC requires an access_token and refresh_token to be 
> revoked independently.  Should a client need to revoke both Tokens the 
> sequence of the revocation request is extremely significant.  A simple 
> solution to this problem would be to provide a method that allows a 
> request to revoke both tokens simultaneously, as stated in one of the 
> responses you referenced in the archives.
>
> The example you gave in your response demonstrating how a denial of 
> service attack might occur is incorrect.  You said “if the AS revokes 
> the refresh_token when an access_token is revoked, I can steal an 
> access_token and send it to the revocation endpoint causing the real 
> client’s refresh_token to be revoked”.  I fail to see how that could 
> occur, since the AS revoked both the access_token and the 
> refresh_token when it received the request to revoke the 
> access_token.  Rather than explaining why a refresh_token shouldn’t be 
> revoked concurrently when an access_token is revoked, your example 
> does the exact opposite.  It shows why a refresh_token should be 
> revoked concurrently when an access_token is revoked.
>
> [Don] The focus of the *ESPI Standard* is to provide Retail Customer’s 
> with access to a single UsagePoint (i.e. their Smart Meter).  
> Therefore an access and refresh token will be tightly correlated with 
> the type and frequency of data the Smart Meter provides.  There are 
> only a few reasons defined within the *ESPI Standard* list of use 
> cases that will require the *Token Revocation* request to be issued.  
> The following summarizes the situations that require a *Token 
> Revocation *request:
>
> ·A Third Party application wishes to terminate their relationship with 
> a Retail Customer.
>
> ·A Third Party application wishes to terminate their relationship with 
> a Data Custodian.
>
> ·A Retail Customer wishes to terminate their relationship with a Third 
> Party application.
>
> ·A Retail Customer wishes to change the data (i.e. scope) a Third 
> Party application has permission to access.
>
> In none of the above situations will it be valid to retain a refresh 
> token, which I realize is implementation dependent, due to the nature 
> of the *ESPI Standard.*
>
> Perhaps the section on the *Server’s Revocation Policy* should address 
> a few of the reasons why a client may want or need to revoke a token.  
> The current description provides no consideration for the relationship 
> between tokens and scope, although there clearly is a relationship.
>
> I'm confident client or resource owner would revoke refresh (and not 
> access) tokens in all use cases you listed above. In my opinion, 
> access tokens are revoked only if the authorization server does not 
> support refresh tokens and therefore uses long term access tokens or 
> in high-security applications.
>
> [Don] Based on the above statement it would appear you assume an 
> access token is only valid for a short period of time. However, as I 
> explained in my last response, due to the nature of the access 
> required by the client and the manner in which the RS provides that 
> data, access token durations will typically be in days not minutes. 
>   Therefore, merely revoking a refresh_token will expose the data to 
> access that the resource owner meant to prevent unless the 
> access_token is also revoked.
>

I don't understand why access tokens need such a long duration in your 
scenario, even if the client needs to obtain energy data once a day. Any 
client can (potentially) obtain a new access token at any time if the 
access token expires if the authorization server issues corresponding 
refresh tokens. So even in your scenario, access tokens could have a 
short duration. If you want to issue long-living access tokens in order 
to minimize load on the authorization servers, then you have to consider 
the extra complexitity and load required to notify resource servers of 
access token revocation. It's a tradeoff decision, which we tried to 
describe in 
http://tools.ietf.org/html/draft-ietf-oauth-revocation-04#section-3.

>     3. If the standard OAuth spec does not provide enough control,
>     your profile of OAuth2 for the ESPI can tighten it to provide the
>     protections desired.
>
>     [Don] I am aware we can provide additional parameters required to
>     integrate *OAuth 2.0 *with the *ESPI Standard* by submitting those
>     parameter values to the *OAuth Parameters* registry. I would
>     prefer not to do that, given the large amount of work being done
>     on RFC-drafts to resolve many of the issues we are facing to
>     integrate *OAuth 2.0* with the *ESPI Standard*, since the need to
>     use those extensions will most likely be short lived.
>
> [Don] My response was to the suggestion that if the OAuth 
> specification does not provide enough control then the ESPI profile of 
> OAuth 2.0 could tighten it to provide the protections desired.  I 
> assumed George meant we could add additional “company” based 
> parameters, which requires us to register them with the “OAuth 
> Parameter Registry”.  I meant the usage of such “company” parameters 
> would be short termed.
>

Understood.

> I do not view the need to identify the type of token being revoked as 
> “short term”.  Even the previous exchanges on the topic within the WG 
> indicates it feels there may be a need to add an additional parameter 
> to the request.  However, because the draft is too far along, the WG 
> seems to prefer releasing an RFC they “suspect” will need to be 
> adjusted and let the implementers confirm their suspicions.   This 
> seems to be a very selfish and rather foolish attitude given we are 
> discussing a security protocol.  Not to mention it would seem easier 
> and faster to add an additional “optional” parameter now, rather than 
> requiring another RFC cycle.  A parameter I sensed in reading the 
> archives the WG feels will very likely need to be added in the future.
>

Since this is a WG item, it is up to the WG to decide.

regards,
Torsten.

>     I am working with the OpenADE Task Force to document how the
>     “*/Energy Service Provider Interface (ESPI) Standard/* ” published
>     by the *North American Energy Standards Board* (NAESB) in October
>     of 2011 should be implemented.  The *ESPI Standard* defines how
>     Retail Customers, Third Party applications, and Data Custodians
>     (i.e. electrical, gas, or water utility) must interface to each
>     other and the data format used to exchange energy information. 
>      The interface between the Retail Customer and the Data Custodian
>     is known as “*Download My Data*”, which defines how a Retail
>     Customer receives their energy information in an XML file
>     downloaded to them by the Data Custodian.  The interface between
>     the Third Party application and the Data Custodian is known as
>     “*Connect My Data*”, which defines the message exchanges between
>     the Third Party application and the Data Custodian to allow the
>     Third Party to access data at the Data Custodian after a Retail
>     Customer has granted the Third Party application access.
>
>     It is my responsibility within the OpenADE Task Force to document
>     the integration of the *OAuth 2.0* protocol with the *ESPI
>     Standard.*  Since the *ESPI Standard* requires Retail Customers,
>     Third Party applications, and Data Custodians to revoke Tokens
>     (i.e. Access and Refresh Tokens) I am very interested in the
>     “*/Token Revocation (draft-ietf-oath-revocation-xx)/*” work being
>     done by you and your working group.
>
>     *_Token Revocation Request_*
>
>     The *Token Revocation* request has only the “token” parameter with
>     the description that the authorization server is supposed to
>     detect the token type automatically.  I would like to request that
>     an addition parameter “token_type” be added to the request.  The
>     “token_type” parameter could be optional and would define the type
>     of token being revoked (i.e. “access”, “refresh”, “registration
>     access”, etc.).
>
>     The *ESPI Standard* was developed to support the *Advanced Meter
>     Interface* *(AMI) *which is the interface used by “Smart Meters”
>     to provide automated energy usage collection and other operational
>     information about a Retail Customer’s residence to their Data
>     Custodian.  Third Party applications will be required to obtain
>     the approval if each Retail Customer that has had a “Smart Meter”
>     installed before they will be able to access the data provided by
>     their “Smart Meter”.  The number of “Smart Meters” currently
>     installed at the three largest California utilities (Pacific Gas &
>     Electric, Southern California Edison, and San Diego Gas &
>     Electric) is in excess of 10.0 M and growing.  The following table
>     indicates the number of “Smart Meters” each of the three utilities
>     had installed as of May 2012:
>
>     *Utility*
>
>     	
>
>     *“Smart Meters” Installed*
>
>     The numbers in the chart were taken from the “*/Utility-Scale
>     Smart Meter Deployments, Plans, & Proposals -- IEE Report/*”
>     published May 2012 by *The Edison Foundation Institute for
>     Electric Efficiency” *which I have attached.  The number of “Smart
>     Meters” currently installed are even larger than shown in the
>     report as I compose this email.  Assuming 10% of Pacific Gas &
>     Electric’s Retail Customers decide to utilize a Third Party
>     application (3 Third Party applications are currently supported
>     and are 3 more Third Party applications are preparing to be
>     supported) in order to support the ability to revoke a token they
>     would be required to track 500,000 access tokens and 500,000
>     refresh tokens.  Requiring PG&E’s authorization server to
>     “automatically” determine the type of Token being revoked begins
>     to negatively impact their processing capability.  If the *Token
>     Revocation* request was capable of indicating the type of Token to
>     be revoked, the amount of time it will take PG&E’s authorization
>     server would show a significant time savings to process the request.
>
>     *_Authorization Server Revocation Policy_*
>
>     6.Does the revocation of the access token also revoke the refresh
>     token (if it was provided) ? Or is this a revocation policy decision ?
>
>     - if the token passed to the request is a refresh token and the
>     server supports access token revocation, the server SHOULD also
>     revoke them.
>     - if the token passed to the request is an access token, the
>     server may decide to revoke the respective refresh token as well.
>
>     I believe that if the token passed in the request is an access
>     token, the server MUST revoke any respective refresh token. 
>     Otherwise, their exist a potential security risk of the respective
>     refresh token being used to gain access to the resources for which
>     the access token was issued. It also means the authorization
>     server will have potential “junk” in the refresh token file to
>     search through for any additional Token Revocation request.
>
>     <mailto:[email-masked]>
>
>
>
>
>
>     [email-masked]  <mailto:[email-masked]>
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 03 Feb 2013 14:04:46 +0100

Hi Donald,

> between tokens and scope, although there clearly is a relationship.

I will extend the description text in the next revision.

regards,
Torsten.

---

From: "Donald F Coffin" <[email-masked]>
Date: Sun, 3 Feb 2013 12:45:31 -0800

Hi Torsten,

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

Phone:      (949) 636-8571

From: Torsten Lodderstedt [mailto:[email-masked]] 
Sent: Sunday, February 03, 2013 4:20 AM
To: Donald F Coffin
Cc: 'George Fletcher'; 'John Adkins'; 'Scott Crowder'; 'Dave Robin'; 'John Teeter'; [email-masked]; 'Edward Denson'; 'Marty Burns'; 'Uday Verma'; 'Ray Perlner'; 'Anne Hendry'; 'Lynne Rodoni'; [email-masked]
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04

Hi Donald,

<snip> 

I don't understand why access tokens need such a long duration in your scenario, even if the client needs to obtain energy data once a day. Any client can (potentially) obtain a new access token at any time if the access token expires if the authorization server issues corresponding refresh tokens. So even in your scenario, access tokens could have a short duration. If you want to issue long-living access tokens in order to minimize load on the authorization servers, then you have to consider the extra complexitity and load required to notify resource servers of access token revocation. It's a tradeoff decision, which we tried to describe in http://tools.ietf.org/html/draft-ietf-oauth-revocation-04#section-3. 

[Don] A critical fact I omitted in my last response is the data obtained on a daily basis by a Third Party application will utilize an access_token obtained using the client_credentials grant_type.  Therefore no refresh_token will be issued with the access_token.  The ESPI Standard requires the Retail Customer (resource owner) and the RS to be notified whenever an authorization is modified or revoked by either the Third Party (client) or Retail Customer (resource owner).  Therefore, the tradeoff decision has already been made.

I personally feel that short lived access_tokens provide greater security, but in discussions with several utilities who have the responsibility of supporting the AS and RS functionality, they currently are planning on implementing long duration access_tokens.  This view may change once the begin to implement “Connect My Data” solutions, but that again is an implementation feature, which is beyond the scope of my groups current work product.

Understood.

[Don] I fully understand it is the WG’s decision.  I am only providing my opinion as an implementer, who the WG desires to obtain feedback from before making the final decision.

regards,
Torsten.

Thanks,
George

Hi Thorsten,

Token Revocation Request

Utility

“Smart Meters” Installed

4,696,000

1,364,000

3,900,000

 

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

Phone:      (949) 636-8571

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 3 Feb 2013 22:14:02 +0100

Hi Donald,

Thanks for the clarification. Let me see whether I got you right. Although the retail customer has to authorize the access by the 3rd party application, there is no external representation of this authorization grant (e.g a refresh token). Instead, the actual access token is issued based on client credentials. Is there any correlation between the access token and the particular customer?

Please note: we highly appreciate your feedback as an implementer.

Best regards,
Torsten.

---

From: "Donald F Coffin" <[email-masked]>
Date: Sun, 3 Feb 2013 13:59:06 -0800

Hi Torsten,

The Third Party will utilize an access_token they obtain utilizing the client_credentials to obtain data from the RS for all Retail Customers who have granted them access to their data.  Therefore, the Third Party will also have an access_token they obtain utilizing the authentication_code response_type (i.e. grant_type of code for the access_token) for each of the Retail Customers who have authorized them access to their data.

Although an access_token will exist for the Third Party, Retail Customer, and RS relationship its usage will be infrequent compared to the access_token the Third Party obtains using the client_credentials grant_type.  This is another reason why I believe in the ESPI Standard implementation it will be necessary to revoke the access_token and refresh_token simultaneously.  The RS should not include in the data stream (covered by the client_credentials access_token) data that is based on the authorization_code access_token when the Retail Customer has indicated  (either by alteration of the authorization scope or an outright revocation) the Third Party no longer is authorized to access the data.  Only revoking the refresh_token possess a privacy.  Only revoking the access_token, as you pointed out, poses a potential security issue allowing for the possibility of a denial of service attack.

I hope this makes sense and clarifies my situation..

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

Phone:      (949) 636-8571

From: Torsten Lodderstedt [mailto:[email-masked]] 
Sent: Sunday, February 03, 2013 1:14 PM
To: Donald F Coffin
Cc: George Fletcher; John Adkins; Scott Crowder; Dave Robin; John Teeter; <[email-masked]>; Edward Denson; Marty Burns; Uday Verma; Ray Perlner; Anne Hendry; Lynne Rodoni; <[email-masked]>
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04

Hi Donald,

Best regards,

Torsten.

Hi Torsten,

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

Phone:      (949) 636-8571

Hi Donald,

<snip> 

 

 

Understood.

regards,
Torsten.

Thanks,
George

Hi Thorsten,

Token Revocation Request

Utility

“Smart Meters” Installed

4,696,000

1,364,000

3,900,000

 

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

Phone:      (949) 636-8571