Here is my impression: Since the community OAuth specification allowed
the usage of PLAIN without TLS there is most likely still a lot of code
out there that uses it without any confidentiality protection (which is
obviously very insecure). (Btw, the current XMPP OAuth XEP is also
insecure...)
While the OAuth 1.0 mandated TLS before it got published as an RFC I
could imagine that deployments have not paid attention to that "tiny"
detail.
On 09/17/2012 10:10 PM, Randy Turner wrote:
PLAIN is going to be deprecated, even though TLS is pretty much ubiquitous?
Randy
Ralph Meijer <[email protected]> wrote:
On 2012-09-13 19:20, Peter Saint-Andre wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 9/11/12 4:24 PM, Lance Stout wrote:
>> It's a bit annoying that they add an extra attribute to the <auth
>> /> element, because it adds a special case to check in what would
>> ideally be a fully generic implementation. Fortunately, it doesn't
>> seem to be required for now.
>
> Namespaced attributes can also be problematic, and as an author of RFC
> 6648 I really don't like the name "X-OAUTH2".
>
> One hopes that they might eventually migrate to the standardized
> mechanism being defined at the IETF:
>
> http://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth/
In this light, the fact that X-GOOGLE-TOKEN and PLAIN will be deprecated
soonish [1] is very interesting. I'd hope we can convince them to do
this the standard way before clients have to implement their botched
version.
[1]
<http://googledevelopers.blogspot.nl/2012/09/adding-oauth-20-support-for-imapsmtp.html>
--
ralphm
