Update SASL code to draft 2

This isn't fully correct yet, but it compiles and passes the existing
tests (with suitable updates).

5 files changed, 744 insertions, 295 deletions

diff --git a/extensions/Channel_Interface_SASL_Authentication.xml b/extensions/Channel_Interface_SASL_Authentication.xml
new file mode 100644
index 000000000..bb25a6b9e
--- /dev/null
+++ b/extensions/Channel_Interface_SASL_Authentication.xml
@@ -0,0 +1,661 @@
+<?xml version="1.0" ?>
+<node name="/Channel_Interface_SASL_Authentication"
+      xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+  <tp:copyright> Copyright © 2010 Collabora Limited </tp:copyright>
+  <tp:license xmlns="http://www.w3.org/1999/xhtml">
+    <p>This library is free software; you can redistribute it and/or
+modify it under the terms of the GNU Lesser General Public
+License as published by the Free Software Foundation; either
+version 2.1 of the License, or (at your option) any later version.</p>
+
+<p>This library is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+Lesser General Public License for more details.</p>
+
+<p>You should have received a copy of the GNU Lesser General Public
+License along with this library; if not, write to the Free Software
+Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</p>
+  </tp:license>
+  <interface name="org.freedesktop.Telepathy.Channel.Interface.SASLAuthentication.DRAFT2"
+      tp:causes-havoc="experimental">
+    <tp:added version="0.21.UNRELEASED">(draft 2)</tp:added>
+    <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <p>A channel interface for SASL authentication,
+        as defined by
+        <a href="http://tools.ietf.org/html/rfc4422">RFC 4422</a>.
+        When this interface appears on a <tp:dbus-ref
+          namespace="ofdT.Channel.Type">ServerAuthentication.DRAFT2</tp:dbus-ref>
+        channel, it represents authentication with the server. In future,
+        it could also be used to authenticate with secondary services,
+        or even to authenticate end-to-end connections with contacts.</p>
+
+      <p>In any protocol that requires a password, the connection manager can
+        use this channel to let a user interface carry out a simple SASL-like
+        handshake with it, as a way to get the user's credentials
+        interactively. This can be used to connect to protocols that may
+        require a password, without requiring that the password is saved in
+        the <tp:dbus-ref
+          namespace="ofdT">Account.Parameters</tp:dbus-ref>.</p>
+
+      <p>In some protocols, such as XMPP, authentication with the server
+        is also carried out using SASL. In these protocols, a channel with this
+        interface can provide a simple 1:1 mapping of the SASL negotiations
+        taking place in the protocol, allowing more advanced clients to
+        perform authentication via SASL mechanisms not known to the
+        connection manager.</p>
+
+      <tp:rationale>
+        <p>By providing SASL directly when the protocol supports it, we can
+          use mechanisms like Kerberos or Google's <code>X-GOOGLE-TOKEN</code>
+          without specific support in the connection manager.</p>
+      </tp:rationale>
+
+      <p>For channels managed by a
+        <tp:dbus-ref namespace="ofdT">ChannelDispatcher</tp:dbus-ref>,
+        only the channel's <tp:dbus-ref
+          namespace="ofdT.Client">Handler</tp:dbus-ref> may call the
+        methods on this interface. Other clients MAY observe the
+        authentication process by watching its signals and properties.</p>
+
+      <tp:rationale>
+        <p>There can only be one Handler, which is a good fit for SASL's
+          1-1 conversation between a client and a server.</p>
+      </tp:rationale>
+    </tp:docstring>
+
+    <tp:simple-type name="SASL_Mechanism" type="s"
+      array-name="SASL_Mechanism_List">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>A SASL mechanism, as defined by
+          <a href="http://tools.ietf.org/html/rfc4422">RFC 4422</a>
+          and registered in
+          <a href="http://www.iana.org/assignments/sasl-mechanisms">the
+            IANA registry of SASL mechanisms</a>, or an unregistered
+          SASL mechanism such as <code>X-GOOGLE-TOKEN</code> used in the
+          same contexts.</p>
+
+        <p>As a special case, pseudo-mechanisms starting with
+          <code>X-TELEPATHY-</code> are defined by this specification.
+          Use of these pseudo-mechanisms indicates that the user's credentials
+          are to be passed to the connection manager, which will then use
+          them for authentication with the service, either by implementing
+          the client side of some SASL mechanisms itself or by using a
+          non-SASL protocol. The only such pseudo-mechanism currently
+          defined is <code>X-TELEPATHY-PASSWORD</code>.</p>
+
+        <p>The <code>X-TELEPATHY-PASSWORD</code> mechanism is extremely
+          simple:</p>
+
+        <ul>
+          <li>The client MUST call
+            <tp:member-ref>StartMechanismWithData</tp:member-ref>, with
+            Initial_Data set to the password encoded in UTF-8.
+            For simplicity, calling <tp:member-ref>StartMechanism</tp:member-ref>
+            followed by calling <tp:member-ref>Respond</tp:member-ref> is not
+            allowed in this mechanism.</li>
+
+          <li>The connection manager uses the password, together with
+            authentication details from the Connection parameters, to
+            authenticate itself to the server.</li>
+
+          <li>When the connection manager finishes its attempt to authenticate
+            to the server, the channel's state changes to
+            either SASL_Status_Server_Succeeded or
+            SASL_Status_Server_Failed as appropriate.</li>
+        </ul>
+      </tp:docstring>
+    </tp:simple-type>
+
+    <property name="AvailableMechanisms"
+      tp:name-for-bindings="Available_Mechanisms"
+      type="as" tp:type="SASL_Mechanism[]"
+      access="read" tp:immutable="yes">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The SASL mechanisms as offered by the server, plus any
+          pseudo-SASL mechanisms supported by the connection manager for
+          credentials transfer. For instance, in a protocol that
+          natively uses SASL (like XMPP), this might be
+          <code>[ "X-TELEPATHY-PASSWORD", "PLAIN", "DIGEST-MD5",
+            "SCRAM-SHA-1" ]</code>.</p>
+
+        <p>To make it possible to implement a very simple password-querying
+          user interface without knowledge of any particular SASL mechanism,
+          implementations of this interface MUST implement the
+          pseudo-mechanism <code>X-TELEPATHY-PASSWORD</code>.</p>
+      </tp:docstring>
+    </property>
+
+    <property name="HasInitialData" tp:name-for-bindings="Has_Initial_Data"
+      type="b" access="read" tp:immutable="yes">
+      <tp:docstring>
+        If true, <tp:member-ref>StartMechanismWithData</tp:member-ref>
+        can be expected to work (this is the case in most, but not all,
+        protocols). If false, <tp:member-ref>StartMechanism</tp:member-ref>
+        must be used instead.
+      </tp:docstring>
+    </property>
+
+    <property name="CanTryAgain" tp:name-for-bindings="Can_Try_Again"
+      type="b" access="read" tp:immutable="yes">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>If true, <tp:member-ref>StartMechanism</tp:member-ref> and (if
+          supported) <tp:member-ref>StartMechanismWithData</tp:member-ref>
+          can be expected to work when in one of the Failed states. If
+          false, the only thing you can do after failure is to close the
+          channel.</p>
+
+        <tp:rationale>
+          <p>Retrying isn't required to work, although some protocols and
+            implementations allow it.</p>
+        </tp:rationale>
+      </tp:docstring>
+    </property>
+
+    <property name="Encrypted"
+      tp:name-for-bindings="Encrypted" type="b"
+      access="read" tp:immutable="yes">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>True if this authentication process occurs over an encrypted
+          connection. This <strong>does not</strong> imply that steps have
+          been taken to avoid man-in-the-middle attacks.</p>
+
+        <tp:rationale>
+          <p>For future support for <a
+              href="http://tools.ietf.org/html/rfc5056">RFC 5056 Channel
+              Binding</a> it is desirable to be able to use some SASL
+            mechanisms over an encrypted connection to an unverified peer,
+            which can prove that it is the desired destination during
+            the SASL negotiation.</p>
+        </tp:rationale>
+
+        <p>Clients MAY use the combination of this property and
+          <tp:member-ref>Verified</tp:member-ref> to decide whether the
+          <code>PLAIN</code> mechanism is acceptable, for instance.</p>
+      </tp:docstring>
+    </property>
+
+    <property name="Verified"
+      tp:name-for-bindings="Verified" type="b"
+      access="read" tp:immutable="yes">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>True if this authentication process occurs over a connection
+          that is protected against tampering, and has been verified to
+          be with the desired destination: for instance, one where TLS
+          was previously negotiated, and the TLS certificate has been
+          verified against a configured certificate authority or
+          accepted by the user.</p>
+
+        <p>Clients MAY use the combination of this property and
+          <tp:member-ref>Encrypted</tp:member-ref> to decide whether the
+        <code>PLAIN</code> mechanism is acceptable, for instance.</p>
+      </tp:docstring>
+    </property>
+
+    <property type="u" tp:type="SASL_Status" access="read"
+      name="SASLStatus" tp:name-for-bindings="SASL_Status">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        The current status of this channel.
+        Change notification is via the
+        <tp:member-ref>SASLStatusChanged</tp:member-ref> signal.
+      </tp:docstring>
+    </property>
+
+    <property type="s" tp:type="DBus_Error_Name" access="read"
+      name="SASLError" tp:name-for-bindings="SASL_Error">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The reason for the <tp:member-ref>SASLStatus</tp:member-ref>, or
+          an empty string if the state is neither
+          Server_Failed nor Client_Failed.</p>
+
+        <p>In particular, an ordinary authentication failure (as would
+          be produced for an incorrect password) SHOULD be represented by
+          <tp:error-ref>AuthenticationFailed</tp:error-ref>,
+          cancellation by the user's request SHOULD be represented
+          by <tp:error-ref>Cancelled</tp:error-ref>, and
+          cancellation by a local process due to inconsistent or invalid
+          challenges from the server SHOULD be represented by
+          <tp:error-ref>ServiceConfused</tp:error-ref>.</p>
+
+        <p>If this interface appears on a <tp:dbus-ref
+            namespace="ofdT.Channel.Type">ServerAuthentication.DRAFT2</tp:dbus-ref>
+          channel, and connection to the server fails with an authentication
+          failure, this error code SHOULD be copied into the
+          <tp:dbus-ref
+            namespace="ofdT">Connection.ConnectionError</tp:dbus-ref>
+          signal.</p>
+      </tp:docstring>
+    </property>
+
+    <property name="SASLErrorDetails"
+      tp:name-for-bindings="SASL_Error_Details"
+      access="read" type="a{sv}" tp:type="String_Variant_Map">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>If <tp:member-ref>SASLError</tp:member-ref> is non-empty,
+          any additional information about the last
+          disconnection; otherwise, the empty map. The keys and values are
+          the same as for the second argument of
+          <tp:dbus-ref
+            namespace="ofdT">Connection.ConnectionError</tp:dbus-ref>.</p>
+
+        <p>If this interface appears on a <tp:dbus-ref
+            namespace="ofdT.Channel.Type">ServerAuthentication.DRAFT2</tp:dbus-ref>
+          channel, and connection to the server fails with an authentication
+          failure, these details SHOULD be copied into the
+          <tp:dbus-ref
+            namespace="ofdT">Connection.ConnectionError</tp:dbus-ref>
+          signal.</p>
+      </tp:docstring>
+    </property>
+
+    <property name="AuthorizationIdentity"
+      tp:name-for-bindings="Authorization_Identity"
+      type="s" access="read" tp:immutable="yes">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The identity for which authorization is being attempted,
+          typically the 'account' from the <tp:dbus-ref
+            namespace="ofdT.ConnectionManager">RequestConnection</tp:dbus-ref>
+          parameters, normalized and formatted according to the
+          conventions used for SASL in this protocol.</p>
+
+        <tp:rationale>
+          <p>The normalization used for SASL might not be the same
+            normalization used elsewhere: for instance, in a protocol
+            with email-like identifiers such as XMPP or SIP, the user
+            "juliet@example.com" might have to authenticate to the
+            example.com server via SASL PLAIN as "juliet".</p>
+        </tp:rationale>
+
+        <p>This is usually achieved by using the authorization identity for
+          authentication, but an advanced Handler could offer the option
+          to authenticate under a different identity.</p>
+
+        <p>The terminology used here is that the authorization identity
+          is who you want to act as, and the authentication identity is
+          used to prove that you may do so. For instance, if Juliet is
+          authorized to access a role account, "sysadmin@example.com",
+          and act on its behalf, it might be possible to authenticate
+          as "juliet@example.com" with her own password, but request to
+          be authorized as "sysadmin@example.com" instead of her own
+          account. See
+          <a href="http://tools.ietf.org/html/rfc4422#section-3.4.1">RFC
+            4422 §3.4.1</a> for more details.</p>
+
+        <tp:rationale>
+          <p>In SASL the authorization identity is normally guessed from
+            the authentication identity, but the information available
+            to the connection manager is the identity for which
+            authorization is required, such as the desired JID in XMPP,
+            so that's what we signal to UIs; it's up to the UI to
+            choose whether to authenticate as the authorization identity
+            or some other identity.</p>
+
+          <p>As a concrete example, the "sysadmin" XMPP account mentioned
+            above would have <code>{ 'account': 'sysadmin@example.com' }</code>
+            in its Parameters, and this property would also be
+            'sysadmin@example.com'. A simple Handler would
+            merely prompt for sysadmin@example.com's password,
+            and use that JID as both the authorization and authentication
+            identity, which might result in SASL PLAIN authentication with the
+            initial response
+            '\000sysadmin@example.com\000root'.</p>
+
+          <p>A more advanced Handler might also ask for an authentication
+            identity, defaulting to 'sysadmin@example.com'; if Juliet
+            provided authentication identity 'juliet@example.com' and
+            password 'romeo', the Handler might perform SASL PLAIN
+            authentication using the initial response
+            'sysadmin@example.com\000juliet@example.com\000romeo'.</p>
+        </tp:rationale>
+      </tp:docstring>
+    </property>
+
+    <property name="DefaultRealm" tp:name-for-bindings="Default_Realm"
+      type="s" access="read" tp:immutable="yes">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The default realm (as defined in
+          <a href="http://tools.ietf.org/html/rfc2831#section-2.1.1">RFC
+            2831</a>) to use for authentication, if the server does not
+          supply one.</p>
+
+        <tp:rationale>
+          <p>The server is not required to provide a realm; if it doesn't,
+            the client is expected to ask the user or provide a sensible
+            default, typically the requested DNS name of the server.
+            In some implementations of <code>DIGEST-MD5</code>, the
+            server does not specify a realm, but expects that the client
+            will choose a particular default, and authentication will
+            fail if the client's default is different. Connection
+            managers for protocols where this occurs are more easily able
+            to work around these implementations than a generic client
+            would be.</p>
+        </tp:rationale>
+      </tp:docstring>
+    </property>
+
+    <property name="SASLContext" tp:name-for-bindings="SASL_Context"
+      type="a{sv}" tp:type="String_Variant_Map" access="read"
+      tp:immutable="yes">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Additional protocol- or mechanism-specific context for the
+          authentication. Only one well-known key is currently defined:</p>
+
+        <dl>
+          <dt>jabber-stream-id (string)</dt>
+          <dd>The <code>id</code> attribute of the XMPP <code>stream</code>
+            element, as used in <a
+              href="http://xmpp.org/extensions/xep-0078.html">the digest
+              mechanism historically used in Jabber</a>.</dd>
+        </dl>
+      </tp:docstring>
+    </property>
+
+    <method name="StartMechanism" tp:name-for-bindings="Start_Mechanism">
+      <arg direction="in" name="Mechanism" type="s" tp:type="SASL_Mechanism">
+        <tp:docstring>
+          The chosen mechanism.
+        </tp:docstring>
+      </arg>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Start an authentication try using <var>Mechanism</var>, without
+          sending initial data (an "initial response" as defined in RFC
+          4422).</p>
+
+        <tp:rationale>
+          <p>This method is appropriate for mechanisms where the client
+            cannot send anything until it receives a challenge from the
+            server, such as <code>DIGEST-MD5</code>.</p>
+        </tp:rationale>
+      </tp:docstring>
+
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+          <tp:docstring>
+            The channel is not in a state where starting authentication makes
+            sense (i.e. SASL_Status_Not_Started, or (if
+            <tp:member-ref>CanTryAgain</tp:member-ref> is true)
+            SASL_Status_Server_Failed or
+            SASL_Status_Client_Failed). You should call
+            <tp:member-ref>AbortSASL</tp:member-ref> and wait for
+            SASL_Status_Client_Failed before starting another attempt.
+          </tp:docstring>
+        </tp:error>
+        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
+          <tp:docstring>
+            The server or connection manager doesn't implement the given
+            SASL mechanism. Choose a SASL mechanism from
+            <tp:member-ref>AvailableMechanisms</tp:member-ref>, or abort
+            authentication if none of them are suitable.
+          </tp:docstring>
+        </tp:error>
+      </tp:possible-errors>
+    </method>
+
+    <method name="StartMechanismWithData"
+      tp:name-for-bindings="Start_Mechanism_With_Data">
+      <arg direction="in" name="Mechanism" type="s" tp:type="SASL_Mechanism">
+        <tp:docstring>
+          The chosen mechanism.
+        </tp:docstring>
+      </arg>
+      <arg direction="in" name="Initial_Data" type="ay">
+        <tp:docstring>
+          Initial data (an "initial response" in RFC 4422's terminology) to send
+          with the mechanism.
+        </tp:docstring>
+      </arg>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Start an authentication try using <var>Mechanism</var>, and send
+          <var>Initial_Data</var> as the "initial response" defined in
+          <a href="http://tools.ietf.org/html/rfc4422#section-3.3">RFC 4422
+            §3.3</a>.</p>
+
+        <p>If the underlying protocol does not make it possible to send
+          initial data, this method will fail.</p>
+
+        <tp:rationale>
+          <p>This method is appropriate for mechanisms where the client may
+            send data first, such as <code>PLAIN</code>.</p>
+
+          <p>Having two methods allows any mechanism where it makes a difference
+            to distinguish between the absence of an initial response
+            (<tp:member-ref>StartMechanism</tp:member-ref>) and a zero-byte
+            initial response (StartMechanismWithData, with Initial_Data
+            empty).</p>
+        </tp:rationale>
+      </tp:docstring>
+
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+          <tp:docstring>
+            The channel is not in a state where starting authentication makes
+            sense (i.e. SASL_Status_Not_Started, or (if
+            <tp:member-ref>CanTryAgain</tp:member-ref> is true)
+            SASL_Status_Server_Failed or
+            SASL_Status_Client_Failed). You should call
+            <tp:member-ref>AbortSASL</tp:member-ref> and wait for
+            SASL_Status_Client_Failed before starting another attempt.
+          </tp:docstring>
+        </tp:error>
+        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
+          <tp:docstring>
+            The server or connection manager doesn't implement the given
+            SASL mechanism (choose one from
+            <tp:member-ref>AvailableMechanisms</tp:member-ref>, or abort
+            authentication if none of them are suitable), or doesn't allow
+            initial data to be sent (as indicated by
+            <tp:member-ref>HasInitialData</tp:member-ref>; call
+            <tp:member-ref>StartMechanism</tp:member-ref> instead).
+          </tp:docstring>
+        </tp:error>
+      </tp:possible-errors>
+    </method>
+
+    <method name="Respond" tp:name-for-bindings="Respond">
+      <arg direction="in" name="Response_Data" type="ay">
+        <tp:docstring>
+          The response data.
+        </tp:docstring>
+      </arg>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Send a response to the the last challenge received via
+          <tp:member-ref>NewChallenge</tp:member-ref>.</p>
+      </tp:docstring>
+
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+          <tp:docstring>
+            Either the state is not In_Progress, or no challenge has been
+            received yet, or you have already responded to the last challenge.
+          </tp:docstring>
+        </tp:error>
+        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
+      </tp:possible-errors>
+    </method>
+
+    <method name="AcceptSASL" tp:name-for-bindings="Accept_SASL">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>If the channel's status is SASL_Status_Server_Succeeded,
+          this method confirms successful authentication and advances
+          the status of the channel to SASL_Status_Succeeded.</p>
+
+        <p>If the channel's status is SASL_Status_In_Progress, calling this
+          method indicates that the last
+          <tp:member-ref>NewChallenge</tp:member-ref> signal was in fact
+          additional data sent after a successful SASL negotiation, and
+          declares that from the client's point of view, authentication
+          was successful. This advances the state of the channel to
+          SASL_Status_Client_Accepted.</p>
+
+        <p>In mechanisms where the server authenticates itself to the client,
+          calling this method indicates that the client considers this to have
+          been successful. In the case of <tp:dbus-ref
+            namespace="ofdT.Channel.Type">ServerAuthentication.DRAFT2</tp:dbus-ref>
+          channels, this means that the connection manager MAY continue to
+          connect, and MAY advance the <tp:dbus-ref
+            namespace="ofdT">Connection.Status</tp:dbus-ref> to Connected.</p>
+      </tp:docstring>
+
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+          <tp:docstring>
+            Either the state is neither In_Progress nor Server_Succeeded, or no
+            challenge has been received yet, or you have already responded to
+            the last challenge.
+          </tp:docstring>
+        </tp:error>
+        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
+      </tp:possible-errors>
+    </method>
+
+    <method name="AbortSASL" tp:name-for-bindings="Abort_SASL">
+      <arg direction="in" name="Reason" type="u" tp:type="SASL_Abort_Reason">
+        <tp:docstring>
+          Reason for abort.
+        </tp:docstring>
+      </arg>
+      <arg direction="in" name="Debug_Message" type="s">
+        <tp:docstring>
+          Debug message for abort.
+        </tp:docstring>
+      </arg>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Abort the current authentication try.</p>
+
+        <p>If the current status is SASL_Status_Server_Failed or
+          SASL_Status_Client_Failed, this method returns successfully, but has
+          no further effect. Otherwise, it changes the channel's state to
+          SASL_Status_Client_Failed, with an appropriate error name and
+          reason code.</p>
+      </tp:docstring>
+    </method>
+
+    <signal name="SASLStatusChanged" tp:name-for-bindings="SASL_Status_Changed">
+      <tp:docstring>
+        Emitted when the status of the channel changes.
+      </tp:docstring>
+      <arg type="u" tp:type="SASL_Status" name="Status">
+        <tp:docstring>
+          The new value of <tp:member-ref>SASLStatus</tp:member-ref>.
+        </tp:docstring>
+      </arg>
+      <arg type="s" tp:type="DBus_Error_Name" name="Reason">
+        <tp:docstring>
+          The new value of <tp:member-ref>SASLError</tp:member-ref>.
+        </tp:docstring>
+      </arg>
+      <arg type="a{sv}" tp:type="String_Variant_Map" name="Details">
+        <tp:docstring>
+          The new value of <tp:member-ref>SASLErrorDetails</tp:member-ref>.
+        </tp:docstring>
+      </arg>
+    </signal>
+
+    <signal name="NewChallenge" tp:name-for-bindings="New_Challenge">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Emitted when a new challenge is received from the server, or when
+          a message indicating successful authentication and containing
+          additional data is received from the server.</p>
+
+        <p>When the channel's handler is ready to proceed, it should respond
+          to the challenge by calling <tp:member-ref>Respond</tp:member-ref>,
+          or respond to the additional data by calling
+          <tp:member-ref>AcceptSASL</tp:member-ref>. Alternatively, it may call
+          <tp:member-ref>AbortSASL</tp:member-ref> to abort authentication.</p>
+      </tp:docstring>
+      <arg name="Challenge_Data" type="ay">
+        <tp:docstring>
+          The challenge data or additional data from the server.
+        </tp:docstring>
+      </arg>
+    </signal>
+
+    <tp:enum name="SASL_Abort_Reason" type="u">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>A reason why SASL authentication was aborted by the client.</p>
+      </tp:docstring>
+
+      <tp:enumvalue suffix="Invalid_Challenge" value="0">
+        <tp:docstring>
+          The server sent an invalid challenge or data.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="User_Abort" value="1">
+        <tp:docstring>
+          The user aborted the authentication.
+        </tp:docstring>
+      </tp:enumvalue>
+    </tp:enum>
+
+    <tp:enum name="SASL_Status" type="u">
+      <tp:enumvalue suffix="Not_Started" value="0">
+        <tp:docstring>
+          The initial state. The Handler SHOULD either
+          call <tp:member-ref>AbortSASL</tp:member-ref>, or connect to the
+          <tp:member-ref>NewChallenge</tp:member-ref> signal then call
+          <tp:member-ref>StartMechanism</tp:member-ref> or
+          <tp:member-ref>StartMechanismWithData</tp:member-ref>.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="In_Progress" value="1">
+        <tp:docstring>
+          The challenge/response exchange is in progress. The Handler SHOULD
+          call either <tp:member-ref>Respond</tp:member-ref> or
+          <tp:member-ref>AcceptSASL</tp:member-ref> exactly once per emission
+          of <tp:member-ref>NewChallenge</tp:member-ref>, or call
+          <tp:member-ref>AbortSASL</tp:member-ref> at any time.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Server_Succeeded" value="2">
+        <tp:docstring>
+          The server has indicated successful authentication, and the
+          connection manager is waiting for confirmation from the Handler.
+          The Handler must call either <tp:member-ref>AcceptSASL</tp:member-ref> or
+          <tp:member-ref>AbortSASL</tp:member-ref> to indicate whether it
+          considers authentication to have been successful.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Client_Accepted" value="3">
+        <tp:docstring>
+          The Handler has indicated successful authentication, and the
+          connection manager is waiting for confirmation from the server.
+          The state will progress to either Succeeded or Server_Failed when
+          confirmation is received.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Succeeded" value="4">
+        <tp:docstring>
+          Everyone is happy (the server sent success, and the client has called
+          <tp:member-ref>AcceptSASL</tp:member-ref>). Connection to the server
+          will proceed as soon as this state is reached. The Handler SHOULD
+          call <tp:dbus-ref
+            namespace="org.freedesktop.Telepathy.Channel">Close</tp:dbus-ref>
+          to close the channel.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Server_Failed" value="5">
+        <tp:docstring>
+          The server has indicated an authentication failure.
+          If <tp:member-ref>CanTryAgain</tp:member-ref> is true,
+          the client may try to authenticate again, by calling
+          <tp:member-ref>StartMechanism</tp:member-ref> or
+          <tp:member-ref>StartMechanismWithData</tp:member-ref> again.
+          Otherwise, it should give up completely, by calling <tp:dbus-ref
+            namespace="org.freedesktop.Telepathy.Channel">Close</tp:dbus-ref>
+          on the channel.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Client_Failed" value="6">
+        <tp:docstring>
+          The client has indicated an authentication failure. The
+          possible actions are the same as for Server_Failed.
+        </tp:docstring>
+      </tp:enumvalue>
+    </tp:enum>
+
+  </interface>
+</node>
+<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/extensions/Channel_Interface_Sasl_Authentication.xml b/extensions/Channel_Interface_Sasl_Authentication.xml
deleted file mode 100644
index 6ae4e1da8..000000000
--- a/extensions/Channel_Interface_Sasl_Authentication.xml
+++ /dev/null
@@ -1,231 +0,0 @@
-<?xml version="1.0" ?>
-<node name="/Channel_Interface_Sasl_Authentication"
-      xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
-  <tp:copyright> Copyright © 2010 Collabora Limited </tp:copyright>
-  <tp:license xmlns="http://www.w3.org/1999/xhtml">
-    <p>This library is free software; you can redistribute it and/or
-modify it under the terms of the GNU Lesser General Public
-License as published by the Free Software Foundation; either
-version 2.1 of the License, or (at your option) any later version.</p>
-
-<p>This library is distributed in the hope that it will be useful,
-but WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
-Lesser General Public License for more details.</p>
-
-<p>You should have received a copy of the GNU Lesser General Public
-License along with this library; if not, write to the Free Software
-Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</p>
-  </tp:license>
-  <interface name="org.freedesktop.Telepathy.Channel.Interface.SaslAuthentication.DRAFT" tp:causes-havoc="experimental">
-    <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
-	<tp:requires interface="org.freedesktop.Telepathy.Channel.Type.Server.Authentication.DRAFT"/>
-    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-      A channel interface for SASL authentication.
-    </tp:docstring>
-
-
-    <property name="AvailableMechanisms"
-             tp:name-for-bindings="Available_Mechanisms"
-              type="as" access="read">
-      <tp:docstring>
-        Example: [ "PLAIN", "DIGEST-MD5", "SCRAM-SHA-1" ]
-        The SASL mechanisms as offered by the server.
-      </tp:docstring>
-    </property>
-
-    <property name="Secure"
-             tp:name-for-bindings="Secure" type="b" access="read">
-      <tp:docstring>
-        Is this exchange secure (ie. TLS)? Good to know if you need to take
-        a calculated risk with plaintext.
-      </tp:docstring>
-    </property>
-
-    <property name="CurrentChallenge" tp:name-for-bindings="Current_Challenge"
-              type="ay" access="read">
-      <tp:docstring>
-        The current challenge from the server. change notification via
-        <tp:member-ref>NewChallenge</tp:member-ref>. The handler either needs
-        to respond by calling <tp:member-ref>Respond</tp:member-ref>
-        (if it needs to send reply data), <tp:member-ref>Accept</tp:member-ref>
-        (If the challenge contained final data) or
-        <tp:member-ref>Abort</tp:member-ref> (in case of errors).
-      </tp:docstring>
-    </property>
-
-    <property name="CurrentState" tp:name-for-bindings="Current_State"
-              type="(uss)" tp:type="Sasl_State" access="read">
-      <tp:docstring>
-        The current state of the authentication.
-        Change notification via <tp:member-ref>StateChanged</tp:member-ref>
-        signal.
-      </tp:docstring>
-    </property>
-
-    <method name="StartMechanism" tp:name-for-bindings="Start_Mechanism">
-      <arg direction="in" name="Mechanism" type="s">
-        <tp:docstring>
-          The chosen mechanism.
-        </tp:docstring>
-      </arg>
-      <arg direction="in" name="InitialData" type="ay">
-        <tp:docstring>
-          Initial data to send with the mechanism.
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        Start an authentication try using Mechanism. If the choosen SASL
-        mechanism is client-first then the first data must be passed in
-        InitialData, otherwise InitialData must be an empty array.
-      </tp:docstring>
-    </method>
-
-    <method name="Respond" tp:name-for-bindings="Respond">
-      <arg direction="in" name="Response_Data" type="ay">
-        <tp:docstring>
-          The response data.
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        Our response to the CurrentChallenge if required.
-      </tp:docstring>
-    </method>
-
-    <method name="Accept" tp:name-for-bindings="Accept">
-      <tp:docstring>
-        Handler accepts the authentication as finished. Can be called
-        whenever the Handler considered the authentication process to
-        be (successfully) finished from its part.
-      </tp:docstring>
-    </method>
-
-    <method name="Abort" tp:name-for-bindings="Abort">
-      <arg direction="in" name="Reason" type="u" tp:type="Abort_Reason">
-        <tp:docstring>
-          Reason for abort.
-        </tp:docstring>
-      </arg>
-      <arg direction="in" name="Debug_Message" type="s">
-        <tp:docstring>
-          Debug message for abort.
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        Abort the current authentication try.
-      </tp:docstring>
-    </method>
-
-    <signal name="StateChanged" tp:name-for-bindings="State_Changed">
-      <tp:docstring>
-        Notifies of <tp:member-ref>CurrentState</tp:member-ref> changing
-      </tp:docstring>
-      <arg type="u" tp:type="Sasl_Status" name="Status">
-        <tp:docstring>
-          The status of the state.
-        </tp:docstring>
-      </arg>
-      <arg type="s" tp:type="DBus_Error_Name" name="Reason">
-        <tp:docstring>
-          The reason for the state.
-        </tp:docstring>
-      </arg>
-      <arg type="s" name="DebugMessage">
-        <tp:docstring>
-          A non-localized debug message.
-        </tp:docstring>
-      </arg>
-    </signal>
-
-    <signal name="NewChallenge" tp:name-for-bindings="New_Challenge">
-      <tp:docstring>
-        Recieved a new challenge from the server.
-      </tp:docstring>
-      <arg name="ChallengeData" type="ay">
-        <tp:docstring>
-          The challenge data from the server.
-        </tp:docstring>
-      </arg>
-    </signal>
-
-    <tp:enum name="Abort_Reason" type="u">
-      <tp:enumvalue suffix="Invalid_Challenge" value="0">
-        <tp:docstring>
-          Server sent an invalid challenge or data.
-        </tp:docstring>
-      </tp:enumvalue>
-      <tp:enumvalue suffix="User_Abort" value="1">
-        <tp:docstring>
-          User aborted the authentication.
-        </tp:docstring>
-      </tp:enumvalue>
-    </tp:enum>
-
-    <tp:enum name="Sasl_Status" type="u">
-      <tp:enumvalue suffix="Not_Started" value="0">
-        <tp:docstring>
-          Need to call <tp:member-ref>StartMechanism</tp:member-ref> to start.
-        </tp:docstring>
-      </tp:enumvalue>
-      <tp:enumvalue suffix="In_Progress" value="1">
-        <tp:docstring>
-          Challenge/Response cycle in progress
-        </tp:docstring>
-      </tp:enumvalue>
-      <tp:enumvalue suffix="Server_Succeeded" value="2">
-        <tp:docstring>
-          Server indicated successful authentication, handler needs to
-          Accept or Abort.
-        </tp:docstring>
-      </tp:enumvalue>
-      <tp:enumvalue suffix="Client_Accepted" value="3">
-        <tp:docstring>
-          Handler indicates that from its perspective the
-          authentication has successfully finished.
-        </tp:docstring>
-      </tp:enumvalue>
-      <tp:enumvalue suffix="Succeeded" value="4">
-        <tp:docstring>
-          Everyone is happy (server sent success, client sent Accept),                    up to the handler to close the channel.
-        </tp:docstring>
-      </tp:enumvalue>
-      <tp:enumvalue suffix="Server_Failed" value="5">
-        <tp:docstring>
-          Server indicated an authentication failure,
-          Authentication can be restarted by calling
-          StartMechanism again or completely aborted by Closing
-          the channel.
-        </tp:docstring>
-      </tp:enumvalue>
-      <tp:enumvalue suffix="Client_Failed" value="6">
-        <tp:docstring>
-          Client indicated an authentication failure,
-          Authentication can be restarted by calling
-          StartMechanism again or completely aborted by Closing
-          the channel.
-        </tp:docstring>
-      </tp:enumvalue>
-    </tp:enum>
-
-    <tp:struct name="Sasl_State">
-      <tp:member type="u" tp:type="Sasl_Status" name="Status">
-        <tp:docstring>
-          The status of the state.
-        </tp:docstring>
-      </tp:member>
-
-      <tp:member type="s" tp:type="DBus_Error_Name" name="Reason">
-        <tp:docstring>
-          The reason for the state.
-        </tp:docstring>
-      </tp:member>
-
-      <tp:member type="s" name="DebugMessage">
-        <tp:docstring>
-          A non-localized debug message.
-        </tp:docstring>
-      </tp:member>
-    </tp:struct>
-  </interface>
-</node>
-<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/extensions/Channel_Type_Server_Authentication.xml b/extensions/Channel_Type_Server_Authentication.xml
index bc9ca150e..ae5fd061c 100644
--- a/extensions/Channel_Type_Server_Authentication.xml
+++ b/extensions/Channel_Type_Server_Authentication.xml
@@ -16,77 +16,96 @@ Lesser General Public License for more details.</p>
 License along with this library; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</p>
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.Channel.Type.ServerAuthentication.DRAFT" tp:causes-havoc="experimental">
+  <interface name="org.freedesktop.Telepathy.Channel.Type.ServerAuthentication.DRAFT2"
+    tp:causes-havoc="experimental">
+    <tp:added version="0.21.UNRELEASED">(draft 2)</tp:added>
     <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-      An interface for SASL authentication.
-    </tp:docstring>
+      <p>The type for a channel representing an authentication step with the
+        server. The actual authentication functionality is implemented by
+        the additional interface named in
+        <tp:member-ref>AuthenticationMethod</tp:member-ref>,
+        such as <tp:dbus-ref namespace="ofdT"
+          >Channel.Interface.SASLAuthentication.DRAFT2</tp:dbus-ref>.</p>
 
-    <property name="AuthenticationInformation"
-              tp:name-for-bindings="Authentication_Information"
-              type="a{sv}" access="read">
-      <tp:docstring>
-          Dictionary of information given by the CM which can be used by the
-          handler for authentication.
-      </tp:docstring>
-    </property>
+      <p>Future authentication steps also supported by this channel type might
+        include solving a captcha and/or agreeing to an EULA or terms-of-use
+        document; each of these would be represented by a channel with this
+        type, but a different
+        <tp:member-ref>AuthenticationMethod</tp:member-ref>.</p>
 
-    <property name="AuthenticationMethod"
-              tp:name-for-bindings="Authentication_Method"
-              type="u" tp:type="Authentication_Type" access="read">
-      <tp:docstring>
-        This property defines the Method used for the current
-        authentication step. The method also defines which Interfaces
-        the channel implements. For exmaple if for the SASL method the
-        SaslAuthentication interface needs to be implemented.
-      </tp:docstring>
-    </property>
+      <p>Channels of this type SHOULD be signalled and dispatched while the
+        <tp:dbus-ref namespace="ofdT">Connection</tp:dbus-ref> owning them is in
+        the CONNECTING state. Normally, only one channel of this type will
+        exist on a given Connection; if there is more than one, the handler
+        must complete authentication with each of them in turn.</p>
 
-    <tp:enum name="Authentication_Type" type="u">
-      <tp:enumvalue suffix="Sasl" value="0">
-        <tp:docstring>
-          SASL authentication.
-        </tp:docstring>
-      </tp:enumvalue>
-      <tp:enumvalue suffix="Captcha" value="1">
-        <tp:docstring>
-          Captcha authentication.
-        </tp:docstring>
-      </tp:enumvalue>
-    </tp:enum>
+      <p>Channels of this type cannot be requested with methods such as
+        <tp:dbus-ref
+          namespace="ofdT.Connection.Interface.Requests">CreateChannel</tp:dbus-ref>.
+        They always have <tp:dbus-ref
+          namespace="ofdT.Channel">Requested</tp:dbus-ref> = False,
+        <tp:dbus-ref
+          namespace="ofdT.Channel">TargetHandleType</tp:dbus-ref> = None
+        and <tp:dbus-ref
+          namespace="org.freedesktop.Telepathy.Channel">TargetHandle</tp:dbus-ref>
+        = 0.</p>
 
-    <tp:mapping name="AuthDetails" array-name="AuthDetails_List">
-      <tp:docstring>
-        An extensible map representing details provided by the server for
-        authentication.
-      </tp:docstring>
+      <p>The Connection MUST NOT proceed with connection, or signal
+        <tp:dbus-ref namespace="ofdT.Connection">StatusChanged</tp:dbus-ref>
+        to the CONNECTED state, until each channel of this type has either
+        been accepted as having a positive result (for instance, on SASL
+        channels this is done with the <tp:dbus-ref
+          namespace="ofdT.Channel.Interface.SASLAuthentication.DRAFT2"
+          >AcceptSASL</tp:dbus-ref> method), or closed with the <tp:dbus-ref
+          namespace="ofdT.Channel">Close</tp:dbus-ref> method.</p>
+
+      <tp:rationale>
+        <p>ServerAuthentication channels normally represent the client
+          authenticating itself to the server, but can also be used for the
+          server to authenticate itself to the client (i.e. prove that it is
+          in fact the desired server and not an imposter). Until the
+          authentication handler has confirmed this, connection should not
+          continue.</p>
+      </tp:rationale>
 
-      <tp:member type="s" name="Key">
-        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          <p>
-            Well-known keys:
-            <dl>
-              <dt>username</dt>
-              <dd>
-                string, Username to authenticate with if needed
-              </dd>
-              <dt>realm</dt>
-              <dd>
-                string, Realm to use for authentication if needed
-              </dd>
-              <dt>session-id</dt>
-              <dd>
-                XMPP session id as needed for the legacy jabber digest method.
-              </dd>
-            </dl>
-          </p>
-        </tp:docstring>
-      </tp:member>
+      <p>If a channel of this type is closed with the <tp:dbus-ref
+            namespace="ofdT.Channel">Close</tp:dbus-ref> method before
+        authentication has succeeded, this indicates that the Handler has
+        given up its attempts to authenticate or that no Handler is
+        available.</p>
 
-      <tp:member name="Value" type="v">
-      </tp:member>
-    </tp:mapping>
+      <p>If this occurs, the connection manager MAY attempt to continue
+        connection (for instance, performing SASL authentication by using any
+        credentials passed to <tp:dbus-ref
+          namespace="ofdT.ConnectionManager">RequestConnection</tp:dbus-ref>,
+        for instance from the <tp:dbus-ref
+          namespace="ofdT">Account.Parameters</tp:dbus-ref>). If this fails
+        or has already been tried, the <tp:dbus-ref
+          namespace="ofdT">Connection</tp:dbus-ref> will
+        disconnect.</p>
+
+      <tp:rationale>
+        <p>In particular, the <tp:dbus-ref
+            namespace="ofdT">ChannelDispatcher</tp:dbus-ref> will close the
+          channel if it cannot find a handler.</p>
+      </tp:rationale>
+    </tp:docstring>
+
+    <property name="AuthenticationMethod"
+              tp:name-for-bindings="Authentication_Method"
+              type="s" tp:type="DBus_Interface" access="read">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>This property defines the method used for the authentication step
+          represented by this channel, which MUST be one of this channel's
+          <tp:dbus-ref namespace="ofdT.Channel">Interfaces</tp:dbus-ref>.</p>
+
+        <p>The initially-defined interface that can be used here is
+          <tp:dbus-ref namespace="ofdT"
+            >Channel.Interface.SASLAuthentication.DRAFT2</tp:dbus-ref>.</p>
+      </tp:docstring>
+    </property>
 
   </interface>
 </node>
diff --git a/extensions/Makefile.am b/extensions/Makefile.am
index e00442dbd..f217b6680 100644
--- a/extensions/Makefile.am
+++ b/extensions/Makefile.am
@@ -17,7 +17,7 @@ EXTRA_DIST = \
     Gabble_Plugin_Test.xml \
     OLPC_Activity_Properties.xml \
     OLPC_Buddy_Info.xml \
-    Channel_Interface_Sasl_Authentication.xml \
+    Channel_Interface_SASL_Authentication.xml \
     Channel_Type_Server_Authentication.xml
 
 noinst_LTLIBRARIES = libgabble-extensions.la
diff --git a/extensions/all.xml b/extensions/all.xml
index 680ba7b32..00d3f02c1 100644
--- a/extensions/all.xml
+++ b/extensions/all.xml
@@ -53,7 +53,7 @@ Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA</p>
 <xi:include href="Channel_Type_Call.xml" />
 
 <xi:include href="Channel_Type_Server_Authentication.xml" />
-<xi:include href="Channel_Interface_Sasl_Authentication.xml" />
+<xi:include href="Channel_Interface_SASL_Authentication.xml" />
 
 <tp:generic-types>
   <tp:external-type name="Contact_Handle" type="u"