<p>Authentication may complete in one of three ways. It may complete successfully, in which case the client is authenticated. It may also fail, in which case the client is not authenticated and the stream and session state remain entirely unchanged.</p>
<p>Finally, it may have completed successfully, but further interaction is required - for example, a password change or second-factor authentication.</p>
<p>If the Client is now authenticated, the Server sends a <success/> element, which contains an OPTIONAL <additional-data/> element containing SASL additional data. It also contains a <authorization-identity/> element containing the negotiated identity - this is a bare JID, unless resource binding has occurred, in which case it is a full JID.</p>
<p>If the Client is now authenticated, the Server sends a <success/> element, which contains contains an <authorization-identity/> element containing the negotiated identity - this is a bare JID, unless resource binding has occurred, in which case it is a full JID.</p>
<p>It MAY contain an <additional-data> element, containing additional data from the exchange (task or SASL mechanism) that has just completed.</p>
<p>After the final octet of the first <continue> element, any SASL security layer negotiated in the preceding exchange SHALL be immediately in effect.</p>
<p>Clients respond with a <next/> element, which has a single mandatory attribute of "task", containing the selected task name, and contains an OPTIONAL base64 encoded initial response.</p>
<p>Clients respond with a <next/> element, which has a single mandatory attribute of "task", containing the selected task name, and contains an OPTIONAL base64 encoded initial response contained in an <initial-response> element.</p>
@ -227,10 +243,222 @@
<p>This section provides a fictional example. It is important to note that many of the extensions used wihtin this section do not, in fact, exist and therefore are to be avoided.</p>
<p>Where no additional features that SASL2 makes available are used, the flow of information is identical to the original SASL profile. This example shows the new syntax and draws the reader's attention to the differences.</p>
Server sends stream features.
These are identical to SASL1, but within a different namespace.
Client intiates authentication.
Beyond the element local name and namespace,
the main distinction is that initial-response data is held within an element,
Here, we have an authzid which is a full jid, since the session is now bound.
The additional-data element here contains the mutual authentication data for the
unrealistic 2FA, and doesn't refer back to the BLURDYBLOOP exchange.
The Server also sends an (empty) features element.
The client can simply continue and send stanzas.
<p>Although the unrealistic 2FA here uses 2 round-trips (real ones will probably use one), the embedding of resource binding as shown here means that a second RTT is saved by SASL2, and there's no net change. A more realistic example would see RTTs saved, and additional negotiations could be added to further reduce RTTs.</p>