> -----Original Message----- > From: Richard L. Barnes [mailto:rbar...@bbn.com] > Sent: Thursday, January 28, 2010 6:56 AM > So you're assuming that somewhere in the process of token issuance, the > client gets told what algorithm to use and remembers it.
Yep. > When is this assumption true? I don't see where it happens in the OAuth > delegation procedure (there's no "use this algorithm" field in responses that > issue tokens/secrets). In 1.0 it's implied. The signature method is "delivered" via the API documentation. Since 1.0 includes a single HMAC method and a single RSA, and they each use very different secrets, the token you get is already bound to an algorithm (and you know it ahead of time). As soon as we allow (and we have wide consensus that we will) more than one algorithm per family (HMAC, RSA, etc.), we need spell out which algorithm the token was created to work with. While the same secret can be used for both HMAC-SHA1 and HMAC-SHA256, this is not always true and it is better to explicitly bind the token secret (or other properties) to the cryptography used with it. > And if Token auth is being used as a general > authentication mechanism, the token secret might just be something like a > password, which the user remembers, not the UA, so the UA would need to > be informed somehow (by the user or the server) of what signing algorithm > to apply. We still don't know what this means. The previous discussion about this showed that using the token method to send human passwords is not going to improve much over Basic, other than requiring SSL. But either way, if we figure out how to use a human password to make an authenticated request, we will define a profile for it that will come with an implied token algorithm. EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
