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 24AD121F859B for ; Sat, 26 Jan 2013 10:33:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] 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 vE9HfWwD4KqC for ; Sat, 26 Jan 2013 10:33:07 -0800 (PST) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.99]) by ietfa.amsl.com (Postfix) with ESMTP id 219CE21F858A for ; Sat, 26 Jan 2013 10:33:07 -0800 (PST) Received: from [91.2.78.85] (helo=[192.168.71.36]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1TzAYq-0003rM-SD; Sat, 26 Jan 2013 19:33:04 +0100 Message-ID: <51042160.5020908@lodderstedt.net> Date: Sat, 26 Jan 2013 19:33:04 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Anthony Nadalin References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080208090605020503050009" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review 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: Sat, 26 Jan 2013 18:33:10 -0000 This is a multi-part message in MIME format. --------------080208090605020503050009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Tony, thanks for your review comments. *** @Justin: thanks for jumping in. *** I would like to recap the results of the discussion so far and propose some changes. Am 24.01.2013 00:54, schrieb Anthony Nadalin: > > Review: > > 1.Since not stated I assume that the Revocation Endpoint can exist on > a different server from the Authorization server (or is it assumed > that they are 1), if so how is the Revocation Endpoint found? > Having read your arguments I realize the current text is a bit specific about the means to obtain the endpoint location (as it does not mention other means). current text: The location of the token revocation endpoint can be found in the authorization server's documentation. The token endpoint URI MAY include a query component. proposal: The means to obtain the location of the revocation endpoint is out of scope of this specification. There is a range of options. The client could, for example, automatically discover this information (along with other server andpoints and properties). Alternatively, the client developer could also get to know the endpoint location from the server's documentation. Note: As this endpoint is handling security sensible credentials, such information must be obtained from a trustworthy resource. > 2.Any token type that is supported can be revoked, including refresh > token ? > The draft currently explicitly states support for access and refresh tokens. Do you want the draft to be weaker at this point and to allow for the revocation of any token? > 3.Why does one have to send the token, can't this just be an auth_code ? > The draft is intended to support token revocation. I agree with Justin. Authz codes are short duration and one time use. I don't see a need to revoke them. I also don't see the need to use them to revoke the respective access token indirectly. > 4.Says CORS SHOULD be supported, I think a MAY be better here since a > site may have issues supporting CORS > I'm fine with MAY since I tend to see CORS as an optional feature. What do others think? > 5.Does not say but is the revocation to be immediate upon the return > of the request ? > The client must assume the revocation is immediate upon the return of the request. I could explicitly express this in the text current text In the next step, the authorization server invalidates the token. The client MUST NOT use this token again after revocation. Proposal In the next step, the authorization server invalidates the token. The client must assume the revocation is immediate upon the return of the request. The client MUST NOT use the token again after the revocation. > 6.Does the revocation of the access token also revoke the refresh > token (if it was provided) ? Or is this a revocation policy decision ? > As described by Justin, there are two use cases: - 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 think every client must be prepared to cope with "sudden" invalidation of any token type. So having different server policies with respect to related tokens shouldn't create interop problems. What changes would you expect? > 7.Section 2 says "the client MUST NOT use this token again", well that > seems odd, not sure this should be here as the client could try to use > it gain, there is no need to put support in client to prevent this. > The client should discard the token immediately after revocation. regards. Torsten. > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------080208090605020503050009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Tony,

thanks for your review comments.

*** @Justin: thanks for jumping in. ***

I would like to recap the results of the discussion so far and propose some changes.

Am 24.01.2013 00:54, schrieb Anthony Nadalin:

Review:

 

1.       Since not stated I assume that the Revocation Endpoint can exist on a different server from the Authorization server (or is it assumed that they are 1), if so how is the Revocation Endpoint found?


Having read your arguments I realize the current text is a bit specific about the means to obtain the endpoint location (as it does not mention other means).

current text:

The location of
   the token revocation endpoint can be found in the authorization
   server's documentation.  The token endpoint URI MAY include a query
   component.

proposal:
The means to obtain the location of the revocation endpoint is out of scope of this specification.

There is a range of options. The client could, for example, 
automatically discover this information (along with other server 
andpoints and properties). Alternatively, the client developer could 
also get to know the endpoint location from the server's documentation. 
Note: As this endpoint is handling security sensible credentials, such information must be obtained from a trustworthy resource.

2.       Any token type that is supported can be revoked, including refresh token ?


The draft currently explicitly states support for access and refresh tokens. Do you want the draft to be weaker at this point and to allow for the revocation of any token?

3.       Why does one have to send the token, can’t this just be an auth_code ?


The draft is intended to support token revocation. I agree with Justin. Authz codes are short duration and one time use. I don't see a need to revoke them. I also don't see the need to use them to revoke the respective access token indirectly.

4.       Says CORS SHOULD be supported, I think a MAY be better here since a site may have issues supporting CORS


I'm fine with MAY since I tend to see CORS as an optional feature. What do others think?

5.       Does not say but is the revocation to be immediate upon the return of the request ?


The client must assume the revocation is immediate upon the return of the request. I could explicitly express this in the text

current text

In the next step, the authorization server invalidates the token.
   The client MUST NOT use this token again after revocation.

Proposal
  In the next step, the authorization server invalidates the token. The 
client must assume the revocation is immediate upon the return of the 
request. The client MUST NOT use the token again after the revocation.

6.       Does the revocation of the access token also revoke the refresh token (if it was provided) ? Or is this a revocation policy decision ?


As described by Justin, there are two use cases:

- 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 think every client must be prepared to cope with "sudden" invalidation of any token type. So having different server policies with respect to related tokens shouldn't create interop problems.

What changes would you expect?

7.       Section 2 says “the client MUST NOT use this token again”, well that seems odd, not sure this should be here as the client could try to use it gain, there is no need to put support in client to prevent this.


The client should discard the token immediately after revocation.

regards.
Torsten.



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--------------080208090605020503050009--