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.

After publishing a moved statement on her old account, Juliet proceeds to notify her contacts about the move.

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:

1. Receive subscription request with 'moved' payload.
2. Verify that the old JID has an approved subscription to the user (i.e. a subscription of 'both' or 'from').
3. Request moved statement from the old account JID.
4. Verify that the new JID in the moved statement matches the 'from' of the subscription request.

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.

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.

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.

The following are considerations for the user (exemplified by Juliet in this document):

• 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.
• 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).

The following are considerations for the contact (exemplified by Romeo in this document), and the contact's server:

• A presence subscription with a <moved/> 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.
• It is important to verify that the original JID of the migrating user was already authorized to view presence before processing a migration.
• 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.

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:

• Pro: Simple and easy to implement
• Con: depends on the original server being available and supporting PEP

Cryptographic verification:

• Pro: Can work even if the original server goes offline or begins blocking migration attempts.
• Con: More complex implementation.
• 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.

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).