<title>Best Practices for Use of SASL ANONYMOUS</title>
<abstract>This document specifies best practices for use of the SASL ANONYMOUS mechanism in the context of client authentication with an XMPP server.</abstract>
<p><cite>RFC 3920</cite> allows the use of any SASL mechanism (see &rfc4422;) in XMPP authentication, including the SASL ANONYMOUS mechanism (see &rfc4505;). This document specifies a recommended protocol flow for such use.</p>
<p>Note: This document is provided for discussion purposes in order to clarify the usage of SASL ANONYMOUS in XMPP systems. It is not meant to supersede the text in <cite>RFC 3920</cite>, <cite>RFC 4422</cite>, or <cite>RFC 4505</cite>. However, the recommendations in this document may be folded into <cite>rfc3920bis</cite>.</p>
<p><cite>RFC 3920</cite> specifies that after an XMPP client authenticates with an XMPP server, it must bind a resource to the XML stream so that XML stanzas can be routed to the client. In essence there are three resource binding scenarios:</p>
<ol>
<li>The client specifies a desired resource identifier and the server accepts it.</li>
<li>The client specifies a desired resource identifier but the server does not accept it, instead overruling the client and assigning a resource identifier.</li>
<li>The client asks the server to assign a resource identifier and the server does so.</li>
</ol>
<p>No matter which scenario is enacted, at the end of the process the server informs the client of its full JID (&FULLJID;). In particular, it might be helpful for an XMPP server to assign a full JID to the client (i.e., not just the resource identifier) if it authenticates with SASL ANONYMOUS, and to ensure that the "bare JID" portion (&BAREJID;) is unique in the context of the domain served by the server.</p>
<p>The method for ensuring the uniqueness of the node identifier is a matter of implementation. It is RECOMMENDED for the node identifier to be a UUID as specified in &rfc4122;.</p>
<p>Although <cite>RFC 4505</cite> allows the initiating entity (client) to provide so-called "trace data" when authenticating via SASL ANONYMOUS, it is NOT RECOMMENDED to include trace data as the XML character data of the <auth/> element (instead, the <auth/> element SHOULD be empty). However, if trace data is included, the server MUST NOT use it for any purpose other than tracing (e.g., in server logs).</p>