Re: [OAUTH-WG] Request for feedback: OAuth IETF Drafts (Due 10/2)

[Mark Nottingham <[e-mail]>]

Digging up some feedback I sent privately a long while back WRT  
problem reporting (so apologies if the drafts have move on since)...

* Overall, I don't think that this is the right approach to solving
these sorts of problems (or writing a protocol generally); while there
is a place for error reporting, it's important to build more error
avoidance into the protocol so that reporting isn't necessary. Instead
of telling people what signature methods you accept after the fact,
advertise it in the challenge. Instead of telling them that they need
additional authentication in a parameter, use another challenge (or
the first one). This is more declarative, avoids round-trips, and
generally simplifies things.

* version_rejected - What's with this? If you're talking about minor
versions, changes should be backwards-compatible, so there's no need
to barf. If you're talking about major versions, you should use a
different scheme name, and let HTTP tell them that the auth scheme
isn't supported.

* parameter_absent - This is overkill; if your protocol is so complex
that you need to do this, it's a very bad sign, and only serves to
make the protocol *more* complex. Is there anything useful that a non-
human recipient can do with this?

* parameter_rejected - Unrecognised parameters should be ignored; see
Postel.

* token_revoked / token_rejected - What is the practical difference
between these, if any?

* user_refused - this seems very fuzzy.

* oauth_acceptable_timestamps - this creates a race condition. If you
really need to inform users of the window for timestamps (seems like a
security risk to me, and in any case they often won't be able to do
much about it, because any skew you see will be caused by network and
processing on both ends), use a delta (e.g., '5' = +- five seconds).

* Your parameter names are quite verbose (e.g.,
oauth_parameters_rejected); this, in combination with the fact that
there are so many, may cause the header to be too large, and in any
case is going to push some messages over packet boundaries. How about
trimming them (e.g., params_rej)?

Cheers,


On 22/09/2009, at 6:40 AM, Eran Hammer-Lahav wrote:

> http://tools.ietf.org/html/draft-ietf-oauth-authentication
> http://tools.ietf.org/html/draft-ietf-oauth-web-delegation
>
> I plan to publish new revisions of the above drafts to include:
>
> * Error codes and optional debug information
> * Cleanup of the authentication extensibility model
> * Change the version / protocol extensibility model
>
> In addition to general feedback about the drafts, I am looking for  
> specific feedback on the following items which I plan to address in  
> the next drafts:
>
> * Drop core support for the RSA-SHA1 method
> * Replace HMAC-SHA1 with HMAC-SHA256
> * Define the authentication parameters as method-specific (for  
> example, drop nonce and timestamp from PLAINTEXT)
> * The proposed Problem Reporting extension [1], its richness and  
> complexity
> * Making the HMAC signature method required for all server  
> implementations
> * Changing the delegation flow to require HTTP POST instead of  
> recommending it
> * Mandating server support for all three parameter transmission  
> methods
> * Adding a token revocation endpoint
> * Adding the ability for servers to declare their configuration  
> (methods, etc.) in the WWW-Authenticate header response
> * The value of the client credentials (Consumer Key) and feedback  
> from actual implementation experience
>
> In order for your feedback to be included or considered for the next  
> revisions it must be received by 10/2 on the [e-mail] list.
>
> EHL
>
> [1] http://wiki.oauth.net/ProblemReporting
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth


--
Mark Nottingham     http://www.mnot.net/