On Tue Jan 8 17:24:16 2008, Guenther Niess wrote:
> The point of SASL is that different protocols, including all
those > mentioned above, can use the same SASL mechanisms, so XMPP
already > can (and does, in some implementations) share the same
authentication > infrastructure with POP3 and IMAP services (as
well as with SUBMIT).
SASL is an authentification framework and it's protocol independend
to
my knowledge. I'm not sure if you understand me correct. I don't
want to authenticate my XMPP session with another XMPP session. I
want to
generalize the scheme behind XEP-0070 (see Section 4.5 and 4.6 of
XEP 70) for using with a libary and other protocols like POP3 and
IMAP.
Yes, SASL is a protocol independent protocol framework for
authentication. I don't think you mean a SASL mechanism, though - or
maybe you do, and I'm confused. :-)
XEP-0070 doesn't introduce a new mechanism, in the protocol sense, it
introduces a hack to get Basic to be used for identity assertion.
(Actually, ownership of a jid).
A new HTTP mechanism is defined in XEP-0101.
Defining a new SASL mechansim would look more like XEP-0101 than
XEP-0070 - the equivalent there would be a method for using PLAIN to
check JID ownership.
And sorry, I don't know SUBMIT.
(SMTP for submission)
> The point of XEP-0070 is for websites which wish to authenticate
that > a particular user owns a particular JID - in this respect
it's > similar to OpenID. But it also notifies the user that the
service is > being used, which is also potentially useful. The
moment you start > introducing SASL, you're well away from this
goal, since HTTP doesn't > - after much effort - do SASL.
I'm in the moment not very familiar with the use of SASL by HTTP but
I'm thinking with the apache modules [4] and [5] a first step for
the connection between them is done. But now I'm working on this.
Both these modules appear to be implementing Basic using Cyrus SASL
to validate the password. Cyrus SASL is a full SASL implementation,
in this case being used purely to check passwords, so that the same
authentication infrastructure can be used to authenticate both HTTP
and "real SASL".
> Offering email services to anyone with a valid JID seems a little
odd > to me, so maybe you could expand on your use-cases a bit
more.
My vision is you have the possibility for a single sign on to
jabber and that's it. You don't have to know all the different
usernames and passwords for the various providers and protocols.
This implies an SSO where administrators consider it so secure
they're willing to delegate authentication to it. I'd point out that
this has never occured before.
For a more practical use case, for example you use Thunderbird as
your favourite mailclient, you can use the XMPP authentification
automatically with a Thunderbird plugin similar with a XMPP plugin
for Firefox browser. And when you are at the airport and want to
check your mail via webmail you can simple do it also without
any password.
But I basically like the vision - however, within a single domain,
SSO can happen "right now" with Kerberos V, and can - potentially -
be cross-domain, as long as the administrators agree.
But that requires SASL support in HTTP to work.
Use of XEP-0070 and XEP-0101 for things like blog comments makes a
lot of sense - using it to secure email services just terrifies me.
:-)
Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
