From f441f4be031528da81874e0c6e76c889ab460f61 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonas=20Sch=C3=A4fer?= Date: Tue, 20 Aug 2019 18:04:56 +0200 Subject: [PATCH] Accept inbox/occupant-id.xml as XEP-0421 --- xep-0421.xml | 218 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 218 insertions(+) create mode 100644 xep-0421.xml diff --git a/xep-0421.xml b/xep-0421.xml new file mode 100644 index 00000000..835e47ad --- /dev/null +++ b/xep-0421.xml @@ -0,0 +1,218 @@ + + + %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 + Experimental + 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
    • +
+ + +