[Standards] XEP-0314 and per-item labels for Pubsub
dave at cridland.net
Fri Jun 16 10:42:05 UTC 2017
As part of Surevine's product work, we're trying to apply labelling to
As some background, the labels we're concerned about are related to
cyber threat intelligence, and are labelled quite simply - people
posting to our system decide if the information they're posting is
Internal, Public, or somewhere in between, and decide how it might be
shared using a "Traffic Light Protocol" marking. Each discussion has a
Other servers, and users, have a clearance which then decides what
labels are visible.
While we're mostly discussion-based, using MIX, we have some
information (such as topic to discussion mappings) which are held as
pubsub items - these are labelled according to the discussion. Users
able to see only public information will then, when querying a topic's
discussions, only see public discussions.
We've looked at XEP-0314, and we think that the more recent changes to
it made it significantly more complex and error-prone, so we went back
to the original design. This places the security label immediately
after the item payload. Servers we tested all reject this, so it
seemed safe to extend here.
A key requirement for us is that remote servers have to be able to
apply their local users' clearances to the security label.
We can assume that all servers either:
* Support XEP-0258 properly.
* Have clearances set in their peers such that this is not an issue.
In other words, we either trust remote servers to handle security
labels properly according to their local users' clearances, or else we
can adjust the clearance we assign the server in order to restrict the
labels sent to public data.
This works fine on the pubsub server as:
A problem is that the posting user might be publishing something they
cannot themselves read, however - we cannot tell.
Here, we extract the security label and place it in the usual place as
an immediate child of the message. This works fine due to XEP-0258:
c) Get Items
This is a bit of a pain.
We've tried doing this in roughly the same way as the publishing, in
(a) above, but this clearly needs an additional control to indicate a
willingness to accept the labels, and moreover needs this from the
We've dealt with filtering on the remote server by intercepting get
items responses; so we're breaking the assumption I'd like to make.
d) Other considerations
In principle, publishing a new item to the same id ought to generate a
retraction for users unable to see the old item who *could* see the
new one. We don't do this.
Sending the last published item on a subscribe is currently a bit of a
pain in the Openfire codebase, so we're just dropping it if the
clearance does not match. This is mildly shonky, but works for us for
More information about the Standards