[Standards-JIG] Inclusion of both, to and from attributes to the stream root element

[Michal vorner Vaner]

On Thu, Sep 28, 2006 at 11:45:37PM +0200, Matthias Wimmer wrote:
> Hi Peter, hi list,
> 
> 
> you already added to http://www.xmpp.org/xmppbis.html, that it might be
> worth considering, that an initiating entity should add both, a to and a
> from attrbiute to the initial stream headers.
> 
> When I proposed this two years ago I only gave a reason why this is
> worth for s2s links.
> 
> I want to add now, that it would also be worth that a client is adding a
> from attribute to the initial stream headers:
> 
> When a server is generating the list of supported authentication schemes
> (SASL mechanisms and/or legacy authentication), the set of possible
> schemes may depend on the user, that tries to authenticate.
> The server currently has no way to offer different users different
> authentication schmes (SASL mechanisms).
> 
> Examples:
> - If we have a legacy authentication database, that just stores hashes
>   of user passwords (not suitable for doing DIGEST-MD5); and for newer
>   users, we store DIGEST-MD5 compatible hashes. The users using old
>   accounts should not get offered DIGEST-MD5 but only PLAIN; while newer
>   accounts should get offered DIGEST-MD5 and should prefere that over
>   PLAIN.
> - We have some users only having a password, but nothing else. We have
>   other users just having certificates, but nothing else (e.g. because
>   they registered for an account by submitting a certification request
>   for a free JabberID - which would be a nice way to enroll XMPP
>   certificates), and the third group of users just have a SecurID token,
>   but neither a certificate nor a password.
>   For each group of users, the server has to present an other SASL
>   mechanism. How can the server decide which one to present, if it does
>   not get a from attribute?
> 
IMHO By providing all 3 and letting the user to authenticate with whatever
he has? If I do know user does not have a certificate and he tries to
authenticate by it, it tells me he is not the user he claims to be, if
he does not know he does not have a certificate.

But the first one seems like a problem.

-- 
Michal "vorner" Vaner
==
This email has been checked by an automatic damage possibility check system.
It can contain harmful instructions if read backwards.
Internal checker ID: lacol.cr/cte/ << tlah ohce
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.jabber.org/pipermail/standards/attachments/20060929/69e547ea/attachment.pgp