Paul, I really like your problem reporting mechanism. Although diminishing, problems with time synch and general OAuth are still prevalent with our Netflix developers.
Hans On Wed, Mar 24, 2010 at 6:26 PM, Paul Lindner <[email protected]> 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 <[email protected]> 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 >> >> [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
