IETF Logo Mail Archive

Re: [OAUTH-WG] Partial set of last call comments on OAuth draft 20 from Yaron Goland

Eran Hammer-Lahav <eran@hueniverse.com> Thu, 18 August 2011 17:20 UTC

Return-Path: <eran@hueniverse.com>
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 B363821F8B3C for <oauth@ietfa.amsl.com>; Thu, 18 Aug 2011 10:20:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.559
X-Spam-Level:
X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XX4GeKuLlNHA for <oauth@ietfa.amsl.com>; Thu, 18 Aug 2011 10:20:45 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 59D7A21F856C for <oauth@ietf.org>; Thu, 18 Aug 2011 10:20:43 -0700 (PDT)
Received: (qmail 14958 invoked from network); 18 Aug 2011 17:21:37 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 18 Aug 2011 17:21:37 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 18 Aug 2011 10:21:28 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: "Lodderstedt, Torsten" <t.lodderstedt@telekom.de>, "oauth@ietf.org" <oauth@ietf.org>
Date: Thu, 18 Aug 2011 10:20:11 -0700
Thread-Topic: [OAUTH-WG] Partial set of last call comments on OAuth draft 20 from Yaron Goland
Thread-Index: AcxXpdCrqvPON2CRS72O2K03CR90kwDcgn2QAJkH2nAAEz+pwA==
Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345029DFAA51@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <4E1F6AAD24975D4BA5B16804296739434A80B587@TK5EX14MBXC201.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72345028F2D75E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <63366D5A116E514AA4A9872D3C533539570852FDCA@QEO40072.de.t-online.corp>
In-Reply-To: <63366D5A116E514AA4A9872D3C533539570852FDCA@QEO40072.de.t-online.corp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] Partial set of last call comments on OAuth draft 20 from Yaron Goland
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Aug 2011 17:20:45 -0000

Chairs - please open an issue for this: "Clarifying reference to refresh tokens in section 1.4.3 of -20".

> -----Original Message-----
> From: Lodderstedt, Torsten [mailto:t.lodderstedt@telekom.de]
> Sent: Thursday, August 18, 2011 1:01 AM
> To: Eran Hammer-Lahav; oauth@ietf.org
> Subject: AW: [OAUTH-WG] Partial set of last call comments on OAuth draft 20
> from Yaron Goland
> 
> >> 1.4.3.  Resource Owner Password Credentials: Comment on "(when
> >> combined with a refresh token)": "This is the first time that refresh
> >> tokens are mentioned in the spec. And yet there is no explanation of
> what they are.
> >> I suspect they should anyway be introduced in section 1.4.1 (as
> >> previously
> >> noted) and then their use here will make sense.  If that isn't
> >> possible then it would be good to have a forward reference to section
> >> 1.5 below so the reader has some idea of what's going on."
> 
> >I removed '(when combined with a refresh token)'. This is actually not true
> as there is no assumption that >access tokens are always short-lived or that
> refresh tokens will always be issued to native applications using >this grant
> type.
> 
> -1 against removing this text (w/o an suitable replacement) and w/o group
> consent.

Since you felt it necessary to make this a process issue, I've asked the chairs to open a ticket.

> The -20 text clearly points out that this combination "... eliminates the need
> for the client to store the resource owner credentials for future use". The
> resource owner grant type alone does not justify this statement.
> It's true that the spec does not explicitly defines the lifetime assumption for
> access and refresh tokens (which is pity in my opinion). So at least add
> something like "if the token lifetime is reasonable long enough".

How about:

   This grant type can eliminates the need for the client to store the resource owner
   credentials for future use, by exchanging the credentials with a long-lived access
   token or refresh token.

As for Yaron's original comment, I think this text is sufficient and no forward reference is needed to 1.5 (which is a few lines lower in the same page). Also, with the new organization proposed by Justin, the access token term isn't full defined yet either and it reads just fine.

EHL

v2.23.0 | Report a Bug | By Email