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

John Bradley <ve7jtb@ve7jtb.com> Tue, 17 January 2012 12:47 UTC

Return-Path: <ve7jtb@ve7jtb.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 9470C21F8623 for <oauth@ietfa.amsl.com>; Tue, 17 Jan 2012 04:47:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, 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 LGpHCU4wF-U4 for <oauth@ietfa.amsl.com>; Tue, 17 Jan 2012 04:47:51 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2912521F8574 for <oauth@ietf.org>; Tue, 17 Jan 2012 04:47:51 -0800 (PST)
Received: by yenr11 with SMTP id r11so1861565yen.31 for <oauth@ietf.org>; Tue, 17 Jan 2012 04:47:49 -0800 (PST)
Received: by 10.236.175.231 with SMTP id z67mr23768896yhl.23.1326804469635; Tue, 17 Jan 2012 04:47:49 -0800 (PST)
Received: from [192.168.1.210] ([190.22.86.51]) by mx.google.com with ESMTPS id y58sm36286095yhi.17.2012.01.17.04.47.43 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Jan 2012 04:47:48 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: multipart/signed; boundary="Apple-Mail=_9E0FAB29-62E3-42E5-9C40-7EAA51F05AEB"; protocol="application/pkcs7-signature"; micalg=sha1
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943663584A1@TK5EX14MBXC285.redmond.corp.microsoft.com>
Date: Tue, 17 Jan 2012 09:47:37 -0300
Message-Id: <0471E0F2-DB8F-4FE3-A636-53684CDA4E6C@ve7jtb.com>
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>
To: Mike Jones <Michael.Jones@microsoft.com>
X-Mailer: Apple Mail (2.1251.1)
Cc: "wolter.eldering" <wolter.eldering@enovation.com.cn>, OAuth WG <oauth@ietf.org>
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 12:47:52 -0000

I am OK with that.

The expiration time in the token is intended for the protected resource.
The client inspecting the token is a potential optimization in cases where the JWT is not encrypted to the 
protected resource.

I think leaving it open to inspect the token or otherwise provide it in configuration information is flexible enough.

John B.


On 2012-01-17, at 5:54 AM, Mike Jones wrote:

> 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