Re: [OAUTH-WG] Access Token Response without expires_in
Justin Richer <jricher@mitre.org> Thu, 19 January 2012 17:50 UTC
Return-Path: <jricher@mitre.org>
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 84C7521F86C6 for <oauth@ietfa.amsl.com>; Thu, 19 Jan 2012 09:50:49 -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 RDRvkGfJrEYl for <oauth@ietfa.amsl.com>; Thu, 19 Jan 2012 09:50:48 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFA621F854C for <oauth@ietf.org>; Thu, 19 Jan 2012 09:50:48 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D74FA21B053B for <oauth@ietf.org>; Thu, 19 Jan 2012 12:50:47 -0500 (EST)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id B61CA21B1534 for <oauth@ietf.org>; Thu, 19 Jan 2012 12:50:47 -0500 (EST)
Received: from [129.83.50.12] (129.83.31.51) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.1.339.1; Thu, 19 Jan 2012 12:50:47 -0500
Message-ID: <4F1857BE.4090803@mitre.org>
Date: Thu, 19 Jan 2012 12:49:50 -0500
From: Justin Richer <jricher@mitre.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0
MIME-Version: 1.0
To: oauth@ietf.org
References: <90C41DD21FB7C64BB94121FBBC2E723453A754C549@P3PW5EX1MB01.EX1.SECURESERVER.NET> <E4309A9E-9BC7-4547-918A-224B6233B25C@mitre.org> <4F157659.7050701@gmail.com> <1451834425-1326818330-cardhu_decombobulator_blackberry.rim.net-253428785-@b4.c11.bise7.blackberry> <4F15A655.4060404@gmail.com>, <2fc6806a-8a15-4b97-87f2-3c0c0cbd3623@email.android.com> <B33BFB58CCC8BE4998958016839DE27E09EC78@IMCMBX01.MITRE.ORG> <1326833912.76041.YahooMailNeo@web31813.mail.mud.yahoo.com> <4F16CFAB.5010506@gmail.com>
In-Reply-To: <4F16CFAB.5010506@gmail.com>
Content-Type: multipart/alternative; boundary="------------080501090004090607000206"
X-Originating-IP: [129.83.31.51]
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: Thu, 19 Jan 2012 17:50:49 -0000
Precisely, and without a strong consensus of use in practice today, getting the semantics right around a new parameter (even if optional) doesn't make sense this late in the game. The information in the token response is easily extensible by other documents, and it should go there if people really want it to go there. -- Justin On 01/18/2012 08:56 AM, Paul Madsen wrote: > which argues for expressing both explicitly > > On 1/17/12 3:58 PM, William Mills wrote: >> >> One use tokens can also expire before they are used. "You have 5 >> minutes to do this once." >> >> ------------------------------------------------------------------------ >> *From:* Torsten Lodderstedt [torsten@lodderstedt.net] >> *Sent:* Tuesday, January 17, 2012 12:26 PM >> *To:* Paul Madsen >> *Cc:* oauth-bounces@ietf.org; Richer, Justin P.; OAuth WG >> *Subject:* Re: AW: Re: [OAUTH-WG] Access Token Response without >> expires_in >> >> Hi Paul, >> >> that's not what I meant. The Client should know which tokens should >> be one time usage based on the API description. The authz server must >> not return expires_in because this would not make any sense in this case. >> >> regards, >> Torsten >> >> >> >> >> Paul Madsen <paul.madsen@gmail.com> schrieb: >> >> Hi Torsten, yes the use case in question is payment-based as well. >> >> Your suggestion for the client to infer one-time usage from a >> missing expires_in contradicts the general consensus of this >> thread does it not? >> >> paul >> >> On 1/17/12 11:38 AM, torsten@lodderstedt.net >> <mailto:torsten@lodderstedt.net> wrote: >>> Hi, >>> >>> isn't one-time semantics typically associated with certain requests on certain resources/resource types. I therefore would assume the client to know which tokens to use one-time only. The authz server should not return an expires_in paramter. We for example use one time access tokens for payment transactions. >>> >>> What would such an extension specify? >>> >>> regards, >>> Torsten. >>> Gesendet mit BlackBerry® Webmail von Telekom Deutschland >>> >>> -----Original Message----- >>> From: Paul Madsen<paul.madsen@gmail.com> <mailto:paul.madsen@gmail.com> >>> Sender:oauth-bounces@ietf.org <mailto:oauth-bounces@ietf.org> >>> Date: Tue, 17 Jan 2012 08:23:37 >>> To: Richer, Justin P.<jricher@mitre.org> <mailto:jricher@mitre.org> >>> Cc: OAuth WG<oauth@ietf.org> <mailto:oauth@ietf.org> >>> Subject: Re: [OAUTH-WG] Access Token Response without expires_in >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
- Re: [OAUTH-WG] Access Token Response without expi… Aaron Parecki
- [OAUTH-WG] Access Token Response without expires_… Eran Hammer
- Re: [OAUTH-WG] Access Token Response without expi… Eran Hammer
- Re: [OAUTH-WG] Access Token Response without expi… Richer, Justin P.
- Re: [OAUTH-WG] Access Token Response without expi… Eran Hammer
- Re: [OAUTH-WG] Access Token Response without expi… Aaron Parecki
- Re: [OAUTH-WG] Access Token Response without expi… Eran Hammer
- Re: [OAUTH-WG] Access Token Response without expi… Eran Hammer
- Re: [OAUTH-WG] Access Token Response without expi… Mike Jones
- Re: [OAUTH-WG] Access Token Response without expi… Eran Hammer
- Re: [OAUTH-WG] Access Token Response without expi… Mike Jones
- Re: [OAUTH-WG] Access Token Response without expi… John Bradley
- Re: [OAUTH-WG] Access Token Response without expi… Paul Madsen
- Re: [OAUTH-WG] Access Token Response without expi… Richer, Justin P.
- Re: [OAUTH-WG] Access Token Response without expi… Richer, Justin P.
- Re: [OAUTH-WG] Access Token Response without expi… Paul Madsen
- Re: [OAUTH-WG] Access Token Response without expi… William Mills
- Re: [OAUTH-WG] Access Token Response without expi… William Mills
- Re: [OAUTH-WG] Access Token Response without expi… Richer, Justin P.
- Re: [OAUTH-WG] Access Token Response without expi… Torsten Lodderstedt
- Re: [OAUTH-WG] Access Token Response without expi… Paul Madsen
- Re: [OAUTH-WG] Access Token Response without expi… Paul Madsen
- Re: [OAUTH-WG] Access Token Response without expi… Richer, Justin P.
- Re: [OAUTH-WG] Access Token Response without expi… William Mills
- Re: [OAUTH-WG] Access Token Response without expi… Torsten Lodderstedt
- Re: [OAUTH-WG] Access Token Response without expi… Paul Madsen
- Re: [OAUTH-WG] Access Token Response without expi… Justin Richer