Re: [OAUTH-WG] Token expiration

In theory I'd agree with you but...
(1) there are ways of achieving reasonable clock sync nowadays
(2) usually the validity period is long enough that the clocks are
     considered roughly in sync.
(3) the n seconds means I can keep the token for a very long period
    of time and present it? Unless you meant seconds starting from
    the sender's clock, in which case we're back to the same issue.

If the token is for a sensitive resource, one can still impose a one time use...

My 2 cents,
Hubert

On Tue, Sep 22, 2009 at 12:47 AM, Jonathan Sergent <sergent@google.com> wrote:
> IMO, it's problematic that this relies on clock synchronization
> between the sender and the receiver to work.  This is a constant
> source of problems in need of debugging for us today.  Why not specify
> times like this using intervals?  "This token is valid for the next n
> seconds."
>
> On Mon, Sep 21, 2009 at 3:34 PM, Hubert Le Van Gong <hubertlvg@gmail.com> wrote:
>> An interesting example (to me at least since we use it) is the SAML token.
>> You have the ability to define three dates:
>> - IssueInstant: the time of issue of the token [required]
>> - NotBefore: time before which the token's invalid [optional]
>> - NotOnOrAfter: time after which the token becomes invalid [optional]
>>
>> All are dateTime (in UTC form).
>>
>> Thanks,
>> Hubert
>>
>>
>> On Tue, Sep 22, 2009 at 12:22 AM, Chris Messina <chris.messina@gmail.com> wrote:
>>> Seems like it'd be worth documenting existing approaches to this... what do
>>> other similar APIs do?
>>> I know I harp on this approach to technology development, but that was how
>>> OAuth was developed (for better or worse): by looking at existing practices,
>>> extracting convention, and codifying ]ideally] best practices.
>>> If this is common and working elsewhere, can't we just imitate it?
>>> Chris
>>>
>>> On Mon, Sep 21, 2009 at 2:41 PM, Hubert Le Van Gong <hubertlvg@gmail.com>
>>> wrote:
>>>>
>>>> It is obviously useful to have. In fact it's so useful I'll bet most
>>>> token format
>>>> used do include one. Having it outside the token becomes redundant then
>>>> but
>>>> maybe it's not that bad.
>>>>
>>>> BTW why not using dateTime (http://www.w3.org/TR/xmlschema-2/#dateTime)?
>>>>
>>>> Cheers,
>>>> Hubert
>>>>
>>>>
>>>> On Mon, Sep 21, 2009 at 11:25 PM, Eran Hammer-Lahav <eran@hueniverse.com>
>>>> wrote:
>>>> > Should the core spec support the ability to indicate the duration of
>>>> > token credentials? This would be an addition to the web delegation draft [1]
>>>> > in section 6 (Token Credentials) in the form of a new response parameter,
>>>> > something like:
>>>> >
>>>> > oauth_token_duration
>>>> >    The token duration specified in second from the time of the HTTP
>>>> > response timestamp.
>>>> >
>>>> > This has been consistently at the top of missing core funcationality.
>>>> >
>>>> >
>>>> > EHL
>>>> >
>>>> > [1] http://tools.ietf.org/html/draft-ietf-oauth-web-delegation-01
>>>> >
>>>> > _______________________________________________
>>>> > 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
>>>
>>>
>>>
>>> --
>>> Chris Messina
>>> Open Web Advocate
>>>
>>> Personal: http://factoryjoe.com
>>> Follow me on Twitter: http://twitter.com/chrismessina
>>>
>>> Citizen Agency: http://citizenagency.com
>>> Diso Project: http://diso-project.org
>>> OpenID Foundation: http://openid.net
>>>
>>> This email is:   [ ] shareable    [X] ask first   [ ] private
>>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>