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

Aaron Parecki <aaron@parecki.com> Tue, 17 January 2012 07:07 UTC

Return-Path: <aaron@parecki.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 A2E6B21F85E4 for <oauth@ietfa.amsl.com>; Mon, 16 Jan 2012 23:07:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.092
X-Spam-Level:
X-Spam-Status: No, score=-2.092 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 X2uJNnNP6ELg for <oauth@ietfa.amsl.com>; Mon, 16 Jan 2012 23:07:46 -0800 (PST)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADA221F85B4 for <oauth@ietf.org>; Mon, 16 Jan 2012 23:07:46 -0800 (PST)
Received: by wgbdq11 with SMTP id dq11so1073638wgb.13 for <oauth@ietf.org>; Mon, 16 Jan 2012 23:07:45 -0800 (PST)
Received: by 10.180.94.97 with SMTP id db1mr25668049wib.16.1326784063537; Mon, 16 Jan 2012 23:07:43 -0800 (PST)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx.google.com with ESMTPS id l8sm26361342wiy.5.2012.01.16.23.07.41 (version=SSLv3 cipher=OTHER); Mon, 16 Jan 2012 23:07:42 -0800 (PST)
Received: by wics10 with SMTP id s10so1937357wic.31 for <oauth@ietf.org>; Mon, 16 Jan 2012 23:07:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.180.82.41 with SMTP id f9mr25677020wiy.7.1326784061442; Mon, 16 Jan 2012 23:07:41 -0800 (PST)
Received: by 10.223.87.204 with HTTP; Mon, 16 Jan 2012 23:07:41 -0800 (PST)
In-Reply-To: <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> <90C41DD21FB7C64BB94121FBBC2E723453A754C5B3@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Mon, 16 Jan 2012 23:07:41 -0800
Message-ID: <CAGBSGjr3RbxA-CyUqBunN67zAyddLxTLbOe6Bj10eGMSRc_NUA@mail.gmail.com>
From: Aaron Parecki <aaron@parecki.com>
To: OAuth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary=f46d041826e6ad0c6b04b6b3fc1c
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 07:07:47 -0000

Actually now I'm having second thoughts about making expires_in
RECOMMENDED. Here's another attempt at a clarification:

expires_in
         OPTIONAL.  The lifetime in seconds of the access token.  For
         example, the value "3600" denotes that the access token will
         expire in one hour from the time the response was generated.
         *If omitted, the authorization server SHOULD document the*
*         default expiration time or indicate that the token will not*
*         expire until explicitly revoked.*

-aaronpk


On Mon, Jan 16, 2012 at 10:37 PM, Eran Hammer <eran@hueniverse.com> wrote:

> 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> wrote:
> ****
>
> How do you feel about changing expires_in from OPTIONAL to RECOMMENDED?
>
> EHL****
>
>
> > -----Original Message-----
> > From: Richer, Justin P. [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
> > > https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth****
>
> ** **
>