%ents; ]>
Anonymous unique occupant identifiers for MUCs This specification defines a method that allows clients to identify a MUC participant across reconnects and renames. It thus prevents impersonification of anonymous users. &LEGALNOTICE; 0421 Deferred Standards Track Standards Council XMPP Core XEP-0001 XEP-0030 XEP-0045 occupant-id Marvin Wissfeld xsf@larma.de jabber@larma.de 0.1.0 2019-08-20 XEP Editor (jsc) Accepted by vote of Council on 2019-07-17. 0.0.1 2019-07-13 mw

First draft.

&xep0045; 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 &xep0308;. At the same time it becomes harder for clients to determine this, for example due to the use of &xep0313; 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 &xep0030;.

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

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.

]]> ]]>

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.

Harpier cries: 'tis time, 'tis time. ]]> Harpier cries: 'tis time, 'tis time. ]]>

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 &xep0313; or any other means.

The <occupant-id> element MUST be ignored if support for the feature is not announced via &xep0030;, 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.

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.

This document requires no interaction with &IANA;.

The ®ISTRAR; includes 'urn:xmpp:occupant-id:0' in its registry of protocol namespaces (see &NAMESPACES;).

  • urn:xmpp:occupant-id:0