On 20 Dec 2007, at 20:18, anders conbere wrote:
On Dec 20, 2007 11:20 AM, Alex Jones <[EMAIL PROTECTED]> wrote:
On 20 Dec 2007, at 19:03, anders conbere wrote:
On Dec 19, 2007 6:12 PM, Alex Jones <[EMAIL PROTECTED]> wrote:
On 19 Dec 2007, at 23:56, anders conbere wrote:
On Dec 19, 2007 10:44 AM, Alex Jones <[EMAIL PROTECTED]> wrote:
I envisage going to a website, clicking "Authenticate via XMPP",
having my browser and my XMPP client do some IPC magic and prompt
me
to choose an identity (i.e. a JID) for which to authenticate as,
and
then be authenticated with the website.
These methods appear to me to be just as misguided. I don't
consider
it particularly likely that any significant portion of the
installed
browser base will include support for xmpp authentication.
This, of course, is not a requirement. Much like XEP-70's hint that
unsupporting clients can simply have their users send an "OK"
message
back, I see no problem with a "manual" token exchange (maybe even
initiated by xmpp URIs) being a fallback mechanism.
I think a
better solution would be to look at how jabber servers can begin
to
integrate a basic http endpoint for digesting http requests. At
least
in the foreseeable future in order to do authentication over the
web
we need to think of ways to work over http.
Could you clarify this point, please?
So one of the problems with XEP-0070 for use on the web that I see
is
that it needs the "client" and in this case that would be a web
browser to send authentication details to the xmpp server via xmpp.
(step 4.6 XMPP Client Confirms Request via XMPP in the spec). The
way
we've seen these clients implemented thus far is simple xmpp clients
that are extensions to browsers that provide an interface for
entering
credentials and authenticating against an xmpp server.
As I see it, this requirement removes from consideration a
majority of
web browsers, getting browser vendors to include support for that
would be an uphill battle and not one I can see being particularly
productive.
As I said, I don't see this as an issue. Every major browser supports
extensions of some form, and those that don't can simply request the
user to initiate a manual token exchange.
This is fine, but will never get traction in the larger population. If
you want users on IE6 (30% of web traffic) to be able to authenticate
to your application using xmpp, then you need to find a methodology
that works across browsers. (not only that but I'm a bit leary of web
technologies that elinks can't digest by default).
So, it's true, making an extension that does XEP-0070 isn't that hard,
and it's a good method of authentication, but I don't think you'll see
any kind of uptake in the web until it's supported without extensions
by browser by default, and the only effective way to do that is use an
http/html based authentication method.
Browsers are great http/html digesters, and there are authentication
protocols that are supported on the web, and further there are
methods
in adhoc standards that make authentication to other services, and
authorization to server api's relatively simple (OpenId, and Oauth
as
an example).
I also don't want to have to give a JS-generated form my login
credentials -- what if I'm using some fancy authentication method
with
my XMPP service? I'm already logged on with my XMPP client -- why not
just use some IPC?
In what I'm describing you wouldn't. The work flow is like this.
1) Site requests Authentication,
2) you enter your JID
3) site sends an http request to the jabber server requesting
confirmation of user identity
4) Jabber server requests user credentials
This is the broken part, the part that can be maliciously abused.
5) User enters credentials (At his own jabber server)
6) if credentials validate, jabber server posts back to the site
requesting Authentication the results (this is the classic OpenID auth
scenario)
I believe that there are amazing potentials for xmpp on the web, the
set of features that it provides are becoming a more and more common
sticking point in web development (asynchronous messaging, presence,
and relationship management) and there is high demand for a protocol
to handle these services. However in order for web developers to use
these services XMPP has to learn how to accommodate the
shortcoming of
web browsers. In particular for the cases of authentication and
authorization I think that means learning to understand some basic
http requests (a post of user credentials over ssl for instance).
As Peter said there are some questions as to whether or not this
belongs as part of an XEP, or is a server level implementation,
and I
don't have a good answer for that, but I'm all ears :-D
~ Anders
Thanks
