From 2f97214a0f887a4726367772436b8551631204e9 Mon Sep 17 00:00:00 2001 From: Sam Whited Date: Tue, 14 Feb 2017 19:51:03 -0600 Subject: [PATCH] ibr2: Simplify the stream features listing --- inbox/ibr2.xml | 74 +++++++++++++++++--------------------------------- 1 file changed, 25 insertions(+), 49 deletions(-) diff --git a/inbox/ibr2.xml b/inbox/ibr2.xml index 70a3198f..2b2083b4 100644 --- a/inbox/ibr2.xml +++ b/inbox/ibr2.xml @@ -31,6 +31,17 @@ ibr2 &sam; + + 0.0.2 + 2017-02-15 + ssw + +
    +
  • Don't allow feature to act as auth.
    • +
  • Use a more conventional list for challenge type listings.
    • +
+ + 0.0.1 2017-02-08 @@ -135,58 +146,24 @@ '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. + 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.

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 <challenge/> elements with a 'type' - attribute that uniquely identifies the type of challenge being issued. + This list should comprise <challenge/> elements containing a string + that uniquely identifies the type of challenge being issued.

@@ -197,12 +174,11 @@ PLAIN - - - + jabber:x:data' + pow-example - + jabber:x:oob ]]>