moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-24 02:02:16 -05:00
Code Issues Releases Wiki Activity

ibr2: Simplify the stream features listing

Browse Source
This commit is contained in:
Sam Whited 2017-02-14 19:51:03 -06:00
parent fe945a049a
commit 2f97214a0f
1 changed files with 25 additions and 49 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

74
inbox/ibr2.xml
View File

@ -31,6 +31,17 @@
<supersededby/>
<shortname>ibr2</shortname>
&sam;
<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>
@ -135,58 +146,24 @@
'urn:xmpp:register:0' namespace for account registration, or a
&lt;recovery/&gt; 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.
</p>
<p>
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 &lt;required/&gt; child element
in the feature.
</p>
<p>
If SASL authentication should be performed after registration,
registration should be voluntary-to-negotiate (no &lt;required/&gt; child
element) and thus may be negotiated before SASL authentication (which is
always mandatory-to-negotiate).
</p>
<p>
If authentication is not advertised, recovery MUST NOT be advertised.
</p>
<p>
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 &lt;required/&gt; child element
in the feature.
</p>
<p>
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
&lt;required/&gt; child element).
This indicates that authentication or another mandatory to negotiate
feature MUST be selected after the recovery process is complete.
The register and recovery features are always voluntary-to-negotiate.
The registration and recovery features MUST NOT be advertised before
encryption has been negotiated, eg. using direct-TLS or STARTTLS.
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.
challenge types 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 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 &lt;challenge/&gt; elements with a 'type'
attribute that uniquely identifies the type of challenge being issued.
This list should comprise &lt;challenge/&gt; elements containing a string
that uniquely identifies the type of challenge being issued.
</p>
<example caption="Host Advertises Stream Features"><![CDATA[
<stream:features>
@ -197,12 +174,11 @@
<mechanism>PLAIN</mechanism>
</mechanisms>
<register xmlns='urn:xmpp:register:0'>
<required/>
<challenge type='jabber:x:data'/>
<challenge type='pow-example'/>
<challenge>jabber:x:data'</challenge>
<challenge>pow-example</challenge>
</register>
<recovery xmlns='urn:xmpp:register:0'>
<challenge type='jabber:x:oob'/>
<challenge>jabber:x:oob</challenge>
</recovery>
</stream:features>]]></example>
</section1>