mirror of
https://github.com/moparisthebest/xeps
synced 2024-12-22 23:58:51 -05:00
766 lines
29 KiB
XML
766 lines
29 KiB
XML
<?xml version='1.0' encoding='UTF-8'?>
|
|
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
|
<!ENTITY % ents SYSTEM 'xep.ent'>
|
|
%ents;
|
|
<!ENTITY bcp47 "<span class='ref'><link url='http://tools.ietf.org/html/bcp47'>BCP 47</link></span> <note>BCP 47: Tags for Identifying Languages <<link url='http://tools.ietf.org/html/bcp47'>http://tools.ietf.org/html/bcp47</link>>.</note>" >
|
|
]>
|
|
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
|
<xep>
|
|
<header>
|
|
<title>Extensible In-Band Registration</title>
|
|
<abstract>
|
|
This specification defines an XMPP protocol extension for in-band
|
|
registration with instant messaging servers and other services with which an
|
|
XMPP entity may initiate a stream.
|
|
It aims to improve upon the state of the art and replace XEP-0077: In-Band
|
|
Registration by allowing multi-factor registration mechanisms, and account
|
|
recovery.
|
|
</abstract>
|
|
&LEGALNOTICE;
|
|
<number>0389</number>
|
|
<status>Experimental</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>ibr2</shortname>
|
|
&sam;
|
|
<revision>
|
|
<version>0.6.0</version>
|
|
<date>2020-11-17</date>
|
|
<initials>ssw</initials>
|
|
<remark>
|
|
<p>Error out if a client selects an invalid flow</p>
|
|
</remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.5.0</version>
|
|
<date>2020-05-26</date>
|
|
<initials>ssw</initials>
|
|
<remark>
|
|
<ul>
|
|
<li>Overhaul document for readability.</li>
|
|
<li>Add JID and username information to success element.</li>
|
|
<li>Always require disco/caps feature.</li>
|
|
<li>More examples.</li>
|
|
</ul>
|
|
</remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.4.0</version>
|
|
<date>2020-04-22</date>
|
|
<initials>ssw</initials>
|
|
<remark>
|
|
<ul>
|
|
<li>Add OOB challenge type.</li>
|
|
<li>Add IQ query for flows.</li>
|
|
<li>Add a glossary.</li>
|
|
<li>Make challenge listings more consistent.</li>
|
|
<li>Cleanup and expand the registrar considerations section.</li>
|
|
<li>Clarifications and typo fixes throughout the text.</li>
|
|
</ul>
|
|
</remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.3.0</version>
|
|
<date>2020-04-19</date>
|
|
<initials>ssw</initials>
|
|
<remark>
|
|
<ul>
|
|
<li>Move back to experimental.</li>
|
|
<li>Add IQ variant of registration/recovery.</li>
|
|
<li>Allow client to select between multiple flows.</li>
|
|
</ul>
|
|
</remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.2.0</version>
|
|
<date>2018-10-01</date>
|
|
<initials>XEP Editor (jsc)</initials>
|
|
<remark>Defer due to lack of activity.</remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.1.0</version>
|
|
<date>2017-03-16</date>
|
|
<initials>XEP Editor (ssw)</initials>
|
|
<remark>
|
|
Move to experimental.
|
|
</remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.0.2</version>
|
|
<date>2017-02-15</date>
|
|
<initials>ssw</initials>
|
|
<remark>
|
|
<ul>
|
|
<li>Don't allow feature to act as auth.</li>
|
|
<li>Use a more conventional list for challenge type listings.</li>
|
|
</ul>
|
|
</remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.0.1</version>
|
|
<date>2017-02-08</date>
|
|
<initials>ssw</initials>
|
|
<remark><p>First draft.</p></remark>
|
|
</revision>
|
|
</header>
|
|
<section1 topic='Introduction' anchor='intro'>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
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-possession registration flows and
|
|
spam prevention mechanisms such as proof-of-work functions.
|
|
</p>
|
|
</section1>
|
|
<section1 topic='Requirements' anchor='reqs'>
|
|
<ul>
|
|
<li>
|
|
The server MUST be able to present multiple challenges to the client.
|
|
</li>
|
|
<li>
|
|
The server SHOULD be able reduce account registration spam.
|
|
</li>
|
|
<li>
|
|
The server MAY present a challenge that requires the user to complete a
|
|
step out-of-band.
|
|
</li>
|
|
<li>
|
|
A client SHOULD be able to register an account without requiring the user
|
|
to leave the client.
|
|
</li>
|
|
<li>
|
|
A client MUST be able to use the same mechanism to register an account and
|
|
to recover a forgotten password (subject to server policy).
|
|
</li>
|
|
<li>
|
|
A client MUST be able to register with a server as well as external
|
|
components.
|
|
</li>
|
|
</ul>
|
|
</section1>
|
|
<section1 topic='Glossary' anchor='glossary'>
|
|
<dl>
|
|
<di>
|
|
<dt>Challenge</dt>
|
|
<dd>
|
|
A challenge is an action taken during account registration or recovery
|
|
that requires a response.
|
|
For example, displaying a form to a user or asking for a token.
|
|
</dd>
|
|
</di>
|
|
<di>
|
|
<dt>Challenge Type</dt>
|
|
<dd>
|
|
The type of a challenge is a unique string that identifies the type of
|
|
payload that can be expected.
|
|
For example, a challenge element with type "jabber:x:data" can be
|
|
expected to contain a data form.
|
|
Challenge types must be defined and registered in the challenge types
|
|
registry.
|
|
When defining a challenge it is often convenient to reuse an XML
|
|
namespace from the document defining the challenge.
|
|
</dd>
|
|
</di>
|
|
<di>
|
|
<dt>Flow</dt>
|
|
<dd>
|
|
A flow, or more specifically a "registration flow" or "recovery flow",
|
|
is a collection of challenges that together can be used to gather enough
|
|
information to register a new account or recover an existing account.
|
|
</dd>
|
|
</di>
|
|
</dl>
|
|
</section1>
|
|
<section1 topic='Use Cases' anchor='usecases'>
|
|
<ul>
|
|
<li>
|
|
As a server operator, I want to prevent individual spammers from
|
|
registering many accounts so I require registrants to perform a
|
|
proof-of-work function before registration is completed.
|
|
</li>
|
|
<li>
|
|
As a server operator I want to prevent bots from registering accounts so I
|
|
require that registrants submit a form which requires user interaction.
|
|
</li>
|
|
<li>
|
|
As a user I do not want to lose access to my account if I forget my
|
|
password, so I provide my email and telephone number in response to the
|
|
servers data form.
|
|
</li>
|
|
<li>
|
|
As a server operator I do not want users to accidentally add an incorrect
|
|
recovery address so I send an email with a unique link to the indicated
|
|
account and require that they click the link before registration can
|
|
continue.
|
|
</li>
|
|
<li>
|
|
As a server operator I want to prevent SPIM using a proof-of-possession
|
|
protocol so I present the user with a form asking for a mobile phone
|
|
number and then send a verification code to that number via SMS and show
|
|
another form requesting the verification code.
|
|
</li>
|
|
</ul>
|
|
</section1>
|
|
<section1 topic='Discovering Support' anchor='disco'>
|
|
<p>
|
|
Clients, servers, and other services such as components that support
|
|
Extensible IBR MUST advertise the fact by including a feature of
|
|
"urn::xmpp:register:0" in response to &xep0030; information requests and in
|
|
their &xep0115; profiles.
|
|
</p>
|
|
<example caption='Disco info response'><![CDATA[
|
|
<query xmlns='http://jabber.org/protocol/disco#info'>
|
|
…
|
|
<feature var='urn:xmpp:register:0' />
|
|
…
|
|
</query>]]></example>
|
|
</section1>
|
|
<section1 topic='Flows' anchor='flows'>
|
|
<p>
|
|
Registration or recovery is completed after responding to a series of
|
|
challenges issued by the server.
|
|
Challenges are grouped in to "flows", a number of challenges that may be
|
|
issued together to complete an action.
|
|
For example, a registration flow might be created that issues a data form
|
|
challenge which will be shown to the user to gather information, then issues
|
|
a second data form challenge to let the user enter a confirmation code that
|
|
was sent to their email.
|
|
</p>
|
|
<section2 topic='Stream Feature'>
|
|
<p>
|
|
If a server supports registering for or recovering an account using
|
|
Extensible IBR during stream negotiation, 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.
|
|
The register and recovery features are always voluntary-to-negotiate.
|
|
The registration and recovery features MUST NOT be advertised before a
|
|
security layer has been negotiated, eg. using direct TLS or opportunistic
|
|
TLS.
|
|
They SHOULD be advertised at the same time as the SASL authentication
|
|
feature, meaning that after registration or recovery is completed SASL
|
|
authentication can proceed.
|
|
</p>
|
|
<p>
|
|
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.
|
|
These are grouped into "flows" and let the client pick a registration
|
|
workflow that only contains challenges which the client supports.
|
|
Each <flow/> element MUST have a unique "id" attribute which is used
|
|
by the client to identify the flow being selected.
|
|
The id attribute is only used during this particular flow negotiation and
|
|
has no meaning after a flow has been selected.
|
|
Flows must also have at least one <name/> element containing a short,
|
|
human readable description of the flow.
|
|
If multiple <name/> elements are present they MUST have unique values
|
|
for the "xml:lang" attribute.
|
|
Clients MAY use the name element to show the different flows to the user and
|
|
ask them to pick between them.
|
|
Each flow element must also contain an unordered set of <challenge/>
|
|
elements representing the various challenge types that may be required to
|
|
complete the registration or recovery flow.
|
|
Each <challenge/> element contains a "type" attribute that uniquely
|
|
identifies the challenge for the purpose of determining if it is supported.
|
|
If a flow would offer the same challenge twice (eg. two data forms asking
|
|
for different data), the challenge SHOULD only be listed once in the flow
|
|
element.
|
|
</p>
|
|
<p>
|
|
For example, a server may advertise a "Verify with SMS" flow and a "Verify
|
|
by Phone Call" flow that both show a data form asking for a phone number
|
|
and then a second data form asking for a token provided to the user in a
|
|
text message or phone call depending on which flow the user selects.
|
|
</p>
|
|
<example caption='Host Advertises Stream Features'><![CDATA[
|
|
<stream:features>
|
|
<mechanisms xmlns='urn:xmpp:sasl:0'>
|
|
<mechanism>EXTERNAL</mechanism>
|
|
<mechanism>SCRAM-SHA-1-PLUS</mechanism>
|
|
<mechanism>SCRAM-SHA-1</mechanism>
|
|
<mechanism>PLAIN</mechanism>
|
|
</mechanisms>
|
|
<register xmlns='urn:xmpp:register:0'>
|
|
<flow id='0'>
|
|
<name>Verify with SMS</name>
|
|
<challenge type='jabber:x:data'/>
|
|
</flow>
|
|
<flow id='1'>
|
|
<name>Verify by Phone Call</name>
|
|
<challenge type='jabber:x:data'/>
|
|
</flow>
|
|
<flow id='2'>
|
|
<name>Verify with the web</name>
|
|
<challenge type='jabber:x:data'/>
|
|
<challenge type='jabber:x:oob'/>
|
|
</flow>
|
|
</register>
|
|
<recovery xmlns='urn:xmpp:register:0'>
|
|
<flow id='0'>
|
|
<name>Visit Password Recovery Site</name>
|
|
<challenge type='jabber:x:oob'/>
|
|
</flow>
|
|
</recovery>
|
|
</stream:features>]]></example>
|
|
</section2>
|
|
<p>
|
|
Just because a challenge type is listed by the server in the initial flow
|
|
element does not mean that it will be issued by the server.
|
|
Servers MAY choose to issue more or fewer challenges based on the result of
|
|
previous challenges and may not use every challenge type listed in the
|
|
original flow.
|
|
</p>
|
|
<section2 topic='Retrieving the Flows'>
|
|
<p>
|
|
Registration or recovery may also be completed after stream neogtiation if
|
|
server policy allows it.
|
|
</p>
|
|
<p>
|
|
To find what flows an entity provides (if any) after stream negotiation is
|
|
complete the requester can send an IQ of type "get" containing a
|
|
<register> or <recovery> element qualified by the
|
|
"urn:xmpp:register:0" namespace.
|
|
</p>
|
|
<example caption='Registration flows query'><![CDATA[
|
|
<iq type='get'>
|
|
<register xmlns='urn:xmpp:register:0'/>
|
|
</iq>]]></example>
|
|
<p>
|
|
When responding to a query for registration or recovery flows the list of
|
|
challenges MUST be included just as it would be during stream feature
|
|
negotiation.
|
|
That is, a "register" or "recovery" element containing a list of flows,
|
|
each with an id, containing a name and a list of challenges.
|
|
</p>
|
|
<example caption='Registration flows results'><![CDATA[
|
|
<iq type='result'>
|
|
<register xmlns='urn:xmpp:register:0'>
|
|
<flow id='0'>
|
|
<name>Verify with SMS</name>
|
|
<challenge type='jabber:x:data'/>
|
|
</flow>
|
|
<flow id='1'>
|
|
<name>Verify by Phone Call</name>
|
|
<challenge type='jabber:x:data'/>
|
|
</flow>
|
|
<flow id='2'>
|
|
<name>Verify with the web</name>
|
|
<challenge type='jabber:x:data'/>
|
|
<challenge type='jabber:x:oob'/>
|
|
</flow>
|
|
</register>
|
|
</iq>]]></example>
|
|
<p>
|
|
If an entity supports issuing challenges but does not provide any flows
|
|
after stream negotiation is complete it MUST respond with an empty list.
|
|
Similarly, an entity that supports this specification but does not support
|
|
issuing challenges itself (for example, a client that only supports
|
|
receiving challenges) it MUST respond successfully with an empty list.
|
|
</p>
|
|
<example caption='Empty registration flows results'><![CDATA[
|
|
<iq type='result'>
|
|
<register xmlns='urn:xmpp:register:0'/>
|
|
</iq>]]></example>
|
|
</section2>
|
|
<section2 topic='Selecting a Flow' anchor='selecting'>
|
|
<p>
|
|
A client selects the registration or recovery feature for negotiation by
|
|
replying with an element of the same name and namespace.
|
|
The element MUST contain a <flow> element that MUST have an "id"
|
|
attribute matching one of the flows advertised by the server.
|
|
For example, to select the "Verify by Phone Call" registration flow from
|
|
the previous example, the client would reply with:
|
|
</p>
|
|
<example caption='Client selects a recovery flow'><![CDATA[
|
|
<register xmlns='urn:xmpp:register:0'>
|
|
<flow id='1'/>
|
|
</register>]]></example>
|
|
<p>
|
|
If during stream initialization the client attempts to select a flow that
|
|
does not match one of the flows sent by the server, the server MUST
|
|
respond with an "undefined-condition" stream error containing an
|
|
"invalid-flow" application error qualified by the 'urn:xmpp:register:0'
|
|
namespace.
|
|
</p>
|
|
<example caption='Server responds to an invalid selection during stream negotiation'><![CDATA[
|
|
<stream:error>
|
|
<undefined-condition xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
|
|
<invalid-flow xmlns='urn:xmpp:register:0'/>
|
|
</stream:error>
|
|
</stream:stream>]]></example>
|
|
<p>
|
|
If the client is initiating registration or recovery after a stream has
|
|
already been initiated it uses the same registration element wrapped in an
|
|
IQ of type "set".
|
|
</p>
|
|
<example caption='Client selects a recovery flow after stream negotiation'><![CDATA[
|
|
<iq type='set' id='foo'>
|
|
<recovery xmlns='urn:xmpp:register:0'>
|
|
<flow id='0'/>
|
|
</recovery>
|
|
</iq>]]></example>
|
|
<p>
|
|
If the client attempts to select a flow that does not match one of the
|
|
flows sent by the server in response to an IQ after stream initialization
|
|
the server MUST respond with a stanza error of type "item-not-found".
|
|
</p>
|
|
<example caption='Server responds to an invalid selection after stream negotiation'><![CDATA[
|
|
<iq type='error'>
|
|
<error type='cancel'>
|
|
<item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
|
|
</error>
|
|
</iq>]]></example>
|
|
</section2>
|
|
<section2 topic='Issuing Challenges' anchor='challenge'>
|
|
<p>
|
|
If a valid flow is selected by the client the server then replies to the
|
|
IQ or feature selection with a challenge.
|
|
If replying to an IQ, the challenge must be wrapped in an IQ of type
|
|
"result".
|
|
Challenges take the form of a <challenge/> element qualified by the
|
|
'urn:xmpp:register:0' namespace with a 'type' attribute that uniquely
|
|
identifies the type of payload a client might expect the element to
|
|
contain.
|
|
</p>
|
|
<example caption='Server issues a challenge'><![CDATA[
|
|
<challenge xmlns='urn:xmpp:register:0'
|
|
type='urn:example:challenge'>
|
|
<example xmlns='urn:example:challenge'>Payload</example>
|
|
</challenge>]]></example>
|
|
<p>
|
|
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 cancellation as defined later in this document.
|
|
If the client sends a response, it MUST also include the payload
|
|
corresponding to the challenges 'type' element (which may be empty).
|
|
</p>
|
|
<example caption='Client responds to a challenge'><![CDATA[
|
|
<response xmlns='urn:xmpp:register:0'>
|
|
<result xmlns='urn:example:challenge'>Example Response</result>
|
|
</response>]]></example>
|
|
<p>
|
|
After a response is received, if the server needs more information it MAY
|
|
issue another challenge.
|
|
For example, if the user has entered their email in response to a
|
|
challenge, the server might send an email and then issue another challenge
|
|
asking for the unique code sent in the email.
|
|
</p>
|
|
</section2>
|
|
<section2 topic='Completing Registration or Recovery' anchor='completion'>
|
|
<p>
|
|
If after receiving a challenge or response a client or server 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 client or server that registration is complete.
|
|
This is the same as submitting a data form of type 'cancel' in response to
|
|
a data form challenge.
|
|
</p>
|
|
<example caption='User Cancels Registration or Recovery'><![CDATA[
|
|
<cancel xmlns='urn:xmpp:register:0'/>]]></example>
|
|
<p>
|
|
If the IQ based registration or recovery flow is being used and the server
|
|
wishes to cancel the flow, it MAY respond to any IQ with the cancel
|
|
element and type "result".
|
|
</p>
|
|
<example caption='Client or server cancels request'><![CDATA[
|
|
<iq type='result' id='bar'>
|
|
<cancel xmlns='urn:xmpp:register:0'/>
|
|
</iq>]]></example>
|
|
<p>
|
|
A server may also issue a cancelation IQ with type 'set' if it wishes to
|
|
cancel after a request/response has been received (ie. when there is no
|
|
existing IQ to respond to).
|
|
</p>
|
|
<example caption='Server cancels flow'><![CDATA[
|
|
<iq type='set' id='bar'>
|
|
<cancel xmlns='urn:xmpp:register:0'/>
|
|
</iq>]]></example>
|
|
<p>
|
|
If the client successfully completes all required challenges during stream
|
|
negotiation the server MUST return a <success/> element qualified by
|
|
the 'urn:xmpp:register:0' namespace, at which point it may continue with
|
|
the stream negotiation process.
|
|
The success element MUST contain a <jid> element containing the bare
|
|
JID as registered or recovered by the server and a <username>
|
|
element containing the simple user name for use with SASL (normally this
|
|
will be the same as the localpart of the JID).
|
|
</p>
|
|
<example caption='Server indicates success during steam negotiation'><![CDATA[
|
|
<success xmlns='urn:xmpp:register:0'>
|
|
<jid>mercutio@example.net</jid>
|
|
<username>mercutio</username>
|
|
</success>]]></example>
|
|
<p>
|
|
If the IQ based flow is being used and the server wishes to indicate
|
|
success after a challenge has been completed it sends an IQ of type "set"
|
|
containing the <success/> element.
|
|
</p>
|
|
<example caption='Server indicates success after stream negotiation'><![CDATA[
|
|
<iq type='set' id='bar'>
|
|
<success xmlns='urn:xmpp:register:0'>
|
|
<jid>mercutio@example.net</jid>
|
|
<username>mercutio</username>
|
|
</success>
|
|
</iq>]]></example>
|
|
</section2>
|
|
</section1>
|
|
<section1 topic='Challenges' anchor='challenge'>
|
|
<p>
|
|
This document defines several challenges that use existing technologies.
|
|
</p>
|
|
<section2 topic='Data Form' anchor='dataform'>
|
|
<p>
|
|
Challenges of type 'jabber:x:data' MUST always contain a data form (an 'x'
|
|
element with type 'form') as defined by &xep0004;.
|
|
</p>
|
|
<example caption='Server issues a data form challenge'><![CDATA[
|
|
<challenge xmlns='urn:xmpp:register:0'
|
|
type='jabber:x:data'>
|
|
<x xmlns='jabber:x:data' type='form'>
|
|
<title>Chat Registration</title>
|
|
<instructions>
|
|
Please provide the following information
|
|
to sign up to view our chat rooms!
|
|
</instructions>
|
|
<field type='hidden' var='FORM_TYPE'>
|
|
<value>urn:xmpp:register:0</value>
|
|
</field>
|
|
<field type='text-single' label='Given Name' var='first'/>
|
|
<field type='text-single' label='Family Name' var='last'/>
|
|
<field type='text-single' label='Nickname' var='nick'>
|
|
<required/>
|
|
</field>
|
|
<field type='text-single' label='Recovery Email Address' var='email'>
|
|
<required/>
|
|
</field>
|
|
</x>
|
|
</challenge>]]></example>
|
|
<p>
|
|
The response to a "jabber:x:data" challenge MUST be a form submission (an
|
|
'x' element of type 'submit').
|
|
For instance, to reply to the data form challenge from the previous example
|
|
a client might send:
|
|
</p>
|
|
<example caption='Client submits a data form in response to the challenge'><![CDATA[
|
|
<response xmlns='urn:xmpp:register:0'>
|
|
<x xmlns='jabber:x:data' type='submit'>
|
|
<field type='hidden' var='FORM_TYPE'>
|
|
<value>urn:xmpp:register:0</value>
|
|
</field>
|
|
<field type='text-single' label='Given Name' var='first'>
|
|
<value>Juliet</value>
|
|
</field>
|
|
<field type='text-single' label='Family Name' var='last'>
|
|
<value>Capulet</value>
|
|
</field>
|
|
<field type='text-single' label='Nickname' var='nick'>
|
|
<value>Jule</value>
|
|
</field>
|
|
<field type='text-single' label='Recovery Email Address' var='email'>
|
|
<value>juliet@capulet.com</value>
|
|
</field>
|
|
</x>
|
|
</response>]]></example>
|
|
</section2>
|
|
<section2 topic='Out of Band Data' anchor='oob'>
|
|
<p>
|
|
Challenges of type "jabber:x:oob" MUST contain an <x/> element
|
|
qualified by the "jabber:x:oob" namespace as defined in &xep0066;.
|
|
</p>
|
|
<example caption='Server issues an OOB challenge'><![CDATA[
|
|
<challenge xmlns='urn:xmpp:register:0'
|
|
type='jabber:x:oob'>
|
|
<x xmlns='jabber:x:oob'>
|
|
<url>http://example.net/login?token=foo</url>
|
|
</x>
|
|
</challenge>]]></example>
|
|
<p>
|
|
If the client sends a response to the OOB challenge it MUST be empty.
|
|
</p>
|
|
<example caption='Client acknowledges the OOB challenge'><![CDATA[
|
|
<response xmlns='urn:xmpp:register:0'/>]]></example>
|
|
</section2>
|
|
<section2 topic='SASL' anchor='sasl'>
|
|
<p>
|
|
Servers can support changing passwords by providing a reset flow
|
|
containing a SASL challenge.
|
|
The SASL challenge re-uses the SASL profile from &rfc6120;.
|
|
The server begins by sending the mechanisms list, and the client responds
|
|
by selecting a mechanism and possibly including initial data.
|
|
Each step in the SASL process is issued as a new SASL challenge.
|
|
</p>
|
|
<example caption='SASL challenge flow'><![CDATA[
|
|
<!-- Server -->
|
|
<challenge xmlns='urn:xmpp:register:0'
|
|
type='urn:ietf:params:xml:ns:xmpp-sasl'>
|
|
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
|
|
<mechanism>EXTERNAL</mechanism>
|
|
<mechanism>SCRAM-SHA-1-PLUS</mechanism>
|
|
<mechanism>SCRAM-SHA-1</mechanism>
|
|
<mechanism>PLAIN</mechanism>
|
|
</mechanisms>
|
|
</challenge>
|
|
|
|
<!-- Client -->
|
|
<response xmlns='urn:xmpp:register:0'>
|
|
<auth xmlns="urn:ietf:params:xml:ns:xmpp-sasl"
|
|
mechanism="SCRAM-SHA-1">
|
|
biwsbj1qdWxpZXQscj1vTXNUQUF3QUFBQU1BQUFBTlAwVEFBQUFBQUJQVTBBQQ==
|
|
</auth>
|
|
</response>
|
|
|
|
<!-- Server -->
|
|
<challenge xmlns='urn:xmpp:register:0'
|
|
type='urn:ietf:params:xml:ns:xmpp-sasl'>
|
|
<challenge xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
|
|
cj1vTXNUQUF3QUFBQU1BQUFBTlAwVEFBQUFBQUJQVTBBQWUxMjQ2OTViLTY5Y
|
|
TktNGRlNi05YzMwLWI1MWIzODA4YzU5ZSxzPU5qaGtZVE0wTURndE5HWTBaaT
|
|
AwTmpkbUxUa3hNbVV0TkRsbU5UTm1ORE5rTURNeixpPTQwOTY=
|
|
</challenge>
|
|
</challenge>
|
|
|
|
<!-- Client -->
|
|
<response xmlns='urn:xmpp:register:0'>
|
|
<response xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
|
|
Yz1iaXdzLHI9b01zVEFBd0FBQUFNQUFBQU5QMFRBQUFBQUFCUFUwQUFlMTI0N
|
|
jk1Yi02OWE5LTRkZTYtOWMzMC1iNTFiMzgwOGM1OWUscD1VQTU3dE0vU3ZwQV
|
|
RCa0gyRlhzMFdEWHZKWXc9
|
|
</response>
|
|
</response>]]></example>
|
|
</section2>
|
|
</section1>
|
|
<section1 topic='Internationalization Considerations' anchor='i18n'>
|
|
<p>
|
|
When providing instructions in a data form, or in the name element of a
|
|
registration or recovery flow, 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).
|
|
</p>
|
|
<p>
|
|
For more information about language tags and matching, see &bcp47;.
|
|
</p>
|
|
</section1>
|
|
<section1 topic='Security Considerations' anchor='security'>
|
|
<p>
|
|
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-possession 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.
|
|
</p>
|
|
</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:register:0</li>
|
|
</ul>
|
|
<p>
|
|
Upon advancement of this specification from a status of Experimental to a
|
|
status of Draft, the ®ISTRAR; shall add the foregoing namespace to the
|
|
registries located at &STREAMFEATURES;, and &DISCOFEATURES; as described
|
|
in Section 4 of &xep0053;.
|
|
</p>
|
|
<code caption='Service Discovery Features Registry Submission'><![CDATA[
|
|
<var>
|
|
<name>urn:xmpp:register:0</name>
|
|
<desc>Support for in band registration and password reset.</desc>
|
|
<doc>&xep0389;</doc>
|
|
</var>]]></code>
|
|
<code caption='Stream Features Registry Submission'><![CDATA[
|
|
<feature>
|
|
<ns>urn:xmpp:register:0</ns>
|
|
<name>Extensible In-Band Registration</name>
|
|
<element>register</element>
|
|
<desc>Support for in band registration and password reset.</desc>
|
|
<doc>&xep0389;</doc>
|
|
</feature>]]></code>
|
|
<p>
|
|
The ®ISTRAR; shall also add the foregoing namespace to the Jabber/XMPP
|
|
Protocol Namespaces Registry located at &NAMESPACES;.
|
|
Upon advancement of this specification from a status of Experimental to a
|
|
status of Draft, the ®ISTRAR; shall remove the provisional status from
|
|
this registry entry.
|
|
</p>
|
|
<code caption='Jabber/XMPP Protocol Namespaces Registry Submission'><![CDATA[
|
|
<ns>
|
|
<name>urn:xmpp:register:0</name>
|
|
<doc>&xep0389;</doc>
|
|
<status>provisional</status>
|
|
</ns>]]></code>
|
|
</section2>
|
|
<section2 topic='IBR Challenges Registry' anchor='registrar-challenges'>
|
|
<p>
|
|
The XMPP Registrar shall maintain a registry of IBR challenges.
|
|
Challenges defined within the XEP series MUST be registered with the XMPP
|
|
Registrar.
|
|
</p>
|
|
®PROCESS;
|
|
<code><![CDATA[
|
|
<challenge>
|
|
<type>A name that uniquely identifies the challenge.</type>
|
|
<desc>A natural-language summary of the challenge.</desc>
|
|
<doc>
|
|
The document (or documents) in which the IBR challenge and its payload are
|
|
defined.
|
|
</doc>
|
|
</challenge>]]></code>
|
|
<p>
|
|
For an example registration, see the next section.
|
|
</p>
|
|
</section2>
|
|
<section2 topic='Challenge Types' anchor='registrar-ibrchallenges'>
|
|
<p>This specification defines the following IBR challenge:</p>
|
|
<ul>
|
|
<li>jabber:x:data</li>
|
|
<li>jabber:x:oob</li>
|
|
</ul>
|
|
<p>
|
|
Upon advancement of this specification from a status of Experimental to a
|
|
status of Draft, the ®ISTRAR; shall add the following definitions to
|
|
the IBR challenges registry, as described in this document:
|
|
</p>
|
|
<code caption='IBR Challenges Registry Submission for Data Forms'><![CDATA[
|
|
<challenge>
|
|
<type>jabber:x:data</type>
|
|
<desc>Requests that the client fill out an XEP-0004 data form.</desc>
|
|
<doc>&xep0389;, &xep0004;</doc>
|
|
</challenge>]]></code>
|
|
<code caption='IBR Challenges Registry Submission for OOB Data'><![CDATA[
|
|
<challenge>
|
|
<type>jabber:x:oob</type>
|
|
<desc>Requests that the client execute a URI.</desc>
|
|
<doc>&xep0066;</doc>
|
|
</challenge>]]></code>
|
|
</section2>
|
|
<section2 topic='Namespace Versioning' anchor='registrar-versioning'>
|
|
&NSVER;
|
|
</section2>
|
|
</section1>
|
|
</xep>
|