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.
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?
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
