diff --git a/inbox/moved2.xml b/inbox/moved2.xml new file mode 100644 index 00000000..81fd25d7 --- /dev/null +++ b/inbox/moved2.xml @@ -0,0 +1,403 @@ + + +%ents; +]> + + +
+ Moved 2.0 + This specification details a way for a user to notify their contacts about an account move. + &LEGALNOTICE; + xxxx + ProtoXEP + Standards Track + Standards + Council + + XMPP Core + XMPP IM + XEP-0163 + + + + NOT_YET_ASSIGNED + &mwild; + + 0.0.1 + 2021-06-05 + mw +

First draft.

 + +
+ +

This document introduces a way for a user to notify contacts of a change to their JID, e.g. if they move to a new server.

+ + +

This document aims to satisfy the following requirements:

+ + + +
+ +
Moved notification
+
An XML <moved/> element sent to a contact to inform them that + the user is moving to a new address. +
+ + +
Moved statement
+
An XML <moved/> element published by the user on their old + account. It is used by contacts to verify that moved notifications + are genuine. +
+ +
+ + +

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.

+ + + + + + + juliet@capulet.example + + + + + +]]> + + +

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@im.example.net + + +]]> + + + +

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.

+ + + + + + + juliet@capulet.example + + + + + +]]> + +

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. +
  2. Verify that the old JID has an approved subscription to the user (i.e. a subscription of 'both' or 'from').
    3. +
  3. Request moved statement from the old account JID.
    4. +
  4. Verify that the new JID in the moved statement matches the 'from' of the subscription request.
    5. +
+ + + + + + + + +]]> + + + + + + + juliet@capulet.example + + + + + +]]> + +

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

None.

+ + + +

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:

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

+ + + + +

TODO.

+ + + +

Many thanks to Kim Alvefur, Maxime Buquet and Jonas Schäfer for their input and feedback on this specification.

+ +