draft-ietf-xcon-conference-policy-privileges-00.txt   draft-ietf-xcon-conference-policy-privileges-01.txt 
XCON H. Khartabil XCON H. Khartabil
Internet-Draft A. Niemi Internet-Draft A. Niemi
Expires: March 10, 2005 Nokia Expires: April 12, 2005 Nokia
September 9, 2004 October 12, 2004
Privileges for Manipulating a Conference Policy Privileges for Manipulating a Conference Policy
draft-ietf-xcon-conference-policy-privileges-00 draft-ietf-xcon-conference-policy-privileges-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable This document is an Internet-Draft and is subject to all provisions
patent or other IPR claims of which I am aware have been disclosed, of section 3 of RFC 3667. By submitting this Internet-Draft, each
and any of which I become aware will be disclosed, in accordance with author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 10, 2005. This Internet-Draft will expire on April 12, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004).
Abstract Abstract
The Conference Policy is defined as the complete set of rules for a The Conference Policy is defined as the complete set of rules for a
particular conference manipulated by the conference policy server. particular conference manipulated by the conference policy server.
The Conferece Policy Control Protocol (CPCP) is the protocol used by The Conferece Policy Control Protocol (CPCP) is the protocol used by
client to manipulate the conference policy. This document specifies client to manipulate the conference policy. This document specifies
an Extensible Markup Language (XML) Schema that enumerates the an Extensible Markup Language (XML) Schema that enumerates the
conference policy meta data that enable a user to assign privileges conference policy meta data that enable a user to assign privileges
to users that enables them to read and/or manipulate parts of or the to users that enables them to read and/or manipulate parts of or the
entire conference policy. entire conference policy.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Structure of a Conference Policy Privileges XML Document . . . 3 4. Structure of a Conference Policy Privileges XML Document . . . 4
4.1 MIME Type for CPCP XML Document . . . . . . . . . . . . . 3 4.1 MIME Type for CPCP XML Document . . . . . . . . . . . . . 4
4.2 Privileges Root . . . . . . . . . . . . . . . . . . . . . 4 4.2 Privileges Root . . . . . . . . . . . . . . . . . . . . . 5
4.3 XML Document Description . . . . . . . . . . . . . . . . . 4 4.3 XML Document Description . . . . . . . . . . . . . . . . . 5
4.3.1 Conference Policy Privileges . . . . . . . . . . . . . 4 4.3.1 Conference Policy Privileges . . . . . . . . . . . . . 5
4.4 XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3.1.1 Conditions . . . . . . . . . . . . . . . . . . . . 6
4.3.1.1.1 Validity . . . . . . . . . . . . . . . . . . . 6
4.3.1.1.2 Identity . . . . . . . . . . . . . . . . . . . 7
4.3.1.1.2.1 Interpreting the <id> Element . . . . . . 8
4.3.1.1.3 Conference Policy Identity . . . . . . . . . . 8
4.3.1.1.3.1 Matching Any Identity . . . . . . . . . . 8
4.3.1.1.3.2 Matching Identities in External Lists . . 8
4.3.1.1.4 Sphere . . . . . . . . . . . . . . . . . . . . 8
4.3.1.2 Actions . . . . . . . . . . . . . . . . . . . . . 8
4.3.1.2.1 Modifying Conference setting . . . . . . . . . 8
4.3.1.2.2 Modifying Conference Information . . . . . . . 9
4.3.1.2.3 Modifying Conference Time . . . . . . . . . . 9
4.3.1.2.4 Modifying Authorization rules . . . . . . . . 9
4.3.1.2.5 Modifying Conference Dial-out List . . . . . . 9
4.3.1.2.6 Modifying Conference Refer List . . . . . . . 9
4.3.1.2.7 Modifying Conference media streams . . . . . . 10
4.3.1.2.8 Creating Sidebars . . . . . . . . . . . . . . 10
4.3.1.2.9 Modifying Conference Dial-in List . . . . . . 10
4.3.1.2.10 Reading Conference setting . . . . . . . . . . 10
4.3.1.2.11 Reading Conference Information . . . . . . . . 11
4.3.1.2.12 Reading Conference Time . . . . . . . . . . . 11
4.3.1.2.13 Reading Authorization rules . . . . . . . . . 11
4.3.1.2.14 Reading Conference Dial-out List . . . . . . . 11
4.3.1.2.15 REading Conference Refer List . . . . . . . . 11
4.3.1.2.16 Reading Conference media streams
Information . . . . . . . . . . . . . . . . . 12
4.3.1.2.17 Reading Sidebar Information . . . . . . . . . 12
4.3.1.2.18 Reading Conference Dial-in List . . . . . . . 12
4.3.1.3 Transformations . . . . . . . . . . . . . . . . . 12
4.4 XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1 A Simple Conference Policy Privileges Document . . . . . . 13 5.1 A Simple Conference Policy Privileges Document . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7.1 application/privileges+xml MIME TYPE . . . . . . . . . . . 15 7.1 application/privileges+xml MIME TYPE . . . . . . . . . . . 15
7.2 URN Sub-Namespace Registration for 7.2 URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:privileges . . . . . . . . . . . . 16 urn:ietf:params:xml:ns:privileges . . . . . . . . . . . . 16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
9. Normative References . . . . . . . . . . . . . . . . . . . . . 17 9. Normative References . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . 19
1. Introduction 1. Introduction
The Conference Policy Control Protocol (CPCP) [1]specifies an The Conference Policy Control Protocol (CPCP) [1]specifies an
Extensible Markup Language (XML) Schema that enumerates the Extensible Markup Language (XML) Schema that enumerates the
conference policy data elements that enable a user to define a conference policy data elements that enable a user to define a
conference policy. It, however, does not define user privileges (who conference policy. It, however, does not define user privileges (who
is allowed to read or modify certain parts or all of a conference is allowed to read or modify certain parts or all of a conference
policy). policy).
skipping to change at page 3, line 37 skipping to change at page 4, line 37
3. Terminology 3. Terminology
This document uses terminology from [13]. Some additional This document uses terminology from [13]. Some additional
definitions are introduced in [1], including the defintion of a definitions are introduced in [1], including the defintion of a
privileged user. privileged user.
4. Structure of a Conference Policy Privileges XML Document 4. Structure of a Conference Policy Privileges XML Document
The conference policy privileges document is an XML [4] document that The conference policy privileges document is an XML [4] document that
MUST be well-formed and MUST be valid. The Conference policy MUST be well-formed and MUST be valid according to schemas, including
privelges documents MUST be based on XML 1.0 and MUST be encoded extension schemas, available to the validater and applicable to the
using UTF-8. This specification makes use of XML namespaces for XML document. The Conference policy privelges documents MUST be
identifying conference policy privileges documents and document based on XML 1.0 and MUST be encoded using UTF-8. This specification
fragments. The namespace URI for elements defined by this makes use of XML namespaces for identifying conference policy
specification is a URN [6], using the namespace identifier 'ietf' privileges documents and document fragments. The namespace URI for
defined by [7] and extended by [8]. This URN is: elements defined by this specification is a URN [6], using the
namespace identifier 'ietf' defined by [7] and extended by [8]. This
URN is:
urn:ietf:params:xml:ns:privileges urn:ietf:params:xml:ns:privileges
4.1 MIME Type for CPCP XML Document 4.1 MIME Type for CPCP XML Document
The MIME type for the CPCP XML document is "application/ The MIME type for the CPCP XML document is
privileges+xml". "application/privileges+xml".
4.2 Privileges Root 4.2 Privileges Root
A conference policy privileges document begins with the root element A conference policy privileges document begins with the root element
tag <privileges>. Other elements from different namespaces MAY be tag <privileges>. Other elements from different namespaces MAY be
present for the purposes of extensibility. Elements or attributes present for the purposes of extensibility. Elements or attributes
from unknown namespaces MUST be ignored. from unknown namespaces MUST be ignored.
A user may create a new conference policy privieleges at the CPS by A user may create a new conference policy privieleges at the CPS by
placing a new conference policy document at the CPS. Depending on placing a new conference policy document at the CPS. Depending on
skipping to change at page 4, line 39 skipping to change at page 5, line 40
4.3 XML Document Description 4.3 XML Document Description
4.3.1 Conference Policy Privileges 4.3.1 Conference Policy Privileges
One of the key components of the conference policy privileges One of the key components of the conference policy privileges
document is the set of authorization rules that specify who is document is the set of authorization rules that specify who is
allowed to read and manipulate a conference policy. The unordered allowed to read and manipulate a conference policy. The unordered
list of authorization rules together define the conference policy list of authorization rules together define the conference policy
privileges in the form of an authorization policy. privileges in the form of an authorization policy.
The <xml-document-rules> element appears after the root element and The <uri> element appears after the root element and contains the URI
contains the mandatory "uri" attribute. This attributes carries the of the conference policy document that the privileges defines within
URI of the conference policy document that the privileges defines it apply to. This is followed by the <ruleset> element which carry
within it apply to. the rules defining the actual privileges.
The conference policy privileges are enclosed in the The conference policy privileges are enclosed in the <ruleset>
<xml-document-rules> element are formatted according to the XML element are formatted according to the XML schema defined in the
schema defined in the common policy framework [2]. In the common policy framework [2]. In the <ruleset> element, there can be
<xml-document-rules> element, there can be multiple rules, each rule multiple rules, each rule is represented by the <rule> element, each
is represented by the <rule> element, each of which consist of three of which consist of three parts: conditions, actions and
parts: conditions, actions and transformations. Conditions determine transformations. Conditions determine whether a particular rule
whether a particular rule applies to a request. Each action or applies to a request. Each action or transformation in the applied
transformation in the applied rule is a positive grant of permission rule is a positive grant of permission to the conference policy user.
to the conference policy user. The details of each specific element The details of each specific element and attribute is described in
and attribute is described in [2]. [2].
Asking the conference policy server to allow certain users to Asking the conference policy server to allow certain users to
manipulate the conference policy is achieved by modifying an existing manipulate the conference policy is achieved by modifying an existing
authorization rule or creating a new one. authorization rule or creating a new one.
If the conference is long-lasting, it is possible that new rules are If the conference is long-lasting, it is possible that new rules are
added all the time but old rules are almost never removed (some of added all the time but old rules are almost never removed (some of
them are overwritten, though). This leads easily to the situation them are overwritten, though). This leads easily to the situation
that the conference policy meta data contains many unnecessary rules that the conference policy meta data contains many unnecessary rules
which are not really needed anymore. Therefore, there is a need to which are not really needed anymore. Therefore, there is a need to
skipping to change at page 5, line 44 skipping to change at page 6, line 46
conference policy server to remove some rules which grant conference policy server to remove some rules which grant
permissions. Hence this mechanisms allows to remove or invalidate permissions. Hence this mechanisms allows to remove or invalidate
granted permissions automatically without further interaction between granted permissions automatically without further interaction between
the rule maker and the conference policy server. the rule maker and the conference policy server.
To give a real life example, there are often meetings where users can To give a real life example, there are often meetings where users can
have access to modify the dial-out list from 10 minutes before the have access to modify the dial-out list from 10 minutes before the
conference starts until 10 mintues after the conference starts. One conference starts until 10 mintues after the conference starts. One
rules can be set in this scenario. The following example demostrates rules can be set in this scenario. The following example demostrates
this. The meeting starts at 9:30 and ends at 12:30. A manager with this. The meeting starts at 9:30 and ends at 12:30. A manager with
identity "manager@example.com can read and modify the dial-out list identity "manager@example.com" can read and modify the dial-out list
betweem 8:50 and 9:40. After that time until the conference ends, betweem 8:50 and 9:40. After that time until the conference ends,
the manager can only read the dial-out-list the manager can only read the dial-out-list
<rule id="1"> <rule id="1">
<conditions> <conditions>
<validity> <validity>
<from>2004-12-17T08:50:00-05:00</from> <from>2004-12-17T08:50:00-05:00</from>
<to>2004-12-17T09:40:00-05:00</to> <to>2004-12-17T09:40:00-05:00</to>
</validity> </validity>
<identity> <identity>
<id>manager@example.com</id> <id>manager@example.com</id>
skipping to change at page 6, line 46 skipping to change at page 7, line 46
2004-12-17T12:30:00-05:00</mixing-stop-time> 2004-12-17T12:30:00-05:00</mixing-stop-time>
</occurrence> </occurrence>
</time> </time>
4.3.1.1.2 Identity 4.3.1.1.2 Identity
The <identity> element is already defined in the common policy The <identity> element is already defined in the common policy
framework [2]The presence of the <identity> element is a condition framework [2]The presence of the <identity> element is a condition
requires any identity within it to be authenticated before a rule is requires any identity within it to be authenticated before a rule is
applied to it. This includes the <id> element (Section 4.3.1.1.2.1), applied to it. This includes the <id> element (Section 4.3.1.1.2.1),
the <any> element (Section 4.3.1.1.2.2), the <external-list> element the <any> element (Section 4.3.1.1.3.1), the <external-list> element
(Section 4.3.1.1.2.3), their exceptions, and any future extension (Section 4.3.1.1.3.2), their exceptions, and any future extension
that carries an identity. The absence of the <identity> element with that carries an identity. The absence of the <identity> element with
in a condition indicated that the rule applies to all unauthenticated in a condition indicated that the rule applies to all unauthenticated
identities. That is participants that have provided no authenticated identities. That is participants that have provided no authenticated
identity to the conference focus. identity to the conference focus.
4.3.1.1.2.1 Interpreting the <id> Element 4.3.1.1.2.1 Interpreting the <id> Element
As earlier indicated, the <identity> element is already defined in As earlier indicated, the <identity> element is already defined in
the common policy framework [2]. However, the rules for interpreting the common policy framework [2]. However, the rules for interpreting
the identities in <id> elements are left for each application to the identities in <id> elements are left for each application to
define separately. This document, however, does not define the rules define separately. This document, however, does not define the rules
for interpreting identities in <id> elements in conferencing for interpreting identities in <id> elements in conferencing
applications since those interpretation rules are signalling protocol applications since those interpretation rules are signalling protocol
specific. specific.
OPEN ISSUE: Do we need to state more than this? How are identities OPEN ISSUE: Do we need to state more than this? How are identities
derived from users that join using POTS, H.323, etc.? derived from users that join using POTS, H.323, etc.?
4.3.1.1.2.2 Matching Any Identity 4.3.1.1.3 Conference Policy Identity
4.3.1.1.3.1 Matching Any Identity
The <any> element is used to match any participant. This allows a The <any> element is used to match any participant. This allows a
conference priveleges to be open to any authenticated user. Just as conference priveleges to be open to any authenticated user. Just as
for the <domain> element in <identity> element, The <any> element for the <domain> element in <identity> element, The <any> element
contains a list of <except> elements and allows to implement a simple contains a list of <except> elements and allows to implement a simple
blacklist mechanism. The <except> element contains the identity. It blacklist mechanism. The <except> element contains the identity. It
differs from the <domain> element in that the domain part is needed differs from the <domain> element in that the domain part is needed
in the identity since it has not domain to refer to. in the identity since it has not domain to refer to.
4.3.1.1.2.3 Matching Identities in External Lists 4.3.1.1.3.2 Matching Identities in External Lists
The <external-list> element can be used to match those participants The <external-list> element can be used to match those participants
that are part of a resource list that is created externally. The use that are part of a resource list that is created externally. The use
of <external-list> is similar to that defined in Section x of [1]. of <external-list> is similar to that defined in Section x of [1].
4.3.1.1.4 Sphere
The <sphere> element has no meaning in the context of conference
policy and MUST be ignored if present.
4.3.1.2 Actions 4.3.1.2 Actions
4.3.1.2.1 Modifying Conference setting 4.3.1.2.1 Modifying Conference setting
The <allow-modify-settings> element represents a boolean action. If The <allow-modify-settings> element represents a boolean action. If
set to TRUE, the identity is allowed to modify the conference set to TRUE, the identity is allowed to modify the conference
settings in the conference policy. If set to FALSE, any settings in the conference policy. If set to FALSE, any
modifications to the conference settings are rejected. modifications to the conference settings are rejected.
If this element is undefined it has a value of FALSE, causing the If this element is undefined it has a value of FALSE, causing the
skipping to change at page 11, line 43 skipping to change at page 12, line 44
If this element is undefined it has a value of FALSE, causing the If this element is undefined it has a value of FALSE, causing the
read requests to be rejected. read requests to be rejected.
4.3.1.3 Transformations 4.3.1.3 Transformations
No transformations are defined at this time. No transformations are defined at this time.
4.4 XML Schema 4.4 XML Schema
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:privileges" xmlns="urn:ietf:params:xml:ns:privileges" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <xs:schema targetNamespace="urn:ietf:params:xml:ns:privileges" xmlns="urn:ietf:params:xml:ns:privileges" xmlns:cr="urn:ietf:params:xml:ns:common-policy" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<!-- This import brings in the XML language attribute xml:lang--> <!-- This import brings in the XML language attribute xml:lang-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"/> <xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<!-- This import brings in the common-policy-->
<xs:import namespace="urn:ietf:params:xml:ns:common-policy"/>
<xs:element name="privileges"> <xs:element name="privileges">
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element name="xml-document-rules" type="XMLDocument"/> <xs:element name="uri" type="xs:string"/>
</xs:sequence> <xs:element ref="cr:ruleset"/>
</xs:complexType>
</xs:element>
<xs:complexType name="XMLDocument">
<xs:sequence>
<xs:element name="rule" type="ruleType" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="uri" type="xs:string" use="required"/>
</xs:complexType>
<xs:complexType name="ruleType">
<xs:sequence>
<xs:element name="conditions" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element ref="condition" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="actions" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element ref="action" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="transformations" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element ref="transformation" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
</xs:sequence> <xs:element name="cp-identity" substitutionGroup="cr:condition">
<xs:attribute name="id" type="xs:string" use="required"/>
</xs:complexType>
<xs:element name="condition" abstract="true"/>
<xs:element name="action" abstract="true"/>
<xs:element name="transformation" abstract="true"/>
<xs:element name="validity" substitutionGroup="condition">
<xs:complexType>
<xs:all>
<xs:element name="from" type="xs:dateTime"/>
<xs:element name="to" type="xs:dateTime"/>
</xs:all>
</xs:complexType>
</xs:element>
<xs:element name="identity" substitutionGroup="condition">
<xs:complexType> <xs:complexType>
<xs:choice> <xs:choice>
<xs:element name="id" type="xs:string" maxOccurs="unbounded"/>
<xs:sequence> <xs:sequence>
<xs:element name="domain" type="xs:string"/> <xs:element name="any"/>
<xs:sequence minOccurs="0">
<xs:element name="except" type="xs:string" maxOccurs="unbounded"/>
</xs:sequence>
</xs:sequence>
<xs:sequence>
<xs:element name="any" type="xs:string"/>
<xs:sequence minOccurs="0"> <xs:sequence minOccurs="0">
<xs:element name="except" type="xs:string" maxOccurs="unbounded"/> <xs:element name="except" type="xs:string"
maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:sequence> </xs:sequence>
<xs:sequence> <xs:sequence>
<xs:element name="external-list" type="xs:string"/> <xs:element name="external-list" type="xs:string"/>
<xs:sequence minOccurs="0"> <xs:sequence minOccurs="0">
<xs:element name="except" type="xs:string" maxOccurs="unbounded"/> <xs:element name="except" type="xs:string"
maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:sequence> </xs:sequence>
</xs:choice> </xs:choice>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name="allow-modify-settings" type="xs:boolean" substitutionGroup="action"/> <xs:element name="allow-modify-settings" type="xs:boolean" substitutionGroup="cr:action"/>
<xs:element name="allow-modify-information" type="xs:boolean" substitutionGroup="action"/> <xs:element name="allow-modify-information" type="xs:boolean" substitutionGroup="cr:action"/>
<xs:element name="allow-modify-time" type="xs:boolean" substitutionGroup="action"/> <xs:element name="allow-modify-time" type="xs:boolean" substitutionGroup="cr:action"/>
<xs:element name="allow-modify-authorization-rules" type="xs:boolean" substitutionGroup="action"/> <xs:element name="allow-modify-authorization-rules" type="xs:boolean" substitutionGroup="cr:action"/>
<xs:element name="allow-modify-dol" type="xs:boolean" substitutionGroup="action"/> <xs:element name="allow-modify-dol" type="xs:boolean" substitutionGroup="cr:action"/>
<xs:element name="allow-modify-rl" type="xs:boolean" substitutionGroup="action"/> <xs:element name="allow-modify-rl" type="xs:boolean" substitutionGroup="cr:action"/>
<xs:element name="allow-modify-ms" type="xs:boolean" substitutionGroup="action"/> <xs:element name="allow-modify-ms" type="xs:boolean" substitutionGroup="cr:action"/>
<xs:element name="allow-modify-sidebar" type="xs:boolean" substitutionGroup="action"/> <xs:element name="allow-modify-sidebar" type="xs:boolean" substitutionGroup="cr:action"/>
<xs:element name="allow-modify-dil" type="xs:boolean" substitutionGroup="action"/> <xs:element name="allow-modify-dil" type="xs:boolean" substitutionGroup="cr:action"/>
<xs:element name="allow-read-settings" type="xs:boolean" substitutionGroup="action"/> <xs:element name="allow-read-settings" type="xs:boolean" substitutionGroup="cr:action"/>
<xs:element name="allow-read-information" type="xs:boolean" substitutionGroup="action"/> <xs:element name="allow-read-information" type="xs:boolean" substitutionGroup="cr:action"/>
<xs:element name="allow-read-time" type="xs:boolean" substitutionGroup="action"/> <xs:element name="allow-read-time" type="xs:boolean" substitutionGroup="cr:action"/>
<xs:element name="allow-read-authorization-rules" type="xs:boolean" substitutionGroup="action"/> <xs:element name="allow-read-authorization-rules" type="xs:boolean" substitutionGroup="cr:action"/>
<xs:element name="allow-read-dol" type="xs:boolean" substitutionGroup="action"/> <xs:element name="allow-read-dol" type="xs:boolean" substitutionGroup="cr:action"/>
<xs:element name="allow-read-rl" type="xs:boolean" substitutionGroup="action"/> <xs:element name="allow-read-rl" type="xs:boolean" substitutionGroup="cr:action"/>
<xs:element name="allow-read-ms" type="xs:boolean" substitutionGroup="action"/> <xs:element name="allow-read-ms" type="xs:boolean" substitutionGroup="cr:action"/>
<xs:element name="allow-read-sidebar" type="xs:boolean" substitutionGroup="action"/> <xs:element name="allow-read-sidebar" type="xs:boolean" substitutionGroup="cr:action"/>
</xs:schema> </xs:schema>
5. Examples 5. Examples
5.1 A Simple Conference Policy Privileges Document 5.1 A Simple Conference Policy Privileges Document
The following document dictates that Bob and Alice are allowed to The following document dictates that Bob and Alice are allowed to
read and modify the conference settings at read and modify the conference settings at
"http://xcap.example.com/services/conferences/users/Alice/conference.xml" why John can only read the dial-out list. "http://xcap.example.com/services/conferences/users/Alice/conference.
xml" why John can only read the dial-out list.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<privileges xmlns="urn:ietf:params:xml:ns:privileges" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <privileges xmlns="urn:ietf:params:xml:ns:privileges" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
<xml-document-rules uri="http://xcap.example.com/services/conferences/users/Alice/conference.xml"> xmlns:cr="urn:ietf:params:xml:ns:common-policy">
<rule id="1"> <uri>http://xcap.example.com/services/conferences/users/Alice/conference.xml"</uri>
<conditions> <cr:ruleset>
<identity> <cr:rule id="1">
<id>bob@example.com</id> <cr:conditions>
<id>alice@example.com</id> <cr:identity>
</identity> <cr:id>bob@example.com</cr:id>
</conditions> <cr:id>alice@example.com</cr:id>
<actions> </cr:identity>
</cr:conditions>
<cr:actions>
<allow-modify-settings>true</allow-modify-settings> <allow-modify-settings>true</allow-modify-settings>
<allow-read-settings>true</allow-read-settings> <allow-read-settings>true</allow-read-settings>
</actions> </cr:actions>
<transformations/> <cr:transformations/>
</rule> </cr:rule>
<rule id="2"> <cr:rule id="2">
<conditions> <cr:conditions>
<identity> <cr:identity>
<id>john@example.com</id> <cr:id>john@example.com</cr:id>
</identity> </cr:identity>
</conditions> </cr:conditions>
<actions> <cr:actions>
<allow-read-dol>true</allow-read-dol> <allow-read-dol>true</allow-read-dol>
</actions> </cr:actions>
<transformations/> <cr:transformations/>
</rule> </cr:rule>
</xml-document-rules> </cr:ruleset>
</privileges> </privileges>
6. Security Considerations 6. Security Considerations
A conference document may contain information that is highly A conference policy privileges document may contain information that
sensitive. Its delivery to the conference server needs to happen is highly sensitive. Its delivery to the conference server needs to
strictly, paying special attention to integrity and confidentiality. happen strictly, paying special attention to integrity and
Reading the document is also a security concern since the conference confidentiality. Reading the document is also a security concern
policy contains sensitive information like the topic of the since the conference policy proviliges document contains sensitive
conference, who is allowed to join and the URIs of the users that can information like who is allowed to modify certain parts of a
participate. conference policy document.
Manipulations of the conference policy have similar security issues.
Users with relevant privileges can manipulate parts of the conference
policy giving themselves and others privileges to manipulate the
conference policy, including the dial-out list and the security level
settings for a conference. This can happen because the conference
policy itself carries the identities and the authorization rules that
apply to those identities. Those authorization rules carry the
privileges that certain identities have. If an unauthorized user
gets access to this document (pretending to be someone else), s/he
can manipulate those rules giving himself and other unauthorized
users access to the conference policy. S/he can also manipulate
other parts of the conference policy under a false identity. Some of
the things that a malicious user can do include: denying users
certain privileges, giving himself floor moderation, removing users
from lists, removing rules for certain identities, giving privileges
to other malicious users, changing the media streams and changing
conference time. Therefore, it is very important that only
authorized clients are able to manipulate the conference policy. Any
conference policy transport protocol MUST provide authentication,
confidentiality and integrity.
In the case that XCAP is used to create and manipulate a conference A milicious user can manipulate parts of the conference policy
policy, the XCAP base specification mandates that all XCAP servers privileges document giving themselves and others privileges to
MUST implement HTTP Authentication: Basic and Digest Access manipulate the conference policy, including the dial-out list and the
Authentication [14]. Furthermore, XCAP servers MUST implement HTTP ruleset. Those authorization rules carry the privileges that certain
over TLS [15]. It is recommended that administrators of XCAP servers identities have. If an unauthorized user gets access to this
use an HTTPS URI as the XCAP root services URI, so that the digest document (pretending to be someone else), s/he can manipulate those
client authentication occurs over TLS. By using these means, XCAP rules giving himself and other unauthorized users access to the
client and server can ensure the confidentiality and integrity of the conference policy. Some of the things that a malicious user can do
XCAP created conference policy document and its manipulation include: denying users certain privileges, removing rules for certain
operations, and that only authorized clients are allowed to perform identities and giving privileges to other malicious users.
them. Therefore, it is very important that only authorized clients are able
to manipulate the conference policy privileges document. Any
conference policy privileges document transport protocol MUST provide
authentication, confidentiality and integrity.
7. IANA Considerations 7. IANA Considerations
7.1 application/privileges+xml MIME TYPE 7.1 application/privileges+xml MIME TYPE
MIME media type: application MIME media type: application
MIME subtype name: privileges+xml MIME subtype name: privileges+xml
Mandatory parameters: none Mandatory parameters: none
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/