First draft.
Multi-User Chat (XEP-0045)
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)
This specification defines a method to combat issues arising out of the pseudonymity of MUC occupants while at the same time ensuring their privacy by not revealing their real JID to other occupants.
If a MUC room implements 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)
When a user enters a room, they send a presence to claim the nickname in the MUC. A MUC that supports occupant identifiers attaches an <occupant-id> element within the "urn:xmpp:occupant-id:0" namespace 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 occupant identifiers attaches an <occupant-id> element within the "urn:xmpp:occupant-id:0" to the message sent to all occupants in the room.
Messages and presences MUST NOT contain more than 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)
The <occupant-id> element MUST be ignored if support for the feature
is not announced via Service Discovery (XEP-0030)
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 pseudonymous. 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. If the MUC service generates the same occupant identifier for the same user in different rooms, information shared using different nicknames and in different rooms could be combined through the occupant identifier and thereby unintentionally reveal information about the user. To guarantee the pseudonymity 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. Alternatively, the service can generate a single private secret key for the whole service and use an HMAC algorithm to generate the occupant identifier from the real bare JID, the room bare JID and the service 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 pseudonymity 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)
The XMPP Registrar
]]>