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 1CFB621F870F for ; Tue, 17 Jan 2012 09:03:21 -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 esd4NXMdAEWL for ; Tue, 17 Jan 2012 09:03:20 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8691821F8606 for ; Tue, 17 Jan 2012 09:03:17 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EB4F921B176C; Tue, 17 Jan 2012 12:03:16 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 8B4AC21B1760; Tue, 17 Jan 2012 12:03:16 -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 12:03:15 -0500 From: "Richer, Justin P." To: William Mills , Paul Madsen Thread-Topic: [OAUTH-WG] Access Token Response without expires_in Thread-Index: AczUf8kvUkdgy1nHSGOm5KixWQExDAAclWSAABTAkIAAB5GZAP//rNWx Date: Tue, 17 Jan 2012 17:03:15 +0000 Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E723453A754C549@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4F157659.7050701@gmail.com>, <1326819620.50670.YahooMailNeo@web31804.mail.mud.yahoo.com> In-Reply-To: <1326819620.50670.YahooMailNeo@web31804.mail.mud.yahoo.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_B33BFB58CCC8BE4998958016839DE27E09EBE7IMCMBX01MITREORG_" MIME-Version: 1.0 Cc: 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 17:03:21 -0000 --_000_B33BFB58CCC8BE4998958016839DE27E09EBE7IMCMBX01MITREORG_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It's a hint to the client so that well-behaved clients don't need to fail w= ith a limited use token to know that it's probably bad. It lets you throw i= t away and re-auth early. -- Justin ________________________________ From: William Mills [wmills@yahoo-inc.com] Sent: Tuesday, January 17, 2012 12:00 PM To: Paul Madsen; Richer, Justin P. Cc: OAuth WG Subject: Re: [OAUTH-WG] Access Token Response without expires_in Does this require an extension? That seems something easy to overload on s= cope. ________________________________ From: Paul Madsen To: "Richer, Justin P." Cc: OAuth WG Sent: Tuesday, January 17, 2012 5:23 AM Subject: Re: [OAUTH-WG] Access Token Response without expires_in Separate from the question posed here, we are seeing customer demand for on= e-time semantics, but agree with Justin that this would best belong in a de= dicated extension parameter and not the default paul On 1/16/12 10:29 PM, Richer, Justin P. wrote: I think #3. #1 will be a common instance, and #2 (or its variant, a limited number of u= ses) is a different expiration pattern than time that would want to have it= s 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 rath= er say that the AS "SHOULD document the token behavior in the absence of th= is parameter, which may include the token not expiring until explicitly rev= oked, expiring after a set number of uses, or other expiration behavior." T= hat'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 --_000_B33BFB58CCC8BE4998958016839DE27E09EBE7IMCMBX01MITREORG_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
It's a hint to the client so that well-behaved clients don't need to= fail with a limited use token to know that it's probably bad. It lets you = throw it away and re-auth early.

 -- Justin

From: William Mills [wmills@yahoo-inc.com= ]
Sent: Tuesday, January 17, 2012 12:00 PM
To: Paul Madsen; Richer, Justin P.
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Access Token Response without expires_in

Does this require an extension?  That seems something easy to ove= rload on scope.

From: Paul Madsen <paul= .madsen@gmail.com>
To: "Richer, Justin P= ." <jricher@mitre.org>
Cc: OAuth WG <oauth@iet= f.org>
Sent: Tuesday, January 17,= 2012 5:23 AM
Subject: Re: [OAUTH-WG] Ac= cess Token Response without expires_in

Separate from the question posed here, we are see= ing customer demand for one-time semantics, but agree with Justin that this= would best belong in a dedicated extension parameter and not the default

paul

On 1/16/12 10:29 PM, Richer, Justin P. wrote: 
I think #3.=0A=
=0A=
#1 will be a common instance, and #2 (or its variant, a limited number of u=
ses) is a different expiration pattern than time that would want to have it=
s own expiration parameter name. I haven't seen enough concrete use of this=
 pattern to warrant its own extension though. =0A=
=0A=
Which is why I vote #3 - it's a configuration issue. Perhaps we should rath=
er say that the AS "SHOULD document the token behavior in the absence =
of this parameter, which may include the token not expiring until explicitl=
y revoked, expiring after a set number of uses, or other expiration behavio=
r." That's a lot of words here though.=0A=
=0A=
 -- Justin=0A=
=0A=
On Jan 16, 2012, at 1:53 PM, Eran Hammer wrote:=0A=
=0A=

A question came up about the access token expiration when expires_in i=
s not included in the response. This should probably be made clearer in the=
 spec. The three options are:=0A=
=0A=
1. Does not expire (but can be revoked)=0A=
2. Single use token=0A=
3. Defaults to whatever the authorization server decides and until revoked=
=0A=
=0A=
#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.=0A=
=0A=
EHL=0A=
=0A=
=0A=
_______________________________________________=0A=
OAuth mailing list=0A=
OAuth@ietf.org=0A=
https://www.iet=
f.org/mailman/listinfo/oauth=0A=

_______________________________________________=0A=
OAuth mailing list=0A=
OAuth@ietf.org=0A=
https://www.iet=
f.org/mailman/listinfo/oauth=0A=

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


--_000_B33BFB58CCC8BE4998958016839DE27E09EBE7IMCMBX01MITREORG_--