moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-22 01:02:17 -05:00
Code Issues Releases Wiki Activity

v0.9 editorial changes and add optional jid to catalog request.

Browse Source
This commit is contained in:
Kurt Zeilenga 2011-08-15 10:01:32 -07:00
parent a94e459234
commit fa5086e125
1 changed files with 45 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

64
xep-0258.xml
View File

@ -15,8 +15,8 @@
<header>
<title>Security Labels in XMPP</title>
<abstract>This document describes the use of security labels in XMPP. The document
specifies how security label metadata is carried in XMPP, when this metadata
should or should not be provided, and how the metadata is to be processed.</abstract>
specifies how security label meta-data is carried in XMPP, when this meta-data
should or should not be provided, and how the meta-data is to be processed.</abstract>
&LEGALNOTICE;
<number>0258</number>
<status>Experimental</status>
@ -36,6 +36,12 @@
<email>Kurt.Zeilenga@Isode.COM</email>
<jid>Kurt.Zeilenga@Isode.COM</jid>
</author>
<revision>
<version>0.9</version>
<date>2011-09-15</date>
<initials>kdz</initials>
<remark><p>Add optional from attribute to catalog element for S2S requests. Make editorial changes.</p></remark>
</revision>
<revision>
<version>0.8</version>
<date>2011-08-11</date>
@ -46,7 +52,7 @@
<version>0.7</version>
<date>2011-03-08</date>
<initials>kdz</initials>
<remark><p>Illustrate XEP 45 security label room configuration. Make clarifications and minor editorial changes.</p></remark>
<remark><p>Illustrate XEP Multi-User Chat room security label configuration. Make clarifications and minor editorial changes.</p></remark>
</revision>
<revision>
<version>0.6</version>
@ -106,7 +112,7 @@
standardized formats for security labels, clearances, and security policy are
generalized and do have application in non-government networks.</p>
<p>This document describes the use of security labels in &xmpp;. The document specifies
how security label metadata is carried in XMPP. It standardizes a mechanism for
how security label meta-data is carried in XMPP. It standardizes a mechanism for
carrying ESS Security Labels in XMPP, as well as provides for use of other label
formats. ESS Security Labels are specified in &rfc2634;. ESS Security Labels are
commonly used in conjunction with &X.500; clearances and either X.841 or &SDN.801c;
@ -134,8 +140,8 @@
]]></example>
<p>Note: The &IC-ISM; label example is for <em>illustrative purposes only</em>.</p>
<p>The document details when security label metadata should or should not be provided, and how
this metadata is to be processed.</p>
<p>The document details when security label meta-data should or should not be provided, and how
this meta-data is to be processed.</p>
<p>This document does not provide:
<ul>
@ -188,7 +194,7 @@
</section1>
<section1 topic='Protocol' anchor='protocol'>
<p>An element, &SECURITYLABEL;, is defined to carry security label metadata. This metadata
<p>An element, &SECURITYLABEL;, is defined to carry security label meta-data. This meta-data
includes a security label, zero or more equivalent security labels, and optionally display
marking data.</p>
<example caption="Labeled Message"><![CDATA[
@ -239,7 +245,7 @@
fulfill the client's request.</p>
<p>While this specification does not preclude a client from directing
a catalog request elsewhere, it is noted that catalog returned by
a party other than its server may not be directly useable by the
a party other than its server may not be directly usable by the
client. For instance, the client's server might require a particular
only-locally-known label be used in messages to a particular remote
JID.</p>
@ -255,11 +261,11 @@
sending a stanza without a label.</p>
<p>Each catalog provided should only contain labels for which the client
is allowed to use (based upon the user's authorization) in a particular
context (such as in chatroom). A catalog may not be include the
context (such as in chat room). A catalog may not be include the
complete set of labels available for the use by the client in the
context.</p>
<blockquote>Note: the single catalog per context approach used here
is likely inadequate in enviroments where there are a large number
is likely inadequate in environments where there are a large number
of labels in use. It is expected that a more sophisticated approach
will be introduced in a subsequent revision of this
specification.</blockquote>
@ -308,7 +314,11 @@ selector-value = (<item>"|")*<item>
</iq>
]]></example>
<p>The following example pair illustrates catalog discovery. Note that client directs the &IQ; to its server regardless of which catalog it requests (via the to= attribute of in &CATALOG; element).</p>
<p>The following example pair illustrates catalog discovery. The
client directs the &IQ; to its server regardless of which catalog
it requests via the to= attribute of in &CATALOG; element. The
client SHOULD NOT provide a from= attribute in the &CATALOG; element.</p>
<example caption="Label Catalog request"><![CDATA[
<iq to='example.com' type='get' id='cat1'>
@ -354,6 +364,15 @@ selector-value = (<item>"|")*<item>
</iq>
]]></example>
<p>
Where the server needs to obtain a catalog from another server in order
to respond to its client, it can send an &IQ; to that server requesting
that catalog. The requesting server provides the bare JID of the
requesting user in the from= attribute in the &CATALOG; element when
it desires a catalog to be prepared specifically for the user.
Otherwise the from= attribute in the &CATALOG; element is absent.
</p>
</section1>
<section1 topic='Use in XMPP' anchor='xmpp-use'>
@ -389,7 +408,7 @@ selector-value = (<item>"|")*<item>
absent.</p>
<p>A client which receives a stanza with &SECURITYLABEL; element is to promiently
display the &DISPLAYMARKING; value. A policy-aware may alternatively
promiently display the marking for the &LABEL; prescribed by the governing
prominently display the marking for the &LABEL; prescribed by the governing
policy.</p>
<p>Each server is expected to make a number of sensitivity-based authorization
decisions. Each decision is made by evaluating an Access Control Decision
@ -415,7 +434,7 @@ selector-value = (<item>"|")*<item>
the ACDF with the user's clearance and a label associated with the service.
A clearance might also be associated with the service to restrict the set
of labels may be used in labeling stanzas. Labels and clearances can also
be associated with network interfaces, remote servers, chatrooms, pubsub
be associated with network interfaces, remote servers, chat rooms, pubsub
nodes.</p>
<section2 topic='Use in Instant Messaging' anchor='im-use'>
<p>A client may provide a &SECURITYLABEL; element in any &MESSAGE; it sends.</p>
@ -435,13 +454,13 @@ selector-value = (<item>"|")*<item>
<p>Clients SHOULD discover label feature and information on a per room basis.</p>
</section3>
<section3 topic='Sending Messages' anchor='muc-send'>
<p>Sending groupchat messages is similiar to sending normal messages, however
<p>Sending groupchat messages is similar to sending normal messages, however
their are a few differences.</p>
<p>Groupchat messages are addressed to the room. The room clearance must
be suitable for the message label, else it should be rejected.</p>
<p>The room's clearance may allow a variety of labels to be used. Not all
partipants may be cleared for all labels allowed in the room. The server
MUST only deliver messages to partipants for which they are cleared to
participants may be cleared for all labels allowed in the room. The server
MUST only deliver messages to participants for which they are cleared to
receive.</p>
</section3>
<section3 topic='Private Messages' anchor='muc-private'>
@ -540,7 +559,7 @@ selector-value = (<item>"|")*<item>
protocol violation.</p>
<p>Presence information is subject to sensitivity-base authorization decisions,
however these decisions are made are made using a label associated with the
presence resource, such as a chatroom's label.</p>
presence resource, such as a chat room's label.</p>
</section2>
<section2 topic='Use in PubSub' anchor='pubsub-use'>
<section3 topic='Discovery' anchor='pubsub-disco'>
@ -622,7 +641,7 @@ And by opposing end them?
<section1 topic='Extension Considerations' anchor='exts'>
<p>
This extension is itself is extensible. In particular, the &LABEL; and &EQUIVALENTLABEL;
elements are designed to hold a range of security labels formats. XML namespaces SHOULD
elements are designed to hold a range of security labels formats. XML name spaces SHOULD
be used to avoid name clashes.
</p>
</section1>
@ -636,7 +655,7 @@ And by opposing end them?
<p>This document is all about authorization, a key aspect of security. Hence,
security considerations are discussed through this document.</p>
<p>Certain XMPP stanzas, such as &PRESENCE; stanzas, are not themselves subject
to any sensitity-based authorization decisions, and may be forwarded throughout
to any sensitivity-based authorization decisions, and may be forwarded throughout
the XMPP network. The content of these stanzas should not contain information
requiring sensitivity-based dissemination controls.</p>
<p>It is desirable to securely bind the security label to the object it labels.
@ -779,6 +798,12 @@ And by opposing end them?
</xs:annotation>
</xs:attribute>
<xs:attribute name="from" type="xs:string">
<xs:annotation>
<xs:documentation>Target JabberId</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="name" type="xs:string">
<xs:annotation>
<xs:documentation>Name</xs:documentation>
@ -839,6 +864,7 @@ And by opposing end them?
</xs:element>
</xs:sequence>
<xs:attribute ref="to" use="optional"/>
<xs:attribute ref="from" use="optional"/>
<xs:attribute ref="name" use="optional"/>
<xs:attribute ref="desc" use="optional"/>
<xs:attribute ref="id" use="optional"/>