Hi John, > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of John Kemp > Sent: Saturday, January 09, 2010 4:43 AM
> What is the actual reasoning behind this change? I don't understand why we > would suddenly now decide to make some whole class of implementations > non-conforming, even if there were only few deployments? I have come to the conclusion that arguments against requiring a secure channel during some portions of the protocols are irrelevant. We have been making the case that some environments will not be able to deploy OAuth if SSL/TLS is requires, but we should put that claim under the same practical scrutiny as other requirements we consider. I did a quick survey of existing implementations and every single one uses HTTPS for obtaining tokens and for PLAINTEXT requests. If someone if going to write internal implementations, they are free to change the protocol as they see fit. In such cases interop is more influenced by the internal nature of the system than the specification. But I can't come up with a single reason why we should allow, by making it a SHOULD, to implement OAuth in such an obviously insecure way (in an IETF RFC). My argument is that there is little practical difference between sending token secrets in the clear to not validating signatures. Once you open the door for someone to steal secrets, nothing else matters. My proposed language would be along the lines of "MUST use a secure channel such as TLS/SSL or another mechanism providing the same protections". This allows not using TLS/SSL when the environment provides the same protections some other way. EHL
-- You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/oauth?hl=en.
