Merge branch 'xep-0283' into premerge

This commit is contained in:
Jonas Schäfer 2021-08-10 19:08:26 +02:00
commit 08baaba5b2
1 changed files with 343 additions and 333 deletions

View File

@ -11,7 +11,7 @@
<abstract>This document defines an XMPP protocol extension that enables a user to inform its contacts about a change in JID.</abstract>
&LEGALNOTICE;
<number>0283</number>
<status>Deferred</status>
<status>Experimental</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
@ -22,12 +22,13 @@
</supersedes>
<supersededby/>
<shortname>moved</shortname>
<author>
<firstname>Tory</firstname>
<surname>Patnoe</surname>
<email>tpatnoe@cisco.com</email>
<jid>tpatnoe@cisco.com</jid>
</author>
&mwild;
<revision>
<version>0.2.0</version>
<date>2021-07-20</date>
<initials>mw</initials>
<remark><p>Re-write the flow with a more focused approach.</p></remark>
</revision>
<revision>
<version>0.1.1</version>
<date>2018-08-06</date>
@ -98,375 +99,384 @@
<section1 topic='Introduction' anchor='intro'>
<p>There are a variety of reasons why a user may wish to change
their JID. For example, a surname change because of marriage or simply
an easier JID to remember.
</p>
an easier JID to remember. Another common reason is that the provider goes
out of service (with a notice).</p>
<p>This XEP defines an approach for communicating that your JID has
moved to a new JID, extending the existing subscription protocol documented
in &xmppim;. The steps outlined here may be done either through a client
or automated by a server.
</p>
or automated by a server.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<p>This document aims to satisfy the following requirements:</p>
<ul>
<li>The methods described here maintain compatibility with &xmppcore; and <cite>RFC 6121</cite>.</li>
<li>Users should be able to notify their contacts of a change of address.</li>
<li>Contacts should be able to verify that such a notification is legitimate, to prevent malicious actors from spoofing notifications.</li>
<li>It should be possible for a contact's server to automatically update the contact's roster for seamless migrations.</li>
<li>In the absence of a contact's support for this protocol, it should fall back to a simple manual subscription approval.</li>
</ul>
</section1>
<section1 topic='The Move'>
<p>In this scenario user@example.com moves to user2@example2.com.
Both the user@example.com and user2@example2.com accounts have been
created and still exist. The roster for user2@example2.com is empty
and the user wants to populate it with their entries from
user@example.com.</p>
<section1 topic='Glossary' anchor='glossary'>
<dl>
<di>
<dt>original JID</dt>
<dd>user@example.com</dd>
<dt>Moved notification</dt>
<dd>An XML &lt;moved/&gt; element sent to a contact to inform them that
the user is moving to a new address.
</dd>
</di>
<di>
<dt>new JID</dt>
<dd>user2@example2.com</dd>
<dt>Moved statement</dt>
<dd>An XML &lt;moved/&gt; element published by the user on their old
account. It is used by contacts to verify that moved notifications
are genuine.
</dd>
</di>
</dl>
</section1>
<section2 topic='Unsubscribing the original JID from outbound subscriptions'
anchor='unsubscribe'>
<p>Because the original JID is no longer going to be used, the user SHOULD
unsubscribe from all the outbound subscriptions user@example.com had.
These can be identified as those in the 'to' or 'ask' states as
defined in the 'jabber:iq:roster' protocol in <cite>RFC 6121</cite>.</p>
<section1 topic='Use Cases' anchor='usecases'>
<p>We start with the situation where the user, let's call them Juliet, has two accounts -
her original account <tt>juliet@im.example.net</tt> and a shiny new account on her personal
domain, <tt>juliet@capulet.example</tt>.</p>
<p>Juliet would like to migrate all her data and contacts to her new account, with minimal
disruption.</p>
<section2 topic='User publishes moved statement' anchor='publish-statement'>
<p>Before notifying contacts of the move, Juliet must connect to her old
account and publish a "statement" that the account is no longer in
use. This statement includes the address of her new account.
</p>
<p>The statement should be posted to a PEP node with the name 'urn:xmpp:moved:1'. The
payload should be a &lt;moved/&gt; element in the 'urn:xmpp:moved:1' namespace. This
element should in turn contain a single &lt;new-jid/&gt; element with the user's new JID
as its text content.</p>
<p>To unsubscribe all outbound subscriptions for the original JID send an
unsubscribe &PRESENCE; stanza to all the old contacts with a &MOVED;
element containing the new JID.</p>
<example caption='Juliet&apos;s client publishes a moved statement on her old account'><![CDATA[
<iq from='juliet@im.example.net/VR0sAGae'
type='set'
id='pub1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='urn:xmpp:moved:1'>
<item id='current'>
<moved xmlns='urn:xmpp:moved:1'>
<new-jid>juliet@capulet.example</new-jid>
</moved>
</item>
</publish>
</pubsub>
</iq>
]]></example>
</section2>
<section2 topic='User notifies contacts of move' anchor='publish-notification'>
<p>After publishing a moved statement on her old account, Juliet proceeds
to notify her contacts about the move.</p>
<p>There is the potential for other users to send a malicious unsubscribe
containing a spoofed &MOVED; JID. Therefore, clients SHOULD NOT
automatically subscribe to the JID contained in the &MOVED; stanza when
receiving a subscribe &PRESENCE; stanza without displaying the &MOVED;
JID to the user. See the Security Considerations section for
details.</p>
<p>Juliet connects to her new account, and sends a subscription request to
each of her contacts. These subscription requests MUST contain a &lt;moved/&gt;
element in the 'urn:xmpp:moved:1' namespace. This element contains a single
&lt;old-jid/&gt; element with the old JID as its text content.&gt;</p>
<example caption='Client unsubscribes outbound subscriptions from original JID'><![CDATA[
<presence from='user@example.com' to='contact@example.com' type='unsubscribe'>
<status>I've changed JIDs from user@example.com to user2@example2.com</status>
<moved xmlns='urn:xmpp:moved:0' new='user2@example2.com'/>
<example caption='Juliet sends a subscription request to Romeo from her new account'><![CDATA[
<presence type='subscribe' to='romeo@montague.example' id='sub1'>
<moved xmlns='urn:xmpp:moved:1'>
<old-jid>juliet@im.example.net</old-jid>
</moved>
</presence>
]]></example>
</section2>
<section2 topic='Contact receives subscription request with moved notification' anchor='receive-notification-client'>
<p>Juliet's contact, Romeo, receives the subscription request from Juliet's
new JID. At this point Romeo has not verified that the new account
actually belongs to Juliet, and MUST perform such verification before
acting on the request any differently to usual.</p>
<p>If the value of &lt;old-jid/&gt; is not in the roster with an approved
incoming subscription ('from' or 'both'), the &lt;moved/&gt; element
MUST be ignored entirely.</p>
<p>To verify the request, Romeo makes a request to the JID specified in
&lt;old-jid/&gt; (which MUST be a bare JID) to fetch a published move
statement.</p>
<example caption='Romeo requests a moved statement from Juliet&apos;s old account'><![CDATA[
<iq type='get'
from='romeo@capulet.example/laptop'
to='juliet@im.example.net'
id='83hKgF'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<items node='urn:xmpp:moved:1'>
<item id='current'/>
</items>
</pubsub>
</iq>
]]></example>
<p>On success, Juliet's server will return the moved statement that Juliet published.</p>
<example caption='Juliet&apos;s old server returns the published moved statement to Romeo'><![CDATA[
<iq type='result'
from='juliet@im.example.net'
to='romeo@capulet.example/laptop'
id='83hKgF'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<items node='urn:xmpp:moved:1'>
<item id='current'>
<moved xmlns='urn:xmpp:moved:1'>
<new-jid>juliet@capulet.example</new-jid>
</moved>
</item>
</items>
</pubsub>
</iq>
]]></example>
<p>Romeo MUST now verify that the received subscription request was from
the same bare JID contained in the &lt;new-jid/&gt; element in the moved
statement. If the JIDs do not match, or if there was an error fetching
the moved statement (except for "gone" - see note below), the
&lt;moved/&gt; element in the incoming subscription request MUST be
ignored entirely.</p>
<p class="box">
<strong>Note:</strong> As a special case, if the attempt to retrieve the
moved statement results in an error with the &lt;gone/&gt; condition as
defined in RFC 6120, and that &lt;gone/&gt; element contains a valid
XMPP URI (e.g. <tt>xmpp:user@example.com</tt>), then the error response
MUST be handled equivalent to a &lt;moved/&gt; statement containing a
&lt;new-jid/&gt; element with the JID provided in the URI (e.g.
<tt>user@example.com</tt>).
</p>
<p>Upon successful verification, Romeo's client may present an appropriate
user interface, informing about Juliet's change of address, and a prompt
to accept the subscription request from the new address. On the user's
approval of such a subscription request, the client will typically want
to also send a subscription request to the contact's new JID to establish
a mutual subscription.</p>
<p>Due to the potential for races between multiple clients connected to
the same account, it is NOT RECOMMENDED for a client to automatically
act upon migration notifications, but instead await manual interaction
from the user. As with any inbound subscription request it SHOULD pay
attention to roster pushes related to the contact, and update the UI
appropriately if the new contact address is authorized from another
device.</p>
</section2>
<section2 topic='Server-side processing of inbound moved notification' anchor='receive-notification-server'>
<p>It is not required for Romeo's server to support this specification.
However if Romeo's server does understand this extension, it SHOULD
handle the inbound subscription request on behalf of Romeo's clients.
This improves the user experience for Romeo, especially when he has
multiple devices.</p>
<p>Broadly the server should follow exactly the same process as a client
would. Specifically:
</p>
<ol>
<li>Receive subscription request with 'moved' payload.</li>
<li>Verify that the old JID has an approved subscription to the user (i.e. a subscription of 'both' or 'from').</li>
<li>Request moved statement from the old account JID.</li>
<li>Verify that the new JID in the moved statement matches the 'from' of the subscription request.</li>
</ol>
<example caption='Romeo&apos;s server requests a moved statement from Juliet&apos;s old account'><![CDATA[
<iq type='get'
from='romeo@capulet.example'
to='juliet@im.example.net'
id='83hKgF'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<items node='urn:xmpp:moved:1'>
<item id='current'/>
</items>
</pubsub>
</iq>
]]></example>
<example caption='Juliet&apos;s old server returns the published moved statement to Romeo&apos;s server'><![CDATA[
<iq type='result'
from='juliet@im.example.net'
to='romeo@capulet.example/laptop'
id='83hKgF'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<items node='urn:xmpp:moved:1'>
<item id='current'>
<moved xmlns='urn:xmpp:moved:1'>
<new-jid>juliet@capulet.example</new-jid>
</moved>
</item>
</items>
</pubsub>
</iq>
]]></example>
<p>If verification fails (e.g. due to a missing or incorrect moved
statement), the server MUST ignore the &lt;moved/&gt; element in the
subscription request, and process the stanza as a normal subscription
request. It MUST NOT strip the &lt;moved/&gt; element before forwarding,
even if verification fails.</p>
<p>Upon successful verification, the server MUST NOT forward the stanza to
Romeo's clients, but instead MUST create a roster entry for the new JID
with a subscription of 'from' (sending out the appropriate roster push),
and then auto-reply to the subscription request with a presence of type
'subscribed'.</p>
<example caption='Romeo&apos;s server notifies Romeo about the new roster entry'><![CDATA[
<iq id='a78b4q6ha463'
to='romeo@montague.example/orchard'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='juliet@capulet.example''
subscription='from'/>
</query>
</iq>
]]></example>
<p>After authorizing the new JID, the server should revoke the presence
subscription of the old account.</p>
<example caption='Romeo&apos;s server notifies Juliet&apos;s old account about unsubscription'><![CDATA[
<presence to='juliet@im.example.net' type='unsubscribed'/>
]]></example>
<example caption='Romeo&apos;s server notifies Romeo&apos;s clients about the old roster entry'><![CDATA[
<iq id='a78b4q6ha463'
to='romeo@montague.example/orchard'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='juliet@im.example.net''
subscription='to'/>
</query>
</iq>
]]></example>
<p>Finally, if the old JID was in the user's roster with a subscription of 'both', the
server MUST also send a presence of type 'subscribe' to the new JID in
order to seek establishment of a mutual subscription.</p>
<example caption='Romeo&apos;s server sends subscription request to Juliet&apos;s new JID'><![CDATA[
<presence type='subscribe' id='uc51xs63' from='romeo@montague.example' to='juliet@capulet.example'/>
]]></example>
</section2>
<section2 topic='Unsubscribing the original JID from inbound subscriptions'
anchor='unsubscribed'>
<p>Because the original JID is no longer going to be used, the user SHOULD
unsubscribe from all contacts the user@example.com had an inbound
subscription from. These can be identified as those in the 'from'
subscription state as defined in in the 'jabber:iq:roster' protocol
in <cite>RFC 6121</cite>.</p>
<p>To unsubscribe all inbound subscriptions send an unsubscribed
&PRESENCE; stanza to all the old contacts with a &MOVED; element
containing the new JID.</p>
<p>There is the potential for other users to send a malicious unsubscribed
containing a spoofed &MOVED; JID. Therefore, clients SHOULD NOT
automatically subscribe to the JID contained in the &MOVED; stanza
without displaying the &MOVED; JID to the user. See the Security
Considerations section for details.</p>
<example caption='Client unsubscribes inbound subscriptions from original JID'>
<![CDATA[
<presence from='user@example.com' to='contact@example.com' type='unsubscribed'>
<status>I've changed JIDs from user@example.com to user2@example2.com</status>
<moved xmlns='urn:xmpp:moved:0' new='user2@example2.com'/>
</presence>
]]>
</example>
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
<section2 topic='Lifetime of moved statement' anchor='impl-lifetime'>
<p>The moved statement is required for contacts to automatically verify
the authenticity of moved notifications. After publishing a moved
statement, the user should keep the statement published and the account
active for long enough for contacts to switch to the user's new account.</p>
<p>It is not necessary to remain connected to the old account during the
transition period. However the account must not be deleted, and the
server must be available.</p>
<p>In the event that the move statement is unpublished, the account is deleted,
or the server becomes unavailable, any contacts that have not yet transitioned
to the user's new JID will be unable to verify the migration. Those contacts
will have to manually approve the subscription from the user's new address.</p>
<p>Migration progress of contacts is obervable through subscription revocations to
the old account, and subscription approvals to the new account.</p>
</section2>
<section2 topic='Subscribing the new JID to all your existing contacts'
anchor='subscribe'>
<p>Once the new JID has been created on a server it is possible for the
new JID to subscribe to the contacts they had on the original JID's
roster. This is done by sending a new subscription request with a
&MOVED; element containing the new JID.
</p>
<p>The new subscription MUST come from the new JID's server.</p>
<p>There is the potential for other users to send a malicious subscribe
request and spoof the content of the &MOVED; element identifying an
original JID. Therefore, clients SHOULD NOT automatically unsubscribe
an existing roster entry if is listed as the target in the &MOVED;
element when a subscribe is received. See the Security
Consideration section for details.</p>
<p>Clients accepting the moved subscription SHOULD indicate to the
user that that this subscription request was the result of a move
operation and because of potential malicious behavior SHOULD NOT
auto-accept the subscription without displaying the &MOVED; JID to the
user.</p>
<example caption='Client requests subscription from new JID'>
<![CDATA[
<presence from='user2@example2.com' to='contact@example.com' type='subscribe'>
<status>I've changed JIDs from user@example.com to user2@example2.com</status>
<moved xmlns='urn:xmpp:moved:0' old='user@example.com'/>
</presence>
]]>
</example>
</section2>
<section2 topic='Contacts Offline at the Time the Rename Occurs'
anchor='offline'>
<p><cite>RFC 6120</cite> clarifies that an incoming subscribe &PRESENCE; stanza
MUST be preserved by the server and &PRESENCE; stanzas of type
unsubscribe and unsubscribed are not preserved on the server.
Therefore, for a contact who is offline, their servers MAY have
automatically removed the original roster entry when seeing the
unsubscribe and unsubscribed stanzas. At the time of writing this XEP,
NOT saving and forwarding the presence stanzas will be the default
behavior of most servers.
</p>
<p>What this means is that a contact coming online after the rename
outlined above MAY only see the &PRESENCE; of type 'subscribe' with
the &MOVED; element. Clients should be aware of this behavior.
</p>
</section2>
<section2 topic='Presence Ordering' anchor='ordering'>
<p>In following the principle of least surprise, it is considered good
practice to send the subscribe stanza after the unsubscribe and unsubscribed
stanzas.
</p>
</section2>
<section2 topic='Preservation of Groups' anchor='grouping'>
<p>One of the side effects of this scheme is the potential for a contact
to lose the groups to which it had organized the original JID. Clients
aware of the &MOVED; element can mitigate this with the following rules.
</p>
<ul>
<li>If the contacts client receives an unsubscribed with a &MOVED;
element, remove the subscription but initiate a roster push for the
original JID with the subscription set to 'none'. When the new
subscription is received the new JID MAY be placed into the roster
in the same groups as the original JID and the original JID can then be
removed from the roster.
</li>
<li>If a subscribe is received with a &MOVED; element, the client MAY
automatically place the new JID into the same groups as the original JID.
</li>
</ul>
<p>As discussed in 'Contacts Offline at the Time the Rename Occurs', a
server MAY automatically handle the unsubscribe and unsubscribed stanzas.
If this occurs it will be impossible to preserve the original groups.
</p>
</section2>
<section2 topic='One-way subcriptions and full roster state' anchor='one-way'>
<section3 topic='One-way Inbound subscription' anchor='from_subs'>
<p>If the original JID, user@example.com, had only an inbound subscription
(from or pending in), then the contact will only receive an
unsubscribed &PRESENCE; stanza. The contact's client, knowing the
state of the subscription (which is 'to' or 'none' with 'ask='subscribe'
from the contact's perspective), at that point MAY choose to prompt the
user to subscribe to the new JID listed in the &MOVED; element.</p>
<p>Because of the ability to spoof the &MOVED; element, the client SHOULD
NOT automatically subscribe to the &MOVED; element target, but SHOULD
present the new JID to the contact before sending out a subscription
request.</p>
</section3>
<section3 topic='One-way Outbound subscription' anchor='to_subs'>
<p>If the original JID, user@example.com, had only an outbound
subscription (to or ask), then the contact SHOULD only receive an
unsubscribe &PRESENCE; stanza. The contact's client, knowing the
state of the subscription (which is 'from' from the contact's perspective),
at that point MAY choose to prompt
the user to subscribe to the new JID listed in the &MOVED; element.</p>
<p>Because of the ability to spoof the &MOVED; element, the client SHOULD
NOT automatically subscribe to the &MOVED; element target.</p>
</section3>
<section3 topic='Roster state and action table' anchor='actions'>
<table caption="Roster states and actios from the renamed user's perspective">
<tr>
<td>Server state</td>
<td>Client state (jabber:iq:roster)</td>
<td>Send unsubscribe from original JID</td>
<td>Send unsubscribed from original JID</td>
<td>Send subscribe from new JID</td>
</tr>
<tr>
<td>none</td>
<td>none</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>none + pending out</td>
<td>none + ask='subscribe'</td>
<td>yes</td>
<td></td>
<td>yes</td>
</tr>
<tr>
<td>none + pending in</td>
<td>n/a</td>
<td></td>
<td>yes - server only</td>
<td></td>
</tr>
<tr>
<td>none + pending in/out</td>
<td>none + ask='subscribe'</td>
<td>yes</td>
<td>yes - server only</td>
<td>yes</td>
</tr>
<tr>
<td>to</td>
<td>to</td>
<td>yes</td>
<td></td>
<td>yes</td>
</tr>
<tr>
<td>to + pending in</td>
<td>to</td>
<td>yes</td>
<td>yes - server only</td>
<td>yes</td>
</tr>
<tr>
<td>from</td>
<td>from</td>
<td></td>
<td>yes</td>
<td></td>
</tr>
<tr>
<td>from + pending out</td>
<td>from/none + ask='subscribe'</td>
<td>yes</td>
<td>yes</td>
<td>yes</td>
</tr>
<tr>
<td>both</td>
<td>both</td>
<td>yes</td>
<td>yes</td>
<td>yes</td>
</tr>
</table>
</section3>
<section2 topic='Alternative verification methods' anchor='impl-alt-verify'>
<p>Future revisions of this document, or alternative documents, may define
alternative verification methods. Such methods SHOULD be communicated via
child elements of &lt;moved/&gt; in an appropriate namespace. As is usual
throughout XMPP, entities MUST ignore unknown child elements of
&lt;moved/&gt; in unrecognised namespaces.</p>
</section2>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>It is not intended for servers to strip any &MOVED; elements from
&PRESENCE; stanzas sent in from a client. This allows clients as well as
servers to implement these same procedures.</p>
<p>In order to prevent other users from maliciously altering contacts
the client SHOULD NOT automatically subscribe to a &MOVED; JID when it
receives an unsubscribe and SHOULD NOT automatically unsubscribe to
a &MOVED; JID when it receives a subscribe.</p>
<p>The following illustrates an example malicious attack.</p>
<ol>
<li>userA@example.com subscribes to userB@example.com</li>
<li>The userB@example.com automatically accepts the subscription from
userA@example.com. (Automatically done by the client using a simple
domain trust).</li>
<li>userA@example.com unsubscribes with the &MOVED; 'new' JID set to
companyCEO@example.com.</li>
<li>The previous steps can be repeated and have userB@example.com subscribe
to a large number of people.</li>
</ol>
<p>A similar attack can be done with a new subscribe request causing users
by guessing which users are subscribed to a contact.</p>
<ol>
<li>hacker@example.com subscribes to userB@example.com guessing that
userA@example.com is on userB's roster.
<![CDATA[
<presence from='hacker@example.com' to='userB@example.com' type='subscribe'>
<status>Subscribe to me!</status>
<moved xmlns='urn:xmpp:moved:0' old='userA@example.com'/>
</presence>
]]>
</li>
<li>If userB's client automatically accepted the subscription without
displaying at prompt to userB showing the new JID to be hacker@example.com,
then the user has no idea that hacker@example.com was just added to
the roster.
</li>
</ol>
<section2 topic='User considerations' anchor='security-user'>
<p>The following are considerations for the user (exemplified by Juliet in this document):</p>
<ul>
<li>A malicious client or other entity with access to the user's account
can perform a migration, potentially against the user's will and/or
without their knowledge. Although this is a concern, any malicious
actor with access to a user's account can abuse that access in many
ways. Servers that support granting restricted access to accounts
should consider blocking attempts to publish to the
'urn:xmpp:moved:1' PEP node from restricted entities.</li>
<li>To avoid leaking the user's new JID to non-contacts, the PEP node
containing the moved statement SHOULD be configured to use the
"presence" access model (this is the default access model defined
by PEP).</li>
</ul>
</section2>
<section2 topic='Contact considerations' anchor='security-contact'>
<p>The following are considerations for the contact (exemplified by Romeo in this document), and the contact's server:</p>
<ul>
<li>A presence subscription with a &lt;moved/&gt; is trivial for a
malicious third-party to spoof. The verification methods discussed
in this document MUST be followed to prevent accepting rogue
subscription requests.</li>
<li>It is important to verify that the original JID of the migrating
user was already authorized to view presence before processing a
migration.</li>
<li>After successfully processing a migration, the original account
should have its presence subscription revoked. This ensures that
each JID may only be migrated once. Without this precaution the
migration mechanism can be abused to introduce unlimited arbitrary
JIDs to contacts' rosters. This precaution also ensures, if the
old account ends up owned by a new entity, that they will not
unexpectedly inherit a presence subscription.</li>
</ul>
</section2>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='reg'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>This specification defines the following XML namespace:</p>
<ul>
<li>urn:xmpp:moved:0</li>
<li>urn:xmpp:moved:1</li>
</ul>
<p>Upon advancement of this specification from a status of Experimental
to a status of Draft, the &REGISTRAR; shall add the foregoing namespace
to the registry located at &NAMESPACES;, as described in Section 4 of
&xep0053;.
</p>
</section2>
<section2 topic='Protocol Versioning' anchor='registrar-versioning'>
&NSVER;
</section1>
<section1 topic='Design Considerations' anchor='design'>
<section2 topic='Verification methods' anchor='design-verification'>
<p>There are two general approaches for verification - network-based
verification, or cryptographic verification. Network-based verification
(as described in this document) requests a verification statement from
the user's old account. Cryptographic verification would check a move
notification against a previously-established cryptographic identify of
the user.</p>
<p>Network-based verification:</p>
<ul>
<li>Pro: Simple and easy to implement</li>
<li>Con: depends on the original server being available and supporting PEP</li>
</ul>
<p>Cryptographic verification:</p>
<ul>
<li>Pro: Can work even if the original server goes offline or begins blocking
migration attempts.</li>
<li>Con: More complex implementation.</li>
<li>Con: Requires user and contacts to manage/track cryptographic keys and
identies. It may be possible to piggyback on top of an existing cryptographic
layer, e.g. OMEMO. However this would eliminate the server-side assistance,
and OMEMO support is not universal among clients.</li>
</ul>
<p>Ultimately this document defines a network-based verification method, but
leaves an obvious path to extend the protocol with alternative verification
methods (either in an update to this document, or defined by other
documents).</p>
</section2>
</section1>
<section1 topic='XML Schema' anchor='schema'>
<code><![CDATA[
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:xmpp:moved:0'
xmlns='urn:xmpp:moved:0'
elementFormDefault='qualified'>
<xs:element name='moved'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:string'>
<xs:attribute name='new' type='xs:string' use='optional'/>
<xs:attribute name='old' type='xs:string' use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:schema>
]]></code>
<p>To be done upon advancement to Draft.</p>
</section1>
<section1 topic='Acknowledgements' anchor='ack'>
<p>The author wishes to thank Doug Abbink, Mikhail Belov, Peter Saint-Andre, and Peter Sheu for their feedback.</p>
<p>This document was formerly driven by Tory Patnoe with the support and feedback provided by Doug Abbink, Mikhail Belov, Peter Saint-Andre, and Peter Sheu.</p>
<p>It has since been taken over by the current author who thanks Kim Alvefur, Maxime Buquet and Jonas Schäfer for their input and feedback on this specification.</p>
</section1>
</xep>