Return-Path: 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 824C121F84C2 for ; Tue, 17 Jan 2012 06:22:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 vNAA-iSPZFrm for ; Tue, 17 Jan 2012 06:22:29 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id E28E721F84CF for ; Tue, 17 Jan 2012 06:22:28 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CC97021B165F; Tue, 17 Jan 2012 09:22:27 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id BA90621B1033; Tue, 17 Jan 2012 09:22:27 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.158]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.01.0339.001; Tue, 17 Jan 2012 09:22:27 -0500 From: "Richer, Justin P." To: John Bradley , Mike Jones Thread-Topic: [OAUTH-WG] Access Token Response without expires_in Thread-Index: AczUf8kvUkdgy1nHSGOm5KixWQExDAAclWSAAAQyJIAAAlXrAAAAC58AAAELx4AAAG05AAABdGKAAAD+9QAAANj2AAAIJbeA///ESZE= Date: Tue, 17 Jan 2012 14:22:27 +0000 Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E723453A754C549@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723453A754C5B1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723453A754C5B3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723453A754C5B6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B168042967394366358386@TK5EX14MBXC285.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723453A754C5B7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943663584A1@TK5EX14MBXC285.redmond.corp.microsoft.com>, <0471E0F2-DB8F-4FE3-A636-53684CDA4E6C@ve7jtb.com> In-Reply-To: <0471E0F2-DB8F-4FE3-A636-53684CDA4E6C@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.52] Content-Type: multipart/alternative; boundary="_000_B33BFB58CCC8BE4998958016839DE27E09EA57IMCMBX01MITREORG_" MIME-Version: 1.0 Cc: "wolter.eldering" , OAuth WG 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 14:22:30 -0000 --_000_B33BFB58CCC8BE4998958016839DE27E09EA57IMCMBX01MITREORG_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Information inside the token is outside of OAuth completely, so I like Eran= 's suggestion that doesn't mention how this information would be communicat= ed. However, I would like to leave it open for different expiration semanti= cs beyond expiration time. I suggest the following text (which could probab= ly use some wordsmithing): 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 provide the token = expiration behavior via other means or documentation. ________________________________ From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] on behalf of John Bra= dley [ve7jtb@ve7jtb.com] Sent: Tuesday, January 17, 2012 7:47 AM To: Mike Jones Cc: wolter.eldering; OAuth WG Subject: Re: [OAUTH-WG] Access Token Response without expires_in 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 con= figuration 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=92t conflict with the possibility o= f 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 thi= s issue. We have to document the meaning of this parameter missing. Also, t= he example of a self-contained token does not conflict with also providing = this information via the parameter whenever possible to improve interop. I=92m 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=92t work for me, as it doesn=92t mesh well with the case of the = token containing the expiration time. For instance, both SAML and JWT toke= ns can contain expiration times. In this case, the expires_in time is unne= cessary and the token may have no default expiration time and will expire e= ven 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-b= ounces@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 > wrote: Hmm. This might become too much work at this stage=85 Happy for suggestions but I won=92t 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 w= hat to do if the server issues non-expiring tokens. aaronpk On Mon, Jan 16, 2012 at 10:29 PM, Eran Hammer > 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 ra= ther > say that the AS "SHOULD document the token behavior in the absence of thi= s > parameter, which may include the token not expiring until explicitly revo= ked, > 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 sp= ec, > 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 --_000_B33BFB58CCC8BE4998958016839DE27E09EA57IMCMBX01MITREORG_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Information inside the token is outside of OAuth completely, so I li= ke Eran's suggestion that doesn't mention how this information would be com= municated. However, I would like to leave it open for different expiration semantics beyond expiration time. I= suggest the following text (which could probably use some wordsmithing):

If

          &n= bsp;     omitted, the authorization server SHOULD provide the token expiration behav= ior

          &n= bsp;     via other means or documentation.


From: oauth-bounces@ietf.org [oauth-bounc= es@ietf.org] on behalf of John Bradley [ve7jtb@ve7jtb.com]
Sent: Tuesday, January 17, 2012 7:47 AM
To: Mike Jones
Cc: wolter.eldering; OAuth WG
Subject: Re: [OAUTH-WG] Access Token Response without expires_in

I am OK with that.

The expiration time in the token is intended for the protected resourc= e.
The client inspecting the token is a potential optimization in cases w= here the JWT is not encrypted to the 
protected resource.

I think leaving it open to inspect the token or otherwise provide it i= n 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=92t conflict with t= he possibility of the expiration time being in the token.
 
          = ;            &n= bsp;            = ;            &n= bsp;            -- M= ike
 
From:<= span class=3D"Apple-converted-space"> Eran Hammer [mailto:eran@= hueniverse.com] 
Sent: Tuesday, Jan= uary 17, 2012 12:30 AM
To: Mike Jones; Aa= ron Parecki; OAuth WG
Cc: wolter.elderin= g
Subject: RE: [OAUT= H-WG] Access Token Response without expires_in
 
This is clearly not a solution as actual implementation fee= dback 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 param= eter whenever possible to improve interop.
 
I=92m going to go with adding: If omitted, the authorizatio= n server SHOULD provide the expiration time via other means or document the= default value.
 
EHL
 
From:<= span class=3D"Apple-converted-space"> Mike Jones [mailto:Michael.Jones@microsoft.com] 
Sent: Tuesday, Jan= uary 17, 2012 12:02 AM
To: Eran Hammer; A= aron Parecki; OAuth WG
Cc: wolter.elderin= g
Subject: RE: [OAUT= H-WG] Access Token Response without expires_in
 
This doesn=92t work for me, as it doesn=92t mesh well with = the case of the token containing the expiration time.  For instance, b= oth SAML and JWT tokens can contain expiration times.  In this case, the expires_in time is unnecessary and the toke= n may have no default expiration time and will expire even though not expli= citly invoked.
 
I would recommend no change to the current text, which is:<= /span>
&n= bsp;  expires_in
&n= bsp;        OPTIONAL.  The lifetime= in seconds of the access token.  For
&n= bsp;        example, the value "360= 0" denotes that the access token will
&n= bsp;        expire in one hour from the = time the response was generated.
 
          = ;            &n= bsp;            = ;            &n= bsp;            -- M= ike
 
From:<= span class=3D"Apple-converted-space"> oauth-bounces@ietf.org [mailto:oauth-bo= unces@ietf.org] On Behalf Of Eran Hamme= r
Sent: Monday, Janu= ary 16, 2012 11:20 PM
To: Aaron Parecki;= OAuth WG
Cc: wolter.elderin= g
Subject: Re: [OAUT= H-WG] Access Token Response without expires_in
 
WFM.
 
From:<= span class=3D"Apple-converted-space"> Aaron Parecki [mailto:aaron@parecki.com]&n= bsp;
Sent: Monday, Janu= ary 16, 2012 11:08 PM
To: OAuth WG
Cc: Eran Hammer; R= icher, Justin P.; wolter.eldering
Subject: Re: [OAUT= H-WG] Access Token Response without expires_in
 
Actually now I'm having seco= nd thoughts about making expires_in RECOMMENDED. Here's another attempt at = a clarification:
 
expires_in
        &nb= sp;OPTIONAL.  The lifetime in seconds of the access token.  For
        &nb= sp;example, the value "3600" denotes that the access token will
        &nb= sp;expire in one hour from the time the response was generated.
        &nb= sp;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=85
 
Happy for suggestions but I won=92t pursue it on my own for= now.
 
EHL
 
From:<= span class=3D"Apple-converted-space"> Aaron Parecki [mailto:aaron@parecki.com] 
Sent: Monday, Janu= ary 16, 2012 10:36 PM
To: OAuth WG
Cc: Richer, Justin= P.; wolter.eldering; Eran Hammer

Subject: Re: [OAUT= H-WG] Access Token Response without expires_in
 
That seems like a good idea, but then it should also be explicitly stated w= hat 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 h= ave its
> own expiration parameter name. I haven't seen enough concrete use of t= his
> 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 absenc= e of this
> parameter, which may include the token not expiring until explicitly r= evoked,
> expiring after a set number of uses, or other expiration behavior.&quo= t; 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/oa= uth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mail= man/listinfo/oauth
 
 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--_000_B33BFB58CCC8BE4998958016839DE27E09EA57IMCMBX01MITREORG_--