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

From: Eran Hammer <[email-masked]>
Date: Mon, 16 Jan 2012 11:53:07 -0700

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

---

From: Eran Hammer <[email-masked]>
Date: Mon, 16 Jan 2012 11:57:28 -0700

expires_in

                OPTIONAL. The lifetime in seconds of the access token. For example, the value
                <spanx style='verb'>3600</spanx> denotes that the access token will expire in one
                hour from the time the response was generated. The authorization server SHOULD
                document its default expiration value in case the parameter is omitted.

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Eran Hammer
> Sent: Monday, January 16, 2012 10:53 AM
> To: OAuth WG
> Cc: wolter.eldering
> Subject: [OAUTH-WG] Access Token Response without expires_in
> 
> 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:
> 
> #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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: "Richer, Justin P." <[email-masked]>
Date: Tue, 17 Jan 2012 03:29:26 +0000

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

---

From: Eran Hammer <[email-masked]>
Date: Mon, 16 Jan 2012 23:29:35 -0700

How do you feel about changing expires_in from OPTIONAL to RECOMMENDED?

EHL

> From: Richer, Justin P. [mailto:[email-masked]]
> 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
> 
> > 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
> >
> >

---

From: Aaron Parecki <[email-masked]>
Date: Mon, 16 Jan 2012 22:36:26 -0800

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

---

From: Eran Hammer <[email-masked]>
Date: Mon, 16 Jan 2012 23:37:44 -0700

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:[email-masked]]
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 <[email-masked]<mailto:[email-masked]>> wrote:
How do you feel about changing expires_in from OPTIONAL to RECOMMENDED?

EHL

> From: Richer, Justin P. [mailto:[email-masked]<mailto:[email-masked]>]
> > [email-masked]<mailto:[email-masked]>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Aaron Parecki <[email-masked]>
Date: Mon, 16 Jan 2012 23:07:41 -0800

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 <[email-masked]> 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:[email-masked]]
> *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****
>
> ** **
>
> what to do if the server issues non-expiring tokens.****
>
> ** **
>
> aaronpk****
>
> ** **
>
> ****
> EHL****
> https://www.ietf.org/mailman/listinfo/oauth****
>
> ** **
>

---

From: Eran Hammer <[email-masked]>
Date: Tue, 17 Jan 2012 00:19:54 -0700

WFM.

From: Aaron Parecki [mailto:[email-masked]]
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 <[email-masked]<mailto:[email-masked]>> wrote:
Hmm. This might become too much work at this stage…

EHL

From: Aaron Parecki [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, January 16, 2012 10:36 PM
To: OAuth WG
Cc: Richer, Justin P.; wolter.eldering; Eran Hammer

aaronpk

EHL

---

From: Mike Jones <[email-masked]>
Date: Tue, 17 Jan 2012 08:01:33 +0000

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: [email-masked] [mailto:[email-masked]] 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:[email-masked]]<mailto:[mailto:[email-masked]]>
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

expires_in

-aaronpk

EHL

aaronpk

EHL

---

From: Eran Hammer <[email-masked]>
Date: Tue, 17 Jan 2012 01:30:04 -0700

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:[email-masked]]
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

                                                            -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> 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.

expires_in

-aaronpk

EHL

aaronpk

EHL

---

From: Mike Jones <[email-masked]>
Date: Tue, 17 Jan 2012 08:54:20 +0000

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:[email-masked]]
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

EHL

From: Mike Jones [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
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

                                                            -- Mike

WFM.

expires_in

-aaronpk

EHL

aaronpk

EHL

---

From: John Bradley <[email-masked]>
Date: Tue, 17 Jan 2012 09:47:37 -0300

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.

---

From: Paul Madsen <[email-masked]>
Date: Tue, 17 Jan 2012 08:23:37 -0500

Separate from the question posed here, we are seeing 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

---

From: "Richer, Justin P." <[email-masked]>
Date: Tue, 17 Jan 2012 14:22:27 +0000

Information inside the token is outside of OAuth completely, so I like Eran's suggestion that doesn't mention how this information would be communicated. 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):

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: [email-masked] [[email-masked]] on behalf of John Bradley [[email-masked]]
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.

John B.

                                                            -- Mike

EHL

                                                            -- Mike

WFM.

expires_in

-aaronpk

EHL

aaronpk

EHL

---

From: Paul Madsen <[email-masked]>
Date: Tue, 17 Jan 2012 11:48:21 -0500

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, [email-masked] 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
>
> From: Paul Madsen<[email-masked]>
> Sender: [email-masked]
> Date: Tue, 17 Jan 2012 08:23:37
> To: Richer, Justin P.<[email-masked]>
> Cc: OAuth WG<[email-masked]>

---

From: William Mills <[email-masked]>
Date: Tue, 17 Jan 2012 08:57:43 -0800 (PST)

"expires_in" is always a hint to the client about when it might expect to need to renew the token.  It's never authoritative, so it never conflicts with an expiry time in the token or any other actual mechanism to expire the token.

________________________________
 From: Mike Jones <[email-masked]>
To: Eran Hammer <[email-masked]>; Aaron Parecki <[email-masked]>; OAuth WG <[email-masked]> 
Cc: wolter.eldering <[email-masked]> 
Sent: Tuesday, January 17, 2012 12:54 AM
Subject: Re: [OAUTH-WG] Access Token Response without expires_in

 
                                                            -- Mike
 
From:Eran Hammer [mailto:[email-masked]] 
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

 
EHL
 
From:Mike Jones [mailto:[email-masked]] 
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

 
                                                            -- Mike
 
From:[email-masked] [mailto:[email-masked]] 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:[email-masked]] 
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

expires_in
 
-aaronpk

 
EHL
 
From:Aaron Parecki [mailto:[email-masked]] 
Sent: Monday, January 16, 2012 10:36 PM
To: OAuth WG
Cc: Richer, Justin P.; wolter.eldering; Eran Hammer

 
aaronpk

EHL

---

From: William Mills <[email-masked]>
Date: Tue, 17 Jan 2012 09:00:20 -0800 (PST)

Does this require an extension?  That seems something easy to overload on scope.

________________________________
 From: Paul Madsen <[email-masked]>
To: "Richer, Justin P." <[email-masked]> 
Cc: OAuth WG <[email-masked]> 
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 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. #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 [email-masked] https://www.ietf.org/mailman/listinfo/oauth 
OAuth mailing list [email-masked] https://www.ietf.org/mailman/listinfo/oauth 
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: "Richer, Justin P." <[email-masked]>
Date: Tue, 17 Jan 2012 17:03:15 +0000

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 [[email-masked]]
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

paul

I think #3.

 -- Justin

EHL

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 17 Jan 2012 18:26:53 +0100

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 <[email-masked]> schrieb:

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

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

---

From: Paul Madsen <[email-masked]>
Date: Tue, 17 Jan 2012 12:53:13 -0500

thanks Torsten, but by the same logic we could say that each RS should 
document the lifetime of tokens it will accept and so the AS need not 
send expires_in .... - why rely on implicit understanding for one-time 
tokens when we dont for those that expire based on time?

I have no particular axe-to-grind here - just hoping for a consensus 
best practice for one-time tokens

paul

On 1/17/12 12:26 PM, Torsten Lodderstedt wrote:
> 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
>
>
>
>
>     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
>
>>     Sender:[email-masked]

---

From: Paul Madsen <[email-masked]>
Date: Tue, 17 Jan 2012 12:55:54 -0500

scope sometimes feels like SAML authncontext - anything can go in there :-)

as I said to Torsten, perhaps an extension is overkill. Just looking for 
a best practice

On 1/17/12 12:00 PM, William Mills wrote:
> ------------------------------------------------------------------------
> *From:* Paul Madsen <[email-masked]>
> *To:* "Richer, Justin P." <[email-masked]>
> *Cc:* OAuth WG <[email-masked]>
> *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 one-time semantics, but agree with Justin that this would best 
> belong in a dedicated extension parameter and not the default
>
> paul
>
>>> [email-masked]  <mailto:[email-masked]>
>> [email-masked]  <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

---

From: "Richer, Justin P." <[email-masked]>
Date: Tue, 17 Jan 2012 18:59:30 +0000

By the same argument, the client can know how long the tokens are good for via API description. What we're talking about is a programmatic hint by the AS to the Client about what the token is good for. One common use is time-limited, and so provisions for that have been baked in so that everybody does it the same way. If there's enough out there to be use-limited or other bits, we should have a tiny provision to extend this in a similar fashion.

 -- Justin

________________________________
From: Torsten Lodderstedt [[email-masked]]
Sent: Tuesday, January 17, 2012 12:26 PM
To: Paul Madsen
Cc: [email-masked]; Richer, Justin P.; OAuth WG
Subject: Re: AW: Re: [OAUTH-WG] Access Token Response without expires_in

Hi Paul,

regards,
Torsten

paul

On 1/17/12 11:38 AM, [email-masked]<mailto:[email-masked]> wrote:

Hi,

regards,
Torsten.

---

From: "Richer, Justin P." <[email-masked]>
Date: Tue, 17 Jan 2012 19:00:59 +0000

Scope is a lot closer to authzcontext in concept than authncontext, since OAuth is out of the authn game.

 -- Justin

________________________________
From: [email-masked] [[email-masked]] on behalf of Paul Madsen [[email-masked]]
Sent: Tuesday, January 17, 2012 12:55 PM
To: William Mills
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Access Token Response without expires_in

as I said to Torsten, perhaps an extension is overkill. Just looking for a best practice

________________________________
From: Paul Madsen <[email-masked]><mailto:[email-masked]>
To: "Richer, Justin P." <[email-masked]><mailto:[email-masked]>
Cc: OAuth WG <[email-masked]><mailto:[email-masked]>
Sent: Tuesday, January 17, 2012 5:23 AM
Subject: Re: [OAUTH-WG] Access Token Response without expires_in

paul

I think #3.

 -- Justin

EHL

---

From: William Mills <[email-masked]>
Date: Tue, 17 Jan 2012 12:58:32 -0800 (PST)

One use tokens can also expire before they are used.  "You have 5 minutes to do this once."

Hi Paul,

regards,
Torsten

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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 18 Jan 2012 07:48:28 +0100

good point

William Mills <[email-masked]> schrieb:

_____________________________________________

Hi Paul,

regards,
Torsten

paul

---

From: Paul Madsen <[email-masked]>
Date: Wed, 18 Jan 2012 08:56:59 -0500

which argues for expressing both explicitly

On 1/17/12 3:58 PM, William Mills wrote:
> *From:* Torsten Lodderstedt [[email-masked]]
> *Sent:* Tuesday, January 17, 2012 12:26 PM
> *To:* Paul Madsen
> *Cc:* [email-masked]; Richer, Justin P.; OAuth WG
> *Subject:* Re: AW: Re: [OAUTH-WG] Access Token Response without expires_in
>
> Hi Paul,
>
>>     From: Paul Madsen<[email-masked]>  <mailto:[email-masked]>
>>     Sender:[email-masked]  <mailto:[email-masked]>
>>     To: Richer, Justin P.<[email-masked]>  <mailto:[email-masked]>
>>     Cc: OAuth WG<[email-masked]>  <mailto:[email-masked]>

---

From: Justin Richer <[email-masked]>
Date: Thu, 19 Jan 2012 12:49:50 -0500

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:
>> 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
>>
>>
>>
>>