Subject: [OAUTH-WG] Comments on draft-ietf-oauth-authentication-01

From: Ethan Jewett <[email-masked]>
Date: Sat, 19 Sep 2009 08:15:08 -0500

All,

I was able to thoroughly read through
draft-ietf-oauth-authentication-01 and my comments are below.
Apologies if calling out typos and grammar issues is out of scope of
this discussion, or if these topics have been addressed before. I've
used a couple of OAuth libraries and tracked development of the
community and IETF specs, but I'm by no means an expert on any of this
or the IETF process.

That said, these are my comments on draft-ietf-oauth-authentication-01
(http://tools.ietf.org/html/draft-ietf-oauth-authentication-01) split
up by section:

Abstract

Typo/Grammar: "such a different client or an end user" should be "such
as a different client or an end user"

Introduction

Typo/Grammar: In "Instead, the user authenticates directly with the
photo sharing service and issue the printing service
delegation-specific credentials", should be "issues"

Authenticated Requests

Typo/Grammar: In "Using these methods for delegation requires the
client to pretend it was the resource owner.", "was" should be "is",
or change the tense of the entire sentence to past.

Typo/Grammar: In "The way in which clients discovery the required
configuration is outside the scope of this specification.",
"discovery" should be "discover".

Nonce and Timestamp

Comment: We still have a requirement for a monotonically increasing
timestamp. What is the reason for this? There are two I can think of:

1. Backwards compatibility -  I'm skeptical of the backwards
compatibility argument in this case, as I thought it had been pretty
well hashed out that this requirement is impossible to implement in
large deployments (of either clients or servers). What library or
client/server implementations actually include a check on this
requirement?

2. Allow the server to discard nonces for previous timestamps - The
server can now restrict the time period after which a request is
rejected due to an old timestamp. I think this meets the need.

If there is not a good reason for this requirement, then shouldn't we
discard it.

Signature

Comment: I know there was previous discussion on the signature methods
included in the spec and optional discovery/error-messaging for
unsupported signature methods, but I don't think there was resolution.
I'm wondering if it would be possible to drop signature methods. Does
any existing provider require RSA-SHA1? (For example, Google provides
the option and used to require it, but now allows HMAC-SHA1 as well.)

Server Response

Comment: "Ensure that the nonce / timestamp / token combination has
not been used before, and MAY reject requests with stale timestamps."
- It is probably impossible to ensure that a given
nonce/timestamp/token combination has never been used before, so I
don't think it makes sense to require that a server do this, as few
servers will ever comply with the spec. I think "and MAY" should read
"or MAY" in order to alleviate this requirement.

Thanks,
Ethan

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 21 Sep 2009 13:53:44 -0700

Thanks Ethan!

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Ethan Jewett
> Sent: Saturday, September 19, 2009 6:15 AM

> "discovery" should be "discover".

Thanks.

> If there is not a good reason for this requirement, then shouldn't we

The entire section needs to be replaced with something better defined. This is one of the sections most people struggle with and there is clear value in replacing it with something that directly deals with timestamps, window for delays, and clock syncing.

> the option and used to require it, but now allows HMAC-SHA1 as well.)

Yes. I would like to see us drop the RSA method. In fact, I would like to drop all the methods and define new ones in order to allow the existing ones to continue to work as is.
 
> "or MAY" in order to alleviate this requirement.

If we define the nonce requirements better, it should be even trivial to ensure.

EHL