Easy Onboarding: use cases

This commit is contained in:
Georg Lukas 2018-01-10 12:06:22 +01:00
parent a0e5fa4011
commit fbe9bc2d4b
1 changed files with 72 additions and 10 deletions

View File

@ -170,10 +170,67 @@
description and the <strong>expire</strong> information, so that Romeo can description and the <strong>expire</strong> information, so that Romeo can
share it with Juliet by other means than XMPP, like e-mail or a QR code.</p> share it with Juliet by other means than XMPP, like e-mail or a QR code.</p>
</section2> </section2>
<section2 topic='Redeeming a User Invitation' anchor='redeem-invitation'> <section2 topic='Landing Page' anchor='landing-page'>
<p></p> <p>The landing page that the generated URL points to should correspond to
the format described in <cite>XEP-0379</cite> §3.3, and it needs to
convey the following information:</p>
<ul>
<li>A short text that this is an XMPP invitation from Romeo.</li>
<li>A client recommendation (based on the detected web browser/OS) with download links.</li>
<li>A prominent button that activates the encoded <strong>xmpp:</strong> link.</li>
</ul>
<p>If the landing page is hosted by Romeo's server, the server MAY display
additional information based on the supplied TOKEN value, like the name
of the inviter or validity information.</p>
</section2> </section2>
<section2 topic='Account Creation' anchor='account-creation'> <section2 topic='Redeeming a User Invitation' anchor='redeem-invitation'>
<p>If Juliet does not have an XMPP client installed, she will not be able
to open the <strong>xmpp:</strong> link from the invitation page.
For this case, the landing page needs to indicate that a client must be
installed first, and that the link will not work as intended without.
The automatic installation of an appropriate IM client when a user
clicks on an <strong>xmpp:</strong> is outside of the scope of this
document.</p>
<p>With an XMPP client installed, Juliet can open the
<strong>xmpp:</strong> link and have the client process it
appropriately, as follows:</p>
<section3 topic='Pre-Configured Account' anchor='redeem-preconfigured'>
<p>If Juliet's client is already configured with an account, the default
action for the presented
<strong>xmpp:inviter@example.com?roster;...</strong> URI is to add the
inviter to Juliet's roster. This should be performed as described in
§3.4 of <cite>XEP-0379</cite>, by sending a presence subscription
request containing the 'preauth' token.</p>
<p>If Juliet already has Romeo in her roster, her client should open the
appropriate chat interface instead.</p>
</section3>
<section3 topic='No Configured Account' anchor='redeem-no-account'>
<p>If Juliet's client does not have an XMPP account configured, she
needs to login or register an account first. Therefore, the client
should provide an interface with the following options:</p>
<ul>
<li>Login with an existing XMPP account.</li>
<li>Register an account with Romeo's server (if the URI contains a
<strong>ibr=y</strong> parameter).</li>
<li>Register an account with a public or client-endorsed server.</li>
</ul>
<p>If the <strong>xmpp:</strong> URI provided by Romeo contains the
<strong>ibr=y</strong> parameter, it indicates that the server
supports the <link url="#preauth-ibr">Pre-Authenticated In-Band
Registration</link> defined in this document. If Juliet chooses this
approach, the server will ensure that after the registration, Romeo is
added to her roster with a full presence subscription.</p> <p>If
Juliet chooses to login or register with a different server, her
client must complete the respective process and issue a subscription
request as described in §3.4 of <cite>XEP-0379</cite>.</p>
</section3>
</section2>
<section2 topic='Initiating Account Creation' anchor='account-creation'>
<p>If Romeo is the administrator of an XMPP server, he might want to
ensure that Juliet obtains an account on this server, with a username
defined either by Romeo or by Juliet, and in a way that does not require
the out-of-band communication of user passwords.</p>
<p>TODO: description of overall process steps, design motivation.</p>
<example caption="Exceute account creation command"><![CDATA[ <example caption="Exceute account creation command"><![CDATA[
<iq type='set' from='romeo@example.com' to='example.com' id='exec1'> <iq type='set' from='romeo@example.com' to='example.com' id='exec1'>
<command xmlns='http://jabber.org/protocol/commands' <command xmlns='http://jabber.org/protocol/commands'
@ -244,12 +301,14 @@
local part of the JID in the XMPP URI is omitted by the server which local part of the JID in the XMPP URI is omitted by the server which
results in the following format:</p> results in the following format:</p>
<code>xmpp:example.com?register;preauth=TOKEN</code> <code>xmpp:example.com?register;preauth=TOKEN</code>
<p>TODO: note about sensitivity of TOKEN</p>
</section2> </section2>
<section2 topic='Extension of In-Band Registration'> <section2 topic='Pre-Authenticated In-Band Registration' anchor='preauth-ibr'>
<p>In order to allow invited users to register on a server, in-band <p>In order to allow invited users to register on a server, the
registration as defined in &xep0077; needs to be extended. registration processs as defined in &xep0077; needs to be extended. The
The invited user MUST send the following extended stanza in order to invited user's client MUST add a &lt;preauth&gt; element in the 'TODO'
register an account with a token.</p> namespace to the 'jabber:iq:register' query in order to inform the
server that it wants to perform Pre-Authenticated IBR:</p>
<example caption="Retrieving registration fields"><![CDATA[ <example caption="Retrieving registration fields"><![CDATA[
<iq type='get' id='reg1' to='example.com'> <iq type='get' id='reg1' to='example.com'>
<query xmlns='jabber:iq:register'> <query xmlns='jabber:iq:register'>
@ -257,6 +316,9 @@
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>If the server supports and is ready to perform Pre-Authenticated IBR,
it MUST add a &lt;token&gt; element to the response (TODO: 'token' or
'preauth'?):</p>
<example caption="Receiving registration fields"><![CDATA[ <example caption="Receiving registration fields"><![CDATA[
<iq type='result' to='romeo@example.com' from='example.com' id='reg1'> <iq type='result' to='romeo@example.com' from='example.com' id='reg1'>
<query xmlns='jabber:iq:register'> <query xmlns='jabber:iq:register'>
@ -271,7 +333,7 @@
<query xmlns='jabber:iq:register'> <query xmlns='jabber:iq:register'>
<username>juliet</username> <username>juliet</username>
<password>m1cro$oft</password> <password>m1cro$oft</password>
<token>TOKEN</token> <token>BADTOKEN</token>
</query> </query>
<error type='cancel'> <error type='cancel'>
<invalid-token xmlns='urn:xmpp:invite:0'/> <invalid-token xmlns='urn:xmpp:invite:0'/>
@ -283,7 +345,7 @@
<query xmlns='jabber:iq:register'> <query xmlns='jabber:iq:register'>
<username>juliet</username> <username>juliet</username>
<password>m1cro$oft</password> <password>m1cro$oft</password>
<token>TOKEN</token> <token>OLDTOKEN</token>
</query> </query>
<error type='cancel'> <error type='cancel'>
<token-expired xmlns='urn:xmpp:invite:0'/> <token-expired xmlns='urn:xmpp:invite:0'/>