IETF Logo Mail Archive

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

Eran Hammer-Lahav <eran@hueniverse.com> Sun, 09 May 2010 20:56 UTC

Return-Path: <eran@hueniverse.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 4B3633A68E9 for <oauth@core3.amsl.com>; Sun, 9 May 2010 13:56:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.474
X-Spam-Level:
X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599]
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 ILSjfgLJuwdt for <oauth@core3.amsl.com>; Sun, 9 May 2010 13:56:55 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id AC8473A6800 for <oauth@ietf.org>; Sun, 9 May 2010 13:56:51 -0700 (PDT)
Received: (qmail 22365 invoked from network); 9 May 2010 20:56:39 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 9 May 2010 20:56:39 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sun, 9 May 2010 13:56:39 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: "Foiles, Doug" <Doug_Foiles@intuit.com>, OAuth WG <oauth@ietf.org>
Date: Sun, 09 May 2010 13:56:39 -0700
Thread-Topic: [OAUTH-WG] Autonomous clients and resource owners (editorial)
Thread-Index: AcrmIscm/BOC6W7iSh+JMT0dgGCAkgAALcx1AAY05pAAC/rNUADksrvwAWctR9AABTLR8AACRLXg
Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1A@P3PW5EX1MB01.EX1.SECURESERVER.NET>
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>
In-Reply-To: <BE42DBBC1969B541915E30C5517382D90484D100@SDGEXEVS07.corp.intuit.net>
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] 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: Sun, 09 May 2010 20:56:56 -0000

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