Just curious - why can't the client check the Date header?
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
