[Standards] Proposed XMPP Extension: Remote Authentication
stpeter at stpeter.im
Thu Dec 2 14:58:21 UTC 2010
On 12/2/10 7:50 AM, Waqas Hussain wrote:
> On Thu, Dec 2, 2010 at 7:54 AM, XMPP Extensions Editor <editor at xmpp.org> wrote:
>> The XMPP Extensions Editor has received a proposal for a new XEP.
>> Title: Remote Authentication
>> Abstract: This document defines an XMPP protocol extension that enables entities to use SASL for authentication with remote services (such as Multi-User Chat rooms).
>> URL: http://www.xmpp.org/extensions/inbox/remote-auth.html
>> The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP.
> Some comments:
> 1. The SASL mechanisms list can be sent back in the presence error,
> avoiding a round trip.
Yeah, I wasn't sure whether to do that or not. My email to the jdev list
on this topic included the mechanisms in the presence error. I'm still
mulling it over, but you're right that it would save a round trip. I
wonder: can that model be generalized to other extensions? (Think
pubsub, gateways, etc.)
> 2. The presence after authentication need not be sent. On successful
> auth, the initially sent presence can be used, avoiding a round trip.
Good point -- and a good reason to include the SASL mechanisms in the
> 3. What the authentication identity looks like is undefined. I'm not
> sure if this is good or bad.
I think it's bad. We need to fix that up.
> 4. The error condition is 'sasl-required'. Does this imply that normal
> MUC password auth should fail, even with a correct password?
What do you think?
Because legacy MUC passwords are sent in the clear, a given MUC service
might not want to accept that other method, but in practice I think they
would for quite a while.
> And finally, an implementation:
> The linked implementation works with Prosody trunk, and verifies that
> the user knows the room password. This would be far more interesting
> with some per-user credentials.
Indeed. How to establish those?
It would also be interesting to use certificate-based authentication.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6105 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards