IETF Logo Mail Archive

Re: [OAUTH-WG] Autonomous clients and resource owners (editorial)

"Foiles, Doug" <Doug_Foiles@intuit.com> Mon, 10 May 2010 16:05 UTC

Return-Path: <Doug_Foiles@intuit.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0FF03A69A0 for <oauth@core3.amsl.com>; Mon, 10 May 2010 09:05:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.097
X-Spam-Level:
X-Spam-Status: No, score=-5.097 tagged_above=-999 required=5 tests=[AWL=1.502, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6dTdJ64DYIc for <oauth@core3.amsl.com>; Mon, 10 May 2010 09:05:20 -0700 (PDT)
Received: from mail2.intuit.com (mail2.intuit.com [12.149.175.12]) by core3.amsl.com (Postfix) with ESMTP id 271A23A67CC for <oauth@ietf.org>; Mon, 10 May 2010 09:05:20 -0700 (PDT)
DomainKey-Signature: s=default; d=intuit.com; c=nofws; q=dns; h=X-SBRS:X-IronPort-AV:Received:Received:X-MimeOLE: Content-class:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:Date:Message-ID: In-Reply-To:X-MS-Has-Attach:X-MS-TNEF-Correlator: Thread-Topic:Thread-Index:References:From:To:Return-Path: X-OriginalArrivalTime; b=looQ4dlbnFo+VUgZq382O+pJrkGAQhbkjlqgv46OFc+Qyw4Uj4Bz4R66 VhkhZ/HauAVSUml0YO4UUbQyPQpevobmgJOZZ4HXdQFwc7JO6Hpkhy9cw 7jwn/MlcP58PA95;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=intuit.com; i=Doug_Foiles@intuit.com; q=dns/txt; s=default; t=1273507509; x=1305043509; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; z=MIME-Version:=201.0|Content-Transfer-Encoding:=20base64 |Subject:=20RE:=20[OAUTH-WG]=20Autonomous=20clients=20and =20resource=20owners=20(editorial)|Date:=20Mon,=2010=20Ma y=202010=2009:05:03=20-0700|Message-ID:=20<BE42DBBC1969B5 41915E30C5517382D90484D1FE@SDGEXEVS07.corp.intuit.net> |In-Reply-To:=20<90C41DD21FB7C64BB94121FBBC2E72343B3AB46E 1A@P3PW5EX1MB01.EX1.SECURESERVER.NET>|References:=20<5DEB 74B3E9FA574EAA911DB8167C559E04425EBE@SDGEXEVS12.corp.intu it.net><C7FCD375.4675%cmortimore@salesforce.com>=20<BE42D BBC1969B541915E30C5517382D9047A164D@SDGEXEVS07.corp.intui t.net>=20<90C41DD21FB7C64BB94121FBBC2E72343B3AB46E0C@P3PW 5EX1MB01.EX1.SECURESERVER.NET>=20<BE42DBBC1969B541915E30C 5517382D90484D100@SDGEXEVS07.corp.intuit.net>=20<90C41DD2 1FB7C64BB94121FBBC2E72343B3AB46E1A@P3PW5EX1MB01.EX1.SECUR ESERVER.NET>|From:=20"Foiles,=20Doug"=20<Doug_Foiles@intu it.com>|To:=20"Eran=20Hammer-Lahav"=20<eran@hueniverse.co m>,=0D=0A=09"OAuth=20WG"=20<oauth@ietf.org>; bh=1b5cXWw0rx6mYAXqIceEiJ/8dwnsfvdTHbPh2HK8gNE=; b=TLyHmmfJiIVGZZ3bt6bLwQS6EuGWttmYQmCY5uIsMLQWUStgbDJdO9bA tl+0iHALikqun71cBq5QuGWIubDbOjtvBGJRDUBKM5rw069iN9x4g5/CG ypfHN/49XXq/fn9;
X-SBRS: None
X-IronPort-AV: E=Sophos;i="4.52,362,1270450800"; d="scan'208";a="183805439"
Received: from sdgexbh03.corp.intuit.net ([172.17.135.77]) by mail2.sdg.ie.intuit.com with ESMTP; 10 May 2010 09:05:04 -0700
Received: from SDGEXEVS07.corp.intuit.net ([172.17.135.1]) by SDGEXBH03.corp.intuit.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 May 2010 09:05:03 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Date: Mon, 10 May 2010 09:05:03 -0700
Message-ID: <BE42DBBC1969B541915E30C5517382D90484D1FE@SDGEXEVS07.corp.intuit.net>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1A@P3PW5EX1MB01.EX1.SECURESERVER.NET>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [OAUTH-WG] Autonomous clients and resource owners (editorial)
Thread-Index: AcrmIscm/BOC6W7iSh+JMT0dgGCAkgAALcx1AAY05pAAC/rNUADksrvwAWctR9AABTLR8AACRLXgACgwRrA=
References: <5DEB74B3E9FA574EAA911DB8167C559E04425EBE@SDGEXEVS12.corp.intuit.net><C7FCD375.4675%cmortimore@salesforce.com> <BE42DBBC1969B541915E30C5517382D9047A164D@SDGEXEVS07.corp.intuit.net> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E0C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <BE42DBBC1969B541915E30C5517382D90484D100@SDGEXEVS07.corp.intuit.net> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1A@P3PW5EX1MB01.EX1.SECURESERVER.NET>
From: "Foiles, Doug" <Doug_Foiles@intuit.com>
To: Eran Hammer-Lahav <eran@hueniverse.com>, OAuth WG <oauth@ietf.org>
X-OriginalArrivalTime: 10 May 2010 16:05:03.0997 (UTC) FILETIME=[8D3082D0:01CAF05A]
Subject: Re: [OAUTH-WG] Autonomous clients and resource owners (editorial)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Mon, 10 May 2010 16:05:22 -0000

Thanks for the clarity Eran and I understand.

-----Original Message-----
From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] 
Sent: Sunday, May 09, 2010 1:57 PM
To: Foiles, Doug; OAuth WG
Subject: RE: [OAUTH-WG] Autonomous clients and resource owners (editorial)



> -----Original Message-----
> From: Foiles, Doug [mailto:Doug_Foiles@intuit.com]
> Sent: Sunday, May 09, 2010 1:07 PM
> To: Eran Hammer-Lahav; OAuth WG
> Subject: RE: [OAUTH-WG] Autonomous clients and resource owners
> (editorial)
> 
> Thanks for addressing my questions Eran.
> 
> For the Assertion Flow I would assume the lifetime of the authorization grant
> would be the same with or without the refresh token support.  It doesn't
> seem to me like the overall lifetime of the authorization grant would change
> based upon the use of the refresh token.

You have three expirations:

- The assertion
- The access token
- The refresh token (if present)

The authorization server can issue an access token with any expiration but should not issue expiration later than that of the assertion. But still, there is nothing to prevent that. The authorization server may issue an access token with a shorter expiration than the assertion. In that case, it can require the use of the same assertion again to get another token, or it can issue a refresh token to accomplish the same thing.

I reject the argument that the expiration policy (and getting it implemented correctly) has much to do with making a refresh token available to the server as a tool.

EHL

v2.23.0 | Report a Bug | By Email