I realize that if a completely fake phishing site, blaxo/plaxoo, got a customer_key and customer_secret from Yahoo! contacts, it is completely true that regardless of signature method, they can fool a user into participating, in an exchange that allows them to pull their contacts. However, signing with HMAC or RSA does add a layer of protection against MITM attacks (which was pointed out clearly right back in the 1.0 spec, and I assume which is why the second two signature types are specified). I guess I instinctively react negatively to a weaker option being allowed (or not discouraged) for a broader reason.
And, I think I made my 'broader reason' point poorly, let me try again: I want OAuth to be thought of as "industrial strength". This means as a community you need to at times say "we wont allow or encourage a 'good enough' approach". PLAINTEXT might be good enough for organization XYZ. But at the end of the day when XYZ gets hacked, OAuth gets a bad rep. Over the last 20 years I've seen this again and again with security protocols. Those passing judgement on a security protocol, or making decisions on whether it can be used for a purpose (often the regulator, not the enterprise) may not dig down into details of an attack and realize it was a poor implementation of a protocol, as opposed to the protocol itself. One can hardly blame them. For instance with recent coverage of "SSL vulnerabilities" one would thing SSL was screwed up, whereas it was things like continuing to use MD5 long after end of life and browser's not performing the checks they should... So all I am suggesting are some very simple principles: i) The credential issued by a SP to a consumer should require strong validation that the consumer is who they say they are, and this verification should be revalidated periodically. ii) In all SP to Consumer communications, whether directly or through a user's browser, both sides should strongly authenticate each other and establish a trusted channel which is believed by the crypto community to be secure even if the user is Dr. Evil or the user's browser is malware ridden. iii) The protocol should be open enough to allow many different ways of making (i) and (ii) happen. I am completely aware of the eternal conflict here between making adoption easy and raising the bar on security. My two cents are: raise the bar by not allowing (or discouraging) weaker forms of OAuth. Hope this helps. Thanks. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
