Re-write the flow with a more focused approach.
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. -
+ an easier JID to remember. Another common reason is that the provider goes + out of service (with a notice).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. -
+ or automated by a server.This document aims to satisfy the following requirements:
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.
- +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 RFC 6121.
+We start with the situation where the user, let's call them Juliet, has two accounts - + her original account juliet@im.example.net and a shiny new account on her personal + domain, juliet@capulet.example.
+Juliet would like to migrate all her data and contacts to her new account, with minimal + disruption.
+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. +
+The statement should be posted to a PEP node with the name 'urn:xmpp:moved:1'. The + payload should be a <moved/> element in the 'urn:xmpp:moved:1' namespace. This + element should in turn contain a single <new-jid/> element with the user's new JID + as its text content.
-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.
+After publishing a moved statement on her old account, Juliet proceeds + to notify her contacts about the move.
-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.
+Juliet connects to her new account, and sends a subscription request to + each of her contacts. These subscription requests MUST contain a <moved/> + element in the 'urn:xmpp:moved:1' namespace. This element contains a single + <old-jid/> element with the old JID as its text content.>
-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.
+ +If the value of <old-jid/> is not in the roster with an approved + incoming subscription ('from' or 'both'), the <moved/> element + MUST be ignored entirely.
+ +To verify the request, Romeo makes a request to the JID specified in + <old-jid/> (which MUST be a bare JID) to fetch a published move + statement.
+ +On success, Juliet's server will return the moved statement that Juliet published.
+ +Romeo MUST now verify that the received subscription request was from + the same bare JID contained in the <new-jid/> 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 + <moved/> element in the incoming subscription request MUST be + ignored entirely.
+ ++ Note: As a special case, if the attempt to retrieve the + moved statement results in an error with the <gone/> condition as + defined in RFC 6120, and that <gone/> element contains a valid + XMPP URI (e.g. xmpp:user@example.com), then the error response + MUST be handled equivalent to a <moved/> statement containing a + <new-jid/> element with the JID provided in the URI (e.g. + user@example.com). +
+ + +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.
+ +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.
+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.
+ +Broadly the server should follow exactly the same process as a client + would. Specifically: +
+If verification fails (e.g. due to a missing or incorrect moved + statement), the server MUST ignore the <moved/> element in the + subscription request, and process the stanza as a normal subscription + request. It MUST NOT strip the <moved/> element before forwarding, + even if verification fails.
+ +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'.
+ +After authorizing the new JID, the server should revoke the presence + subscription of the old account.
+ +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.
+ +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 RFC 6121.
- -To unsubscribe all inbound subscriptions send an unsubscribed - &PRESENCE; stanza to all the old contacts with a &MOVED; element - containing the new JID.
- -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.
- -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.
+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.
+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.
+Migration progress of contacts is obervable through subscription revocations to + the old account, and subscription approvals to the new account.
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. -
- -The new subscription MUST come from the new JID's server.
- -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.
- -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.
- -RFC 6120 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. -
- -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. -
-In following the principle of least surprise, it is considered good - practice to send the subscribe stanza after the unsubscribe and unsubscribed - stanzas. -
-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. -
- -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. -
- -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.
- -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.
-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.
- -Because of the ability to spoof the &MOVED; element, the client SHOULD - NOT automatically subscribe to the &MOVED; element target.
-| Server state | -Client state (jabber:iq:roster) | -Send unsubscribe from original JID | -Send unsubscribed from original JID | -Send subscribe from new JID | -
| none | -none | -- | - | - |
| none + pending out | -none + ask='subscribe' | -yes | -- | yes | -
| none + pending in | -n/a | -- | yes - server only | -- |
| none + pending in/out | -none + ask='subscribe' | -yes | -yes - server only | -yes | -
| to | -to | -yes | -- | yes | -
| to + pending in | -to | -yes | -yes - server only | -yes | -
| from | -from | -- | yes | -- |
| from + pending out | -from/none + ask='subscribe' | -yes | -yes | -yes | -
| both | -both | -yes | -yes | -yes | -
Future revisions of this document, or alternative documents, may define + alternative verification methods. Such methods SHOULD be communicated via + child elements of <moved/> in an appropriate namespace. As is usual + throughout XMPP, entities MUST ignore unknown child elements of + <moved/> in unrecognised namespaces.
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.
- -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.
- -The following illustrates an example malicious attack.
- -A similar attack can be done with a new subscribe request causing users - by guessing which users are subscribed to a contact.
- -The following are considerations for the user (exemplified by Juliet in this document):
+The following are considerations for the contact (exemplified by Romeo in this document), and the contact's server:
+This document requires no interaction with &IANA;.
This specification defines the following XML namespace:
+ +This specification defines the following XML namespace:
+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.
+Network-based verification:
Upon advancement of this specification from a status of Experimental - to a status of Draft, the ®ISTRAR; shall add the foregoing namespace - to the registry located at &NAMESPACES;, as described in Section 4 of - &xep0053;. -
-Cryptographic verification:
+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).
-
-
-
-
-
-
-
-
-
-
-
-
-
-]]>
+ To be done upon advancement to Draft.
The author wishes to thank Doug Abbink, Mikhail Belov, Peter Saint-Andre, and Peter Sheu for their feedback.
+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.
+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.