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

"Lodderstedt, Torsten" <> Thu, 18 August 2011 08:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ECD9721F8A51 for <>; Thu, 18 Aug 2011 01:00:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.17
X-Spam-Status: No, score=-3.17 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wychtYevjm52 for <>; Thu, 18 Aug 2011 01:00:20 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2003C21F8A4F for <>; Thu, 18 Aug 2011 01:00:19 -0700 (PDT)
Received: from ([]) by with ESMTP; 18 Aug 2011 10:01:06 +0200
Received: from ( []) by with ESMTP; Thu, 18 Aug 2011 10:01:06 +0200
Received: from ([]) by ([]) with mapi; Thu, 18 Aug 2011 10:01:05 +0200
From: "Lodderstedt, Torsten" <>
To: Eran Hammer-Lahav <>, "" <>
Date: Thu, 18 Aug 2011 10:01:04 +0200
Thread-Topic: [OAUTH-WG] Partial set of last call comments on OAuth draft 20 from Yaron Goland
Thread-Index: AcxXpdCrqvPON2CRS72O2K03CR90kwDcgn2QAJkH2nA=
Message-Id: <>
References: <> <90C41DD21FB7C64BB94121FBBC2E72345028F2D75E@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345028F2D75E@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Accept-Language: de-DE
Content-Language: de-DE
acceptlanguage: de-DE
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-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: Thu, 18 Aug 2011 08:00:21 -0000

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

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".