1
0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-25 10:42:19 -05:00
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@440 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-01-29 16:27:48 +00:00
parent e91378b24a
commit cba1dd9f45

View File

@ -22,6 +22,12 @@
<shortname>N/A</shortname> <shortname>N/A</shortname>
&stpeter; &stpeter;
&pgmillard; &pgmillard;
<revision>
<version>0.6</version>
<date>2007-01-29</date>
<initials>psa</initials>
<remark><p>Allowed client to not include an authorization identity if the certificate contains no XMPP address (thus depending on the server to assign the identity).</p></remark>
</revision>
<revision> <revision>
<version>0.5</version> <version>0.5</version>
<date>2007-01-25</date> <date>2007-01-25</date>
@ -161,7 +167,7 @@
]]></code> ]]></code>
</li> </li>
<li> <li>
<p>Because client presented a certificate, client SHOULD consider EXTERNAL to be its preferred SASL mechanism. Note: If the client certificate includes only one XMPP address and the user wishes to authorize as the identity that has been authenticated by the TLS layer (i.e., the XMPP address that is contained in the client certificate), then the client SHOULD NOT include an authorization identity (i.e., the XML character data for the <auth/> element SHOULD be "=", indicating an empty response); however, if the client certificate contains either no XMPP address or more than one XMPP address, or if the user wishes to authorize as another identity, then the client MUST include an authorization identity.</p> <p>Because client presented a certificate, client SHOULD consider EXTERNAL to be its preferred SASL mechanism. If the client certificate includes only one XMPP address and the user wishes to authorize as the identity that has been authenticated by the TLS layer (i.e., the XMPP address that is contained in the client certificate), then the client SHOULD NOT include an authorization identity (i.e., the XML character data for the <auth/> element SHOULD be "=", indicating an empty response); if the client certificate contains more than one XMPP address or if the user wishes to authorize as another identity, then the client MUST include an authorization identity; if the client certificate contain no XMPP address, then the client SHOULD include an authorization identity (but MAY include no authorzation identity since the client may not even know its identity, instead having it assigned by the server).</p>
<code><![CDATA[ <code><![CDATA[
<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='EXTERNAL'>=</auth> <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='EXTERNAL'>=</auth>
]]></code> ]]></code>
@ -200,7 +206,7 @@
</failure> </failure>
</stream:stream> </stream:stream>
]]></code> ]]></code>
<p>If JID mapping is successful but the mapped JID does not match the authorization identity provided, then the server MUST return a SASL failure case of &lt;invalid-authzid/&gt; and close the stream.</p> <p>If JID mapping is successful but the mapped JID does not match the authorization identity provided (if any), then the server MUST return a SASL failure case of &lt;invalid-authzid/&gt; and close the stream.</p>
<code><![CDATA[ <code><![CDATA[
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<invalid-authzid/> <invalid-authzid/>
@ -348,7 +354,7 @@
<p>This document requires no interaction with the &REGISTRAR;.</p> <p>This document requires no interaction with the &REGISTRAR;.</p>
</section1> </section1>
<section1 topic='Acknowledgements' anchor='ack'> <section1 topic='Acknowledgements' anchor='ack'>
<p>Thanks to Dave Cridland, Phillip Hancke, Justin Karneges, Rob Norris, and Matthias Wimmer for their comments.</p> <p>Thanks to Dave Cridland, Phillip Hancke, Joe Hildebrand, Justin Karneges, Rob Norris, and Matthias Wimmer for their comments.</p>
</section1> </section1>
<section1 topic='Author Note' anchor='authornote'> <section1 topic='Author Note' anchor='authornote'>
<p>Peter Millard, co-author of the initial version of this specification, died on April 26, 2006. The remaining author appreciates his assistance in defining the best practices described herein.</p> <p>Peter Millard, co-author of the initial version of this specification, died on April 26, 2006. The remaining author appreciates his assistance in defining the best practices described herein.</p>