Extensions are allowed through the use of &xep0004; only. Data Forms are flexible for humans, yet security requires explicit definitions and automatic computations of cryptographic algorithms, which is impossible with generic Data Forms. 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).

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.

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.

By definition, this feature MUST always be considered as optional.

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.

If in-band registration is possible, the available <storage/> mechanisms MUST be advertised as childs of the <registration/> tag.

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 PLAIN 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 SCRAM-SHA1 storage will allow the use of the SASL SCRAM-SHA1, SCRAM-SHA1-PLUS, but also the PLAIN mechanisms.

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 Out-of-Band Data 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.

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.

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:

• 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;
• an <instructions/> tag giving various human-readable information (without requiring any data to be filled);
• an Out-of-Band Data 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;
• a Captcha Forms (see &xep0158;) directly embedded in XMPP for the same purpose.

Further versions of this protocol or other extensions may add new type of possible contents.

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.

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.

If a challenge awaits for no response, for instance if the challenge consists only on <instructions> or Out-of-Band Data, 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).

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.

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.

The client sends the credentials data. This part is discussed later in Defined Storage Mechanisms.

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.

After the Registration step, the server can again request new <challenge/> as described in Optional: additional informations.

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.

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).

At all time, the client can cancel the registration before the end by sending an <abort/>, to which the server must return a <failure/>

If cancellation comes from the server, this one directly sends a <failure/>.

If the feature is implemented, it MUST be advertised as a stream feature after 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.

By definition, this feature MUST always be considered as optional.

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.

The full deletion process has no more options than described in Account Deletion, except that -- same as for registration -- additional <challenge/> tags 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.

If the feature is implemented, it MUST be advertised as a stream feature after 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.

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.

The full modification process has no more options than described in Account Modification, except that -- same as for registration -- additional <challenge/> tags can be sent by the server and answered by the client between the <modify/> tag and the <proceed/> then between <complete/> and <modified/>.

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 RFC-6120. 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.

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.

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.

Optionally the <required/> element MAY have a <instructions/> or a Out-of-Band Data child, in particular if the service wishes to give an explanation of this required change.

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.
Another use case could be when your service updated storage mechanisms and wish to propose you to update. For instance a server compliant to RFC-3920 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.

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.

Optionally the <recommended/> element SHOULD have a <instructions/> or a Out-of-Band Data child, in particular if the service wishes to give an explanation of this recommended change.

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.

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.

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.

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.

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.

See &rfc5802; for more information about the StoredKey and the ServerKey in the context of SCRAM-*. Both data are base64-encoded.

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).

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;

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.