mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-13 21:05:09 -05:00
515 lines
53 KiB
XML
515 lines
53 KiB
XML
<?xml version='1.0' encoding='UTF-8'?>
|
|
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
|
<!ENTITY % ents SYSTEM 'xep.ent'>
|
|
%ents;
|
|
]>
|
|
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
|
<xep>
|
|
<header>
|
|
<title>Account Management</title>
|
|
<abstract>This specification provides a collection of stream features meant to manage one's account, in particular for account registration, deletion and change of password.</abstract>
|
|
<legal>
|
|
<copyright>This XMPP Extension Protocol is copyright (c) 1999 - 2011 by the XMPP Standards Foundation (XSF).</copyright>
|
|
<permissions>Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.</permissions>
|
|
<warranty>## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. In no event shall the XMPP Standards Foundation or the authors of this Specification be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. ##</warranty>
|
|
<liability>In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising out of the use or inability to use the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.</liability>
|
|
<conformance>This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at <<link url='http://www.xmpp.org/extensions/ipr-policy.shtml'>http://www.xmpp.org/extensions/ipr-policy.shtml</link>> or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA).</conformance>
|
|
</legal>
|
|
<number>xxxx</number>
|
|
<status>ProtoXEP</status>
|
|
<type>Standards Track</type>
|
|
<sig>Standards</sig>
|
|
<approver>Council</approver>
|
|
<dependencies>
|
|
<spec>XMPP Core</spec>
|
|
</dependencies>
|
|
<supersedes><spec>XEP-0077</spec></supersedes>
|
|
<supersededby/>
|
|
<shortname>NOT_YET_ASSIGNED</shortname>
|
|
<author>
|
|
<firstname>Jehan</firstname>
|
|
<surname>Pages</surname>
|
|
<email>hysseo@zemarmot.net</email>
|
|
<jid>hysseo@zemarmot.net</jid>
|
|
</author>
|
|
<revision>
|
|
<version>0.0.1</version>
|
|
<date>2011-07-17</date>
|
|
<initials>jp</initials>
|
|
<remark><p>First draft.</p></remark>
|
|
</revision>
|
|
</header>
|
|
<section1 topic='Introduction' anchor='intro'>
|
|
<p>The XMPP protocols has long had an extension for in-band account management (&xep0077;). Nevertheless, although this extension has known a wide, though usually incomplete, implementation and usage in servers and clients, it lacks the most basic security and flexibility. The present extension protocol defines a new approach, closer to XMPP's design; also it provides highly secure credential exchanges, made possible by late SASL technologies, such as the SCRAM family's mechanisms (Mandatory-To-Implement technology since &rfc6120;); and finally it keeps an open design, in the great modular tradition of XMPP, so that future account management extensions will be easily added, without breaking previous implementations.</p>
|
|
</section1>
|
|
<section1 topic='Issues with XEP-0077' anchor='rules'>
|
|
<p><cite>XEP-0077</cite> is so widely implemented that it might seem undesirable to change it. Nevertheless it showed a lot of weaknesses over time and there are very few full implementations (often, only the account registration part is implemented. Account deletion and password management are usually dealt in other means, for instance with &xep0050;). This is why it predicted its own obsolecence: "Furthermore, this document should be deprecated as soon as a successor protocol is defined and implemented" (section 10. "Security Considerations" of <cite>XEP-0077</cite>). The present extension plans on being this "successor protocol".</p>
|
|
<section2 topic='Design Issues' anchor='design'>
|
|
<p>&xep0134; clearly states that "XMPP is Sacred", in the meaning that extensions MUST NOT break the basic design of XMPP. <cite>XEP-0077</cite> proposes to send IQ stanzas, qualified with the content namespace, on an incompletely negotiated stream, which is contradictory to <cite>RFC-6120</cite>'s basic concepts (section 4.3.1): "At a minimum, the initiating entity needs to authenticate with the receiving entity before it is allowed to send stanzas to the receiving entity". This is not a specification violation as section 4.3.5 allows exceptions to this rule for stanzas sent to the initiating entity itself or its server, yet it can be seen as a contradictory philosophy.
|
|
<br/>Moreover it attempts to be considered as a stream feature, but indicates that the stream feature advertisement is not mandatory and the namespace advertised in the <stream:features/> is not reused during the feature negotiation. Finally the queries can be used either authenticated or unauthenticated. These various lacks of consistency are somewhat annoying.</p>
|
|
</section2>
|
|
<section2 topic='Lack of Flexibility' anchor='lack-flexibility'>
|
|
<p>Even though we could pass on the blasphemy over XMPP design, and would want to build over <cite>XEP-0077</cite> to support secure features of newer SASL mechanisms, it would require a way to extend <cite>XEP-0077</cite> without breaking existing implementations. This is unfortunately made impossible by built-in strict restrictions and a rigid syntax preventing us from doing any useful extension.</p>
|
|
<section3 topic='Rigid Syntax' anchor='rigidity'>
|
|
<p>Extensions are allowed through the use of &xep0004; only. <cite>Data Forms</cite> are flexible for humans, yet security requires explicit definitions and automatic computations of cryptographic algorithms, which is impossible with generic <cite>Data Forms</cite>. Also we are not allowed to define new credential exchanges, other than with raw password, which is highly unsecure: "A host MUST NOT add new fields to the 'jabber:iq:register' namespace; instead, extensibility SHOULD be pursued via the Data Forms protocol as specified herein" (section 4. Extensibility).</p>
|
|
</section3>
|
|
<section3 topic='Single Feature Defined' anchor='single-featured'>
|
|
<p>The namespace has only one stream feature defined. In particular no differentiation is made between creation, deletion and modification of an account. Also the namespace does not follow &rfc4854; format, making versionning of the protocol impossible. Hence any client would be unable to determine whether the server understands or not the current extension, and which part, resulting inevitably in incompatible implementations, unless a new URN namespace was created, which is equivalent to create a new extension anyway.</p>
|
|
</section3>
|
|
<p>As a consequence of these various points, it makes more sense to design this new extension from scratch, adapted to XMPP design and flexibility.</p>
|
|
</section2>
|
|
</section1>
|
|
<section1 topic='Requirements' anchor='reqs'>
|
|
<p><strong>Account Management</strong>, defined herein as a collection of stream features, is designed to meet the following requirements:</p>
|
|
<ol>
|
|
<li>if a credentials exchange is necessary, render this exchange as secure as possible;</li>
|
|
<li>define the management protocol as flexible as possible, in order to allow new features, as well as improvement of existing features;</li>
|
|
<li>account registration in particular should be possible without being authenticated, as a stream feature.</li>
|
|
</ol>
|
|
</section1>
|
|
<section1 topic='Glossary' anchor='glossary'>
|
|
<dl>
|
|
<di>
|
|
<dt>Account Management</dt>
|
|
<dd>Gestion of a client XMPP account on a given server deployment. An account is being defined by the locale part of the JID, and by the authentication mechanisms available for this account.</dd>
|
|
</di>
|
|
<di><dt>In-Band</dt>
|
|
<dd>Capacity of acting directly through a XMPP stream. As a consequence, an In-Band Account Management MAY allow users to bootstrap the existence of their account, and oppositely to end it, or modify it, without ever having to use another medium (like the web for instance), or without the existence of a previous account.</dd></di>
|
|
<di><dt>Storage Mechanism</dt>
|
|
<dd>The internal logics of a server to store authentication data.</dd></di>
|
|
</dl>
|
|
</section1>
|
|
<section1 topic='Use Cases' anchor='usecases'>
|
|
<section2 topic="Account Creation" anchor='creation'>
|
|
<p>A XMPP account usually consists of a <cite>JID</cite> and the <em>secret</em> necessary to impersonate it, in other words <strong>credentials</strong>. While this secret is most often a password, it may consists of other means, for instance a client certificate. Moreover even a password does not necessarily mean that the server should ever have knowledge of the actual password. Modern authentication mechanisms indeed allow a user to be recognized as the rightfull owner of an account by asymetric cryptographic algorithms or other similar technologies. The current extension allows an exchange of only the necessary data which the server should know to recognize an account owner, without ever accessing the actual password. For this to be possible, a server should be able to advertize the ways credentials can be stored.</p>
|
|
<p>In order to advertize these storage mechanisms, the server MUST list them as children of the account <registration/> feature, qualified with the protocol namespace, before authentication.</p>
|
|
<example caption='After successful TLS encryption, server sends SASL and account registration stream features.'><![CDATA[
|
|
<stream:features>
|
|
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
|
|
<mechanism>SCRAM-SHA-1</mechanism>
|
|
<mechanism>SCRAM-SHA-1-PLUS</mechanism>
|
|
<mechanism>SCRAM-SHA-256</mechanism>
|
|
<mechanism>SCRAM-SHA-256-PLUS</mechanism>
|
|
<mechanism>PLAIN</mechanism>
|
|
</mechanisms>
|
|
<registration xmlns='urn:xmpp:account:0'>
|
|
<storage>SCRAM-SHA-1</storage>
|
|
<storage>SCRAM-SHA-256</storage>
|
|
<storage>PLAIN</storage>
|
|
</registration>
|
|
</stream:features>
|
|
]]></example>
|
|
<p>The user wants to create a new account, using a password. Storing data as both SCRAM-SHA-256 and SCRAM-SHA-1 garanties all authentication possibilities, still keeping a secure credential exchange. Hence the client requests to store in both mechanisms.</p>
|
|
<example caption='client sends a registration demand, using 2 storages.'><![CDATA[
|
|
<register xmlns='urn:xmpp:account:0'>
|
|
<storage>SCRAM-SHA-256</storage>
|
|
<storage>SCRAM-SHA-1</storage>
|
|
</register>
|
|
]]></example>
|
|
<example caption='The server accepts both storages and sends along some instructions.'><![CDATA[
|
|
<proceed xmlns='urn:xmpp:account:0'>
|
|
<instructions>Try a long password, which is not a dictionnary word,
|
|
using at least one uppercase, one lowercase, one number and one special character.</instructions>
|
|
<storage>SCRAM-SHA-256</storage>
|
|
<storage>SCRAM-SHA-1</storage>
|
|
</proceed>
|
|
]]></example>
|
|
<p>Note: the server could refuse one storage if another requested storage is compatible and more secure. In the current use case, if the user had requested the three storage (<cite>PLAIN</cite>, <cite>SCRAM-SHA-1</cite> and <cite>SCRAM-SHA-256</cite>), the server SHOULD answer to proceed only with <cite>SCRAM-SHA-1</cite> and <cite>SCRAM-SHA-256</cite>, the exchange being by far more secure, and equivalent in authentication posssibilities.</p>
|
|
<example caption='The client sends the storage data for these mechanisms.'><![CDATA[
|
|
<complete xmlns='urn:xmpp:account:0'>
|
|
<login>jehan</login>
|
|
<store mechanism="SCRAM-SHA-256">
|
|
<stored-key>XXXX</stored-key>
|
|
<server-key>YYYY</server-key>
|
|
</store>
|
|
<store mechanism="SCRAM-SHA-1">
|
|
<stored-key>XXXX</stored-key>
|
|
<server-key>YYYY</server-key>
|
|
</store>
|
|
</complete>
|
|
]]></example>
|
|
<p>Note: following the same logics as <cite>RFC-6120</cite> (section 6.3.7 "Simple User Name"), in the absence of specific information for a given server deployment, the client SHOULD assume that the login is the localpart of the desired JID. In the case of a server hosting several domains, the value of the 'to' attribute of the initiation opening stream MUST be used by the server to determine the service where the registration occurs ('to' is mandatory in initial stream headers, as described in section 4.7.2 or <cite>RFC-6120</cite>).</p>
|
|
<example caption='Case 1: the server acknowledges the completion of the registration.'><![CDATA[
|
|
<registered xmlns='urn:xmpp:account:0'>
|
|
<login>jehan@shakespeare.lit</login>
|
|
<stored mechanism="SCRAM-SHA-1"/>
|
|
<stored mechanism="SCRAM-SHA-256"/>
|
|
</registered>
|
|
]]></example>
|
|
<p>Following success of a registration, the stream MUST be restarted. If the 'from' parameter was empty in the previous stream opening tag, and if the current connection is encrypted, the new stream header SHOULD contain a 'from' attribute filled with the newly created JID (as described in <cite>RFC-6120</cite>, section 4.7.1).</p>
|
|
<example caption='Case 2: server informs of failure'><![CDATA[
|
|
<failure xmlns='urn:xmpp:account:0' />
|
|
]]></example>
|
|
</section2>
|
|
<section2 topic="Account Deletion" anchor='deletion'>
|
|
<p>If a server wishes to provide in-band account deletion, it MUST advertize the <deletion/> feature, qualified with the protocol namespace, after authentication.</p>
|
|
<example caption='After successful SASL authentication, server advertizes the resource binding, the deletion and the account modification stream features.'><![CDATA[
|
|
<stream:features>
|
|
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
|
|
<deletion xmlns='urn:xmpp:account:0' />
|
|
<modification xmlns='urn:xmpp:account:0'>
|
|
<storage>EXTERNAL</storage>
|
|
<storage>SCRAM-SHA-1</storage>
|
|
<storage>SCRAM-SHA-256</storage>
|
|
</modification>
|
|
</stream:features>
|
|
]]></example>
|
|
<p>After stream features have been advertized, a user can require the deletion of one's account.</p>
|
|
<example caption='client sends a deletion demand'><![CDATA[
|
|
<delete xmlns='urn:xmpp:account:0' />
|
|
]]></example>
|
|
<p>Note: this protocol does not define management of other user's account, as could do an administrator on a server, but management of one's own account. As a consequence, even when a user has administration power, this feature provides no way to delete a user account other than the one currently authenticated (if needed, such a feature should be defined in another XEP, or may be implemented with generic capabilities as ad-hoc commands). Nevertheless as detailed in section 4.3.6 "Determination of Addresses" of <cite>RFC-6120</cite>, if an authorization identity different from the authentication identity is used during the SASL negotiation, the authorization identity is used to determine the client's address. Consequently an administrator who has the permissions to impersonate users through SASL authentication can delete a user account this way.</p>
|
|
<example caption='Case 1: server informs of successful deletion'><![CDATA[
|
|
<deleted xmlns='urn:xmpp:account:0'>
|
|
<instructions>Too bad! Hope to see you back soon in our services!</instructions>
|
|
<login>juliet@shakespeare.lit</login>
|
|
</deleted>
|
|
]]></example>
|
|
<p>Note: after a successful deletion, if this JID had resources currently authenticated on the server, the server should close their stream with a 'not-authorized' stream error (with optional additional message to inform that the account has been closed).</p>
|
|
<example caption='Case 2: server informs of failure'><![CDATA[
|
|
<failure xmlns='urn:xmpp:account:0' />
|
|
]]></example>
|
|
</section2>
|
|
<section2 topic="Account modification" anchor='change'>
|
|
<p>An account modification is used for three reasons:</p>
|
|
<ol>
|
|
<li>the user wants to change its password;</li>
|
|
<li>the user wants to change the storage mechanisms;</li>
|
|
<li>the server wants to force or encourage users to change their password or their storage mechanisms.</li>
|
|
</ol>
|
|
<p>The two first reasons will lead basically to the same procedure. After the stream features have been advertized, a user might decide to change its credential, wherever he changes only the password, only the storage mechanism or both does not change in the server's point of view (in some storage mechanisms, the server may not be aware of the actual password, hence it may be unable to determine whether the password stayed the same).</p>
|
|
<example caption='client sends a modification demand, using 2 storages.'><![CDATA[
|
|
<modify xmlns='urn:xmpp:account:0' />
|
|
<storage>SCRAM-SHA-256</storage>
|
|
<storage>SCRAM-SHA-1</storage>
|
|
</modify>
|
|
]]></example>
|
|
<p>The rest of the exchange highly ressembles an account creation process.</p>
|
|
<example caption='The server accepts both storages and sends along some instructions.'><![CDATA[
|
|
<proceed xmlns='urn:xmpp:account:0'>
|
|
<instructions>Try a long password, which is not a dictionnary word,
|
|
using at least one uppercase, one lowercase, one number and one special character.</instructions>
|
|
<storage>SCRAM-SHA-256</storage>
|
|
<storage>SCRAM-SHA-1</storage>
|
|
</proceed>
|
|
]]></example>
|
|
<example caption='The client sends the storage data for these mechanisms.'><![CDATA[
|
|
<complete xmlns='urn:xmpp:account:0'>
|
|
<store mechanism="SCRAM-SHA-256">
|
|
<stored-key>XXXX</stored-key>
|
|
<server-key>YYYY</server-key>
|
|
</store>
|
|
<store mechanism="SCRAM-SHA-1">
|
|
<stored-key>XXXX</stored-key>
|
|
<server-key>YYYY</server-key>
|
|
</store>
|
|
</complete>
|
|
]]></example>
|
|
<example caption='Case 1: server informs of successful modification'><![CDATA[
|
|
<modified xmlns='urn:xmpp:account:0'>
|
|
<instructions>Credentials successfully modified!</instructions>
|
|
<stored>SCRAM-SHA-1</stored>
|
|
<stored mechanism="SCRAM-SHA-256"/>
|
|
</modified>
|
|
]]></example>
|
|
<example caption='Case 2: server informs of failure'><![CDATA[
|
|
<failure xmlns='urn:xmpp:account:0' />
|
|
]]></example>
|
|
</section2>
|
|
</section1>
|
|
<section1 topic='Detailed Protocol Description' anchor='rules'>
|
|
<p>The following section describes exhaustively the possibilities of the three features described in this extension and possibilities of extensions.</p>
|
|
<section2 topic="Registration Feature" anchor='detailed-registration'>
|
|
<section3 topic='Feature Advertising' anchor='registration-advertising'>
|
|
<p>If the feature is implemented, it MUST be advertised as a stream feature before the authentication. Though the feature MAY be advertised before any stream encryption, it is adviced to advertise it only after, for obvious security reasons.</p>
|
|
<p>By definition, this feature MUST always be considered as optional.</p>
|
|
<p>Even when any in-band account management is undesired on a given deployment, rather than disabling completely the feature altogether, it is preferred to advertise it and provide suitable alternatives, either a human readable message, a redirection (using &xep0066;), or both in order for a user to know how one can manage one's account. Note that only these two kinds of alternatives are defined in the present document, but other alternative contents may be defined in further versions of this protocol, or in other protocols. As a consequence, if an alternative is not understood, the client SHOULD silently ignore it.</p>
|
|
<example caption='The server acknowledges two alternative registration methods.'><![CDATA[
|
|
<stream:features>
|
|
[...]
|
|
<registration xmlns='urn:xmpp:account:0'>
|
|
<alternative>
|
|
<x xmlns='jabber:x:oob'>
|
|
<desc>To register, visit https://www.shakespeare.lit/register.html</desc>
|
|
<url>https://www.shakespeare.lit/register.html</url>
|
|
</x>
|
|
</alternative>
|
|
<alternative>
|
|
<instructions>In case of any problem to register, contact our support at support@shakespeare.lit!</instructions>
|
|
</alternative>
|
|
</registration>
|
|
[...]
|
|
<stream:features>
|
|
]]></example>
|
|
<p>If in-band registration is possible, the available <storage/> mechanisms MUST be advertised as childs of the <registration/> tag.</p>
|
|
<example caption='The server acknowledges two different storage mechanisms.'><![CDATA[
|
|
<stream:features>
|
|
[...]
|
|
<registration xmlns='urn:xmpp:account:0'>
|
|
<storage>PLAIN</storage>
|
|
<storage>SCRAM-SHA-1</storage>
|
|
</registration>
|
|
[...]
|
|
<stream:features>
|
|
]]></example>
|
|
<p>Note: though storage mechanisms actually look like SASL mechanisms, they are slightly different, which is why the "mechanism" keyword used by the SASL stream feature has not been re-used, in an attempt to clearly distinguish both. Indeed this extension wishes to differentiate the storage logics and the actual authentication mechanism used, because some storage logics allows several SASL mechanisms to be used. In particular the <cite>PLAIN</cite> storage, though the less secure password exchange and storage, is the most flexible as it allows any kind of SASL mechanism (with password) afterwards. On the other hand, the <cite>SCRAM-SHA1</cite> storage will allow the use of the SASL <cite>SCRAM-SHA1</cite>, <cite>SCRAM-SHA1-PLUS</cite>, but also the <cite>PLAIN</cite> mechanisms.</p>
|
|
<p>Note 2: the <registration/> feature MUST contain at least one <storage> child, or one <alternative> child, or any mix of one of several <alternative> and <storage>. If only <alternative> children are available, then no In-Band registration is possible on this server, but a user wishing to register an account on this server should be presented with the different alternatives (which can be either a URI presented with an optional description, as described in <cite>Out-of-Band Data</cite> or a human-readable text in an <instructions> child). In this case, nothing is to be negotiated and the client SHOULD close the stream without an error.</p>
|
|
</section3>
|
|
<section3 topic='Request a Registration' anchor='request-registration'>
|
|
<p>If the client detects one or more known storage mechanisms that satisfies its security requirements, it MUST initiate the feature negotiation by a <register/> tag, qualified by the feature namespace, and containing the desired <storage> mechanisms.</p>
|
|
<example caption='The server acknowledges requests a SCRAM-SHA-1 storage.'><![CDATA[
|
|
<register xmlns='urn:xmpp:account:0'>
|
|
<mechanism>SCRAM-SHA-1</mechanism>
|
|
</register>
|
|
]]></example>
|
|
</section3>
|
|
<section3 topic='Optional: additional informations' anchor='additional-before'>
|
|
<p>As an optional step, before going further into registration, the server can request additional information in a <challenge> tag. The contents of this tag can be:</p>
|
|
<ul>
|
|
<li>a data form (as described in &xep0004;) <x/> tag as a direct child that the user is expected to fill. A deployment could therefore propose (or require) to enter various information, for instance real name, address, and so on;</li>
|
|
<li>an <instructions/> tag giving various human-readable information (without requiring any data to be filled);</li>
|
|
<li>an <cite>Out-of-Band Data</cite> link, with optional <desc/> can be used for instance to ask a user to click a given link before going further, which could be for instance an http link with a random question (captcha) to confirm you are not a machine;</li>
|
|
<li>a <cite>Captcha Forms</cite> (see &xep0158;) directly embedded in XMPP for the same purpose.</li>
|
|
</ul>
|
|
<p>Further versions of this protocol or other extensions may add new type of possible contents.</p>
|
|
<example caption='The server sends a form challenge.'><![CDATA[
|
|
<challenge xmlns='urn:xmpp:account:0'>
|
|
<x xmlns='jabber:x:data' type='form'>
|
|
<title>User Information</title>
|
|
<instructions>These information are only used for verification purpose and won't be ever divulgated to any third party.</instructions>
|
|
<field type='text-single'
|
|
label='Display name (optional)'
|
|
var='display-name'/>
|
|
<field type='text-single'
|
|
label='Email (must be a valid email)'
|
|
var='email'/>
|
|
</x>
|
|
</challenge>
|
|
]]></example>
|
|
<p>A single <challenge> MUST contains only one child. If the client is not able to understand the contents of a challenge, it must return <unknown-challenge/>, to which the receiving entity can either answer by sending another <challenge/>, or with a <failure> if this <unknown-challenge> is considered a terminale failure.</p>
|
|
<example caption='Case 1: the client does not understand the challenge.'><![CDATA[
|
|
<unknown-challenge xmlns='urn:xmpp:account:0'/>
|
|
]]></example>
|
|
<example caption='If it is considered a terminale error, the receiving entity returns a failure.'><![CDATA[
|
|
<failure xmlns='urn:xmpp:account:0'/>
|
|
]]></example>
|
|
<p>Upon receiving a <failure>, the account creation failed and the feature negotiation ends. Unless the client can attempt another feature negotiation, it should close the XMPP stream.</p>
|
|
<example caption='Case 2: the client understands the challenge and the user fills the form.'><![CDATA[
|
|
<response xmlns='urn:xmpp:account:0'>
|
|
<x xmlns='jabber:x:data' type='submit'>
|
|
<field var='display-name'><value>Jehan</value></field>
|
|
<field var='email'><value>jehan@shakespeare.lit</value></field>
|
|
</x>
|
|
</challenge>
|
|
]]></example>
|
|
<p>If a challenge awaits for no response, for instance if the challenge consists only on <instructions> or <cite>Out-of-Band Data</cite>, the client must still return an empty <response/>in order to acknowledge the challenge and pass to the next one. For instance, if the challenge are instructions or a link, the <response/> MUST be sent only when the user acknowledged reading the instructions or the link (on a typical UI, usually by clicking a button).</p>
|
|
<example caption='The server sends a oob challenge.'><![CDATA[
|
|
<challenge xmlns='urn:xmpp:account:0'>
|
|
<x xmlns='jabber:x:oob'>
|
|
<desc>Thanks for your interest.
|
|
If you want to know more about our services before registering,
|
|
visit our website.</desc>
|
|
<url>https://www.shakespeare.lit/our_im_service.html</url>
|
|
</x>
|
|
</challenge>
|
|
]]></example>
|
|
<example caption='Case 2: the client acknowledges the challenge.'><![CDATA[
|
|
<response xmlns='urn:xmpp:account:0' />
|
|
]]></example>
|
|
<p>Upon receiving a challenge response, the server can either send a <failure/> if the response is not considered acceptable and unrecoverable, another challenge (either because the previous challenge failed but the issue is recoverable, or because several challenge are necessary), or ends the challenge step.</p>
|
|
</section3>
|
|
<section3 topic='Registration Step' anchor='register'>
|
|
<p>After all pre-challenges are accepted, the server asks the client to <proceed/>. The children are the <storage> mechanisms which the user wants the client to exchange. These mechanisms MUST be a subset of the ones requested by the client in the <register/>. In particular, there can be less <storage/> if some of them are considered irrelevant when others will be exchanged. The server MAY add one or several human-readable <instructions/> depending on the kind of data expected to be presented by the user.</p>
|
|
<example caption='The server asks the client to proceed with registration.'><![CDATA[
|
|
<proceed xmlns='urn:xmpp:account:0'>
|
|
<instructions>Try a long password, which is not a dictionnary word, and using at least one uppercase, one lowercase, one number and one special character (for instance, an underscore, an hyphen, a period, a comma or a space).</instructions>
|
|
<storage>SCRAM-SHA-1</storage>
|
|
</proceed>
|
|
]]></example>
|
|
<p>The client sends the credentials data. This part is discussed later in <link url='#mechanisms'>Defined Storage Mechanisms</link>.</p>
|
|
<p>If the credentials sent by the client are not acceptable and the error is considered unrecoverable by the server, it must send a <failure/>. Otherwise it must send again <proceed/> with the same <storage/>, and preferrably updated <instructions/> detailing what was wrong in the previously provided data.</p>
|
|
</section3>
|
|
<section3 topic='Optional: again additional information' anchor='additional-after'>
|
|
<p>After the Registration step, the server can again request new <challenge/> as described in <link url='#additional-before'>Optional: additional informations</link>.</p>
|
|
<p>Note: during a single registration, a server can request challenges before the registration step, or after, or before-and-after, or none at all. Any combination is possible.</p>
|
|
</section3>
|
|
<section3 topic='Registration Completed' anchor='registration-complete'>
|
|
<p>Once the registration is done and all challenges are answered, the server can finally acknowledge the successfull completion of the registration by a <registered/> tag. Its children will confirm the login in the form of the full JID as well as confirming the <stored/> mechanisms, and can optionally provide <instructions/> with human readable information.. Note that the registration is not complete as long as <registered/> has not been received (as such a registration can fail even after the user sent credentials).</p>
|
|
<example caption='The server acknowledge the success of the registration.'><![CDATA[
|
|
<registered xmlns='urn:xmpp:account:0'>
|
|
<instructions>Welcome to our services!
|
|
To get more information, you can also visit our web site:
|
|
https://shakespeare.li.</instructions>
|
|
<login>jehan@shakespeare.lit</login>
|
|
<stored mechanism="SCRAM-SHA1"/>
|
|
</registered>
|
|
]]></example>
|
|
</section3>
|
|
<section3 topic='Cancellation' anchor='cancel'>
|
|
<p>At all time, the client can cancel the registration before the end by sending an <abort/>, to which the server must return a <failure/></p>
|
|
<example caption='The client cancels the registration.'><![CDATA[
|
|
<abort xmlns='urn:xmpp:account:0'/>
|
|
]]></example>
|
|
<p>If cancellation comes from the server, this one directly sends a <failure/>.</p>
|
|
</section3>
|
|
</section2>
|
|
<section2 topic="Deletion Feature" anchor='detailed-deletion'>
|
|
<section3 topic='Feature Advertising' anchor='deletion-advertising'>
|
|
<p>If the feature is implemented, it MUST be advertised as a stream feature <strong>after</strong> the authentication. Though the feature MAY be used without any stream encryption, it is adviced to activate it only on encrypted stream, in order to prevent malevolent users from deleting highjacked accounts.</p>
|
|
<p>By definition, this feature MUST always be considered as optional.</p>
|
|
<p>Even when any in-band account management is undesired on a given deployment, rather than disabling completely the feature altogether, it is preferred to advertise it and provide suitable alternatives, either a human readable message, a redirection (using &xep0066;), or both in order for a user to know how one can delete one's account, especially as personal data deletion can be considered a security measure to protect private information and is legally mandatory in some countries. Note that only these two kinds of alternatives are defined in the present document, but other alternative contents may be defined in further versions of this protocol, or in other protocol. As a consequence, if an alternative is not understood, the client SHOULD silently ignore it.</p>
|
|
</section3>
|
|
<section3 topic='Deletion Process' anchor='deletion-process'>
|
|
<p>The full deletion process has no more options than described in <link url='#deletion'>Account Deletion</link>, except that -- same as for registration -- <link url='#additional-before'>additional <challenge/> tags</link> can be sent by the server and answered by the client between the <delete/> tag and the <deleted/> acknowledgement. This is particularly useful in order to protect users from inadvertently "click a button" and see their account definitely deleted. Of course a good client which is meant to be used by a human user should also provide protection to avoid this kind of mistake.</p>
|
|
</section3>
|
|
</section2>
|
|
<section2 topic="Modification Feature" anchor='detailed-modification'>
|
|
<section3 topic='Feature Advertising' anchor='modification-advertising'>
|
|
<p>If the feature is implemented, it MUST be advertised as a stream feature <strong>after</strong> the authentication. Though the feature MAY be used without any stream encryption, it is adviced to activate it only on encrypted stream, in order to prevent malevolent users from modifying highjacked accounts credentials, hence preventing its rightful user to later log-in.</p>
|
|
<p>Even when in-band account modification is undesired on a given deployment, rather than disabling completely the feature altogether, it is preferred to advertise it and provide suitable alternatives, either a human readable message, a redirection (using &xep0066;), or both in order for a user to know how one can modify one's account, especially as credentials modification can be considered a security measure. Note that only these two kinds of alternatives are defined in the present document, but other alternative contents may be defined in further versions of this protocol, or in other protocol. As a consequence, if an alternative is not understood, the client SHOULD silently ignore it.</p>
|
|
</section3>
|
|
<section3 topic='Modification Process' anchor='modification-process'>
|
|
<p>The full modification process has no more options than described in <link url='#modification'>Account Modification</link>, except that -- same as for registration -- <link url='#additional-before'>additional <challenge/> tags</link> can be sent by the server and answered by the client between the <modify/> tag and the <proceed/> then between <complete/> and <modified/>.</p>
|
|
</section3>
|
|
<section3 topic='Mandatory Modification' anchor='modification-required'>
|
|
<p>By default, this feature is optional. Nevertheless this protocol allows a modification to be a mandatory-to-negotiate feature before going further into stream negotiation by including an empty <required/> tag as recommended in section 4.3.2 of <cite>RFC-6120</cite>. This can be useful for instance on a service which has been targetted by an attack and it is believed some accounts may be compromised, hence the service would force any such account to modify their credentials.</p>
|
|
<p>Note: if the presumption of compromised accounts is very high, a fast move might be to reinitialize all passwords as soon as possible. But this is always not possible, for instance if the user has not provided any other way of contact (no other email, JID, address, etc.). In such a case, in order not to block user out of the service, it might be preferable to force them to make a new password themselves at their next connection.</p>
|
|
<p>Also some highly secure services would appreciate the possibility to force users to modify their credentials in a regular time span, even without any known compromision. For instance a governmental IM service could require the account credentials to be updated every three months.</p>
|
|
<example caption='After successful SASL authentication, server advertizes deletion (optional), account modification stream features (required), but no resource binding.'><![CDATA[
|
|
<stream:features>
|
|
<deletion xmlns='urn:xmpp:account:0' />
|
|
<modification xmlns='urn:xmpp:account:0'>
|
|
<required/>
|
|
<storage>EXTERNAL</storage>
|
|
<storage>SCRAM-SHA-1</storage>
|
|
<storage>SCRAM-SHA-256</storage>
|
|
</modification>
|
|
</stream:features>
|
|
]]></example>
|
|
<p>Optionally the <required/> element MAY have a <instructions/> or a <cite>Out-of-Band Data</cite> child, in particular if the service wishes to give an explanation of this required change.</p>
|
|
</section3>
|
|
<section3 topic='Recommended Modification' anchor='modification-recommended'>
|
|
<p>This protocol also defines an intermediary <recommended/> option meant to make users aware of security considerations. This can be used in particular if you wish to have your user aware of security issues about keeping the same password for too long, but without forcing them.
|
|
<br />Another use case could be when your service updated storage mechanisms and wish to propose you to update. For instance a server compliant to <cite>RFC-3920</cite> and which was mainly using DIGEST-MD5 (&rfc2831;) could have stored the password in a hash which would be incompatible for authentication with the more secure SCRAM-* mechanisms; moreover DIGEST-MD5 is now a deprecated mechanism considered highly unsecured (see &rfc6331;) and should be removed from usage as soon as possible.</p>
|
|
<p>In a <recommended/> use case, the server MAY want to propose part of the storage algorithms. For instance even when a server might still have a "DIGEST-MD5" storage mechanism implemented, when recommending a user to update to a better mechanism, it should obviously not propose the same problematic mechanism.</p>
|
|
<p>Optionally the <recommended/> element SHOULD have a <instructions/> or a <cite>Out-of-Band Data</cite> child, in particular if the service wishes to give an explanation of this recommended change.</p>
|
|
<example caption='After successful SASL authentication, server advertizes deletion and resource binding, and recommend account modification.'><![CDATA[
|
|
<stream:features>
|
|
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
|
|
<deletion xmlns='urn:xmpp:account:0' />
|
|
<modification xmlns='urn:xmpp:account:0'>
|
|
<recommended>
|
|
<instructions>We updated the storage of your password in a much more secure way, but it requires you to update it.</instructions>
|
|
</recommended>
|
|
<storage>SCRAM-SHA-1</storage>
|
|
<storage>SCRAM-SHA-256</storage>
|
|
</modification>
|
|
</stream:features>
|
|
]]></example>
|
|
<p>A compliant client receiving such a stream feature SHOULD either automatically update the password choosing its prefered storage mechanism in the list, if it is a client without human user or if it is able to compute the storage data without prompting the user (for instance because the client stores the password as plain text, thus is able to compute any other storage data), or prompt the user, displaying the <instructions/> message so that one can decide whether or not to do the update before completing stream negotiation.</p>
|
|
</section3>
|
|
</section2>
|
|
<section2 topic="Defined Storage Mechanisms" anchor='mechanisms'>
|
|
<p>This specification will define three storage mechanisms, two of them corresponding to the mandatory-to-implement technologies for SASL authentication. Any further storage mechanism can be defined in extensions to the current protocol. These mechanisms are used either in the registration or the modification features.</p>
|
|
<section3 topic="PLAIN mechanism" anchor="plain">
|
|
<p>The PLAIN mechanism simply sends the password as plain text, base64 encoded (to authorize characters which could be authorized in the password but would mess with XML). An empty password is obviously not authorized and will result in a <failure/> or a proposition to retry.</p>
|
|
<example caption='The client sends the storage data with PLAIN for password "Juliet, je t'M!".'><![CDATA[
|
|
<complete xmlns='urn:xmpp:account:0'>
|
|
<login>jehan</login>
|
|
<store mechanism="PLAIN">
|
|
<password>SnVsaWV0LCBqZSB0J00h</password>
|
|
</store>
|
|
</complete>
|
|
]]></example>
|
|
<p>Note: using this storage mechanism does not mean that the implementation will necessarily be stored as plain text on the server. The server may encode this data using other more or less secure encryption scheme. Nevertheless it still means that the server has had the password at some point and that this one passed as plain text over the network.</p>
|
|
</section3>
|
|
<section3 topic="SCRAM-* mechanisms" anchor="scram">
|
|
<p>The SASL SCRAM-* mechanism family has some very interesting features. In particular, it allows the server to store data enabling it to identify a user, without knowing the actual password, and even without being able to use this stored data to impersonate this user on another service. This is true even though the user may have used the same credentials on this third party service and if by extreme coincidence, this third party service used the same SASL mechanism, cryptographic hash function, salt and iteration count as the server. Thus this is a very secure mechanism which allows a user to trust a service for transmitting XMPP data, but avoiding to give it one's password (not necessarily because one think the service administrator may wish to impersonate you elsewhere, but also in case of database compromission). The following storage mechanism, named the same way as the corresponding SASL mechanism, allows the user to send only the strict required information for authentication to be possible without the server ever knowing the original password.</p>
|
|
<p>Note: the storage mechanism "SCRAM-XXX" for a given cryptographic hash function XXX, will allow a user to authenticate later to the service with the SASL mechanisms SCRAM-XXX, SCRAM-XXX-PLUS and PLAIN.</p>
|
|
<p>See &rfc5802; for more information about the StoredKey and the ServerKey in the context of SCRAM-*. Both data are base64-encoded.</p>
|
|
<example caption='The client sends the storage data with SCRAM-SHA1 for password "Juliet, je t'M!".'><![CDATA[
|
|
<complete xmlns='urn:xmpp:account:0'>
|
|
<login>jehan</login>
|
|
<store mechanism="SCRAM-SHA-1">
|
|
<stored-key>XXXX</stored-key>
|
|
<server-key>YYYY</server-key>
|
|
</store>
|
|
</complete>
|
|
]]></example>
|
|
<p>Note: when receiving the StoredKey and ServerKey, the server has no way to "test" these credentials, other than trying an authentication with the client. It is therefore the duty of the client to be sure of sending the right data, as corrupted data could block the user's account. Nevertheless the server can make a single minor check. Both StoredKey and ServerKey are the result of the hash computation, which has a defined result size. For instance, it will be 20 octets for SHA-1. As base64 codes 3 octets into 4 octets, both StoredKey and ServerKey will be 28 octets long for SCRAM-SHA1. If they are any other size, the account registration or modication must fail with <failure/> (and not be proposed for a retry. A client not able to output a rightly-sized output cannot be trusted on such a delicate operation).</p>
|
|
</section3>
|
|
<section3 topic="Certificate mechanism" anchor="cert">
|
|
<p>X.509 certificates are very interesting as well, as they allow you to send a public certificate over the wire which cannot be used to authenticate to any service, but only to recognize you as its righful owner if you own the private key associated to it. This said, a client could generate such a certificate and send it to the server with the current protocol. Once this done, it can later authenticate with the certificate as described in &xep0178;</p>
|
|
<p>Note: this storage mechanism does not use a password on server side. The server stores only the public certificate. Yet there MAY still be a password on the private key (client side), as additional security.</p>
|
|
<example caption='The client sends a public certificate to be stored by the server.'><![CDATA[
|
|
<complete xmlns='urn:xmpp:account:0'>
|
|
<login>jehan</login>
|
|
<store mechanism="X509-CERT">
|
|
<certificate>A certificate in PEM format</certificate>
|
|
</store>
|
|
</complete>
|
|
]]></example>
|
|
</section3>
|
|
</section2>
|
|
<section2 topic="Protocol Extensions" anchor='extension'>
|
|
<p>Account management can be extended in the following ways:</p>
|
|
<ul>
|
|
<li>By creating new stream features which will use the same protocol namespace, possibly at an higher version numbering.</li>
|
|
<li>If the extension proposes to update one of the existing features in a way which is incompatible with the current version, the version number must be updated, as described in &xep0053;.</li>
|
|
<li>New <challenge/> contents can be defined (for a specific feature or generic) without increasing the version number if this challenge cannot break the feature negotiation in the case the client does not understand it, and will therefore send a <unknown-challenge/>. If the challenge is such that such a <unknown-challenge/> is unacceptable and can result in a <failure/>, then it implies a version increase.</li>
|
|
<li>New Storage Mechanisms can be defined without increasing the namespace version, as they are advertised along with the features themselves.</li>
|
|
</ul>
|
|
</section2>
|
|
</section1>
|
|
<section1 topic='Business Rules' anchor='rules'>
|
|
<ul>
|
|
<li>These stream features are meant to be implemented and active on any deployed server where in-band account management is desired, either complete, with the possibility for a user to create, delete and modify an account; or partial, comprising any combinations of these possibilities;</li>
|
|
<li>If implemented on a server, even when in-band capacity is not desired, it SHOULD also be active in order to redirect users to, and inform them of, alternatives;</li>
|
|
<li>On clients, it SHOULD be implemented and active on any implementation wishing to give users advanced possibilities of in-band account management from the client itself;</li>
|
|
<li>On clients, as a minimum, it SHOULD be able to read and display the alternatives of account management to a user;</li>
|
|
<li>On a running XML stream, if the user wishes to delete or modify its account, as this protocol is described as a stream feature, the client must close the current stream and start a new one in order to do so;</li>
|
|
<li>A server may wish to force users currently logged-in into updating their passwords. If it wishes to do so, it SHOULD close the stream with a <reset/> stream error, then advertise the <modification/> feature as <required;> when the stream restarts. If this is done massively for all users, all the streams SHOULD NOT be resetted in the same time, in order to avoid a denial of service while all clients try to restart a new stream in the same time.</li>
|
|
</ul>
|
|
</section1>
|
|
<section1 topic='Internationalization Considerations' anchor='i18n'>
|
|
<p><instructions/> elements or other similar human-readable elements should have 'xml:lang' attribute determined by the procedure in section 4.7.4 of <cite>RFC-6120</cite></p>
|
|
</section1>
|
|
<section1 topic='Security Considerations' anchor='security'>
|
|
<ul>
|
|
<li>An implementation or a specific deployment is not forced in any way to provide any other storage mechanism than PLAIN (which would in substance be similar to the security provided by <cite>XEP-0077</cite>) or other algorithm known to be easily broken. Nevertheless a secure client SHOULD, during account creation, warn the user when the exchange is considered unsecure and would allow the server or any malevolent listener to easily break the user's password. In particular if the server uses no TLS encryption (or an unsecure certificate) combined with a weak storage mechanism, a very secure client could be wise to be very insistant on the security problem.</li>
|
|
<li>The storage mechanisms proposed by this protocol are only considered secure as long as the corresponding SASL mechanism or cryptographic hash functions are considered secure as well (the SCRAM-SHA1 storage is secure if we consider SCRAM secure <strong>and</strong> SHA-1 a strong encryption function). This is why the present protocol is written so that any new credential exchange for other mechanisms can be easily defined in the future.</li>
|
|
<li>For a better user experience, it is important to provide <challenge/> fallbacks rather than directly fail with a <failure/> on the first user error. <cite>XEP-0158</cite> for instance proposes to fail directly on a wrong answer to a CAPTCHA challenge, while it is well known that many actual human users regularly fails, sometimes even several, captchas before succeeding one. As a consequence, in such a case or other similar challenge, it is better to return a new challenge (a new CAPTCHA for instance) rather than cancelling the negotiation, doing so eventually only after a few retries.</li>
|
|
<li>The storage mechanism does not mean necessarily that credentials have to be stored in the given form, in particular when the server estimates a storage mechanism being stronger than the one desired by the user, and still without losing any authentication possibility. For instance if a client was to exchange credentials in PLAIN, and if the server usually provides SCRAM-SHA1, SCRAM-SHA-256 and PLAIN authentication mechanisms, then it would be wise to store it as both SCRAM-SHA-1 and SCRAM-SHA-256 instead of PLAIN. This way the security of the password is highly renforced in the case of the database being stolen and the three authentication mechanisms are still available to this user. Of course it would have been even more secure for the client itself to exchange the credentials as SCRAM-SHA-1 and SCRAM-SHA-256 from the start, because by exchanging PLAIN data, possibility is given to a man-in-the-middle attack to steal directly the password during this one-time account registration.</li>
|
|
<li>Security may have a price. If you were to store credentials with SCRAM-SHA-256 only, and later you change to a client which supports only PLAIN and SCRAM-SHA-1, you may fall in a case where you force yourself to log in using PLAIN. For this reason, a good client implementation SHOULD be able to determine such edge case. In the previous case, if possible, it SHOULD have stored both SCRAM-SHA-1 and SCRAM-SHA-256 on registration or silently modify later its storage.</li>
|
|
<li>When registering a new account, considering that the user has obviously not been authenticated yet, the server MUST NOT rely on the 'from' value of the initiating stream. In particular:
|
|
<ul>
|
|
<li><p>the server MUST NOT decide whether or not to propose the <registration/> feature based on the existence of the JID filled in 'from'. Doing so would leak away information about the existence of a JID which could therefore be sent undesirable messages. Being consistent on showing the feature forces to try to register which can already eliminates part of the risk if the challenge provides some bot protection (for instance CAPTCHAs).</p>
|
|
<p>A perfectly valid alternative would be to always provide the <registration/> feature when no "from" is filled but never provide it when a "from is filled" (no matter it is an existing JID or not). This consistent logics does not leak information.</p></li>
|
|
<li><p>Do not modify the SASL authentication's mechanisms listed in the <mechanisms/> feature depending on the 'from'. Even though a given JID might not be able to connect with some mechanisms because the credentials storage is incompatible, this would leak information on the kind of storage mechanism used for this user. This information would allow attackers to determine, then target, users whose storage would be weaker.</p>
|
|
<p>Of course this particular point might cause issues for users regularly changing their clients or log in from various computer. For instance the SCRAM-SHA-1 and SCRAM-SHA-256 storage are incompatible. If you first registered by specifying the SCRAM-SHA-256 storage, then on another client which does not support SCRAM-SHA-256 or even who supports it, but for some reason always try and gives priority to SCRAM-SHA-1, the user could be found in a situation where he never manages to authenticate while providing the right password. For this reason, it could be wiser for server deployments to choose compatible mechanisms, when possible. On client side, if they are provided a raw password, instead of pre-computed data for a specific mechanism, then they should intelligently try the various mechanisms, starting from the one they consider the stronger. Hence try SCRAM-SHA-256, then SCRAM-SHA-1 if the first failed, then only if both failed, tell the user that authentication failed (note that the client should not try PLAIN as a last fallback, because we remind that any SCRAM-* storage is compatible with the SASL PLAIN mechanism. Trying PLAIN would therefore be a security risk.</p></li>
|
|
</ul></li>
|
|
</ul>
|
|
</section1>
|
|
<section1 topic='IANA Considerations' anchor='iana'>
|
|
<p>This document requires no interaction with &IANA;.</p>
|
|
</section1>
|
|
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
|
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
|
|
<p>This specification defines the following XML namespace:</p>
|
|
<ul>
|
|
<li>urn:xmpp:account:0</li>
|
|
<!-- <li>urn:xmpp:account:register:0</li>
|
|
<li>urn:xmpp:account:delete:0</li>
|
|
<li>urn:xmpp:account:modify:0</li> -->
|
|
</ul>
|
|
<p>The ®ISTRAR; includes the foregoing namespace in its registry at &NAMESPACES;, as governed by &xep0053;.</p>
|
|
</section2>
|
|
<section2 topic='Namespace Versioning' anchor='registrar-versioning'>
|
|
&NSVER;
|
|
</section2>
|
|
</section1>
|
|
<section1 topic='XML Schema' anchor='schema'>
|
|
<p>REQUIRED for protocol specifications. TODO</p>
|
|
</section1>
|
|
</xep>
|