Right now if a client with an inaccurate clock makes an OAuth call they are rejected. OAuth Problem Reporting<http://oauth.pbworks.com/ProblemReporting>includes a mechanism to send the server's concept of 'now' to the client:
The parameter named *oauth_acceptable_timestamps* consists of two numbers in decimal notation, separated by '-' (hyphen). It's the range of timestamps acceptable to the sender. That is, it means the sender will currently accept an oauth_timestamp that's not less than the first number and not greater than the second number. With that data a client can maintain a time skew value to translate localized time to the server's (reliable) time. We've found that this problem is more widespread than I would have imagined. On Wed, Mar 24, 2010 at 5:15 PM, Luke Shepard <lshep...@facebook.com> wrote: > Hey Paul, > > I was just curious, what do you mean by OAuth Problem Reporting and clock > synchronization? I'm not familiar with those. > > On Mar 24, 2010, at 4:12 PM, Paul Lindner wrote: > > > <hat roles="lurker,enduser"> > > > > Here at LinkedIn we've been following the OAuth developments and we're > all happy to see progress being made on 2.0. From our side we'd love to see > standardization of a number of defacto standards we use in our > implementation. Specifically the following: > > > > * OAuth Problem Reporting -- If we had not implemented this we would > probably had half as many devs on our platform. It's that important and > I'll contribute what I can on this. > > * Responses for throttled responses. Right now we return a 403 and add > some descriptive info that the dev ignores :) > > * Clock synchronization (covered by problem reporting somewhat..) > > * Signaling the correct authz URL to the client (currently using > xoauth_authorize_url) > > * Signaling the expiry time of the token to the client. > > * Explicit token invalidation endpoints > > * Signaling the client when a user 'declines/cancels' an authz request. > > > > I'll try to contribute to the process as my limited time allows. > > > > In any case, congrats for moving forward on this. > > > > </hat> > > > > On Mar 24, 2010, at 10:11 AM, Blaine Cook wrote: > > > >> <chair hat> > >> > >> Hi all, > >> > >> Hannes and I have discussed the results of the WG meeting, and while > >> there was a lot of good discussion that happened, it seems like the > >> next step for the WG is to buckle down and produce a stable draft that > >> incorporates all the various proposals, in particular WRAP and OAuth > >> 1.0a. David has done an excellent job with his draft, and I'd like to > >> see us follow through on that work quickly and effectively to offer > >> the various organizations who are looking to ship interoperable > >> solutions something to base their work on. > >> > >> To that end, we'd like to see Eran take up the editing work over the > next week. > >> > >> That work should be premised on re-incorporating the features from > >> WRAP that were removed in David's great start at a unified spec. > >> Dick's contributions have been invaluable towards reconciling the gap > >> between HMAC-based approaches and expiring bearer token approaches, > >> and we'd like to see that work be properly credited and evaluated > >> along with all of the other aspects of OAuth 1.0a and WRAP. > >> > >> Our hope is that soon, certainly well before the next OAuth WG meeting > >> (virtual or otherwise), we'll have a new RFC-style document that > >> satisfies the needs of everyone in the community. > >> > >> Blaine and Hannes. > >> > >> </chair hat> > >> _______________________________________________ > >> 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 > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
