[Standards] HTTP Authentication with XMPP (Concern over XEP-70)

[Alex Jones]

On 20 Dec 2007, at 19:03, anders conbere wrote:

> On Dec 19, 2007 6:12 PM, Alex Jones <alex at weej.com> wrote:
>>
>> On 19 Dec 2007, at 23:56, anders conbere wrote:
>>
>>> On Dec 19, 2007 10:44 AM, Alex Jones <alex at weej.com> 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
>>