Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBA4621F854B for ; Sun, 3 Feb 2013 13:14:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.628 X-Spam-Level: X-Spam-Status: No, score=0.628 tagged_above=-999 required=5 tests=[AWL=-1.619, BAYES_20=-0.74, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fViCTAND+X4i for ; Sun, 3 Feb 2013 13:14:14 -0800 (PST) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.29.8]) by ietfa.amsl.com (Postfix) with ESMTP id D9FFC21F8488 for ; Sun, 3 Feb 2013 13:14:13 -0800 (PST) Received: from [79.253.33.56] (helo=[192.168.71.56]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1U26t3-0000bi-9n; Sun, 03 Feb 2013 22:14:05 +0100 References: <006401cdfe5f$2555f170$7001d450$@reminetworks.com> <51085B43.3080103@aol.com> <00c901cdfe80$e7d0eb30$b772c190$@reminetworks.com> <9DFD603A-1170-41D8-A22F-8654D55546B3@lodderstedt.net> <00a301ce0205$b6b1ca00$24155e00$@reminetworks.com> <510E560A.4090107@lodderstedt.net> <003e01ce024f$6894feb0$39befc10$@reminetworks.com> Mime-Version: 1.0 (1.0) In-Reply-To: <003e01ce024f$6894feb0$39befc10$@reminetworks.com> Content-Type: multipart/alternative; boundary=Apple-Mail-67BDD6D1-D210-4B99-9CA0-CC32BC500837 Content-Transfer-Encoding: 7bit Message-Id: <446E24A6-1E3A-4596-AAEA-8B6F1AD7D1A0@lodderstedt.net> X-Mailer: iPad Mail (10B141) From: Torsten Lodderstedt Date: Sun, 3 Feb 2013 22:14:02 +0100 To: Donald F Coffin X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: John Adkins , Marty Burns , Scott Crowder , Dave Robin , John Teeter , "" , Edward Denson , "" , Ray Perlner , Anne Hendry , Lynne Rodoni , Uday Verma Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 21:14:16 -0000 --Apple-Mail-67BDD6D1-D210-4B99-9CA0-CC32BC500837 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Donald, Thanks for the clarification. Let me see whether I got you right. Although t= he retail customer has to authorize the access by the 3rd party application,= there is no external representation of this authorization grant (e.g a refr= esh token). Instead, the actual access token is issued based on client crede= ntials. 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. Am 03.02.2013 um 21:45 schrieb "Donald F Coffin" : > Hi Torsten, > =20 > Best regards, > Don > Donald F. Coffin > Founder/CTO > =20 > REMI Networks > 22751 El Prado Suite 6216 > Rancho Santa Margarita, CA 92688-3836 > =20 > Phone: (949) 636-8571 > Email: donald.coffin@reminetworks.com > =20 > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]=20 > Sent: Sunday, February 03, 2013 4:20 AM > To: Donald F Coffin > Cc: 'George Fletcher'; 'John Adkins'; 'Scott Crowder'; 'Dave Robin'; 'John= Teeter'; pmadsen@pingidentity.com; 'Edward Denson'; 'Marty Burns'; 'Uday Ve= rma'; 'Ray Perlner'; 'Anne Hendry'; 'Lynne Rodoni'; oauth@ietf.org > Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 > =20 > Hi Donald, >=20 > Am 03.02.2013 12:57, schrieb Donald F Coffin: > > =20 > [Don] A typical Third Party application built to use the ESPI Standard wil= l interact with a Retail Customer and their energy provider. The nature of i= nteraction with the Retail Customer will utilize short interactive sessions.= However, the interaction with their energy provider will require the appli= cation obtain new energy information for the previous 24-hours once a day. T= herefore, I anticipate access_tokens will be granted for long periods of tim= e as well as any supporting refresh_tokens. Because of the amount of data b= eing exchanged between the Third Party application and the energy provider, b= oth in number of retail customers and the amount of energy meter data, it wi= ll be necessary to minimize the amount of =E2=80=9Cadministrative=E2=80=9D t= raffic required in the exchange. Therefore, although I understand the use c= ase you described, I anticipate such an implementation would be rare.=20 > =20 > The need to perform an audience style check to prevent exposure of the AS t= o a denial of service attack, appears primarily due to the fact the Revocati= on RFC requires an access_token and refresh_token to be revoked independentl= y. Should a client need to revoke both Tokens the sequence of the revocatio= n request is extremely significant. A simple solution to this problem would= be to provide a method that allows a request to revoke both tokens simultan= eously, as stated in one of the responses you referenced in the archives.=20= > =20 > The example you gave in your response demonstrating how a denial of servic= e attack might occur is incorrect. You said =E2=80=9Cif the AS revokes the r= efresh_token when an access_token is revoked, I can steal an access_token an= d send it to the revocation endpoint causing the real client=E2=80=99s refre= sh_token to be revoked=E2=80=9D. I fail to see how that could occur, since t= he AS revoked both the access_token and the refresh_token when it received t= he request to revoke the access_token. Rather than explaining why a refresh= _token shouldn=E2=80=99t be revoked concurrently when an access_token is rev= oked, your example does the exact opposite. It shows why a refresh_token sh= ould be revoked concurrently when an access_token is revoked. > =20 > [Don] The focus of the ESPI Standard is to provide Retail Customer=E2=80=99= 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 frequ= ency 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 Revo= cation request to be issued. The following summarizes the situations that r= equire a Token Revocation request: >=20 > =C2=B7 A Third Party application wishes to terminate their relatio= nship with a Retail Customer. >=20 > =C2=B7 A Third Party application wishes to terminate their relatio= nship with a Data Custodian. >=20 > =C2=B7 A Retail Customer wishes to terminate their relationship wi= th a Third Party application. >=20 > =C2=B7 A Retail Customer wishes to change the data (i.e. scope) a T= hird Party application has permission to access. >=20 > 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. >=20 > Perhaps the section on the Server=E2=80=99s Revocation Policy should addre= ss a few of the reasons why a client may want or need to revoke a token. Th= e current description provides no consideration for the relationship between= tokens and scope, although there clearly is a relationship. >=20 > I'm confident client or resource owner would revoke refresh (and not acces= s) tokens in all use cases you listed above. In my opinion, access tokens ar= e revoked only if the authorization server does not support refresh tokens a= nd therefore uses long term access tokens or in high-security applications. > =20 > [Don] Based on the above statement it would appear you assume an access to= ken 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 t= he manner in which the RS provides that data, access token durations will ty= pically be in days not minutes. Therefore, merely revoking a refresh_token= will expose the data to access that the resource owner meant to prevent unl= ess the access_token is also revoked. >=20 > I don't understand why access tokens need such a long duration in your sce= nario, 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 wa= nt to issue long-living access tokens in order to minimize load on the autho= rization servers, then you have to consider the extra complexitity and load r= equired to notify resource servers of access token revocation. It's a tradeo= ff decision, which we tried to describe in http://tools.ietf.org/html/draft-= ietf-oauth-revocation-04#section-3.=20 >=20 > =20 > [Don] A critical fact I omitted in my last response is the data obtained o= n a daily basis by a Third Party application will utilize an access_token ob= tained using the client_credentials grant_type. Therefore no refresh_token w= ill be issued with the access_token. The ESPI Standard requires the Retail C= ustomer (resource owner) and the RS to be notified whenever an authorization= is modified or revoked by either the Third Party (client) or Retail Custome= r (resource owner). Therefore, the tradeoff decision has already been made.= > =20 > I personally feel that short lived access_tokens provide greater security,= but in discussions with several utilities who have the responsibility of su= pporting the AS and RS functionality, they currently are planning on impleme= nting long duration access_tokens. This view may change once the begin to i= mplement =E2=80=9CConnect My Data=E2=80=9D solutions, but that again is an i= mplementation feature, which is beyond the scope of my groups current work p= roduct. >=20 > =20 > I would also like to hear the opinion of other WG members on this topic. > =20 > 3. If the standard OAuth spec does not provide enough control, your profil= e of OAuth2 for the ESPI can tighten it to provide the protections desired. >=20 > [Don] I am aware we can provide additional parameters required to integrat= e OAuth 2.0 with the ESPI Standard by submitting those parameter values to t= he 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 ar= e facing to integrate OAuth 2.0 with the ESPI Standard, since the need to us= e those extensions will most likely be short lived. >=20 > =20 > Hmmm, if the need is only short lived, why do you want to make it part of t= he long living revocation RFC? > =20 > [Don] My response was to the suggestion that if the OAuth specification do= es not provide enough control then the ESPI profile of OAuth 2.0 could tight= en it to provide the protections desired. I assumed George meant we could a= dd additional =E2=80=9Ccompany=E2=80=9D based parameters, which requires us t= o register them with the =E2=80=9COAuth Parameter Registry=E2=80=9D. I mean= t the usage of such =E2=80=9Ccompany=E2=80=9D parameters would be short term= ed. >=20 > Understood. >=20 >=20 > I do not view the need to identify the type of token being revoked as =E2=80= =9Cshort term=E2=80=9D. 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 p= refer releasing an RFC they =E2=80=9Csuspect=E2=80=9D will need to be adjust= ed and let the implementers confirm their suspicions. This seems to be a v= ery selfish and rather foolish attitude given we are discussing a security p= rotocol. Not to mention it would seem easier and faster to add an additiona= l =E2=80=9Coptional=E2=80=9D 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. >=20 > Since this is a WG item, it is up to the WG to decide. > =20 > [Don] I fully understand it is the WG=E2=80=99s decision. I am only provi= ding my opinion as an implementer, who the WG desires to obtain feedback fro= m before making the final decision. >=20 >=20 > regards, > Torsten. >=20 >=20 >=20 >=20 >=20 > Thanks, > George >=20 > On 1/29/13 3:28 PM, Donald F Coffin wrote: > Hi Thorsten, > =20 > I am working with the OpenADE Task Force to document how the =E2=80=9CEner= gy Service Provider Interface (ESPI) Standard =E2=80=9D published by the Nor= th American Energy Standards Board (NAESB) in October of 2011 should be impl= emented. The ESPI Standard defines how Retail Customers, Third Party applic= ations, and Data Custodians (i.e. electrical, gas, or water utility) must in= terface to each other and the data format used to exchange energy informatio= n. The interface between the Retail Customer and the Data Custodian is kno= wn as =E2=80=9CDownload My Data=E2=80=9D, which defines how a Retail Custome= r receives their energy information in an XML file downloaded to them by the= Data Custodian. The interface between the Third Party application and the D= ata Custodian is known as =E2=80=9CConnect My Data=E2=80=9D, which defines t= he message exchanges between the Third Party application and the Data Custod= ian to allow the Third Party to access data at the Data Custodian after a Re= tail Customer has granted the Third Party application access. > =20 > It is my responsibility within the OpenADE Task Force to document the inte= gration of the OAuth 2.0 protocol with the ESPI Standard. Since the ESPI St= andard requires Retail Customers, Third Party applications, and Data Custodi= ans to revoke Tokens (i.e. Access and Refresh Tokens) I am very interested i= n the =E2=80=9CToken Revocation (draft-ietf-oath-revocation-xx)=E2=80=9D wor= k being done by you and your working group. > =20 > Token Revocation Request > =20 > The Token Revocation request has only the =E2=80=9Ctoken=E2=80=9D paramete= r with the description that the authorization server is supposed to detect t= he token type automatically. I would like to request that an addition param= eter =E2=80=9Ctoken_type=E2=80=9D be added to the request. The =E2=80=9Ctok= en_type=E2=80=9D parameter could be optional and would define the type of to= ken being revoked (i.e. =E2=80=9Caccess=E2=80=9D, =E2=80=9Crefresh=E2=80=9D,= =E2=80=9Cregistration access=E2=80=9D, etc.). > =20 > The ESPI Standard was developed to support the Advanced Meter Interface (A= MI) which is the interface used by =E2=80=9CSmart Meters=E2=80=9D to provide= automated energy usage collection and other operational information about a= Retail Customer=E2=80=99s residence to their Data Custodian. Third Party a= pplications will be required to obtain the approval if each Retail Customer t= hat has had a =E2=80=9CSmart Meter=E2=80=9D installed before they will be ab= le to access the data provided by their =E2=80=9CSmart Meter=E2=80=9D. The n= umber of =E2=80=9CSmart Meters=E2=80=9D currently installed at the three lar= gest California utilities (Pacific Gas & Electric, Southern California Ediso= n, and San Diego Gas & Electric) is in excess of 10.0 M and growing. The fo= llowing table indicates the number of =E2=80=9CSmart Meters=E2=80=9D each of= the three utilities had installed as of May 2012: > =20 > Utility > =E2=80=9CSmart Meters=E2=80=9D 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 > =20 > The numbers in the chart were taken from the =E2=80=9CUtility-Scale Smart M= eter Deployments, Plans, & Proposals -- IEE Report=E2=80=9D published May 20= 12 by The Edison Foundation Institute for Electric Efficiency=E2=80=9D which= I have attached. The number of =E2=80=9CSmart Meters=E2=80=9D currently in= stalled are even larger than shown in the report as I compose this email. A= ssuming 10% of Pacific Gas & Electric=E2=80=99s Retail Customers decide to u= tilize a Third Party application (3 Third Party applications are currently s= upported and are 3 more Third Party applications are preparing to be support= ed) 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=E2= =80=99s authorization server to =E2=80=9Cautomatically=E2=80=9D determine th= e type of Token being revoked begins to negatively impact their processing c= apability. If the Token Revocation request was capable of indicating the ty= pe of Token to be revoked, the amount of time it will take PG&E=E2=80=99s au= thorization server would show a significant time savings to process the requ= est. > =20 > Authorization Server Revocation Policy > =20 > =20 > 6. Does the revocation of the access token also revoke the ref= resh token (if it was provided) ? Or is this a revocation policy decision ? > =20 > - if the token passed to the request is a refresh token and the server sup= ports access token revocation, the server SHOULD also revoke them. > - if the token passed to the request is an access token, the server may de= cide to revoke the respective refresh token as well. > =20 > I believe that if the token passed in the request is an access token, the s= erver MUST revoke any respective refresh token. Otherwise, their exist a po= tential security risk of the respective refresh token being used to gain acc= ess to the resources for which the access token was issued. It also means t= he authorization server will have potential =E2=80=9Cjunk=E2=80=9D in the re= fresh token file to search through for any additional Token Revocation reque= st. > =20 > I look forward to receiving your response. > =20 > Best regards, > Don > Donald F. Coffin > Founder/CTO > =20 > REMI Networks > 22751 El Prado Suite 6216 > Rancho Santa Margarita, CA 92688-3836 > =20 > Phone: (949) 636-8571 > Email: donald.coffin@reminetworks.com > =20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 > =20 --Apple-Mail-67BDD6D1-D210-4B99-9CA0-CC32BC500837 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Donald,

Th= anks 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, t= here is no external representation of this authorization grant (e.g a refres= h token). Instead, the actual access token is issued based on client credent= ials. Is there any correlation between the access token and the particular c= ustomer?

Please note: we highly appreciate your fee= dback as an implementer.

Best regards,
To= rsten.

Am 03.02.2013 um 21:45 schrieb "Donald F Coffin" <donald.coffin@reminetworks.c= om>:

Hi Torsten,

 

Best regar= ds,

Don=

Donald F. Coffin

Founder/CTO

=

 

REMI Networks

22751 El Prado Suite 6= 216

Rancho Santa Margarita, CA  92688-3836=

 

Phone:      (949) 6= 36-8571

Email:       donald= .coffin@reminetworks.com

 

<= p class=3D"MsoNormal">From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
Sent: Sunday, Febru= ary 03, 2013 4:20 AM
To: Donald F Coffin
Cc: 'George Fle= tcher'; 'John Adkins'; 'Scott Crowder'; 'Dave Robin'; 'John Teeter'; pmadsen@pingidentity.com; 'Edward D= enson'; 'Marty Burns'; 'Uday Verma'; 'Ray Perlner'; 'Anne Hendry'; 'Lynne Ro= doni'; oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04

=

 

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 inter= act with a Retail Customer and their energy provider.  The nature of in= teraction with the Retail Customer will utilize short interactive sessions.&= nbsp; However, the interaction with their energy provider will require the a= pplication obtain new energy information for the previous 24-hours once a da= y.  Therefore, I anticipate access_tokens will be granted for long peri= ods of time as well as any supporting refresh_tokens.  Because of the a= mount of data being exchanged between the Third Party application and the en= ergy provider, both in number of retail customers and the amount of energy m= eter data, it will be necessary to minimize the amount of =E2=80=9Cadministr= ative=E2=80=9D traffic required in the exchange.  Therefore, although I= understand the use case you described, I anticipate such an implementation w= ould be rare. 

 =

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

 

The examp= le you gave in your response demonstrating how a denial of service attack mi= ght occur is incorrect.  You said =E2=80=9Cif the AS revokes the refres= h_token when an access_token is revoked, I can steal an access_token and sen= d it to the revocation endpoint causing the real client=E2=80=99s refresh_to= ken to be revoked=E2=80=9D.  I fail to see how that could occur, since t= he AS revoked both the access_token and the refresh_token when it received t= he request to revoke the access_token.  Rather than explaining why a re= fresh_token shouldn=E2=80=99t be revoked concurrently when an access_token i= s revoked, your example does the exact opposite.  It shows why a refres= h_token should be revoked concurrently when an access_token is revoked.

 

[Don] The focus of the ESPI Standard is to provide Reta= il Customer=E2=80=99s with access to a single UsagePoint (i.e. their Smart M= eter).  Therefore an access and refresh token will be tightly correlate= d with the type and frequency of data the Smart Meter provides.  There a= re only a few reasons defined within the ESPI Standard list of use ca= ses that will require the Token Revocation request to be issued. = ; The following summarizes the situations that require a Token Revocation= request:

=C2=B7     &= nbsp;   A T= hird Party application wishes to terminate their relationship with a Retail C= ustomer.

=C2=B7      = ;   A Thir= d Party application wishes to terminate their relationship with a Data Custo= dian.

=C2=B7      &n= bsp;  A Retail C= ustomer wishes to terminate their relationship with a Third Party applicatio= n.

=C2=B7       = ;  A Retail Cus= tomer wishes to change the data (i.e. scope) a Third Party application has p= ermission to access.

In none of the above situations will it be valid to re= tain a refresh token, which I realize is implementation dependent, due to th= e nature of the ESPI Standard.

Perhaps the section on the Server=E2= =80=99s Revocation Policy should address a few of the reasons why a clie= nt may want or need to revoke a token.  The current description provide= s no consideration for the relationship between tokens and scope, although t= here clearly is a relationship.

I'm confident client or resource= owner would revoke refresh (and not access) tokens in all use cases you lis= ted above. In my opinion, access tokens are revoked only if the authorizatio= n server does not support refresh tokens and therefore uses long term access= tokens or in high-security applications.

 


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

<= /span>

 

[Don] A critical fact I omitted in my last response is the data obtai= ned on a daily basis by a Third Party application will utilize an access_tok= en obtained using the client_credentials grant_type.  Therefore no refr= esh_token will be issued with the access_token.  The ESPI Standard requ= ires the Retail Customer (resource owner) and the RS to be notified whenever= an authorization is modified or revoked by either the Third Party (client) o= r Retail Customer (resource owner).  Therefore, the tradeoff decision h= as already been made.

&nbs= p;

I personally feel that short lived access_tokens pr= ovide greater security, but in discussions with several utilities who have t= he responsibility of supporting the AS and RS functionality, they currently a= re planning on implementing long duration access_tokens.  This view may= change once the begin to implement =E2=80=9CConnect My Data=E2=80=9D soluti= ons, but that again is an implementation feature, which is beyond the scope o= f my groups current work product.

 =

I would also like to hear the opinion of other WG members on th= is topic.

 

3. If the standard OAuth spec does not provide enough con= trol, your profile of OAuth2 for the ESPI can tighten it to provide the prot= ections desired.

[Don] I am aware we can provide addition= al parameters required to integrate OAuth 2.0 with the ESPI Standa= rd by submitting those parameter values to the OAuth Parameters r= egistry. 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 pa= rt of the long living revocation RFC?

 

[D= on] My response was to the suggestion that if the OAuth specification does n= ot provide enough control then the ESPI profile of OAuth 2.0 could tighten i= t to provide the protections desired.  I assumed George meant we could a= dd additional =E2=80=9Ccompany=E2=80=9D based parameters, which requires us t= o register them with the =E2=80=9COAuth Parameter Registry=E2=80=9D.  I= meant the usage of such =E2=80=9Ccompany=E2=80=9D parameters would be short= termed.


Unde= rstood.


I do not view the need to identify th= e type of token being revoked as =E2=80=9Cshort term=E2=80=9D.  Even th= e 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, bec= ause the draft is too far along, the WG seems to prefer releasing an RFC the= y =E2=80=9Csuspect=E2=80=9D will need to be adjusted and let the implementer= s confirm their suspicions.   This seems to be a very selfish and r= ather foolish attitude given we are discussing a security protocol.  No= t to mention it would seem easier and faster to add an additional =E2=80=9Co= ptional=E2=80=9D parameter now, rather than requiring another RFC cycle. &nb= sp;A parameter I sensed in reading the archives the WG feels will very likel= y need to be added in the future.


Since this is a WG item, it is up to the WG to decide.<= /span>

 

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



regards,
Torst= en.





Thanks,
George

<= div>

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 =E2=80=9CEner= gy Service Provider Interface (ESPI) Standard =E2=80=9D published by= the North American Energy Standards Board (NAESB) in October of 2011= should be implemented.  The ESPI Standard defines how Retail Cu= stomers, 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 C= ustomer and the Data Custodian is known as =E2=80=9CDownload My Data=E2= =80=9D, which defines how a Retail Customer receives their energy informatio= n in an XML file downloaded to them by the Data Custodian.  The interfa= ce between the Third Party application and the Data Custodian is known as =E2= =80=9CConnect My Data=E2=80=9D, which defines the message exchanges b= etween 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 gran= ted the Third Party application access.

 

It i= s my responsibility within the OpenADE Task Force to document the integratio= n of the OAuth 2.0 protocol with the ESPI Standard.  Sinc= e the ESPI Standard requires Retail Customers, Third Party applicatio= ns, and Data Custodians to revoke Tokens (i.e. Access and Refresh Tokens) I a= m very interested in the =E2=80=9CToken Revocation (draft-ietf-oath-re= vocation-xx)=E2=80=9D work being done by you and your working group.=

 

Token Revocation Request=

 

The Token Revocation request has only t= he =E2=80=9Ctoken=E2=80=9D parameter with the description that the authoriza= tion server is supposed to detect the token type automatically.  I woul= d like to request that an addition parameter =E2=80=9Ctoken_type=E2=80=9D be= added to the request.  The =E2=80=9Ctoken_type=E2=80=9D parameter coul= d be optional and would define the type of token being revoked (i.e. =E2=80=9C= access=E2=80=9D, =E2=80=9Crefresh=E2=80=9D, =E2=80=9Cregistration access=E2=80= =9D, etc.).

 =

The ESPI Standard was de= veloped to support the Advanced Meter Interface (AMI) which is= the interface used by =E2=80=9CSmart Meters=E2=80=9D to provide automated e= nergy usage collection and other operational information about a Retail Cust= omer=E2=80=99s residence to their Data Custodian.  Third Party applicat= ions will be required to obtain the approval if each Retail Customer that ha= s had a =E2=80=9CSmart Meter=E2=80=9D installed before they will be able to a= ccess the data provided by their =E2=80=9CSmart Meter=E2=80=9D.  The nu= mber of =E2=80=9CSmart Meters=E2=80=9D currently installed at the three larg= est California utilities (Pacific Gas & Electric, Southern California Ed= ison, and San Diego Gas & Electric) is in excess of 10.0 M and growing.&= nbsp; The following table indicates the number of =E2=80=9CSmart Meters=E2=80= =9D each of the three utilities had installed as of May 2012:

 

<= /tr>

Utility

=E2=80=9CSmart Meters=E2=80=9D 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 t= he =E2=80=9CUtility-Scale Smart Meter Deployments, Plans, & Propos= als -- IEE Report=E2=80=9D published May 2012 by The Edison Found= ation Institute for Electric Efficiency=E2=80=9D which I have attached.&= nbsp; The number of =E2=80=9CSmart Meters=E2=80=9D currently installed are e= ven larger than shown in the report as I compose this email.  Assuming 1= 0% of Pacific Gas & Electric=E2=80=99s Retail Customers decide to utiliz= e a Third Party application (3 Third Party applications are currently suppor= ted and are 3 more Third Party applications are preparing to be supported) i= n order to support the ability to revoke a token they would be required to t= rack 500,000 access tokens and 500,000 refresh tokens.  Requiring PG&am= p;E=E2=80=99s authorization server to =E2=80=9Cautomatically=E2=80=9D determ= ine the type of Token being revoked begins to negatively impact their proces= sing 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=E2=80=99s authorization server would show a significant time savin= gs to process the request.

 

Authorizat= ion Server Revocation Policy

 

 <= /span>

      6.&nb= sp;      Does the revocation of the access t= oken also revoke the refresh token (if it was provided) ? Or is this a revoc= ation policy decision ?

 

- if the token passed to the request is a refresh token an= d the server supports access token revocation, the server SHOULD also revoke= them.
- if the token passed to the request is an access token, the serve= r may decide to revoke the respective refresh token as well.

 

I believe that if the token passed in the requ= est is an access token, the server MUST revoke any respective refresh token.=   Otherwise, their exist a potential security risk of the respective re= fresh token being used to gain access to the resources for which the access t= oken was issued.  It also means the authorization server will have pote= ntial =E2=80=9Cjunk=E2=80=9D 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

Ranc= ho Santa Margarita, CA  92688-3836

 

Phone:   &nb= sp;  (949) 636-8571

Email:       donald.coffin@reminetworks.com

 






_______________________________________________
O=
Auth mailing list
OAu=
th@ietf.org
https://www.ietf.org/mailman/listinfo/oauth<=
/pre>

 

 = ;

= --Apple-Mail-67BDD6D1-D210-4B99-9CA0-CC32BC500837--