Subject: [OAUTH-WG] Next Steps

From: Blaine Cook <[email-masked]>
Date: Wed, 24 Mar 2010 17:11:09 +0000

<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>

---

From: Paul Lindner <[email-masked]>
Date: Wed, 24 Mar 2010 16:12:06 -0700

<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:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Luke Shepard <[email-masked]>
Date: Wed, 24 Mar 2010 17:15:50 -0700

Hey Paul,

I was just curious, what do you mean by OAuth Problem Reporting and clock synchronization? I'm not familiar with those.

---

From: Paul Lindner <[email-masked]>
Date: Wed, 24 Mar 2010 18:26:51 -0700

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 <[email-masked]> wrote:

> Hey Paul,
>
> I was just curious, what do you mean by OAuth Problem Reporting and clock
> synchronization? I'm not familiar with those.
>
> > 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 :)

---

From: David Recordon <[email-masked]>
Date: Wed, 24 Mar 2010 19:13:25 -0700

I'm certainly supportive of this approach; Eran has shown that he's a
good editor. :)

---

From: Allen Tom <[email-masked]>
Date: Wed, 24 Mar 2010 19:31:03 -0700

In our experience at Yahoo, we¹ve found that many clients don¹t have the
right time. You¹d think that NTP would have solved this by now, but it
hasn¹t for a surprising number of clients.

Are timestamps really necessary in Oauth 2.0? In OAuth 1.0a, timestamps are
included in the signature to protect against replay attacks. This is not
really necessary in Oauth 2.0 since signatures are optional when SSL is
used.

Allen

On 3/24/10 6:26 PM, "Paul Lindner" <[email-masked]> wrote:

> 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
>> 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.
>

---

From: Brent Goldman <[email-masked]>
Date: Wed, 24 Mar 2010 20:18:22 -0700

I am also supportive of this approach.

---

From: Hans Granqvist <[email-masked]>
Date: Wed, 24 Mar 2010 20:21:02 -0700

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-masked]> wrote:
> rejected.   OAuth Problem Reporting includes a mechanism to send the

---

From: Luke Shepard <[email-masked]>
Date: Wed, 24 Mar 2010 21:46:08 -0700

This is probably a stupid question, but why do we need accurate timestamps? Why is it not sufficient to use a monotonically increasing call_id to prevent replay attacks? (this is how the Facebook sig algorithm works)

On Mar 24, 2010, at 9:28 PM, Raffi Krikorian wrote:

but timestamps are still necessary in the signature method?

On Wed, Mar 24, 2010 at 7:31 PM, Allen Tom <[email-masked]<mailto:[email-masked]>> wrote:
In our experience at Yahoo, we’ve found that many clients don’t have the right time. You’d think that NTP would have solved this by now, but it hasn’t for a surprising number of clients.

Are timestamps really necessary in Oauth 2.0? In OAuth 1.0a, timestamps are included in the signature to protect against replay attacks. This is not really necessary in Oauth 2.0 since signatures are optional when SSL is used.

Allen

On 3/24/10 6:26 PM, "Paul Lindner" <[email-masked]<http://[email-masked]/>> wrote:

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.

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

--
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi

---

From: Brian Eaton <[email-masked]>
Date: Wed, 24 Mar 2010 22:06:55 -0700

On Wed, Mar 24, 2010 at 9:46 PM, Luke Shepard <[email-masked]> wrote:
> This is probably a stupid question, but why do we need accurate timestamps?
> Why is it not sufficient to use a monotonically increasing call_id to
> prevent replay attacks? (this is how the Facebook sig algorithm works)

Monotonically increasing counters don't scale well in distributed
systems.  It is rapidly changing state that needs to be synchronously
replicated across lots of clients and servers.

(Wow, I hadn't realized that FB requires call_id to monotonically
increase.  I may have to eat my words about this not scaling well. =)

Bearer tokens eliminate the need for timestamps - authorization
servers and protected resources need roughly synchronized clocks, but
clients don't need to worry about it.

Challenge-response protocols eliminate the need for timestamps, but
add an extra round trip.

The OAuth 1.0 extension to report server-side time basically makes the
protocol fall back on challenge-response.   Folks who really can't
live with bearer tokens should probably use this approach.

Cheers,
Brian

> On Wed, Mar 24, 2010 at 7:31 PM, Allen Tom <[email-masked]> wrote:
>>
>> In our experience at Yahoo, we’ve found that many clients don’t have the
>> right time. You’d think that NTP would have solved this by now, but it
>> hasn’t for a surprising number of clients.
>>
>> Are timestamps really necessary in Oauth 2.0? In OAuth 1.0a, timestamps
>> are included in the signature to protect against replay attacks. This is not
>> 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:
>>

---

From: Subbu Allamaraju <[email-masked]>
Date: Thu, 25 Mar 2010 06:09:30 -0700

Just curious - why can't the client check the Date header?

Subbu

On Mar 24, 2010, at 6:26 PM, Paul Lindner <[email-masked]> 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.
>
>
> I was just curious, what do you mean by OAuth Problem Reporting and  
> clock synchronization? I'm not familiar with those.
>
> > 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 :)

---

From: John Kemp <[email-masked]>
Date: Thu, 25 Mar 2010 10:38:48 -0400

> 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

>> 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:
>>

---

From: Brian Eaton <[email-masked]>
Date: Thu, 25 Mar 2010 09:55:29 -0700

> Just curious - why can't the client check the Date header?

Yes, that works, but lots of clients don't realize it is possible.

---

From: Dick Hardt <[email-masked]>
Date: Thu, 25 Mar 2010 09:58:47 -0700

> Yes, that works, but lots of clients don't realize it is possible.

Do all clients have access to it?

---

From: Subbu Allamaraju <[email-masked]>
Date: Thu, 25 Mar 2010 15:26:43 -0700

> Yes, that works, but lots of clients don't realize it is possible.

In other words, this is part of HTTP, and should not have to be specified in layered protocols like OAuth.

Regards,
Subbu

---

From: Allen Tom <[email-masked]>
Date: Thu, 25 Mar 2010 15:27:35 -0700

A single client could generate multiple requests simultaneously, and have
them show up out of order.

Allen