XEP-0223: Persistent Storage of Private Data via PubSub

NOTICE: This Informational specification defines a best practice or protocol profile that has been approved by the XMPP Council and/or the XSF Board of Directors. Implementations are encouraged and the best practice or protocol profile is appropriate for deployment in production systems.

Table of Contents

1. Introduction

<iq from='juliet@capulet.lit/balcony' type='set' id='pdp1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='storage:bookmarks'>
      <item>
        <conference xmlns='storage:bookmarks'
                    autojoin='true'
                    jid='theplay@conference.shakespeare.lit'
                    name='The Play&apos;s the Thing'>
          <nick>JC</nick>
          <password>Gl0b3</password>
        </conference>
      </item>
    </publish>
    <publish-options>
      <x xmlns='jabber:x:data' type='submit'>
        <field var='FORM_TYPE' type='hidden'>
          <value>http://jabber.org/protocol/pubsub#publish-options</value>
        </field>
        <field var='pubsub#persist_items'>
          <value>true</value>
        </field>
        <field var='pubsub#access_model'>
          <value>whitelist</value>
        </field>
      </x>
    </publish-options>
  </pubsub>
</iq>

<message from='juliet@capulet.lit'
         to='juliet@capulet.lit/balcony'
         type='headline'
         id='bmfoo1'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node='storage:bookmarks'>
      <item id='SomeID'>
        <conference xmlns='storage:bookmarks'
                    autojoin='true'
                    jid='theplay@conference.shakespeare.lit'
                    name='The Play&apos;s the Thing'>
          <nick>JC</nick>
          <password>Gl0b3</password>
        </conference>
      </item>
    </items>
  </event>
</message>

<message from='juliet@capulet.lit'
         to='juliet@capulet.lit/chamber'
         type='headline'
         id='bmfoo2'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node='storage:bookmarks'>
      <item id='SomeID'>
        <conference xmlns='storage:bookmarks'
                    autojoin='true'
                    jid='theplay@conference.shakespeare.lit'
                    name='The Play&apos;s the Thing'>
          <nick>JC</nick>
          <password>Gl0b3</password>
        </conference>
      </item>
    </items>
  </event>
</message>

2. Concepts and Approach

The best practices defined herein re-use the concepts already defined in XEP-0060 and XEP-0163. In order to optimize for object persistence of private information instead of transient event notifications related to semi-public data, a node MUST be configured as follows:

1. Set pubsub#persist_items to true.
2. Set pubsub#access_model to "whitelist".

3. Storing Data

An account owner publishes an item to a node by following the protocol specified in XEP-0060:

Example 3. Account owner stores data

<iq from='juliet@capulet.lit/balcony' type='set' id='pdp1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='storage:bookmarks'>
      <item>
        <conference xmlns='storage:bookmarks'
                    autojoin='true'
                    jid='theplay@conference.shakespeare.lit'
                    name='The Play&apos;s the Thing'>
          <nick>JC</nick>
          <password>Gl0b3</password>
        </conference>
      </item>
    </publish>
  </pubsub>
</iq>

If the node does not already exist, the virtual pubsub service MUST create the node. As described in XEP-0163, this "auto-create" feature (defined in XEP-0060) MUST be supported by a PEP service. (Naturally, the account owner's client MAY follow the node creation use case specified in XEP-0060 before attempting to publish an item.)

In order for the client to reliably persist private information, the virtual pubsub service must also support the "publish-options" feature defined in XEP-0060. Typically, a client will publish with options so that the object is privately stored.

Example 4. Storing bookmarks

<iq from='juliet@capulet.lit/balcony' type='set' id='pdp1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='storage:bookmarks'>
      <item>
        <conference xmlns='storage:bookmarks'
                    autojoin='true'
                    jid='theplay@conference.shakespeare.lit'
                    name='The Play&apos;s the Thing'>
          <nick>JC</nick>
          <password>Gl0b3</password>
        </conference>
      </item>
    </publish>
    <publish-options>
      <x xmlns='jabber:x:data' type='submit'>
        <field var='FORM_TYPE' type='hidden'>
          <value>http://jabber.org/protocol/pubsub#publish-options</value>
        </field>
        <field var='pubsub#persist_items'>
          <value>true</value>
        </field>
        <field var='pubsub#access_model'>
          <value>whitelist</value>
        </field>
      </x>
    </publish-options>
  </pubsub>
</iq>

If the publication logic dictates that event notifications shall be sent, the account owner's server generates notifications and sends them to all appropriate entities as described in the Receiving Event Notifications section of XEP-0163.

4. Composition

Each item published to the node is a logically separate instance of the data to be stored. It is the responsibility of the publishing and receiving entities to construct a complete view of all such items, if desired. For example, each bookmark published to a private data node is a separate piece of data, whereas the history of all items published to the node provides a complete list of the user's bookmarks. This history may include items that are republished with an existing ItemID (thus overwriting the previous version of that item).

5. Determining Support

Before an account owner attempts to complete any of the use cases defined herein, its client MUST verify that the account owner's server supports both PEP and the "publish-options" feature; to do so, it MUST send a Service Discovery (XEP-0030) [6] information request to the server (or cache Entity Capabilities information received from the server).

Example 5. Account owner queries server regarding protocol support

<iq from='juliet@capulet.lit/balcony'
    to='capulet.lit'
    id='disco1'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

The server MUST return an identity of "pubsub/pep" and include the "publish-options" feauture in the list of the namespaces and other features it supports:

Example 6. Server communicates protocol support

<iq from='capulet.lit'
    to='juliet@capulet.lit/balcony'
    id='disco1'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity category='server' type='im'/>
    <identity category='pubsub' type='pep'/>
    ...
    <feature var='http://jabber.org/protocol/pubsub#publish-options'/>
    ...
  </query>
</iq>

6. Security Considerations

Since private data is to be stored in a mechanism originally intended to publish data, it is REQUIRED for entities to ensure that the restrictive <publish-options/> will actually be honored by the server by performing the feature discovery procedure as specified in Determining Support. If an entity using that procedure finds that the server does not support <publish-options/>, it MUST NOT store private data in PubSub, unless it can ensure privacy of the data with other means.

The Security Considerations specified in XEP-0060 and XEP-0163 need to be taken into account.

7. IANA Considerations

This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [7].

8. XMPP Registrar Considerations

This document requires no interaction with the XMPP Registrar [8].

Appendices

Appendix A: Document Information

Series: XEP
Number: 0223
Publisher: XMPP Standards Foundation
Status: Active
Type: Informational
Version: 1.1
Last Updated: 2018-03-28
Approving Body: XMPP Council
Dependencies: XMPP Core, XMPP IM, XEP-0030, XEP-0060, XEP-0115
Supersedes: None
Superseded By: None
Short Name: N/A
Source Control: HTML
This document in other formats: XML  PDF

Appendix B: Author Information

Appendix C: Legal Notices

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.

Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.

Errata can be sent to <editor@xmpp.org>.

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

Appendix G: Notes

Appendix H: Revision History

Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/

END