End-to-End Encrypted Contacts Metadata

End-to-End Encrypted Contacts Metadata This specification describes how to encrypt contacts metadata to minimize server exposure. This XMPP Extension Protocol is copyright © 1999 – 2024 by the XMPP Standards Foundation (XSF). Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation. ## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ## In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages. This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <https://xmpp.org/about/xsf/ipr-policy> or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA). xxxx ProtoXEP Standards Track Standards Council XMPP Core XEP-0060 XEP-0163 XEP-0223 XEP-0473 contacts Roster Pubsub e2ee Jérôme Poisson goffi@goffi.org goffi@jabber.fr https://www.goffi.org 0.0.1 2026-01-11 jp

First draft.

Roster is a central component of the XMPP specifications, serving as the mechanism for indicating to the server and other devices who we know, along with associated metadata and presence permission data. While convenient, this information carries significant privacy implications. In the context of ongoing efforts to reduce metadata exposure in XMPP, this document specifies a method for managing contact data in a more privacy-respectful way by using end-to-end encryption, while retaining the original roster mechanism described in RFC 6121 RFC 6121: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://tools.ietf.org/html/rfc6121>. for server-required features and backward compatibility.

The design goals of this XEP are:

Reduce metadata exposure: no contact data should be exposed to server beyond what is required for presence permission and backward compatibility.
Mandatory end-to-end encryption.
Contact data must not be tied to a JID or any domain-specific identifier.
The mechanism must be usable in serverless configurations, without relying on server-side storage or processing of contact data.

A few words to explain the design decisions. There are basically two ways to encrypt contact metadata:

By using the existing roster mechanism, adding a new element to handle metadata, and implementing end-to-end encryption for this element.
By implementing another metadata mechanism, exploiting other XMPP mechanisms. Publish-Subscribe (XEP-0060) XEP-0060: Publish-Subscribe <https://xmpp.org/extensions/xep-0060.html>. is the most suitable one for this use case.

Option 2 has been chosen for the following reasons:

The <item/> element of the roster mechanism, as specified in RFC 6121 RFC 6121: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://tools.ietf.org/html/rfc6121>. §2.1.2, has a mandatory "jid" element, and as per requirements we don't want to tie contact data to a JID.
The roster's <item/> element has not been explicitly designed to accept extra elements, and most implementations probably do not support them. While this could be added, there is a risk that some implementations remove unknown elements, and it would take years for the entire ecosystem to support them. Even then, there will always be a risk that an old client removes unknown metadata, as experience has shown with legacy bookmark mechanisms (with Bookmark Storage (XEP-0048) XEP-0048: Bookmark Storage <https://xmpp.org/extensions/xep-0048.html>. clients could remove unknown elements).
There is no end-to-end encryption mechanism for roster. While this could be added, it would certainly bring compatibility issues with existing implementations, would still leave the JID visible in clear text (as it is mandatory on the <item/> element), and would require additional extensions. On the other hand, there are already end-to-end encryption mechanisms for Publish-Subscribe (XEP-0060) XEP-0060: Publish-Subscribe <https://xmpp.org/extensions/xep-0060.html>. (notably OpenPGP for XMPP Pubsub (XEP-0473) XEP-0473: OpenPGP for XMPP Pubsub <https://xmpp.org/extensions/xep-0473.html>.).

Encrypted contacts use two well-known nodes:

urn:xmpp:contacts where contact information is stored.
urn:xmpp:contacts-groups where groups used to classify contacts are stored.

These nodes MUST be set on the Personal Eventing Protocol (XEP-0163) XEP-0163: Personal Eventing Protocol <https://xmpp.org/extensions/xep-0163.html>. service (except in serverless configurations, where they MAY be set on another relevant pubsub service, see Business Rules), and MUST follow Best Practices for Persistent Storage of Private Data via Publish-Subscribe (XEP-0223) XEP-0223: Best Practices for Persistent Storage of Private Data via Publish-Subscribe <https://xmpp.org/extensions/xep-0223.html>.. The IDs used for the pubsub items MUST NOT have any semantic meaning, and in particular MUST NOT be derived from any contact-related data.

Both node items MUST be end-to-end encrypted. The currently recommended method is using OpenPGP for XMPP Pubsub (XEP-0473) XEP-0473: OpenPGP for XMPP Pubsub <https://xmpp.org/extensions/xep-0473.html>. as OX is well adapted for this use case. However, another encryption method MAY be used in the future if proven better.

Contact metadata are stored on the 'urn:xmpp:contacts' node. Each published item MUST have either a <contact/> element qualified by the 'urn:xmpp:contacts:0' namespace or a <reserved/> element qualitifed by the 'urn:xmpp:contacts:0' namespace (see below).

The <contact/> element MAY have a 'name' attribute to specify the "handle" to be associated with the contact, in the same way as for roster items as described in RFC 6121 RFC 6121: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://tools.ietf.org/html/rfc6121>. §2.1.2.4.

The <contact/> element may have the following child elements:

The <contact/> MUST have a way to identify the contact, by having one or more <identity/> elements qualified by the 'urn:xmpp:contacts:0' namespace. This element MUST have a 'type' attribute. The 'type' attribute can have the value "jid" when the contact is identified by its bare JID; in that case, its content is the bare JID of the contact. Future specifications may propose other <identity/> types to identify contacts by other means (e.g., cryptographic fingerprint).

In a similar way as for RFC 6121 RFC 6121: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://tools.ietf.org/html/rfc6121>. roster, zero, one, or more groups may be associated with a contact. However, groups use IDs and are defined in the separate node 'urn:xmpp:contacts-groups'. This allows group names or other metadata to be modified without having to change all references to this group.

A group is specified by the <group/> element, which MUST have an 'id' attribute set to the ID of the desired group. This ID is associated with group metadata in the 'urn:xmpp:contacts-groups' node.

Romeo adds Juliet to his contacts:

juliet@example.org ]]>

Note: the example is in clear here, but in real use cases it is end-to-end encrypted.

Group metadata are stored on the 'urn:xmpp:contacts-groups' node. Each published item MUST have either a <group/> element qualified by the 'urn:xmpp:contacts:0' namespace or a <reserved/> element qualitifed by the 'urn:xmpp:contacts:0' namespace (see below).

The <group/> element MUST have an 'id' attribute set to a unique value. This ID defines the group identity and MUST NOT change as long as the group is not deleted.

The <group/> element MUST have a 'name' attribute to specify the "handle" to be associated with the group. This name MAY be changed in an existing group.

The <group/> element may have the following child element:

An optional <description/> element may be used to describe the group.

Romeo adds the groups where he places Juliet:

]]>

Note: the example is in clear here, but in real use cases it is end-to-end encrypted.

Since contact and group metadata are stored one per pubsub item, the number of items may reveal the size of the contact list. To mitigate this, clients MAY publish additional items without actual data, which should be ignored by other clients. This prevents the server from precisely determining the number of contacts or groups by simply counting encrypted pubsub items.

For either the contacts or groups node, a client MAY publish an item containing only a <reserved/> element qualified by the 'urn:xmpp:contacts:0' namespace. A client may publish as many such items as desired, replace an existing <contact/> or <group/> element with a reserved one, or vice versa.

Romeo wants to hide the size of his contact list by publishing reserved items:

]]>

Note: the example is in clear here, but in real use cases it is end-to-end encrypted.

The RFC 6121 RFC 6121: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://tools.ietf.org/html/rfc6121>. roster mechanism is still used, as it is necessary for presence permission handling and backward compatibility. However, when encrypted contacts metadata are used, the roster should be kept minimal: the 'name' attribute and <group/> element SHOULD NOT be used. Instead, an encrypted contact with the same JID SHOULD be used to store the name and group metadata.
As random IDs are used, it is possible that two or more <contact/> elements referring to the same contact are published (e.g., due to a race condition between two clients updating the same contact). In this case, the receiving client MUST merge the data from both elements (overwriting data from the previous item in case of conflict, in the order of item reception). The receiving client MAY overwrite the last seen <contact/> element with the result of the merge, and MAY either delete the older items or replace them with <reserved/> elements.
In serverless setups, as there is no server to offer a PEP service, the well-known node may be placed on whichever service is used to replace Personal Eventing Protocol (XEP-0163) XEP-0163: Personal Eventing Protocol <https://xmpp.org/extensions/xep-0163.html>..

If a client supports encrypted contacts, it MUST advertise it by including the "urn:xmpp:contacts:0" discovery feature in response to a Service Discovery (XEP-0030) XEP-0030: Service Discovery <https://xmpp.org/extensions/xep-0030.html>. information request:

]]> ... ... ]]>

The security consideration of used XEPs apply here and must be carrefully checked, in paritcular the ones from Publish-Subscribe (XEP-0060) XEP-0060: Publish-Subscribe <https://xmpp.org/extensions/xep-0060.html>. Best Practices for Persistent Storage of Private Data via Publish-Subscribe (XEP-0223) XEP-0223: Best Practices for Persistent Storage of Private Data via Publish-Subscribe <https://xmpp.org/extensions/xep-0223.html>. and OpenPGP for XMPP Pubsub (XEP-0473) XEP-0473: OpenPGP for XMPP Pubsub <https://xmpp.org/extensions/xep-0473.html>..

This document does not require interaction with the Internet Assigned Numbers Authority (IANA) The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>..

TODO

This work has been done for the Serverless and Metadata Reduction for XMPP project. Many thanks to NLNet foundation and NGI Zero Core for funding the work on this specification.

TODO