First draft.
+ Historically, registering with an XMPP service has been difficult. Each + server either used customized out-of-band registration mechanisms such as + web forms which were difficult to discover, or they used &xep0077; which + could easily be abused by spammers to register large numbers of accounts and + which allowed for only limited extensibility. +
++ To solve these issues this specification provides a new in-band registration + protocol that allows servers to present the user with a series of + "challenges". + This allows for both multi-stage proof-of-posession registration flows and + spam prevention mechanisms such as proof-of-work functions. +
++ If a server supports registering for or recovering an account using + Extensible IBR, it MUST inform the connecting client when returning stream + features during the stream negotiation process. + This is done by including a <register/> element, qualified by the + 'urn:xmpp:register:0' namespace for account registration, or a + <recovery/> element qualified by the same namespace for account + recovery. + This SHOULD be done when informing a client that authentication is + required. + These features MUST NOT be advertised before encryption has been + negotiated, eg. using direct-TLS or STARTTLS. +
++ If the registration challenges contain enough data to consider the + connection authenticated after negotiation is successful or authentication + is not required by the server (eg. the server only allows temporary + registrations using this protocol), the register feature MUST be + advertised as mandatory-to-negotiate (indicating that the client may pick + between registration and authentication, if advertised). + This is accomplished by including an empty <required/> child element + in the feature. +
++ If SASL authentication should be performed after registration, + registration should be voluntary-to-negotiate (no <required/> child + element) and thus may be negotiated before SASL authentication (which is + always mandatory-to-negotiate). +
++ If authentication is not advertised, recovery MUST NOT be advertised. +
++ If account recovery would result in the user being authenticated (eg. the + recovery process involved proving the users identity, and entering a new + password) recovery MUST be advertised as mandatory-to-negotiate indicating + that it may be selected instead of authentication. + This is accomplished by including an empty <required/> child element + in the feature. +
++ If account recovery does not provide enough information to authenticate + the user (eg. the user was sent an email and opened a link to a web form + where they could reset their password, but the password is not entered + into the client) then it MUST be advertised as voluntary-to-negotiate (no + <required/> child element). + This indicates that authentication or another mandatory to negotiate + feature MUST be selected after the recovery process is complete. +
++ For recovery or registration, the server MUST include a list of all + challenges which the client may receive during the course of registering + or recovering an account. + The purpose of this list is to allow clients to detect if registration + requires a challenge type which the client does not support, so servers + need only include each type once; the list is merely informative, and + should not be relied upon by clients except to ensure that all mechanisms + are supported. + This list should comprise <challenge/> elements with a 'type' + attribute that uniquely identifies the type of challenge being issued. +
++ A client selects the registration or recovery feature for negotiation by + replying with an empty element of the same name and namespace. + For example, to attempt account recovery the client would send a + <recovery> element qualified by the 'urn:xmpp:register:0' namespace. +
++ The server then replies with a challenge. + Challenges take the form of a <challenge/> element qualified by the + 'urn:xmpp:register:0' namespace with a 'type' attribute containing the + challenge type and containing a challenge data payload. +
++ Type type of a challenge is a value which identifes what sort of payload a + client might expect. + This document defines a type of 'jabber:x:data' which MUST always contain a + data form (an 'x' element with type 'form') as defined by &xep0004;. + Other types may be defined in the future. + For example, a challenge containing a data form might look like the + following: +
++ After a challenge is received, the client replies to the challenge by + sending a <response/> element qualified by the 'urn:xmpp:register:0' + namespace or a cancelation as defined later in this document. + If the client sends a response, it MUST also include a payload defined by + the specific challenge type. + In the case of a jabber:x:data challenge, the payload should be a form + submission as defined by &xep0004; (an 'x' element of type 'submit'). + For instance, to reply to the data form challenge from the previous example + a client might send: +
++ If after receiving a challenge a client does not wish to continue + registration or recovery, it may send an empty <cancel> element + qualified by the 'urn:xmpp:register:0' namespace. + This informs the server that registration is complete. + This is the same as submitting a data form of type 'cancel' in response to a + data form challenge. +
++ If the client submits invalid data, or the server wishes to cancel for some + other reason, it may reply with an empty <cancel/> element qualified + by the 'urn:xmpp:register:0' namespace. + If the client successfully completes the challenge, the server MAY return an + empty <success/> element qualified by the 'urn:xmpp:register:0' + namespace, at which point it may continue with the stream negotiation + process. + If the server needs more information, for example, in the previous challenge + the user entered an email and now the server wishes to ask for a code that + was sent to that email, the server MAY send another challenge. +
++ When providing instructions in a data form the server SHOULD use the + language specified in the XML stream's current xml:lang, or the closest + language for which the server has a translation (eg. based on mutual + intelligibility between scripts and languages). +
++ For more information about language tags and matching, see &bcp47; +
++ Servers that allow in-band registration need to take measures to prevent + abuse. + Common techniques to prevent spam registrations include displaying CAPTCHAs + or requiring proof-of-posession of a valid email address or telephone number + by sending a unique code (e.g. an HMAC that can later be verified as having + originated at the server) to the users email and requiring that they enter + the code before continuing. + Servers that do not take such measures risk being black listed by other + servers in the network. +
+This document requires no interaction with &IANA;.
+This specification defines the following XML namespace:
++ Upon advancement of this specification from a status of Experimental to a + status of Draft, the ®ISTRAR; shall add the foregoing namespace to the + registry located at &STREAMFEATURES;, as described in Section 4 of + &xep0053;. +
++ The XMPP Registrar shall maintain a registry of IBR challenge types. + Challenge types defined within the XEP series MUST be registered with the + XMPP Registrar. +
+ ®PROCESS; +
+ The name of the challenge type.
+ A natural-language summary of the challenge.
+
+ The document in which the IBR challenge payload is specified.
+
+
+ The doucment in which the IBR challenge itself is specified (may be the same
+ as
+]]>
+ + For an example registration, see the next section. +
+This specification defines the following IBR challenge types:
++ Upon advancement of this specification from a status of Experimental to a + status of Draft, the ®ISTRAR; shall add the following definition to the + IBR challenge types registry, as described in this document: +
+
+ Data Forms Challenge
+ Requests that the client fill out an XEP-0004 data form.
+ XEP-0004
+ TODO: Insert this document once it is assigned a number
+]]>
+ TODO before advancing to Draft.
+