Comments on draft-hammer-http-token-auth-01 (3 Feb 2010) after a quick read.
[http://tools.ietf.org/html/draft-hammer-http-token-auth-01] The simple bearer token mode is still buried as an exception to the request signing rules. This just isn’t necessary, it’s awful. Choosing a hash algorithm is assumed to be done when a credential is issued. It is nice crypto-hygiene to only use a given secret with a single algorithm, but it is not always sensible. One app may only support SHA-1, while another only supports SHA-256. Standard APIs may only accept an id and secret, and assume that acceptable hash algorithms are configured elsewhere in the software. Having to reissue all credentials to stop supporting an old hash algorithm will not always be practical, and looks like a substantial barrier to removing support for algorithms that get broken. I would prefer to stick with more common practise: explicitly list the MAC algorithm in a signed request; and support some algorithm negotiation when accessing a protected resource (eg by the server listing supported algorithms in a WWW-Authenticate header). This doesn’t stop a credential-issuer stating that only a specific hash alg can be used with a specific secret, it just doesn’t force this mode. There is only a spot for a single id in the protocol, not spots for separate authentication and authorization ids. The absence of both in existing authentication mechanisms is the only reason there is any concern about using those mechanisms with credentials from delegation. The example use a poor choice of realm: realm=”http://example.com/”. Realms are only meaningful in the scope of the current server. The example suggests any-old-site.com can return realm=”http://yahoo.com/” and the client will retry the request a set of token credentials issued for Yahoo services. Yikes! The 1st paragraph of the introduction confuses the “client” terminology. “Client” is used to means an OAuth “resource owner” and OAuth “client”. Breaking the existing model of HTTP authentication (1 scheme per mechanism) is the wrong approach. -- James Manger
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
