Multi-User Chat (XEP-0045) [1] allows the creation of semi-anonymous multi-user text chats where the real JID of a occupant can not be discovered by other MUC occupants except moderators. As such users can freely join with using any identity of their choice, allowing to impersonate users while they are not online.
With recent standard extensions, it becomes more relevant to be able to know if the occupant that sends one message is the same as the sender of another message, for example for Last Message Correction (XEP-0308) [2]. At the same time it becomes harder for clients to determine this, for example due to the use of Message Archive Management (XEP-0313) [3] with MUCs.
This specification defines a method to combat issues arising out of the anonymity of MUC occupants while at the same time ensuring their privacy by not leaking their real JID to other occupants.
If a MUC implements anonymous unique occupant identifiers, it MUST specify the 'urn:xmpp:occupant-id:0' feature in its service discovery information features as specified in Service Discovery (XEP-0030) [4].
<iq type='get'
to='coven@chat.shakespeare.lit'
from='hag66@shakespeare.lit/pda'
id='info1'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
<iq type='result'
to='hag66@shakespeare.lit/pda'
from='coven@chat.shakespeare.lit'
id='info1'>
<query xmlns='http://jabber.org/protocol/disco#info'>
...
<feature var='urn:xmpp:occupant-id:0'/>
...
</query>
</iq>When a user enters a room, they send a presence to claim the nickname in the MUC. A MUC that supports anonymous unique occupant identifiers attaches an <occupant-id> element to the presence sent to all occupants in the room.
<presence
from='hag66@shakespeare.lit/pda'
id='n13mt3l'
to='coven@chat.shakespeare.lit/thirdwitch'>
<x xmlns='http://jabber.org/protocol/muc'/>
</presence>
<presence
from='coven@chat.shakespeare.lit/thirdwitch'
id='27C55F89-1C6A-459A-9EB5-77690145D624'
to='crone1@shakespeare.lit/desktop'>
<x xmlns='http://jabber.org/protocol/muc#user' />
<occupant-id xmlns="urn:xmpp:occupant-id:0" id="dd72603deec90a38ba552f7c68cbcc61bca202cd" />
</presence>An occupant sends a message to all other occupants in the room by sending a message of type "groupchat" to the <room@service>. A MUC supporting anonymous unique occupant identifiers attaches an <occupant-id> element to the message sent to all occupants in the room.
<message
from='hag66@shakespeare.lit/pda'
id='hysf1v37'
to='coven@chat.shakespeare.lit'
type='groupchat'>
<body>Harpier cries: 'tis time, 'tis time.</body>
</message>
<message
from='coven@chat.shakespeare.lit/thirdwitch'
id='hysf1v37'
to='crone1@shakespeare.lit/desktop'
type='groupchat'>
<body>Harpier cries: 'tis time, 'tis time.</body>
<occupant-id xmlns="urn:xmpp:occupant-id:0" id="dd72603deec90a38ba552f7c68cbcc61bca202cd" />
</message>Messages and presences MUST NOT contain more then one <occupant-id> element. If the message or presence received by the MUC service already contains <occupant-id> element, the MUC service MUST replace such element before reflecting the message or presence including it.
The <occupant-id> element MUST be attached to every message and every presence sent by a MUC. This includes messages sent as part of the discussion history after joining a room, requested via Message Archive Management (XEP-0313) [3] or any other means.
The <occupant-id> element MUST be ignored if support for the feature is not announced via Service Discovery (XEP-0030) [4], as malicious clients might forge occupant identifiers if the room does not support them.
A MUC service MAY allow the administrator to enable or disable occupant identifiers on a per-room basis. If occupant identifiers are force enabled for all rooms on a MUC service, it SHOULD additionally specify the 'urn:xmpp:occupant-id:0' feature on the MUC service. It MUST NOT specify the feature on the service otherwise.
The occupant identifier MUST be generated such that it is stable. This means that if a user joins the same room a second time, the occupant identifier MUST be the same as was assigned the first time. A user in the sense of this specification is identified by its real bare JID.
The occupant identifier MUST be generated such that it is unique. This means that it MUST be sufficiently improbable that one user is able to re-create the occupant identifier of another user.
The occupant identifier MUST be generated such that it is anonymous. This means that it MUST be sufficiently hard to determine the real bare JID of an occupant from its occupant identifier. Additionally, a MUC service SHOULD generate the identifier such that the occupant identifier of a user in one room of the service does not match the occupant identifier of the same user in another room of the same service. To guarantee the anonymity property, the server MUST NOT generate an occupant identifier by only hashing the real bare JID using static, guessable or discoverable parameters.
The occupant identifier MUST have a maximum length of 128 characters. The recipient MUST consider the occupant identifier to be an opaque string.
One way to ensure these properties is to generate a private secret key for every room and use an HMAC algorithm with a sufficiently secure hash function to generate the occupant identifier from the real bare JID and that secret key. This procedure ensures all the required properties with minimal server side storage requirements.
If a MUC uses occupant identifiers, nickname changes will be visible to all occupants of the room. Clients may warn users about this circumstance before joining the room or when changing the nickname.
When the MUC service does not support this specification, the server will likely forward any <occupant-id> included in <message>s sent by other room occupants and reflected by the MUC service. Receiving clients must be careful to only process occupant identifiers if the MUC server advertises support for this specification as described in the Discovering support section.
The anonymity property of occupant identifiers is crucial to not accidentally reveal an occupant's real bare JID to other room occupants. Specifically, a simple hash over the occupant's real bare JID is not sufficient as an occupant identifier, as unsalted hashes can be reversed easily based on a dictionary of candidate JIDs. Review the Occupant ID generation section for more details.
This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [5].
The XMPP Registrar [6] includes 'urn:xmpp:occupant-id:0' in its registry of protocol namespaces (see <https://xmpp.org/registrar/namespaces.html>).
<?xml version='1.0' encoding='utf-8'?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:xmpp:occupant-id:0"
xmlns="urn:xmpp:occupant-id:0"
elementFormDefault="qualified">
<xs:element name="occupant-id">
<xs:complexType>
<xs:attribute name="id" type="OccupantIdentifier" use="required" />
</xs:complexType>
</xs:element>
<xs:simpleType name="OccupantIdentifier">
<xs:restriction base="xs:string">
<xs:minLength value="1"/>
<xs:maxLength value="128"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
This document in other formats: XML PDF
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).
The HTML representation (you are looking at) is maintained by the XSF. It is based on the YAML CSS Framework, which is licensed under the terms of the CC-BY-SA 2.0 license.
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.
The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.
Discussion on other xmpp.org discussion lists might also be appropriate; see <https://xmpp.org/community/> for a complete list.
Errata can be sent to <editor@xmpp.org>.
The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".
1. XEP-0045: Multi-User Chat <https://xmpp.org/extensions/xep-0045.html>.
2. XEP-0308: Last Message Correction <https://xmpp.org/extensions/xep-0308.html>.
3. XEP-0313: Message Archive Management <https://xmpp.org/extensions/xep-0313.html>.
4. XEP-0030: Service Discovery <https://xmpp.org/extensions/xep-0030.html>.
5. 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/>.
6. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <https://xmpp.org/registrar/>.
Note: Older versions of this specification might be available at https://xmpp.org/extensions/attic/
First draft.
@report{wissfeld2019occupant-id,
title = {Anonymous unique occupant identifiers for MUCs},
author = {Wissfeld, Marvin},
type = {XEP},
number = {0421},
version = {0.2.0},
institution = {XMPP Standards Foundation},
url = {https://xmpp.org/extensions/xep-0421.html},
date = {2019-07-13/2024-05-28},
}END