Thanks James. > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Manger, James H > Sent: Wednesday, February 03, 2010 5:03 PM > To: OAuth WG (oauth@ietf.org) > Subject: [OAUTH-WG] Comment on draft-hammer-http-token-auth-01 > > 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 draft was just to remove the confusing bits. I am still working on it to make the plain method easier to notice. > This just isn’t necessary, it’s awful. Constructive criticism is always helpful. :-) > 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 disagree. Voiding a token to stop supporting an algorithm is perfectly reasonable and might not even require user involvement if the refresh mechanism is (adopted and) used. And if the reason for this is a broken algorithm, well, I would hope the tokens are voided, not just used with the same secret and new algorithm. I am not sure what you mean by "one app may only support SHA-1, while another only supports SHA-256". Are you suggesting something like a company with centralized token service but where each service using a different set of algorithm, but still sharing the same token across services? Sounds like a company in need of new management. > 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. This change was based directly on WG feedback. I asked two questions: 1. What should be included in the challenge? 2. Should one token be allowed to support multiple algorithms? It seems to me that were was no interest in negotiating algorithms or tokens with multiple methods. But I am happy to ask these questions again and see if people have different answers now that there is a new draft to poke at. > 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. That's another area where I feel there is no interest. The existing schemes come with too much existing deployment and expectations - that's why we are not reusing them. The token scheme is designed to always work with a server issuing tokens, even if there is no end-user. The idea of using it as a replacement for Basic auth is pretty much dead considering that requiring servers to keep plain text copies of passwords is a deal breaker. Did you reach a different conclusion from these discussions? > 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. Yeah. I had "Example Resources" before but changed it. The realm parameter needs a lot of work. > Yikes! Sorry. Didn't mean to scare you. > The 1st paragraph of the introduction confuses the “client” terminology. > “Client” is used to means an OAuth “resource owner” and OAuth “client”. Fixed. > Breaking the existing model of HTTP authentication (1 scheme per > mechanism) is the wrong approach. Not sure what you mean. EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
