* 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 modelIn 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 experienceIn order for your feedback to be included or considered for the next revisions it must be received by 10/2 on the oauth at ietf.org list.EHL [1] http://wiki.oauth.net/ProblemReporting _______________________________________________ OAuth mailing list OAuth at ietf.org https://www.ietf.org/mailman/listinfo/oauth
-- Mark Nottingham http://www.mnot.net/
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.