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

[Maciek Niedzielski]

Guenther Niess wrote:
>> I was just chatting about this with Maciek Niedzielski and he suggested 
>> a different kind of workflow for XEP-0070-like functionality
> But some problems are still there. 
> 
> 1. If you want to use the authorization service, you have to use a 
>    client that support that protocoll.
I think that there are more clients out there that support sending a 
plain message than clients that support XEP-0070 ;)
But I guess what you wanted to say is that a client needs to support 
xmpp URI to make this work. So I can say two things:
1. I am almost sure that supporting XMPP URI is more important than 
XEP-0070 for every client developer.
2. You don't really need XMPP URI here.. It just makes things easier. 
But a website can also say "If this link doesn't work for you, please 
copy the ID below and send it to auth at example.com.


> 2. I think the web based XMPP clients like meebo [1] have big problems 
>    to implement such a protocol. (This should look more a configuration
>    problem of the browser)
I think firefox3 will allow you to use web-based applications to handle 
URIs, so... at least browser world already noticed the problem.

> 4. It's not secure that the user "can't modify" information which the
>    user get from a website and send to a xmpp server, it's an illusion. 
No matter how creative you are, you cannot invent a protocol that will 
prevent this. But yes, here it would be really easy to do..

> At all I think the spam problem by another user is not as big as the
> problems you get when you can't use the authorization service. And
> at my opinion when you implement the existing XEP 70 you can help the
> user to get not such a big problem, by:
> a) for XMPP browser plugins: automated server responses don't disturb
>    the user
That's a bit unfair to compare XEP-0070 with dedicated browser support 
with my approach in a standard browser.
(And as as side note, it is easier to write firefox extension that will 
support xmpp: URI and do something smart about it, even open your 
web-based XMPP client, than to hack a special treatment for HTTP 
authorization with "xmpp" realm).

> b) other clients: caching decisions and delimit user requests at a 
>    session can help.
Caching decisions? If you read XEP-0070, it is essential that you must 
always check if the transaction id is the same as the one entered in 
your web browser. You cannot assume that if you confirmed one request to 
example.org 5 seconds ago, the next one can also be confirmed - because 
this may be a person standing behind you trying to access the same 
website at the same time.

> c) for servers: saving denys in combination with the request ip can
>    help to locate spammer and exclude them
Every time you start banning by IPs, domains, etc, innocent people get hurt.

-- 
Maciek Niedzielski
  xmpp:machekku at uaznia.net