On Saturday, January 9, 2010, Eran Hammer-Lahav <[email protected]> wrote: > 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. >
(Such as a vpn for example.) +1. > EHL > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > -- -- John Panzer / Google [email protected] / abstractioneer.org / @jpanzer _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
