Return-Path: <paul.madsen@gmail.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 6EE0C21F86EB; Tue, 17 Jan 2012 08:48:30 -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=[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 Mc7Zo4kzZQqn;
 Tue, 17 Jan 2012 08:48:29 -0800 (PST)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com
 [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5F26921F86E1;
 Tue, 17 Jan 2012 08:48:29 -0800 (PST)
Received: by lagv3 with SMTP id v3so2755575lag.31 for <multiple recipients>;
 Tue, 17 Jan 2012 08:48:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
 h=message-id:date:from:user-agent:mime-version:to:cc:subject
 :references:in-reply-to:content-type;
 bh=S8NsG2SwYd3TJ4ujM9I6Vf6kQi9K1NbZMGAOtLMPS4M=;
 b=aWLVfXUaLwkj3OuYr/ycIVIEkLVZQ0HRi2yu9quKcm7vcOHN3hgjNRthgGIPxLDhfx
 hmYMtJaA3xBK6DUX5j/wZiCUF4+mFjBbEJMKyJ3ZH16HfHqfZW+GVvFACONvbTsHmBfx
 lqor8ydI9d4CcrwZdjEHdRB5oTD0JkgpUOBKE=
Received: by 10.112.25.99 with SMTP id b3mr3554823lbg.8.1326818907237;
 Tue, 17 Jan 2012 08:48:27 -0800 (PST)
Received: from pmadsen-mbp.local
 (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com. [72.136.168.159])
 by mx.google.com with ESMTPS id q1sm20751736lbf.15.2012.01.17.08.48.23
 (version=SSLv3 cipher=OTHER); Tue, 17 Jan 2012 08:48:25 -0800 (PST)
Message-ID: <4F15A655.4060404@gmail.com>
Date: Tue, 17 Jan 2012 11:48:21 -0500
From: Paul Madsen <paul.madsen@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
 rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: torsten@lodderstedt.net
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>
In-Reply-To: <1451834425-1326818330-cardhu_decombobulator_blackberry.rim.net-253428785-@b4.c11.bise7.blackberry>
Content-Type: multipart/alternative;
 boundary="------------030606050504060102070709"
Cc: OAuth WG <oauth@ietf.org>, oauth-bounces@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 16:48:30 -0000

This is a multi-part message in MIME format.
--------------030606050504060102070709
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

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 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>
> Sender: oauth-bounces@ietf.org
> Date: Tue, 17 Jan 2012 08:23:37
> To: Richer, Justin P.<jricher@mitre.org>
> Cc: OAuth WG<oauth@ietf.org>
> Subject: Re: [OAUTH-WG] Access Token Response without expires_in
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--------------030606050504060102070709
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <font face="Arial">Hi Torsten, yes the use case in question is
      payment-based as well. <br>
      <br>
      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?<br>
      <br>
      paul<br>
    </font><br>
    On 1/17/12 11:38 AM, <a class="moz-txt-link-abbreviated" href="mailto:torsten@lodderstedt.net">torsten@lodderstedt.net</a> wrote:
    <blockquote
cite="mid:1451834425-1326818330-cardhu_decombobulator_blackberry.rim.net-253428785-@b4.c11.bise7.blackberry"
      type="cite">
      <pre wrap="">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 <a class="moz-txt-link-rfc2396E" href="mailto:paul.madsen@gmail.com">&lt;paul.madsen@gmail.com&gt;</a>
Sender: <a class="moz-txt-link-abbreviated" href="mailto:oauth-bounces@ietf.org">oauth-bounces@ietf.org</a>
Date: Tue, 17 Jan 2012 08:23:37 
To: Richer, Justin P.<a class="moz-txt-link-rfc2396E" href="mailto:jricher@mitre.org">&lt;jricher@mitre.org&gt;</a>
Cc: OAuth WG<a class="moz-txt-link-rfc2396E" href="mailto:oauth@ietf.org">&lt;oauth@ietf.org&gt;</a>
Subject: Re: [OAUTH-WG] Access Token Response without expires_in

_______________________________________________
OAuth mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OAuth@ietf.org">OAuth@ietf.org</a>
<a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org/mailman/listinfo/oauth</a>

</pre>
    </blockquote>
  </body>
</html>

--------------030606050504060102070709--