On Mar 25, 2010, at 9:09 AM, Subbu Allamaraju wrote: > Just curious - why can't the client check the Date header?
It can. Once it got a failed response from the first call. Regards, - johnk > > Subbu > > > On Mar 24, 2010, at 6:26 PM, Paul Lindner <lind...@inuus.com> wrote: > >> Right now if a client with an inaccurate clock makes an OAuth call they are >> rejected. OAuth Problem Reporting 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 > _______________________________________________ > 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
