Agreed. I like the idea of expires_at as well. One of the first things a client is going to do after receiving the expires_in is calculate the current time plus the offset. Makes sense to eliminate one source of timing errors. On Dec 14, 2010 2:54 PM, "Paul Walker" <[email protected]> wrote: > It seems to me that expires_in suffers from the same machine time synchronization issue and additionally throws in an indeterminable time amount, while expires_at would only suffer from the former. > > ~pj > > On Dec 14, 2010, at 1:35 PM, Marius Scurtescu wrote: > >> expires_at requires very good time synchronization for all machines involved. >> >> expires_in, while not very exact, is more resilient. >> >> Marius >> >> >> >> On Tue, Dec 14, 2010 at 1:24 PM, Jitesh Bhate <[email protected]> wrote: >>> I have same question, Thanks Paul for Raising this >>> >>> Regards >>> Jitesh >>> >>> -----Original Message----- >>> From: [email protected] [mailto:[email protected]] On Behalf Of Paul Walker >>> Sent: Tuesday, December 14, 2010 4:14 PM >>> To: OAuth WG >>> Subject: [OAUTH-WG] expires_at vs expires_in >>> >>> Has there been discussion of using expires_at as an exact epoch time in seconds as opposed to expires_in which is, at best, an approximation "from the time the response was generated by the authorization server?" I apologize if this has been discussed previously. >>> >>> ~pj >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >>> > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
