XEP-0404: Mediated Information eXchange (MIX): JID Hidden Channels.

WARNING: This Standards-Track document is Experimental. Publication as an XMPP Extension Protocol does not imply approval of this proposal by the XMPP Standards Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems are advised to carefully consider whether it is appropriate to deploy implementations of this protocol before it advances to a status of Draft.

1. Introduction
2. Concepts
    2.1. Private Messages
    2.2. JID Visibility Services
    2.3. JID Visibility Architecture
    2.4. Resource Hiding
    2.5. JID Map Node
3. Use Cases
    3.1. User Preferences and Additional Information
    3.2. Sending Private Messages
    3.3. Requesting vCard
4. Internationalization Considerations
5. Security Considerations
6. IANA Considerations
7. XMPP Registrar Considerations
8. XML Schema
9. Acknowledgements

Appendices
    A: Document Information
    B: Author Information
    C: Legal Notices
    D: Relation to XMPP
    E: Discussion Venue
    F: Requirements Conformance
    G: Notes
    H: Revision History

1. Introduction

The Mediated Information eXchange (MIX) protocol framework and core capabilities are specified in Mediated Information eXchange (MIX) (XEP-0369) [1] (MIX-CORE). This specification provides mechanisms to hide participant JIDs from other participants. This is needed to address privacy concerns and to prevent JID harvesting. It also addresses privacy issues, and gives participants options to control sharing of information.

2. Concepts

2.1 Private Messages

Mediated Information eXchange (MIX) (XEP-0369) [1] exposes participant JIDs to other participants, and so messages can always be sent directly. When JIDs are hidden this is no longer possible. Private messages MAY be sent to channel participants if allowed by channel policy. Private messages are addressed to the user's bare proxy JID determined from the participants node, and routed by the MIX to the user's bare real JID, where standard distribution rules will apply.

2.2 JID Visibility Services

MIX channels have three modes controlling JID visibility, defined to prevent JID harvesting:

Table 1: JID Visibility Modes

Mode	Description
'JID Visible'	In these channels all participant JIDs are visible to all channel participants.
'JID Maybe Visible'	In these channels, participant JIDs are visible to all channel participants when participant preference allows.
'JID Hidden'	In these channels, no participant JIDs are visible to channel participants, but they are visible to channel administrators.

A channel participant MAY specify a preference for JID visibility for the channel, with one of the following values:

Table 2: JID Visibility Preference Options

Preference	Description
'Prefer Visible'	The users JID will be visible if the channel is JID Visible or JID Maybe Visible channels and hidden if the channel is JID Hidden.
'Prefer Hidden'	The user's JID will be hidden if the channel is JID Maybe Visible and shown if the channel is JID Visible .
'Enforce Hidden'	The user's JID will never be shown and the user will be removed from channel if channel mode is changed to JID Visible.
'Enforce Visible'	The users JID will always be shown and the user will be removed from channel if mode is changed to 'JID Hidden'.

The default value is 'Prefer Hidden'.

2.3 JID Visibility Architecture

MUC hides real JIDs by using Nicks to identify room occupants. This has problems with Nick changing and with multiple active clients for the same user. MIX identifies channel participants by a proxy JID, which is an anonymized stable JID format identifier for each participant. In Mediated Information eXchange (MIX) (XEP-0369) [1], the participants node provides a mapping from the proxy JID to the real JID. To hide JIDs, this specification makes two key changes

The requirement to include real JID in the participants list is relaxed for channels that are not "JID Visible". For a "JID Hidden" channel, real JIDs MUST NOT be included in the participants list. For a "JID Maybe Visible" channel, real JIDs will be included in the participants node according to participant preference.
In presence messages, the client resource is anonymized, to prevent leakage of information through the resource.

This change means that the client will not be able to determine real JID of the participant using the participant node, as it can with Mediated Information eXchange (MIX) (XEP-0369) [1].

It is important that MUC owners and administrators are able to see the real JIDs of participant. For this reason, a MIX channel following this specification MUST hold a JID Map node, which gives a mapping between proxy JID and real JID.

2.4 Resource Hiding

When JIDs are being hidden, the resource of the full JIDs stored in the presence node MUST also be anonymized using a similar mechanism. First the bare JID in presence is a proxy JID, as defined in Mediated Information eXchange (MIX) (XEP-0369) [1]. Where the JID is not being hidden, the resource is simply the resource of the clients full JID. Where the JID is hidden, the resource is replaced with a generated value. For example, 'hag66@shakespeare.example/UUID-a1j/7533' in the channel coven might have a proxy JID of '123456#coven@mix.shakespeare.example/789'. There is no client visible mapping of proxy full JIDs maintained as this is not needed. The MIX channel will need to maintain a mapping, to support directly addressing clients, such as for client to client disco#info queries. While an full proxy JID is held in the presence node, the mapping to real JID MUST NOT be changed. When adding a client to the presence node, the server MAY add the same anonymized JID as used before by that client, or it MAY create a different anonymized JID.

2.5 JID Map Node

This specification defines a JID Map node, so that administrators can see real JIDs for JID Hidden channels.

Table 3: JID Map Node

JID Map

'urn:xmpp:mix:nodes:jidmap'

For storing a list of bare proxy JIDs from the participants node with a 1:1 mapping to the corresponding real JIDs.

Automatic

PubSub

The JID Map node is used to associate a proxy bare JID to its corresponding real bare JID. It is a PubSub node with the 'node' attribute set to 'urn:xmpp:mix:nodes:jidmap'. The JID Map node MUST have one entry for each entry in the Participants node. This value is added when a user joins the channel and is removed when the user leaves the channel. Each item is identified by proxy bare JID, mapping to the real bare JID. This node is used to give administrator access to real JIDs and participant access to real JIDs in jid-visible channels. This node MUST NOT be modified directly using pubsub. In JID Visible channels, all participants MAY subscribe to this node. In JID Hidden and JID Maybe Visible channels, only administrators can subscribe. The JID Map node is a permanent node with one item per participant. Information is stored in a <participant/> element qualified by the 'urn:xmpp:mix:anon:0' namespace. The real JID is stored in a <jid/> child element of the <participant/> element.

Example 1. Value of JID Map Node

<items node='urn:xmpp:mix:nodes:jidmap'>
  <item id='123456#coven@mix.shakespeare.example'>
      <participant xmlns='urn:xmpp:mix:anon:0'>
         <jid>hecate@mix.shakespeare.example</jid>
      </participant>
  </item>
</items>

3. Use Cases

3.1 User Preferences and Additional Information

A channel MAY store user preferences and parameters with each user. A user JID visibility preference has the following values:

'default'. In this setting, the channel default value will be used. This value is used if another value is not explicitly set. This means JID is visible for a JID Visible channel and JID is hidden for JID Hidden and JID Maybe Visible channels.
'never'. If this is set, JID will never be shared and user will be removed from the channel if its mode changes to JID Visible.
'always'. If this is set, JID will always be shared and users will be removed from the channel if its mode changes to JID Hidden.
'prefer not'. If this is set, JID will only be shared if mode is JID Visible.

The user MAY specify that no Private Messages are to be sent from the channel, and allow vCard retrieval.

The user MAY specify that presence is not to be shared, which will prevent the MIX Channel from sending a presence probe for the user on channel start-up. The user will also choose to not include the MIX channel in the user's roster, so that presence will not be updated. Where the channel configuration sets 'Participants Must Provide Presence', this variable MUST be set to 'Share'.

The following table sets out the standardized user preference values. A MIX implementation MAY use other values.

Table 4: Standard User Preference Options

Option	Values	Default
'JID Visibility'	'default', 'never', 'always', 'prefer not'	'default'
'Private Messages'	'allow', 'block'	'allow'
'vCard'	'allow', 'block'	'block'
'Presence'	'share', 'not share'	'share'

When joining a channel, the client MAY specify one or more preference options as a Data Forms (XEP-0004) [2] form. In the response, the server MUST specify all of the user preferences supported by the server, with default values if the user has not requested a different value. The following example shows joining a channel and setting a preference. The following example shows the message sent from the user's server to the MIX channel, which will have been preceded by a message from the user's client to the user's server.

Example 2. User Joins a Channel and Specifies a preference

<iq type='set'
    from='hag66@shakespeare.example'
    to='coven@mix.shakespeare.example'
    id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
    <join xmlns='urn:xmpp:mix:anon:0'>
    <subscribe node='urn:xmpp:mix:nodes:messages'/>
    <subscribe node='urn:xmpp:mix:nodes:presence'/>
    <x xmlns='jabber:x:data' type='submit'>
        <field var='FORM_TYPE' type='hidden'>
             <value>urn:xmpp:mix:anon:0</value>
        </field>
        <field var='JID Visibility'>
            <value>never</value>
        </field>
     </x>
  </join>
</iq>

The following example shows the result of a successful join, which also reports all the user preferences. This example shows the message coming from the MIX channel to the user's server, which will be sent on to the user.

Example 3. Channel Successfully Processes Join and returns the preferences set

<iq type='result'
    from='coven@mix.shakespeare.example'
    to='hag66@shakespeare.example'
    id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
  <join xmlns='urn:xmpp:mix:anon:0' jid='hag66@shakespeare.example'>
    <subscribe node='urn:xmpp:mix:nodes:messages'/>
    <subscribe node='urn:xmpp:mix:nodes:presence'/>
    <x xmlns='jabber:x:data' type='result'>
      <field var='FORM_TYPE' type='hidden'>
        <value>urn:xmpp:mix:anon:0</value>
      </field>
      <field var='JID Visibility'>
        <value>never</value>
      </field>
      <field var='Private Messages'>
        <value>allow</value>
      </field>
      <field var='vCard'>
        <value>block</value>
      </field>
    </x>
  </join>
</iq>

The client MAY also query the channel in order to find out which user preferences are supported and the options available. This will allow users to set options not specified in the standard, by providing a form template in the result. The request is encoded as a <user-preference/> child element of <iq/>. <user-preference/> is qualified by the 'urn:xmpp:mix:anon:0' namespace. The result is encoded as a form child element in the <user-preference/> element.

Example 4. User Requests and Recieves Preferences Template Form

<iq type='get'
    from='hag66@shakespeare.example/UUID-a1j/7533'
    to='coven@mix.shakespeare.example'
    id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
    <user-preference xmlns='urn:xmpp:mix:anon:0'/>
</iq>

<iq type='result'
    from='coven@mix.shakespeare.example'
    to='hag66@shakespeare.example/UUID-a1j/7533'
    id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
    <user-preference xmlns='urn:xmpp:mix:anon:0'>
    <x xmlns='jabber:x:data' type='form'>
      <field var='FORM_TYPE' type='hidden'>
        <value>urn:xmpp:mix:anon:0</value>
     </field>
     <field type='list-single' label='Preference for JID Visibility
            var='JID Visibility'>
        <option label='JID Never Shown'><value>Never</value></option>
        <option label='Default Behaviour'
        <value>default</value></option>
          <option label='Try not to show JID'>
            <value>prefer not</value></option>
     </field>
     <field type='list-single' label='Example Custom Preference'
            var='Custom Preference'>
        <option label='One Option'><value>a</value></option>
        <option label='Another Option'><value>b</value></option>
      </field>
    </x>
  </user-preference>
</iq>

A user MAY modify preferences using the corresponding set operation. The set MAY specify values for some or all attributes. All attributes are returned in the result.

Example 5. User Updates Preferences

<iq type='set'
    from='hag66@shakespeare.example/UUID-a1j/7533'
    to='coven@mix.shakespeare.example'
    id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
    <user-preference xmlns='urn:xmpp:mix:anon:0'/>
     <x xmlns='jabber:x:data' type='submit'>
        <field var='FORM_TYPE' type='hidden'>
             <value>urn:xmpp:mix:anon:0</value>
        </field>
        <field var='JID Visibility'>
            <value>never</value>
        </field>
        <field var='Private Messages'>
           <value>allow</value>
         </field>
        <field var='vCard'>
          <value>block</value>
         </field>
     </x>
</iq>

<iq type='result'
    from='coven@mix.shakespeare.example'
    to='hag66@shakespeare.example/UUID-a1j/7533'
    id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
    <user-preference xmlns='urn:xmpp:mix:anon:0'>
    <x xmlns='jabber:x:data' type='result'>
        <field var='FORM_TYPE' type='hidden'>
             <value>urn:xmpp:mix:anon:0</value>
        </field>
        <field var='JID Visibility'>
            <value>never</value>
        </field>
        <field var='Private Messages'>
           <value>allow</value>
         </field>
        <field var='vCard'>
          <value>block</value>
         </field>
     </x>
  </user-preference>
</iq>

3.2 Sending Private Messages

Private Messages are used to provide communication with another channel participant through the MIX channel, where the initiating user does not the real JID of the channel participant. A channel MAY support use of Private Messages. Private messages are standard XMPP messages and MUST NOT be groupchat. A message goes through a number of stages with different addressing. This is set out in the following table.

Table 5: Setting From and To when sending Private Messages

Message	From	To
First Message from Client to MIX Channel	Full JID of initiator's client	Proxy bare JID of responder
First Message from MIX Channel to responder's server	Proxy full JID of initiator's client	Bare JID of responder
First Message from responder's server to one or more of the responder's clients	Proxy full JID of initiator	Full JID of responder's client
Messages from responder's client to MIX Channel	Full JID of responder's client	Proxy full JID of initiator's client
Messages from MIX channel to initiator's client	Proxy full JID of responder's client	Full JID of initiator's client
Messages from initiator's client to MIX Channel	Full JID of initiator's client	Proxy full JID of responder's client
Message from MIX Channel to responder's client	Proxy full JID of initiator's client	Full JID of responder's client

Private Messages MAY be archived using MAM by the XMPP servers associated with initiator and responder. Private Messages MUST NOT be archived by the MIX channel.

3.3 Requesting vCard

A client MAY request the vCard of a channel participant where the participant's real JID is not known, by sending a request through the channel. The MIX channel MAY pass this request on or MAY block it. vCard requests MAY use vcard-temp (XEP-0054) [3] (vcard-temp) or vCard4 over XMPP (XEP-0292) [4] (vCard4 over XMPP). The MIX channel does not process the vCard requests, but simply relays them on to real bare JID of the target. A MIX service MAY choose to relay one or both protocols. Where a MIX service relays one or both of these protocols, each protocol relayed MUST be advertised as a feature of the MIX service. In the following example, using vcard-temp, the requesting client sends a message to the bare proxy JID of the channel participant for which the vCard is desired.

Example 6. Client directly requests vCard through channel

<iq from='hag66@shakespeare.example/UUID-c8y/1573'
    id='lx09df27'
    to='989898#coven@mix.shakespeare.example'
    type='get'>
  <vCard xmlns='vcard-temp'/>
</iq>

The MIX channel MAY pass on the vCard request or MAY reject with an error, dependent on channel policy. The MIX service will then address the vCard request to the user's server (using bare JID) using a full proxy JID to hide the requester.

Example 7. Channel passes on vCard request to the User's Server

<iq from='123456#coven@mix.shakespeare.example/6789'
    id='lx09df27'
    to='peter@shakespeare.example'
    type='get'>
  <vCard xmlns='vcard-temp'/>
</iq>

The user's server, on behalf of the user, MAY send a response or reject with an error. The user's server will send the vCard back to the channel.

Example 8. User's Server sends vCard Response via MIX channel

<iq from='peter@shakespeare.example'
    id='lx09df27'
    to='123456#coven@mix.shakespeare.example/6789'
    type='result'>
    <vCard xmlns='vcard-temp'>
    <FN>Peter Saint-Andre</FN>
    <N>
      <FAMILY>Saint-Andre</FAMILY>
      <GIVEN>Peter</GIVEN>
      <MIDDLE/>
    </N>
    <NICKNAME>stpeter</NICKNAME>
    <URL>http://www.xmpp.org/xsf/people/stpeter.shtml</URL>
  </vCard>
  <query xmlns='http://jabber.org/protocol/disco#info'>
</iq>

The MIX channel will then send the vCard response to the requesting client on behalf of the client sending the response.

Example 9. MIX Channel sends vCard responst to Client

<iq from='989898#coven@mix.shakespeare.example'
    id='lx09df27'
    to='hag66@shakespeare.example/UUID-c8y/1573'
    type='result'>
 <vCard xmlns='vcard-temp'>
    <FN>Peter Saint-Andre</FN>
    <N>
      <FAMILY>Saint-Andre</FAMILY>
      <GIVEN>Peter</GIVEN>
      <MIDDLE/>
    </N>
    <NICKNAME>stpeter</NICKNAME>
    <URL>http://www.xmpp.org/xsf/people/stpeter.shtml</URL>
  </vCard>
</iq>

4. Internationalization Considerations

5. Security Considerations

6. IANA Considerations

7. XMPP Registrar Considerations

8. XML Schema

9. Acknowledgements

Appendices

Appendix A: Document Information

Series: XEP
Number: 0404
Publisher: XMPP Standards Foundation
Status: Experimental
Type: Standards Track
Version: 0.1.0
Last Updated: 2018-05-21
Approving Body: XMPP Council
Dependencies: XMPP Core, XMPP IM, XEP-0004, XEP-0030, XEP-0054, XEP-0060, XEP-0084, XEP-0128, XEP-0198, XEP-0292, XEP-0297, XEP-0313, XEP-0369, XEP-0372, XEP-0403
Supersedes: None
Superseded By: None
Short Name: MIX-ANON
Source Control: HTML
This document in other formats: XML PDF

Appendix B: Author Information

Kevin Smith

Email: kevin.smith@isode.com
JabberID: kevin.smith@isode.com

Steve Kille

Email: steve.kille@isode.com
JabberID: steve.kille@isode.com

Appendix C: Legal Notices

Copyright

Permissions

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.

Disclaimer of Warranty

## 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. ##

Limitation of Liability

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.

IPR Conformance

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).

Appendix D: Relation to XMPP

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.

Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Appendix F: Requirements Conformance

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".

Abstract:	This document defines an extension to Mediated Information eXchange (MIX) specified in XEP-0369. This specification extends MIX to provide a number of privacy control options and in particular JID Hidden Channels.
Authors:	Kevin Smith, Steve Kille
Copyright:	© 1999 – 2017 XMPP Standards Foundation. SEE LEGAL NOTICES.
Status:	Experimental
Type:	Standards Track
Version:	0.1.0
Last Updated:	2018-05-21