Re: [OAUTH-WG] Access Token Response without expires_in

Eran Hammer <eran@hueniverse.com> Tue, 17 January 2012 06:37 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 295B621F85CC for <oauth@ietfa.amsl.com>; Mon, 16 Jan 2012 22:37:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.518
X-Spam-Level:
X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 S4EtgvwToUEt for <oauth@ietfa.amsl.com>; Mon, 16 Jan 2012 22:37:49 -0800 (PST)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 5B35521F85C9 for <oauth@ietf.org>; Mon, 16 Jan 2012 22:37:49 -0800 (PST)
Received: (qmail 30099 invoked from network); 17 Jan 2012 06:37:48 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 17 Jan 2012 06:37:48 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 16 Jan 2012 23:37:48 -0700
From: Eran Hammer <eran@hueniverse.com>
To: Aaron Parecki <aaron@parecki.com>, OAuth WG <oauth@ietf.org>
Date: Mon, 16 Jan 2012 23:37:44 -0700
Thread-Topic: [OAUTH-WG] Access Token Response without expires_in
Thread-Index: AczU4lpyZsOLTHMlQeCb2u0/BUYeWQAABY6w
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453A754C5B3@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E723453A754C549@P3PW5EX1MB01.EX1.SECURESERVER.NET> <E4309A9E-9BC7-4547-918A-224B6233B25C@mitre.org> <90C41DD21FB7C64BB94121FBBC2E723453A754C5B1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <CAGBSGjoajjjf+PaFE_byDxu-E4DOdhn+tPLCQVy-w1XZS878ZQ@mail.gmail.com>
In-Reply-To: <CAGBSGjoajjjf+PaFE_byDxu-E4DOdhn+tPLCQVy-w1XZS878ZQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723453A754C5B3P3PW5EX1MB01E_"
MIME-Version: 1.0
Cc: "wolter.eldering" <wolter.eldering@enovation.com.cn>
Subject: Re: [OAUTH-WG] Access Token Response without expires_in
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: Tue, 17 Jan 2012 06:37:50 -0000

Hmm. This might become too much work at this stage…

Happy for suggestions but I won’t pursue it on my own for now.

EHL

From: Aaron Parecki [mailto:aaron@parecki.com]
Sent: Monday, January 16, 2012 10:36 PM
To: OAuth WG
Cc: Richer, Justin P.; wolter.eldering; Eran Hammer
Subject: Re: [OAUTH-WG] Access Token Response without expires_in

That seems like a good idea, but then it should also be explicitly stated what to do if the server issues non-expiring tokens.

aaronpk

On Mon, Jan 16, 2012 at 10:29 PM, Eran Hammer <eran@hueniverse.com<mailto:eran@hueniverse.com>> wrote:
How do you feel about changing expires_in from OPTIONAL to RECOMMENDED?

EHL

> -----Original Message-----
> From: Richer, Justin P. [mailto:jricher@mitre.org<mailto:jricher@mitre.org>]
> Sent: Monday, January 16, 2012 7:29 PM
> To: Eran Hammer
> Cc: OAuth WG; wolter.eldering
> Subject: Re: [OAUTH-WG] Access Token Response without expires_in
>
> I think #3.
>
> #1 will be a common instance, and #2 (or its variant, a limited number of
> uses) is a different expiration pattern than time that would want to have its
> own expiration parameter name. I haven't seen enough concrete use of this
> pattern to warrant its own extension though.
>
> Which is why I vote #3 - it's a configuration issue. Perhaps we should rather
> say that the AS "SHOULD document the token behavior in the absence of this
> parameter, which may include the token not expiring until explicitly revoked,
> expiring after a set number of uses, or other expiration behavior." That's a lot
> of words here though.
>
>  -- Justin
>
> On Jan 16, 2012, at 1:53 PM, Eran Hammer wrote:
>
> > A question came up about the access token expiration when expires_in is
> not included in the response. This should probably be made clearer in the
> spec. The three options are:
> >
> > 1. Does not expire (but can be revoked) 2. Single use token 3.
> > Defaults to whatever the authorization server decides and until
> > revoked
> >
> > #3 is the assumed answer given the WG history. I'll note that in the spec,
> but wanted to make sure this is the explicit WG consensus.
> >
> > EHL
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org<mailto:OAuth@ietf.org>
> > https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth