IETF Logo Mail Archive

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

Igor Faynberg <igor.faynberg@alcatel-lucent.com> Thu, 18 August 2011 17:15 UTC

Return-Path: <igor.faynberg@alcatel-lucent.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 CFA4C21F8BBA for <oauth@ietfa.amsl.com>; Thu, 18 Aug 2011 10:15:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.077
X-Spam-Level:
X-Spam-Status: No, score=-6.077 tagged_above=-999 required=5 tests=[AWL=-0.678, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_MED=-4]
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 6Q2WZZVXq74w for <oauth@ietfa.amsl.com>; Thu, 18 Aug 2011 10:15:54 -0700 (PDT)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id BE5F821F8BB3 for <oauth@ietf.org>; Thu, 18 Aug 2011 10:15:47 -0700 (PDT)
Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p7IHGfA3018939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <oauth@ietf.org>; Thu, 18 Aug 2011 12:16:41 -0500 (CDT)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p7IHGf1p031577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <oauth@ietf.org>; Thu, 18 Aug 2011 12:16:41 -0500
Received: from [135.244.34.67] (faynberg.lra.lucent.com [135.244.34.67]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p7IHGe3W008715; Thu, 18 Aug 2011 12:16:41 -0500 (CDT)
Message-ID: <4E4D48F8.8050803@alcatel-lucent.com>
Date: Thu, 18 Aug 2011 13:16:40 -0400
From: Igor Faynberg <igor.faynberg@alcatel-lucent.com>
Organization: Alcatel-Lucent
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: oauth@ietf.org
References: <4E1F6AAD24975D4BA5B16804296739434A80B587@TK5EX14MBXC201.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72345028F2D75E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <63366D5A116E514AA4A9872D3C533539570852FDCA@QEO40072.de.t-online.corp> <B26C1EF377CB694EAB6BDDC8E624B6E7263DAE45@SN2PRD0302MB137.namprd03.prod.outlook.com>
In-Reply-To: <B26C1EF377CB694EAB6BDDC8E624B6E7263DAE45@SN2PRD0302MB137.namprd03.prod.outlook.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12
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
Reply-To: igor.faynberg@alcatel-lucent.com
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:15:54 -0000

+1  (against the removal)



On 8/18/2011 12:58 PM, Anthony Nadalin wrote:
> Agree,  against the removal of text
>
> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Lodderstedt, Torsten
> Sent: Thursday, August 18, 2011 1:01 AM
> To: Eran Hammer-Lahav; oauth@ietf.org
> Subject: Re: [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.
>
> 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".
>
> regards,
> Torsten.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

v2.23.0 | Report a Bug | By Email