mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-21 08:45:04 -05:00
revised version from authors
This commit is contained in:
Peter Saint-Andre
parent
5f4cb14050
commit
f54258e364
@ -11,13 +11,24 @@
|
||||
<!ENTITY HEADLINE "<tt><headline/></tt>">
|
||||
<!ENTITY IDENTITY "<tt><identity/></tt>">
|
||||
<!ENTITY PUBLISH "<tt><publish/></tt>">
|
||||
<!ENTITY ITEMNOTFOUND "<tt><item-not-found/></tt>">
|
||||
<!ENTITY NOTAUTHORIZED "<tt><not-authorized/></tt>">
|
||||
<!ENTITY NOTACCEPTABLE "<tt><not-acceptable/></tt>">
|
||||
<!ENTITY INSUFFICIENTCLEARANCE "<tt><insufficient-clearance/></tt>">
|
||||
<!ENTITY ITEMS "<tt><items/></tt>">
|
||||
<!ENTITY ASSOCIATE "<tt><associate/></tt>">
|
||||
<!ENTITY NSMAIN "urn:xmpp:sec-label:pubsub:0">
|
||||
<!ENTITY NSERRORS "urn:xmpp:sec-label:pubsub:errors:0">
|
||||
]>
|
||||
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
||||
<xep>
|
||||
<header>
|
||||
<title>Security Labels in PubSub</title>
|
||||
<abstract>This document describes an extension to XEP-0258 (Security Labels in XMPP) to allow for the use of security labels in PubSub. This document describes
|
||||
how security label metadata can be applied to the various elements within PubSub, including nodes and items.</abstract>
|
||||
<abstract>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
|
||||
and items.
|
||||
</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>xxxx</number>
|
||||
<status>ProtoXEP</status>
|
||||
@ -36,69 +47,406 @@
|
||||
<firstname>Ashley</firstname>
|
||||
<surname>Ward</surname>
|
||||
<email>ashley.ward@surevine.com</email>
|
||||
<jid>ashley.ward@surevine.com</jid>
|
||||
</author>
|
||||
<author>
|
||||
<firstname>Lloyd</firstname>
|
||||
<surname>Watkin</surname>
|
||||
<email>lloyd.watkin@surevine.com</email>
|
||||
<jid>lloyd.watkin@surevine.com</jid>
|
||||
<jid>ashward@jabber.org</jid>
|
||||
<uri>http://www.surevine.com/</uri>
|
||||
</author>
|
||||
<revision>
|
||||
<version>0.0.1</version>
|
||||
<date>2012-05-16</date>
|
||||
<date>2012-06-08</date>
|
||||
<initials>asw</initials>
|
||||
<remark><p>First draft.</p></remark>
|
||||
</revision>
|
||||
</header>
|
||||
<section1 topic='Introduction' anchor='intro'>
|
||||
<p>This XEP defines a method to include Security Labels (as defined in &xep0258;) into PubSub (as
|
||||
defined in &xep0060;). Security labels (sometimes referred to as confidentiality labels) blah
|
||||
blah blah</p>
|
||||
<p>The use of security labels within XMPP is currently defined in &xep0258;. This, however, does
|
||||
not cover the use of security labels within &xep0060;. This XEP defines a method to include
|
||||
security labels into publish-subscribe.</p>
|
||||
<p>This allows content publishers to limit visibility of any sensitive published items to only
|
||||
those users with appropriate clearance to view them.</p>
|
||||
<p>This document does not deal with the semantics of a Security Label or how the security policy
|
||||
is applied to decisions regarding Security Labels and Clearances.</p>
|
||||
<p>This document should be read in conjunction with &xep0060; and &xep0258;.</p>
|
||||
</section1>
|
||||
<section1 topic='Requirements' anchor='reqs'>
|
||||
<p>STRONGLY RECOMMENDED.</p>
|
||||
<ul>
|
||||
<li>A publisher MUST be able to apply a Security Label to items within a node.</li>
|
||||
<li>A node creator SHOULD be able to apply a Security Label to a node (this controls which
|
||||
entities can access the node).</li>
|
||||
<li>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).</li>
|
||||
<li>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).</li>
|
||||
<li>Node lists returned by the server SHOULD NOT contain nodes that the requesting entity is
|
||||
not Cleared to view.</li>
|
||||
<li>Item lists returned by the server MUST NOT contain items that the requesting entity is not
|
||||
Cleared to view.</li>
|
||||
<li>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.</li>
|
||||
<li>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.</li>
|
||||
<li>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.</li>
|
||||
<li>A server MUST NOT notify or deliver items to an entity that the entity does not have
|
||||
appropriate Clearance to view.</li>
|
||||
</ul>
|
||||
</section1>
|
||||
<section1 topic='Glossary' anchor='glossary'>
|
||||
<p>OPTIONAL.</p>
|
||||
<p>In addition to the Glossary defined for &xep0060; the following terms are used:</p>
|
||||
<dl>
|
||||
<dt>Security Label</dt>
|
||||
<dd>The schema defined in &xep0258; with the XML namespace "urn:xmpp:sec-label:0"</dd>
|
||||
<di>
|
||||
<dt>Security Label</dt>
|
||||
<dd>
|
||||
<p>A label that can be applied to content to restrict the visibility of the content to
|
||||
entities with appropriate Clearance.</p>
|
||||
<p>The schema is defined in &xep0258; with the XML namespace "urn:xmpp:sec-label:0".</p>
|
||||
</dd>
|
||||
</di>
|
||||
<di>
|
||||
<dt>Clearance</dt>
|
||||
<dd>A collection of Security Labels that an entity is authorized to access.</dd>
|
||||
</di>
|
||||
<di>
|
||||
<dt>Cleared</dt>
|
||||
<dd>An entity is Cleared to access content if the Access Control Decision Function (ACDF) of
|
||||
the server yields a <i>Grant</i> given the entity's Clearance, the Security Label of the
|
||||
content and the governing security policy.</dd>
|
||||
</di>
|
||||
</dl>
|
||||
</section1>
|
||||
<section1 topic='Entity Use Cases' anchor='entityusecases'>
|
||||
<p>This section defines the use cases for and protocols to be used by any entity wishing to
|
||||
publish or subscribe to content with a Security Label</p>
|
||||
<section2 topic='Discovery' anchor='entityusecases-discovery'>
|
||||
<p>A server SHOULD provide a label feature and information discovery for each node</p>
|
||||
<p>Clients SHOULD discover label feature and information on a per-node basis</p>
|
||||
<p>This section defines the additions and caveats for the use cases and protocols defined in
|
||||
&xep0060;.</p>
|
||||
<section2 topic='Discovering Feature Support' anchor='entityusecases-discoveringfeaturesupport'>
|
||||
<p>A Security Label aware client SHOULD discover support for Security Labels within the
|
||||
&xep0060; service domain. If the service domain does not report support for Security Labels
|
||||
then the client SHOULD NOT publish with Security Labels.</p>
|
||||
<example caption='Service discovery information request'><![CDATA[
|
||||
<iq from='francisco@denmark.lit/barracks'
|
||||
id='disco1'
|
||||
to='pubsub.shakespeare.lit'
|
||||
type='get'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'/>
|
||||
</iq>
|
||||
]]></example>
|
||||
<example caption='Service discovery information response'><![CDATA[
|
||||
<iq from='pubsub.shakespeare.lit'
|
||||
id='disco1'
|
||||
to='francisco@denmark.lit/barracks'
|
||||
type='result'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'>
|
||||
...
|
||||
<feature var='urn:xmpp:sec-label:0'/>
|
||||
...
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>A server SHOULD provide label feature and information discovery for each node.</p>
|
||||
<p>Clients SHOULD discover label feature and information on a per-node basis.</p>
|
||||
<example caption='Label feature discovery request for a node'><![CDATA[
|
||||
<iq from='francisco@denmark.lit/barracks'
|
||||
id='disco2'
|
||||
to='pubsub.shakespeare.lit'
|
||||
type='get'>
|
||||
<query node='princely_musings' xmlns='http://jabber.org/protocol/disco#info'/>
|
||||
</iq>
|
||||
]]></example>
|
||||
<example caption='Label feature discovery response for a node'><![CDATA[
|
||||
<iq from='pubsub.shakespeare.lit'
|
||||
id='disco2'
|
||||
to='francisco@denmark.lit/barracks'
|
||||
type='result'>
|
||||
<query node='princely_musings' xmlns='http://jabber.org/protocol/disco#info'>
|
||||
...
|
||||
<feature var='urn:xmpp:sec-label:catalog:2'/>
|
||||
...
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>A server SHOULD provide Security Label catalog discovery for each node.</p>
|
||||
<p>Clients SHOULD discover the Security Label catalog on a per-node basis.</p>
|
||||
<p>The server SHOULD limit the catalog for a node to those labels that are compatible with any
|
||||
Clearance associated with the node.</p>
|
||||
<example caption='The client requests the catalog for a node'><![CDATA[
|
||||
<iq id='cat1'
|
||||
to='pubsub.shakespeare.lit'
|
||||
type='get'>
|
||||
<catalog xmlns='urn:xmpp:sec-label:catalog:2'
|
||||
to='pubsub.shakespeare.lit'
|
||||
node='princely_musings'/>
|
||||
</iq>
|
||||
]]></example>
|
||||
<example caption='The server responds with the catalog for the node'><![CDATA[
|
||||
<iq from='pubsub.shakespeare.lit'
|
||||
id='cat1'
|
||||
to='francisco@denmark.lit/barracks'
|
||||
type='result'>
|
||||
<catalog xmlns='urn:xmpp:sec-label:catalog:2'
|
||||
to='example.com'
|
||||
name='Default'
|
||||
desc='The set of labels applicable to the "princely_musings" node'
|
||||
restrict='false'
|
||||
node='princely_musings'>
|
||||
<item selector="Classified|SECRET">
|
||||
<securitylabel xmlns='urn:xmpp:sec-label:0'>
|
||||
<displaymarking fgcolor='black' bgcolor='red'>SECRET</displaymarking>
|
||||
<label>
|
||||
<esssecuritylabel xmlns='urn:xmpp:sec-label:ess:0'
|
||||
>MQYCAQQGASk=</esssecuritylabel>
|
||||
</label>
|
||||
</securitylabel>
|
||||
</item>
|
||||
<item selector="Classified|CONFIDENTIAL">
|
||||
<securitylabel xmlns='urn:xmpp:sec-label:0'>
|
||||
<displaymarking fgcolor='black' bgcolor='navy'>CONFIDENTIAL</displaymarking>
|
||||
<label>
|
||||
<esssecuritylabel xmlns='urn:xmpp:sec-label:ess:0'
|
||||
>MQYCAQMGASk</esssecuritylabel>
|
||||
</label>
|
||||
</securitylabel>
|
||||
</item>
|
||||
<item selector="Classified|RESTRICTED">
|
||||
<securitylabel xmlns='urn:xmpp:sec-label:0'>
|
||||
<displaymarking fgcolor='black' bgcolor='aqua'>RESTRICTED</displaymarking>
|
||||
<label>
|
||||
<esssecuritylabel xmlns='urn:xmpp:sec-label:ess:0'
|
||||
>MQYCAQIGASk=</esssecuritylabel>
|
||||
</label>
|
||||
</securitylabel>
|
||||
</item>
|
||||
<item selector="UNCLASSIFIED" default="true"/>
|
||||
</catalog>
|
||||
</iq>
|
||||
]]></example>
|
||||
</section2>
|
||||
<section2 topic='Discover Nodes' anchor='entityusecases-discovernodes'>
|
||||
<p>The protocol for node discovery is as defined in &xep0060;, but with the caveat that the
|
||||
server SHOULD NOT return any nodes that have a security marking that the entity is not
|
||||
authorised to view.</p>
|
||||
<p>If a service implements a hierarchy of nodes (via
|
||||
<link url="http://xmpp.org/extensions/xep-0060.html#collections">Collection Nodes</link>)
|
||||
then the server MUST also prevent access to any child nodes of any nodes which the entity
|
||||
is not authorised to view, even if the node's individual security label would otherwise
|
||||
allow this</p>
|
||||
<p>The server SHOULD NOT return any nodes that have a Security Label that the entity is not
|
||||
Cleared to view.</p>
|
||||
<example caption='Entity request list of top-level nodes'><![CDATA[
|
||||
<iq from='francisco@denmark.lit/barracks'
|
||||
id='nodes1'
|
||||
to='pubsub.shakespeare.lit'
|
||||
type='get'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#items'/>
|
||||
</iq>
|
||||
]]></example>
|
||||
<example caption='Server responds with list of nodes with Security Labels'><![CDATA[
|
||||
<iq type='result'
|
||||
from='pubsub.shakespeare.lit'
|
||||
to='francisco@denmark.lit/barracks'
|
||||
id='nodes1'
|
||||
xmlns:slps='urn:xmpp:sec-label:pubsub:0'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#items'>
|
||||
<item jid='pubsub.shakespeare.lit'
|
||||
node='blogs'
|
||||
name='Weblog updates'
|
||||
slps:label='seclabel-1'/>
|
||||
<item jid='pubsub.shakespeare.lit'
|
||||
node='news'
|
||||
name='News and announcements'
|
||||
slps:label='seclabel-2'/>
|
||||
<securitylabel xmlns='urn:xmpp:sec-label:0' slps:id='seclabel-1'>
|
||||
<displaymarking fgcolor='black' bgcolor='green'>UNCLASSIFIED</displaymarking>
|
||||
<label>
|
||||
<esssecuritylabel xmlns='urn:xmpp:sec-label:ess:0'>MQMGASk=</esssecuritylabel>
|
||||
</label>
|
||||
</securitylabel>
|
||||
<securitylabel xmlns='urn:xmpp:sec-label:0' slps:id='seclabel-2'>
|
||||
<displaymarking fgcolor='black' bgcolor='red'>SECRET</displaymarking>
|
||||
<label>
|
||||
<esssecuritylabel xmlns='urn:xmpp:sec-label:ess:0'>MQYCAQIGASk=</esssecuritylabel>
|
||||
</label>
|
||||
</securitylabel>
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
</section2>
|
||||
<section2 topic='Discover Items for a Node' anchor='entityusecases-discoveritems'>
|
||||
|
||||
<p>The item list MUST NOT contain items that the entity is not Cleared to view.</p>
|
||||
<p>The server SHOULD return an &ITEMNOTFOUND; error if the entity is not Cleared to view
|
||||
the node.</p>
|
||||
<p>See <link url='#subscriberusecases-retrieveitems'>Subscriber Use Cases: Retrieve Items from a
|
||||
Node</link> for more details of how Security Labels are respresented in the server response.
|
||||
</p>
|
||||
<example caption='Entity requests all of the items for a node'><![CDATA[
|
||||
<iq from='francisco@denmark.lit/barracks'
|
||||
id='items1'
|
||||
to='pubsub.shakespeare.lit'
|
||||
type='get'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#items'
|
||||
node='princely_musings'/>
|
||||
</iq>
|
||||
]]>
|
||||
</example>
|
||||
<example caption='Server responds with items in the node'><![CDATA[
|
||||
<iq from='pubsub.shakespeare.lit'
|
||||
id='items1'
|
||||
to='francisco@denmark.lit/barracks'
|
||||
type='result'
|
||||
xmlns:slps='urn:xmpp:sec-label:pubsub:0'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#items'
|
||||
node='princely_musings'>
|
||||
<item
|
||||
jid='pubsub.shakespeare.lit'
|
||||
name='368866411b877c30064a5f62b917cffe'
|
||||
slps:label='seclabel-1'/>
|
||||
<item
|
||||
jid='pubsub.shakespeare.lit'
|
||||
name='3300659945416e274474e469a1f0154c'
|
||||
slps:label='seclabel-1'/>
|
||||
<item
|
||||
jid='pubsub.shakespeare.lit'
|
||||
name='4e30f35051b7b8b42abe083742187228'
|
||||
slps:label='seclabel-2'/>
|
||||
<item
|
||||
jid='pubsub.shakespeare.lit'
|
||||
name='ae890ac52d0df67ed7cfdf51b644e901'
|
||||
slps:label='seclabel-1'/>
|
||||
<securitylabel xmlns='urn:xmpp:sec-label:0' slps:id='seclabel-1'>
|
||||
<displaymarking fgcolor='black' bgcolor='green'>UNCLASSIFIED</displaymarking>
|
||||
<label>
|
||||
<esssecuritylabel xmlns='urn:xmpp:sec-label:ess:0'>MQMGASk=</esssecuritylabel>
|
||||
</label>
|
||||
</securitylabel>
|
||||
<securitylabel xmlns='urn:xmpp:sec-label:0' slps:id='seclabel-2'>
|
||||
<displaymarking fgcolor='black' bgcolor='red'>SECRET</displaymarking>
|
||||
<label>
|
||||
<esssecuritylabel xmlns='urn:xmpp:sec-label:ess:0'>MQYCAQIGASk=</esssecuritylabel>
|
||||
</label>
|
||||
</securitylabel>
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic='Subscriber Use Cases' anchor='subscriberusecases'>
|
||||
<section2 topic='Subscribe to a Node' anchor='subscriberusecases-subscribenode'>
|
||||
<p>The server SHOULD return an &ITEMNOTFOUND; error if the subscriber is not Cleared to view
|
||||
the node.</p>
|
||||
</section2>
|
||||
<section2 topic='Retrieve Items from a Node' anchor='subscriberusecases-retrieveitems'>
|
||||
<p>The server SHOULD return an &ITEMNOTFOUND; error if the subscriber is not Cleared to view the
|
||||
node.</p>
|
||||
<p>The item list MUST NOT contain items that the subscriber is not Cleared to view.</p>
|
||||
<p>The server MUST attach relevant &SECURITYLABEL; child elements to the &ITEMS; element.</p>
|
||||
<p>Each of these &SECURITYLABEL; elements MUST posess an 'id' attribute (from the &NSMAIN;
|
||||
namespace) which is unique within the stanza.</p>
|
||||
<p>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
|
||||
are duplicates.</p>
|
||||
<p>Each &ITEM; that has a Security Label MUST posess a 'label' attribute (from the &NSMAIN;
|
||||
namespace) that references the id of the relevant &SECURITYLABEL;.</p>
|
||||
<p>The server SHOULD NOT include &SECURITYLABEL; elements which are not referenced within the
|
||||
stanza.</p>
|
||||
<example caption='The server returns a list of items with Security Labels'><![CDATA[
|
||||
<iq from='pubsub.shakespeare.lit'
|
||||
id='items1'
|
||||
to='francisco@denmark.lit/barracks'
|
||||
type='result'
|
||||
xmlns:slps='urn:xmpp:sec-label:pubsub:0'>
|
||||
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
|
||||
<items node='princely_musings'>
|
||||
<item id='368866411b877c30064a5f62b917cffe' slps:label='seclabel-1'>
|
||||
<entry xmlns='http://www.w3.org/2005/Atom'>
|
||||
<title>The Uses of This World</title>
|
||||
<summary>
|
||||
O, that this too too solid flesh would melt
|
||||
Thaw and resolve itself into a dew!
|
||||
</summary>
|
||||
<link rel='alternate' type='text/html'
|
||||
href='http://denmark.lit/2003/12/13/atom03'/>
|
||||
<id>tag:denmark.lit,2003:entry-32396</id>
|
||||
<published>2003-12-12T17:47:23Z</published>
|
||||
<updated>2003-12-12T17:47:23Z</updated>
|
||||
</entry>
|
||||
</item>
|
||||
<item id='3300659945416e274474e469a1f0154c' slps:label='seclabel-1'>
|
||||
<entry xmlns='http://www.w3.org/2005/Atom'>
|
||||
<title>Ghostly Encounters</title>
|
||||
<summary>
|
||||
O all you host of heaven! O earth! what else?
|
||||
And shall I couple hell? O, fie! Hold, hold, my heart;
|
||||
And you, my sinews, grow not instant old,
|
||||
But bear me stiffly up. Remember thee!
|
||||
</summary>
|
||||
<link rel='alternate' type='text/html'
|
||||
href='http://denmark.lit/2003/12/13/atom03'/>
|
||||
<id>tag:denmark.lit,2003:entry-32396</id>
|
||||
<published>2003-12-12T23:21:34Z</published>
|
||||
<updated>2003-12-12T23:21:34Z</updated>
|
||||
</entry>
|
||||
</item>
|
||||
<item id='4e30f35051b7b8b42abe083742187228' slps:label='seclabel-2'>
|
||||
<entry xmlns='http://www.w3.org/2005/Atom'>
|
||||
<title>Alone</title>
|
||||
<summary>
|
||||
Now I am alone.
|
||||
O, what a rogue and peasant slave am I!
|
||||
</summary>
|
||||
<link rel='alternate' type='text/html'
|
||||
href='http://denmark.lit/2003/12/13/atom03'/>
|
||||
<id>tag:denmark.lit,2003:entry-32396</id>
|
||||
<published>2003-12-13T11:09:53Z</published>
|
||||
<updated>2003-12-13T11:09:53Z</updated>
|
||||
</entry>
|
||||
</item>
|
||||
<item id='ae890ac52d0df67ed7cfdf51b644e901' slps:label='seclabel-1'>
|
||||
<entry xmlns='http://www.w3.org/2005/Atom'>
|
||||
<title>Soliloquy</title>
|
||||
<summary>
|
||||
To be, or not to be: that is the question:
|
||||
Whether 'tis nobler in the mind to suffer
|
||||
The slings and arrows of outrageous fortune,
|
||||
Or to take arms against a sea of troubles,
|
||||
And by opposing end them?
|
||||
</summary>
|
||||
<link rel='alternate' type='text/html'
|
||||
href='http://denmark.lit/2003/12/13/atom03'/>
|
||||
<id>tag:denmark.lit,2003:entry-32397</id>
|
||||
<published>2003-12-13T18:30:02Z</published>
|
||||
<updated>2003-12-13T18:30:02Z</updated>
|
||||
</entry>
|
||||
</item>
|
||||
<securitylabel xmlns='urn:xmpp:sec-label:0' slps:id='seclabel-1'>
|
||||
<displaymarking fgcolor='black' bgcolor='green'>UNCLASSIFIED</displaymarking>
|
||||
<label>
|
||||
<esssecuritylabel xmlns='urn:xmpp:sec-label:ess:0'>MQMGASk=</esssecuritylabel>
|
||||
</label>
|
||||
</securitylabel>
|
||||
<securitylabel xmlns='urn:xmpp:sec-label:0' slps:id='seclabel-2'>
|
||||
<displaymarking fgcolor='black' bgcolor='red'>SECRET</displaymarking>
|
||||
<label>
|
||||
<esssecuritylabel xmlns='urn:xmpp:sec-label:ess:0'>MQYCAQIGASk=</esssecuritylabel>
|
||||
</label>
|
||||
</securitylabel>
|
||||
</items>
|
||||
</pubsub>
|
||||
</iq>
|
||||
]]></example>
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic='Publisher Use Cases' anchor='publisherusecases'>
|
||||
<section2 topic='Publish an Item' anchor='publisherusecases-publishitem'>
|
||||
<p>Each Item within a &PUBLISH; element may be individually labelled with a &SECURITYLABEL;</p>
|
||||
<p>The server SHOULD apply the default label for the node to any items which do not contain a
|
||||
&SECURITYLABEL;</p>
|
||||
<example caption="Publisher publishes an Item with a Security Label"><![CDATA[
|
||||
<iq type='set'
|
||||
from='hamlet@denmark.lit/blogbot'
|
||||
<section2 topic='Publish an Item to a Node' anchor='publisherusecases-publishitem'>
|
||||
<p>A &PUBLISH; element MAY contain a &SECURITYLABEL; which the service must apply to all the
|
||||
items within the &PUBLISH;.</p>
|
||||
<p>If a publisher wishes to publish multiple items with different Security Labels, they MUST
|
||||
send multiple &iq; stanzas - one for each Security Label.</p>
|
||||
<p>The server SHOULD apply the default label for the node to any items within a &PUBLISH; which
|
||||
does not contain a &SECURITYLABEL;.</p>
|
||||
<p>Any &SECURITYLABEL; within a &PUBLISH; should be compatible with any Clearance associated
|
||||
with the node, else the service MUST return an &INSUFFICIENTCLEARANCE; error.</p>
|
||||
<p>If a publisher attempts to publish to a node which the publisher is not Cleared to view, the
|
||||
service SHOULD return an &ITEMNOTFOUND; error.</p>
|
||||
<p>A publisher SHOULD not attempt to publish an item with a Security Label which is not suitable
|
||||
to the Clearance of the node.</p>
|
||||
<p>Any &PUBLISH; with a &SECURITYLABEL; should be compatible with the Clearance of the
|
||||
publishing entity, else the server MUST return an &INSUFFICIENTCLEARANCE; error.</p>
|
||||
<example caption='Publisher publishes an item with a Security Label'><![CDATA[
|
||||
<iq from='hamlet@denmark.lit/blogbot'
|
||||
id='pub1'
|
||||
to='pubsub.shakespeare.lit'
|
||||
id='pub1'>
|
||||
type='set'>
|
||||
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
|
||||
<publish node='princely_musings'>
|
||||
<item>
|
||||
@ -117,21 +465,25 @@ And by opposing end them?
|
||||
<published>2003-12-13T18:30:02Z</published>
|
||||
<updated>2003-12-13T18:30:02Z</updated>
|
||||
</entry>
|
||||
<securitylabel xmlns='urn:xmpp:sec-label:0'>
|
||||
<displaymarking fgcolor='black' bgcolor='green'>UNCLASSIFIED</displaymarking>
|
||||
<label>
|
||||
<esssecuritylabel xmlns='urn:xmpp:sec-label:ess:0'>MQMGASk=</esssecuritylabel>
|
||||
</label>
|
||||
</securitylabel>
|
||||
</item>
|
||||
<securitylabel xmlns='urn:xmpp:sec-label:0'>
|
||||
<displaymarking fgcolor='black' bgcolor='green'>UNCLASSIFIED</displaymarking>
|
||||
<label>
|
||||
<esssecuritylabel xmlns='urn:xmpp:sec-label:ess:0'>MQMGASk=</esssecuritylabel>
|
||||
</label>
|
||||
</securitylabel>
|
||||
</publish>
|
||||
</pubsub>
|
||||
</iq>
|
||||
]]></example>
|
||||
<section3 topic='Notification with Payloads'>
|
||||
<p>The service then notifies appropriately cleared subscribers</p>
|
||||
<example caption="Subscriber receives event notification with payload"><![CDATA[
|
||||
<message from='pubsub.shakespeare.lit' to='francisco@denmark.lit' id='foo'>
|
||||
]]></example>
|
||||
<p>The service then notifies appropriately Cleared subscribers. The server MUST NOT notify
|
||||
subscribers that do not have appropriate Clearance to view the item.</p>
|
||||
<p>The server MUST include the &SECURITYLABEL; element as a child of the &MESSAGE; stanza. The
|
||||
server MUST NOT include the &SECURITYLABEL; element within the &ITEMS; element.</p>
|
||||
<p>The Security Label applies to the entire message (including all the items within the &ITEMS;
|
||||
element and any &BODY; if the entity's subscription is so configured).</p>
|
||||
<example caption='Subscriber receives event notification with payload'><![CDATA[
|
||||
<message from='pubsub.shakespeare.lit' id='foo' to='francisco@denmark.lit'>
|
||||
<event xmlns='http://jabber.org/protocol/pubsub#event'>
|
||||
<items node=princely_musings'>
|
||||
<item id='ae890ac52d0df67ed7cfdf51b644e901'>
|
||||
@ -150,60 +502,361 @@ And by opposing end them?
|
||||
<published>2003-12-13T18:30:02Z</published>
|
||||
<updated>2003-12-13T18:30:02Z</updated>
|
||||
</entry>
|
||||
<securitylabel xmlns='urn:xmpp:sec-label:0'>
|
||||
<displaymarking fgcolor='black' bgcolor='green'>UNCLASSIFIED</displaymarking>
|
||||
<label>
|
||||
<esssecuritylabel xmlns='urn:xmpp:sec-label:ess:0'>MQMGASk=</esssecuritylabel>
|
||||
</label>
|
||||
</securitylabel>
|
||||
</item>
|
||||
</items>
|
||||
</event>
|
||||
<securitylabel xmlns='urn:xmpp:sec-label:0'>
|
||||
<displaymarking fgcolor='black' bgcolor='green'>UNCLASSIFIED</displaymarking>
|
||||
<label>
|
||||
<esssecuritylabel xmlns='urn:xmpp:sec-label:ess:0'>MQMGASk=</esssecuritylabel>
|
||||
</label>
|
||||
</securitylabel>
|
||||
</message>
|
||||
]]></example>
|
||||
<example caption='Subscriber receives event notification without payload'><![CDATA[
|
||||
<message from='pubsub.shakespeare.lit' id='foo' to='francisco@denmark.lit'>
|
||||
<event xmlns='http://jabber.org/protocol/pubsub#event'>
|
||||
<items node=princely_musings'>
|
||||
<item id='ae890ac52d0df67ed7cfdf51b644e901' />
|
||||
</items>
|
||||
</event>
|
||||
<securitylabel xmlns='urn:xmpp:sec-label:0'>
|
||||
<displaymarking fgcolor='black' bgcolor='green'>UNCLASSIFIED</displaymarking>
|
||||
<label>
|
||||
<esssecuritylabel xmlns='urn:xmpp:sec-label:ess:0'>MQMGASk=</esssecuritylabel>
|
||||
</label>
|
||||
</securitylabel>
|
||||
</message>
|
||||
]]></example>
|
||||
<section3 topic='Error Cases'>
|
||||
<section4 topic='An Attempt to Publish an Item which Exceeds the Node's Clearance'
|
||||
anchor='publisherusecases-publishitem-errors-nodeclearance'>
|
||||
<p>If a publisher attempts to publish to a node with a Security Label that is incompatible
|
||||
with the Clearance of the node then the server MUST return an &INSUFFICIENTCLEARANCE;
|
||||
error.</p>
|
||||
<example caption='Publishing to a node with insufficient node Clearance'><![CDATA[
|
||||
<iq from='pubsub.shakespeare.lit'
|
||||
id='sub1'
|
||||
to='francisco@denmark.lit/barracks'
|
||||
type='error'>
|
||||
<error type='modify'>
|
||||
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
|
||||
<insufficient-clearance xmlns='urn:xmpp:sec-label:pubsub:errors:0'/>
|
||||
</error>
|
||||
</iq>
|
||||
]]></example>
|
||||
</section4>
|
||||
<section4 topic='An Attempt to Publish an Item which is Incompatible with the Publisher's
|
||||
Clearance'
|
||||
anchor='publisherusecases-publishitem-errors-publisherclearance'>
|
||||
<p>If a publisher attempts to publish to a node with a Security Label that is incompatible
|
||||
with the Clearance of the publisher then the server MUST return an &INSUFFICIENTCLEARANCE;
|
||||
error.</p>
|
||||
<example caption='Publishing to a node with insufficient publisher Clearance'><![CDATA[
|
||||
<iq from='pubsub.shakespeare.lit'
|
||||
id='sub1'
|
||||
to='francisco@denmark.lit/barracks'
|
||||
type='error'>
|
||||
<error type='auth'>
|
||||
<insufficient-clearance xmlns='urn:xmpp:sec-label:pubsub:errors:0'/>
|
||||
</error>
|
||||
</iq>
|
||||
]]></example>
|
||||
</section4>
|
||||
</section3>
|
||||
</section2>
|
||||
<section2 topic='Delete an item from a node' anchor='publisherusecases-deleteitem'>
|
||||
<p>The server SHOULD return an &ITEMNOTFOUND; error if the subscriber is not Cleared to view
|
||||
the node or item.</p>
|
||||
<p>The server MUST NOT send retract requests to subscribers who are not Cleared to view the
|
||||
item.</p>
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic='Owner Use Cases' anchor='ownerusecases'>
|
||||
<section2 topic='Node Configuration'>
|
||||
<p>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
|
||||
other approaches.</p>
|
||||
<p>The server MUST disallow a node being created that has a default Security Label that is not
|
||||
within the clearance of the node.</p>
|
||||
<example caption='Node configuration form'><![CDATA[
|
||||
<iq from='pubsub.shakespeare.lit'
|
||||
id='config1'
|
||||
to='hamlet@denmark.lit/elsinore'
|
||||
type='result'>
|
||||
<pubsub xmlns='http://jabber.org/protocol/pubsub#owner'>
|
||||
<configure node='princely_musings'>
|
||||
<x xmlns='jabber:x:data' type='form'>
|
||||
...
|
||||
<field label='Node Label' type='list-single' var='sec-label#label'>
|
||||
<value>Catalog:UNCLASSIFIED</value>
|
||||
<option label='SECRET'><value>Catalog:SECRET</value></option>
|
||||
<option label='CONFIDENTIAL'><value>Catalog:CONFIDENTIAL</value></option>
|
||||
<option label='UNCLASSIFIED'><value>Catalog:UNCLASSIFIED</value></option>
|
||||
<option label='Custom'><value>Custom</value></option>
|
||||
</field>
|
||||
<field label='Custom Node Label' type='text-single'
|
||||
var='sec-label#custom-label'/>
|
||||
|
||||
<field label='Node Clearance' type='list-multi' var='sec-label#clearance'>
|
||||
<value>Catalog:UNCLASSIFIED</value>
|
||||
<option label='SECRET'><value>Catalog:SECRET</value></option>
|
||||
<option label='CONFIDENTIAL'><value>Catalog:CONFIDENTIAL</value></option>
|
||||
<option label='UNCLASSIFIED'><value>Catalog:UNCLASSIFIED</value></option>
|
||||
<option label='Custom'><value>Custom</value></option>
|
||||
</field>
|
||||
<field label='Custom Node Clearance' type='text-single'
|
||||
var='sec-label#custom-clearance'/>
|
||||
</x>
|
||||
</configure>
|
||||
</pubsub>
|
||||
</iq>
|
||||
]]></example>
|
||||
<section3 topic='Updating an Existing Node Configuration'
|
||||
anchor='ownerusercases-configuration-updating'>
|
||||
<p>Changing the Security Label or Clearance of an existing node is problematic for a number of
|
||||
reasons:</p>
|
||||
<ul>
|
||||
<li>Subscribers may no longer be Cleared to view a node to which they are already subscribed
|
||||
</li>
|
||||
<li>Existing items persisted within a node may be of a higher Security Label than the new
|
||||
node clearance allows</li>
|
||||
</ul>
|
||||
<p>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.
|
||||
</p>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<p>The server MUST prevent a change to the Security Label of the node which would prevent a
|
||||
node owner from accessing the node.</p>
|
||||
<example caption='Node Deletion Notification'><![CDATA[
|
||||
<message from='pubsub.shakespeare.lit' id='deletenotify1' to='francisco@denmark.lit'>
|
||||
<event xmlns='http://jabber.org/protocol/pubsub#event'>
|
||||
<delete node='princely_musings' />
|
||||
</event>
|
||||
</message>
|
||||
]]></example>
|
||||
</section3>
|
||||
<section3 topic='Notification without Payloads'>
|
||||
<p>If the node is configured not to include payloads</p>
|
||||
</section3>
|
||||
<example caption='Subscription Cancellation Notification'><![CDATA[
|
||||
<message from='pubsub.shakespeare.lit' id='unsubnotify1' to='horatio@denmark.lit'>
|
||||
<event xmlns='http://jabber.org/protocol/pubsub#event'>
|
||||
<subscription jid='horatio@denmark.lit' node='princely_musings' subscription='none'/>
|
||||
</event>
|
||||
</message>
|
||||
]]></example>
|
||||
</section3>
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic='Business Rules' anchor='rules'>
|
||||
<p>OPTIONAL.</p>
|
||||
<ol>
|
||||
<li>Server responses from a request for a node which the entity is not authorised to view MUST
|
||||
be identical to a response as if that node did not exist.
|
||||
<example caption="Request for a node that the entity is not authorised to view"><![CDATA[
|
||||
<iq type='error'
|
||||
from='pubsub.shakespeare.lit'
|
||||
<li id='rules-1'>An entity SHOULD NOT be aware of the existance of nodes or items that they do
|
||||
not have appropriate Clearance to view (But see <link url='#impl-access'>Implementation Notes:
|
||||
Access to items for which the entity is not Cleared</link>)</li>
|
||||
<li id='rules-2'>Items MUST only be accessible by entities with the appropriate Clearance</li>
|
||||
<li id='rules-3'>If a node has an associated Clearance then the node MUST only deal with (i.e.
|
||||
persist or notify) items which are compatible with the Clearance</li>
|
||||
</ol>
|
||||
</section1>
|
||||
<section1 topic='Implementation Notes' anchor='impl'>
|
||||
<section2 topic='Access to Items for which the Entity is not Cleared' anchor='impl-access'>
|
||||
<p>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 <link url="#rules-1">BR1</link>), i.e. an
|
||||
&ITEMNOTFOUND; error is returned</p>
|
||||
<example caption="Request for a node that the entity is not Cleared to view"><![CDATA[
|
||||
<iq from='pubsub.shakespeare.lit'
|
||||
id='sub1'
|
||||
to='francisco@denmark.lit/barracks'
|
||||
id='sub1'>
|
||||
type='error'>
|
||||
<error type='cancel'>
|
||||
<item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
|
||||
</error>
|
||||
</iq>
|
||||
]]></example>
|
||||
</li>
|
||||
</ol>
|
||||
</section1>
|
||||
<section1 topic='Implementation Notes' anchor='impl'>
|
||||
<p>OPTIONAL.</p>
|
||||
</section1>
|
||||
<section1 topic='Accessibility Considerations' anchor='access'>
|
||||
<p>OPTIONAL.</p>
|
||||
</section1>
|
||||
<section1 topic='Internationalization Considerations' anchor='i18n'>
|
||||
<p>OPTIONAL.</p>
|
||||
]]></example>
|
||||
<p>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.</p>
|
||||
<p>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 &INSUFFICIENTCLEARANCE;
|
||||
error MAY be returned instead.</p>
|
||||
</section2>
|
||||
<section2 topic='Collection Nodes' anchor='impl-collections'>
|
||||
<p>If a service implements &xep0248; then there will need to be some consideration of node
|
||||
and item visibility within the node hierarchy.</p>
|
||||
<p>Due to the complexity of the access control policies involved, an implementation MAY choose
|
||||
to do one or more of the following to simplify the implementation:</p>
|
||||
<ul>
|
||||
<li>Prevent the use of Security Labels and/or Clearances on collection nodes.</li>
|
||||
<li>Prevent publishing items with Security Labels to non-orphan leaf nodes (i.e. leaf nodes
|
||||
with an association to a collection node).</li>
|
||||
<li>Prevent the association of leaf nodes containing Security Labelled items with collection
|
||||
nodes.</li>
|
||||
<li>Prevent the association of Security Labelled nodes with collection nodes.</li>
|
||||
</ul>
|
||||
<p>The rules and protocols defined elsewhere in this document are generally applicable to
|
||||
collection nodes with the following additions:</p>
|
||||
<section3 topic='Notifications' anchor='impl-collections-notifications'>
|
||||
<p>A collection node MUST NOT forward a publish notification with a Security Label that is
|
||||
incompatible with the Clearance of the collection node.</p>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
</section3>
|
||||
<section3 topic='Retrieving Items on Collection Nodes' anchor='impl-collections-retrieveitems'>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
</section3>
|
||||
<section3 topic='Associating a Node to a Collection' anchor='impl-collections-associating'>
|
||||
<p>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.</p>
|
||||
</section3>
|
||||
</section2>
|
||||
<section2 topic='Implementation Specific Structuring within Items' anchor='impl-itemstructure'>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<p>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).</p>
|
||||
</section2>
|
||||
<section2 topic='Limiting Notifications to a Certain Clearance' anchor='impl-limitclearance'>
|
||||
<p>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.</p>
|
||||
<p>One way this could be implemented is by expanding the Data Form for the subscription options.
|
||||
</p>
|
||||
<example caption="Form with ability to limit subscription clearance"><![CDATA[
|
||||
<iq from='pubsub.shakespeare.lit'
|
||||
id='options1'
|
||||
to='francisco@denmark.lit/barracks'
|
||||
type='result'>
|
||||
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
|
||||
<options node='princely_musings' jid='francisco@denmark.lit'>
|
||||
<x xmlns='jabber:x:data' type='form'>
|
||||
...
|
||||
<field label='Limit Clearance' type='list-multi' var='sec-label#clearance'>
|
||||
<value>Catalog:UNCLASSIFIED</value>
|
||||
<option label='SECRET'><value>Catalog:SECRET</value></option>
|
||||
<option label='CONFIDENTIAL'><value>Catalog:CONFIDENTIAL</value></option>
|
||||
<option label='UNCLASSIFIED'><value>Catalog:UNCLASSIFIED</value></option>
|
||||
<option label='Custom'><value>Custom</value></option>
|
||||
</field>
|
||||
...
|
||||
</x>
|
||||
</options>
|
||||
</pubsub>
|
||||
</iq>
|
||||
]]></example>
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic='Security Considerations' anchor='security'>
|
||||
<p>REQUIRED.</p>
|
||||
<p>This document is an extension to &xep0258; and therefore any security considerations noted in
|
||||
that document will also apply to this document.</p>
|
||||
</section1>
|
||||
<section1 topic='IANA Considerations' anchor='iana'>
|
||||
<p>REQUIRED.</p>
|
||||
<p>This document requires no interaction with the &IANA;</p>
|
||||
</section1>
|
||||
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
||||
<p>REQUIRED.</p>
|
||||
<section2 topic='Protocol Namespaces' anchor='registrar-namespaces'>
|
||||
<p>This specification defines the following XML namespaces:</p>
|
||||
<ul>
|
||||
<li>&NSMAIN;</li>
|
||||
<li>&NSERRORS;</li>
|
||||
</ul>
|
||||
</section2>
|
||||
<section2 topic='Protocol Versioning' anchor='registrar-versioning'>
|
||||
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.
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic='XML Schema' anchor='schema'>
|
||||
<p>REQUIRED for protocol specifications.</p>
|
||||
<section2 topic='&NSMAIN;' anchor='schemas-main'>
|
||||
<code><![CDATA[
|
||||
<?xml version="1.0" encoding="utf-8" ?>
|
||||
|
||||
<xs:schema
|
||||
elementFormDefault='qualified'
|
||||
targetNamespace='urn:xmpp:sec-label:pubsub:0'
|
||||
xmlns='urn:xmpp:sec-label:pubsub:0'
|
||||
xmlns:xs='http://www.w3.org/2001/XMLSchema'>
|
||||
|
||||
<xs:annotation>
|
||||
<xs:documentation>
|
||||
The protocol documented by this schema is defined in
|
||||
XEP-xxxx: http://www.xmpp.org/extensions/xep-xxxx.html
|
||||
</xs:documentation>
|
||||
</xs:annotation>
|
||||
|
||||
<xs:attribute name='label' type='xs:IDREF'>
|
||||
<xs:annotation>
|
||||
<xs:documentation>
|
||||
References an "id" value in a <securitylabel> element. The referenced
|
||||
Security Label MUST then be applied to the element content.
|
||||
</xs:documentation>
|
||||
</xs:annotation>
|
||||
</xs:attribute>
|
||||
|
||||
<xs:attribute name='id' type='xs:ID'>
|
||||
<xs:annotation>
|
||||
<xs:documentation>
|
||||
Defines a unique (across the document) id for a <securitylabel> element that can be
|
||||
referenced from a "label" attribute.
|
||||
</xs:documentation>
|
||||
</xs:annotation>
|
||||
</xs:attribute>
|
||||
|
||||
</xs:schema>
|
||||
]]></code>
|
||||
</section2>
|
||||
<section2 topic='&NSERRORS;' anchor='schemas-error'>
|
||||
<code><![CDATA[
|
||||
<?xml version='1.0' encoding='UTF-8'?>
|
||||
<xs:schema
|
||||
elementFormDefault='qualified'
|
||||
targetNamespace='urn:xmpp:sec-label:pubsub:errors:0'
|
||||
xmlns='urn:xmpp:sec-label:pubsub:errors:0'
|
||||
xmlns:xs='http://www.w3.org/2001/XMLSchema'>
|
||||
|
||||
<xs:annotation>
|
||||
<xs:documentation>
|
||||
This namespace is used for error reporting only, as
|
||||
defined in XEP-xxxx:
|
||||
|
||||
http://xmpp.org/extensions/xep-xxxx.html
|
||||
</xs:documentation>
|
||||
</xs:annotation>
|
||||
|
||||
<xs:element name='insufficient-clearance' type='empty'/>
|
||||
|
||||
</xs:schema>
|
||||
]]></code>
|
||||
</section2>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Acknowledgements' anchor='ack'>
|
||||
<p>Thanks to Dave Cridland, John Atherton, Kurt Zeilenga, Lloyd Watkin, Ralph Meijer and Stephen
|
||||
Welch for their contributions.</p>
|
||||
</section1>
|
||||
</xep>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user