I fully support this. I think Zachary has been questioning that
"should," too, in his recent post.
Furthermore, even if there are implementations that are not using TLS
(or SSL), I would look at it as an implementation--not
specification--problem. The specification must not have known security
holes.
Igor
Eran Hammer-Lahav wrote:
I no longer think there is a valid reason why the OAuth 1.0 specification does
not mandate using a secure channel with PLAINTEXT, and I would like to make
this change from SHOULD to MUST in the RFC draft [1].
Is there anyone using OAuth PLAINTEXT *not* over TLS/SSL? Is there a *good*
reason why the 1.0 specification should not mandate using a secure channel for
PLAINTEXT? If someone really wants to use it without, it's a free country but I
can't think of any reason.
The only reason not to make the change is if there are existing deployed use
cases where PLAINTEXT is used in such a way. If there are none after two years,
we should not allow it moving forward.
EHL
[1] http://tools.ietf.org/html/draft-hammer-oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
