This specification defines an extension to XEP-0258 (Security Labels) to allow for the
use of security labels in XEP-0060 (Publish-Subscribe). This document describes how security
label metadata can be applied to the various elements within Publish-Subscribe, including nodes
WARNING: This document has been automatically Deferred after 12 months of inactivity in its previous Experimental state. Implementation of the protocol described herein is not recommended for production systems. However, exploratory implementations are encouraged to resume the standards process.
A publisher MUST be able to apply a Security Label to items within a node.
A node creator SHOULD be able to apply a Security Label to a node (this controls which
entities can access the node).
A node creator SHOULD be able to apply a Clearance to a node (this controls which Security
Labels can be applied to items within the node).
A node creator MAY be able to apply a default Security Label to a node (this applies to
items published to the node without a Security Label).
Node lists returned by the server SHOULD NOT contain nodes that the requesting entity is
not Cleared to view.
Item lists returned by the server MUST NOT contain items that the requesting entity is not
Cleared to view.
A client SHOULD only publish items to a node that are compatible with the Clearance of the
node (if the node has a Clearance), and a server MUST NOT store such items against the node
or send any notifications of any such items to subscribers.
Server responses from a request involving a node that the entity is not Cleared to view
SHOULD be identical to a response as if that node did not exist.
Server responses from a request involving an item that the entity is not Cleared to view
MUST be identical to a response as if that item did not exist.
A server MUST NOT notify or deliver items to an entity that the entity does not have
appropriate Clearance to view.
A collection of Security Labels that an entity is authorized to access.
An entity is Cleared to access content if the Access Control Decision Function (ACDF) of
the server yields a Grant given the entity's Clearance, the Security Label of the
content and the governing security policy.
A Security Label aware client SHOULD discover support for Security Labels within the
Publish-Subscribe (XEP-0060)  service domain. If the service domain does not report support for Security Labels
then the client SHOULD NOT publish with Security Labels.
A server SHOULD provide label feature and information discovery for each node.
Clients SHOULD discover label feature and information on a per-node basis.
A server SHOULD provide Security Label catalog discovery for each node.
Clients SHOULD discover the Security Label catalog on a per-node basis.
The server SHOULD limit the catalog for a node to those labels that are compatible with any
Clearance associated with the node.
The server SHOULD return an <item-not-found/> error if the subscriber is not Cleared to view the
The item list MUST NOT contain items that the subscriber is not Cleared to view.
The server MUST attach relevant <securitylabel/> child elements to the <items/> element.
Each of these <securitylabel/> elements MUST posess an 'id' attribute (from the urn:xmpp:sec-label:pubsub:0
namespace) which is unique within the stanza.
The server SHOULD normalise the elements so that multiple <item/> elements with the same
Security Label reference the same <securitylabel/> element; However, the server might
instead include a <securitylabel/> element for each <item/> element regardless of whether there
Each <item/> that has a Security Label MUST posess a 'label' attribute (from the urn:xmpp:sec-label:pubsub:0
namespace) that references the id of the relevant <securitylabel/>.
The server SHOULD NOT include <securitylabel/> elements which are not referenced within the
The server SHOULD allow for configuration of Security Label parameters for a node via node
configuration mechanisms. This approach is intended to be ad-hoc and so this section is
intended to be illustrative of one possible approach. Implementations are free to utilize
The server MUST disallow a node being created that has a default Security Label that is not
within the clearance of the node.
Changing the Security Label or Clearance of an existing node is problematic for a number of
Subscribers may no longer be Cleared to view a node to which they are already subscribed
Existing items persisted within a node may be of a higher Security Label than the new
node clearance allows
For these reasons an implementation MAY wish to disallow changes to the Security Label of
an existing node with subscribers, disallow changes to the Clearance of a node with items,
or limit the options within the node configuration to those which do not cause a conflict.
If an implementation chooses to allow a change to the clearance of a node that conflicts
with the Security Label of existing items within the node then the server MUST purge the
node of all items which are no longer within the updated clearance of the node, with or
without notifying subscribers.
If an implementation chooses to allow a change to the Security Label of the node that
causes conflicts with existing subscribers to the node then the server MUST remove all
subscriptions from subscribers that are no longer Cleared to view the node. The server MUST
notify these subscribers. The server SHOULD send a Node Deletion notification, but might
instead send a Subscription Cancellation notification if entities are to be aware of the
existence of nodes they do not have Clearance to view.
The server MUST prevent a change to the Security Label of the node which would prevent a
node owner from accessing the node.
9.1 Access to Items for which the Entity is not Cleared¶
The protocol defined has the intention that, as far as possible, an entity should be unaware of
the existence of any nodes or items which they are not Cleared to view. Therefore server
responses to a request for a node which the entity is not Cleared to view SHOULD be identical to
a response as if that node did not exist (See BR1), i.e. an
<item-not-found/> error is returned
It is worth noting that there are certain situations where this is impossible, for example if
an entity wishes to create a node with the same NodeID as an existing node that they are not
Cleared to view.
Alternatively, an implementation might wish to relax this rule and allow entities to become
aware of nodes they do not have Clearance to view. In this case an <insufficient-clearance/>
error MAY be returned instead.
A collection node MUST NOT forward a publish notification with a Security Label that is
incompatible with the Clearance of the collection node.
A collection node SHOULD NOT forward a node change notification
(create/update/delete/associate) where the Security Label of the affected node is
incompatible with the Clearance of the collection node.
The server SHOULD NOT send node change notifications to any entity where the Security Label
of the affected node is incompatible with the Clearance of the entity.
The server MUST NOT return any items from leaf nodes where the individual Security Label of
the item is incompatible with the Clearance of the requesting entity.
The server SHOULD NOT return any items from any associated nodes where the Security Label
of the leaf node, or any intermediate collection node on the node graph, is incompatible
with the Clearance of the requesting entity.
A server SHOULD NOT allow an entity to associate, either through configuration or through
an <associate/> statement, a child node to a collection node if the Security Label of the
child node is incompatible with the Clearance of the collection node.
9.3 Implementation Specific Structuring within Items¶
An implementation might choose to impose some kind of structure on items within a node. For
example: items may include a list of blog posts, but may also include comments relating to
specific blog posts from other users.
An implementation MAY apply different logic to the visibility of items in this case,
perhaps by disallowing access to comment items if the requester is not Cleared to view the
associated blog post item, even if the individual Security Label on the comment item would not
normally prevent access.
However, the server MUST NOT allow access to an item if the requester is not Cleared to view
the Security Label for the item (i.e. this mechanism must only be used to further restrict
access to items and must not be used to widen access).
9.4 Limiting Notifications to a Certain Clearance¶
An implementation may wish to allow a subscriber to limit the sensitivity of items which are
delivered for a certain subscription. For example: a subscriber may wish to only receive
notifications of items which are unclassified, even if the node has a higher clearance.
One way this could be implemented is by expanding the Data Form for the subscription options.
If the protocol defined in this specification undergoes a revision that is not fully backwards-compatible with an older version, the XMPP Registrar shall increment the protocol version number found at the end of the XML namespaces defined herein, as described in Section 4 of XEP-0053.
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.
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).
The HTML representation (you are looking at) is maintained by the XSF. It is based on the YAML CSS Framework, which is licensed under the terms of the CC-BY-SA 2.0 license.
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.
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".
4. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.