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

William Mills <wmills@yahoo-inc.com> Tue, 17 January 2012 16:57 UTC

Return-Path: <wmills@yahoo-inc.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 5B48521F8699 for <oauth@ietfa.amsl.com>; Tue, 17 Jan 2012 08:57:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.338
X-Spam-Level:
X-Spam-Status: No, score=-17.338 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15]
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 ryMJytAlBlrQ for <oauth@ietfa.amsl.com>; Tue, 17 Jan 2012 08:57:45 -0800 (PST)
Received: from nm2-vm0.bullet.mail.sp2.yahoo.com (nm2-vm0.bullet.mail.sp2.yahoo.com [98.139.91.248]) by ietfa.amsl.com (Postfix) with SMTP id 36C5911E8081 for <oauth@ietf.org>; Tue, 17 Jan 2012 08:57:45 -0800 (PST)
Received: from [98.139.91.66] by nm2.bullet.mail.sp2.yahoo.com with NNFMP; 17 Jan 2012 16:57:45 -0000
Received: from [98.139.91.12] by tm6.bullet.mail.sp2.yahoo.com with NNFMP; 17 Jan 2012 16:57:45 -0000
Received: from [127.0.0.1] by omp1012.mail.sp2.yahoo.com with NNFMP; 17 Jan 2012 16:57:45 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 127421.87354.bm@omp1012.mail.sp2.yahoo.com
Received: (qmail 63558 invoked by uid 60001); 17 Jan 2012 16:57:44 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1326819464; bh=ajP7I8CFMhMwPwQCGaBprgSxL+ICE6KJe/cxvVeqLlg=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=NDUyyjN0FKkpxXQuP4qyHLacD5BDfY5dVDn+eyXbo3qF8RKT+xMFxlLYrJzbRA9WkOuplHBdeR3xfMa9OZIsiorPJSjMwr2+LVrbYjk6+lCBDiLAVaEYgPSsUxpltKice9rJ65T3ey+JsXE8ZnvLumkSayypt2yKFPD+d6cviVM=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=aTYw+D2icYj/vNJn8rRWR1FtV1cdJDmPiU40/k0ZF14caWfsB7Y8bYnfLQERrs4PbUV42lnyRo66NUNbIoe/C6Rc9SfdAx0DZDs8yHg1cq4eAf7AV5kLFrdng764JZmsWz5KSl7WZlpQgAi1CHulhbN1W1ttVjRQ233uVboC9kI=;
X-YMail-OSG: 7abCnFEVM1leoKrn8x5AFvRMq7gri_UV_7rSRZhCrQNKPFh m5zODl6de4sdWjlfx5waiSRigrE8ajrbd8jSFXQhQIeAdotejzw7zawpCY_e V89pWq3145rKMEgJhDmr91Lm4c5mZM8JMHzoKYdroZDVn4DWe6lxHB5e7OY8 HbenVynnNYxl.t52GGvaQa8NfMzdP8pw9DxjwW9L9aLpvyp2Ix8Jb2tVq9xj 8bsqgZLMO6Z2MYT310KGJ_0I9fC0dHC27cmoZGpC7JFS2iLouQI9yYYfIZC9 GSGUI5d3cVSfnRUcXKN5PKfBJp128lbtJgO7HCbkhI.cOcHVo0r8fsR.5kZv rTxIIPxA9MX7B93m7dhBDMaYIHXdRBlvsrTwAcCDN709HQ3rAhfFd5kTrZxz I7fxRlpTzyqc-
Received: from [99.31.212.42] by web31801.mail.mud.yahoo.com via HTTP; Tue, 17 Jan 2012 08:57:43 PST
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.116.331537
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> <CAGBSGjr3RbxA-CyUqBunN67zAyddLxTLbOe6Bj10eGMSRc_NUA@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E723453A754C5B6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B168042967394366358386@TK5EX14MBXC285.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723453A754C5B7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943663584A1@TK5EX14MBXC285.redmond.corp.microsoft.com>
Message-ID: <1326819463.63513.YahooMailNeo@web31801.mail.mud.yahoo.com>
Date: Tue, 17 Jan 2012 08:57:43 -0800 (PST)
From: William Mills <wmills@yahoo-inc.com>
To: Mike Jones <Michael.Jones@microsoft.com>, Eran Hammer <eran@hueniverse.com>, Aaron Parecki <aaron@parecki.com>, OAuth WG <oauth@ietf.org>
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943663584A1@TK5EX14MBXC285.redmond.corp.microsoft.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-368338466-1994465251-1326819463=:63513"
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
Reply-To: William Mills <wmills@yahoo-inc.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: Tue, 17 Jan 2012 16:57:46 -0000

"expires_in" is always a hint to the client about when it might expect to need to renew the token.  It's never authoritative, so it never conflicts with an expiry time in the token or any other actual mechanism to expire the token.



________________________________
 From: Mike Jones <Michael.Jones@microsoft.com>
To: Eran Hammer <eran@hueniverse.com>om>; Aaron Parecki <aaron@parecki.com>om>; OAuth WG <oauth@ietf.org> 
Cc: wolter.eldering <wolter.eldering@enovation.com.cn> 
Sent: Tuesday, January 17, 2012 12:54 AM
Subject: Re: [OAUTH-WG] Access Token Response without expires_in
 

 
Your new wording is better, as it doesn’t conflict with the possibility of the expiration time being in the token.
 
                                                            -- Mike
 
From:Eran Hammer [mailto:eran@hueniverse.com] 
Sent: Tuesday, January 17, 2012 12:30 AM
To: Mike Jones; Aaron Parecki; OAuth WG
Cc: wolter.eldering
Subject: RE: [OAUTH-WG] Access Token Response without expires_in
 
This is clearly not a solution as actual implementation feedback raised this issue. We have to document the meaning of this parameter missing. Also, the example of a self-contained token does not conflict with also providing this information via the parameter whenever possible to improve interop.
 
I’m going to go with adding: If omitted, the authorization server SHOULD provide the expiration time via other means or document the default value.
 
EHL
 
From:Mike Jones [mailto:Michael.Jones@microsoft.com] 
Sent: Tuesday, January 17, 2012 12:02 AM
To: Eran Hammer; Aaron Parecki; OAuth WG
Cc: wolter.eldering
Subject: RE: [OAUTH-WG] Access Token Response without expires_in
 
This doesn’t work for me, as it doesn’t mesh well with the case of the token containing the expiration time.  For instance, both SAML and JWT tokens can contain expiration times.  In this case, the expires_in time is unnecessary and the token may have no default expiration time and will expire even though not explicitly invoked.
 
I would recommend no change to the current text, which is:
   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.
 
                                                            -- Mike
 
From:oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer
Sent: Monday, January 16, 2012 11:20 PM
To: Aaron Parecki; OAuth WG
Cc: wolter.eldering
Subject: Re: [OAUTH-WG] Access Token Response without expires_in
 
WFM.
 
From:Aaron Parecki [mailto:aaron@parecki.com] 
Sent: Monday, January 16, 2012 11:08 PM
To: OAuth WG
Cc: Eran Hammer; Richer, Justin P.; wolter.eldering
Subject: Re: [OAUTH-WG] Access Token Response without expires_in
 
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
 
 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth