Re: [OAUTH-WG] Token expiration

[Jonathan Sergent <[e-mail]>]

I meant n seconds from when the response was sent by the server.

On Mon, Sep 21, 2009 at 4:00 PM, Hubert Le Van Gong <[e-mail]> wrote:
> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]>
>>>> 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 <[e-mail]>
>>>>> 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
>>>>> > [e-mail]
>>>>> > https://www.ietf.org/mailman/listinfo/oauth
>>>>> >
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [e-mail]
>>>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>