[jdev] How to specify username with SASL ANONYMOUS

[Ralph Meijer]

On Wed, 2007-10-17 at 15:48 -0600, Peter Saint-Andre wrote:
> On Wed, Oct 17, 2007 at 02:40:26PM -0700, Justin Karneges wrote:
> > On Wednesday 17 October 2007 2:11 pm, Mark Doliner wrote:
> > > So I've read through XEP-0175[1], and I think I have a pretty good idea of
> > > how SASL ANONYMOUS login is supposed to work (I love the protocol
> > > flow--thank you).
> > >
> > > But it's not clear to me how the client is supposed to specify a username. 
> > > This is supposed to be possible, right?  Or is the node always assigned by
> > > the server no matter what?  Should I just send the base64 encoded username
> > > as text within the 'auth' element?
> > 
> > XEP-175 doesn't seem to mention the fact that SASL ANONYMOUS can send data.  
> > The rfc3920bis-04 document even indicates that transmitting an initial 
> > response with ANONYMOUS is is invalid (section 7.5.5).  This is wrong, 
> > ANONYMOUS can send data, and it can be an initial response or not.  See RFC 
> > 4505.
> > 
> > The client response for ANONYMOUS is "trace" data.  This is just supposed to 
> > be some generic id string, possibly an email address (like how anonymous FTP 
> > would often ask you to put your email address as the password, that's what 
> > this essentially replaces).  It might be interesting to specify in XEP-175 
> > that the trace data may be used as a node suggestion.
> 
> How is ANONYMOUS used right now? Do XMPP servers (1) create a temporary 
> node or (2) create a temporary resource for some anonymous user? I think 
> that (1) is probably a safer approach, in which case it might be nice to
> specify the "trace" data in version 1.1 of XEP-0175 (and of course correct 
> rfc3920bis while we're at it).

It seems to me that ANONYMOUS is inherently not intended to give a user
a more or less permanent handle that has part of the user's identity
encoded in it.

As I see it, the trace data is for allowing administrators to have some
way to contact the user. The validity of this information is not
verified and also may cause privacy issues if sent automatically by
client implementations.

-- 
Groetjes,

ralphm