One document matched: draft-niemi-xcon-cpcp-rules-00.txt
Network Working Group A. Niemi
Internet-Draft Nokia
Expires: November 16, 2004 May 18, 2004
Conference Policy Authorization Rules
draft-niemi-xcon-cpcp-rules-00
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 16, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
Authorization is a key component in conference policy. Authorization
rules specify who is allowed to join a conference, see floors and
request them, subscribe to conference-information and so on. This
document proposes an Extensible Markup Language (XML) document format
for conference authorization rules.
This draft is intended for discussion purposes only, and in case this
approach is taken, it would need to be merged with the on-going
Conference Policy Control Protocol (CPCP) work.
Niemi Expires November 16, 2004 [Page 1]
Internet-Draft Conference Authorization May 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Document Conventions and Terminology . . . . . . . . . . . . . 3
3. Motivations for Using Common Policy Framework . . . . . . . . 3
4. Conference Permission Statements . . . . . . . . . . . . . . . 4
4.1 Conditions . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1.1 Identity . . . . . . . . . . . . . . . . . . . . . . . 4
4.1.2 Validity . . . . . . . . . . . . . . . . . . . . . . . 5
4.2 Actions . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2.1 Conference State Events . . . . . . . . . . . . . . . 6
4.2.2 Floor Control Events . . . . . . . . . . . . . . . . . 6
4.2.3 Conference Join Handling . . . . . . . . . . . . . . . 6
4.3 Transformations . . . . . . . . . . . . . . . . . . . . . 7
4.3.1 Key Participant . . . . . . . . . . . . . . . . . . . 7
4.3.2 Floor Moderator . . . . . . . . . . . . . . . . . . . 7
4.3.3 Conference Information . . . . . . . . . . . . . . . . 7
4.3.4 Floor Holder . . . . . . . . . . . . . . . . . . . . . 8
4.3.5 Floor Requests . . . . . . . . . . . . . . . . . . . . 8
5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1 Normative References . . . . . . . . . . . . . . . . . . . . 9
10.2 Informative References . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . 11
Niemi Expires November 16, 2004 [Page 2]
Internet-Draft Conference Authorization May 2004
1. Introduction
A conference is an instance of a multi-party conversation. Each
conference instance has an associated conference policy, which is the
complete set of rules that govern the operation of the conference.
One of the key components of conference policy is the set of
authorization rules that specify who is allowed to join a conference,
see floors and request/grant them, subscribe to
conference-information notifications and so on.
The current Conference Policy Control Protocol (CPCP) [5] defines the
authorization policy as a combination of an Access Control List (ACL
element), and a Privilege Control List (PCL element).
This document proposes an alternate Extensible Markup Language (XML)
document format for conference authorization rules that is based on
the common policy framework [1]. It is intended that if the approach
laid out in this document is acceptable to the XCON Working Group,
that this Internet-Draft is then merged with CPCP [5], replacing the
access control and privilege control rules defined therein.
2. Document Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 [2]
and indicate requirement levels for compliant implementations.
3. Motivations for Using Common Policy Framework
The common policy framework is intended for setting policies that
control access to application specific data. It has been developed
in an effort to harmonise the development of both location
authorization [6] and Session Initiation Protocol (SIP) presence
authorization [7]. The framework includes an XML-based language for
representing policy rules, and can be extended to other application
domains.
TBD: the below needs work...
One aspect of conference authorization policy relates to
participation, namely whether a particular user is allowed to join
the conference or not. For example, a user would attempt to join a
conference using the SIP session setup (INVITE request) at which
point the conference focus would visit the authorization policy of
the conference to see if that user is allowed to join.
Niemi Expires November 16, 2004 [Page 3]
Internet-Draft Conference Authorization May 2004
Another aspect of conference authorization policy relates to
privileges within a conference. For example, a user would attempt to
subscribe to the conference-information event package, at which point
the conference focus would visit the authorization policy to see if
that user is allowed to subscribe.
Both of these modes of operation are supported by the common policy
framework. In fact, the same policy language can be used to specify
both types of authorization rules.
The main advantage in using the common policy framework for
authorization policy is that implementations of different
applications can reuse a single policy language and engine. The
common policy framework also includes a well-defined way of combining
different rules in a manner which is privacy-safe.
4. Conference Permission Statements
A conference permission statement is an XML document, formatted
according to the XML schema defined in the common policy framework
[1]. Each permission document is composed of three parts:
conditions, actions and transformations. Conditions determine
whether a particular rule applies to a request. Each action or
transformation is a positive grant of permission to the conference
participant, in case the conditions part evaluated to TRUE.
Since each action or transformation is a positive grant of
permission, different permissions can be combined in a well-defined
way. As a result, the system is privacy-safe, since the lack of any
actions of transformations can only result in less privileges to be
granted or information to be provided to a conference participant.
This section outlines the new conditions, actions and transformations
defined by this document.
4.1 Conditions
4.1.1 Identity
4.1.1.1 Internpreting the "uri" Element
The "identity" element is already defined in the common policy
framework [1]. However, the rules for interpreting the identities in
"uri" elements are left for each application to define separately.
This section defines the rules for interpreting identities in "uri"
elements in conferencing applications.
Niemi Expires November 16, 2004 [Page 4]
Internet-Draft Conference Authorization May 2004
OPEN ISSUE: Deriving user identities from the Digest
authentication credentials needs further thinking. the "username"
alone is not directly usable, since it may not be in a NAI format.
For requests that are authenticated according to [8], the username
and domain parts of the "uri" element are matched against the user
and host parts of the SIP URI in the P-Asserted-Identity header
field.
For systems other than SIP, the identity of the user would be derived
using a similar pattern.
OPEN ISSUE: Do we need to state more than this? How are identities
derived from users that join using POTS, H.323, etc.?
4.1.1.2 Anonymous
The "anonymous" element is used to match anonymous participants.
OPEN ISSUE: The CPCP requirements [3] requires that users be able
to join a conference anonymously, yet anonymous Digest
authentication is explicitly disallowed. Therefore it remains an
open issue as to how anonymous users are identified for conference
authorization purposes.
4.1.1.3 Matching Any Identity
The "any" element is a new child element for the "identity" element.
An "identity" condition that includes the "any" element will create a
successful match for any authenticated identity.
Zero or more "except" elements may also be present alongside the
"any" element. A request MUST match all of the "except" element as
well as the "any" element in an atomic fashion to be a sucessful
match.
4.1.2 Validity
The "validity" element can be set to implement conference timing. If
the current time falls outside the "validity" the condition evaluates
to FALSE.
OPEN ISSUE: Is the "validity" element appropriate for the
conferencing needs?
4.2 Actions
Niemi Expires November 16, 2004 [Page 5]
Internet-Draft Conference Authorization May 2004
4.2.1 Conference State Events
The "allow-conference-state" element represents a boolean action. If
set to TRUE, the focus is instructed to allow the subscription to
conference state events, such as the SIP Event Package for Conference
State [4]. If set to FALSE, the subscription to conference state
events would be rejected.
If this element is undefined it has a value of FALSE, causing the
subscription to conference state events to be rejected.
OPEN ISSUE: Is a simple block/allow sufficient here, or should the
subscription handling be similar to e.g. presence, and have three
states (block, confirm, allow), or possibly even four states
(block, confirm, polite-block, allow)?
4.2.2 Floor Control Events
The "allow-floor-events" element represents a boolean action. If set
to TRUE, the focus is instructed to accept the subscription to floor
control events. If set to FALSE, the focus is instructed to reject
the subscription.
If this element is undefined, it has a value of FALSE, causing the
subscription to floor control events to be rejected.
OPEN ISSUE: Is a simple block/allow sufficient here, or should the
subscription handling be similar to e.g. presence, and have three
states (block, confirm, allow), or possibly even four states
(block, confirm, polite-block, allow)?
4.2.3 Conference Join Handling
The "join-handling" element defines the actions used by the conferene
focus to control conference participation. This element defines the
action that the focus is to take when processing a particular request
to join a conference. This element is an enumerated integer type,
with defined values of:
block: This action instructs the focus to deny access to the
conference. This action has a value of zero and it is the lowest
value of the "join-handling" element. This action is the default
action taken in the absence of any other actions.
confirm: This action instructs the focus to place the participant on
a pending list (e.g., by parking the call on a music-on-hold
server), awaiting moderator input for further actions. This
action has a value of one.
Niemi Expires November 16, 2004 [Page 6]
Internet-Draft Conference Authorization May 2004
allow: This action instructs the focus to accept the conference join
request and grant access to the conference within the instructions
specified in the transformations of this rule. This action has a
value of two.
Note that placing a value of block for this element doesn't guarantee
that a participant is blocked from joining the conference. Any other
rule that might evaluate to true for this participant that carried an
action whose value was higher than block would automatically grant
confirm/allow permission to that participant.
4.3 Transformations
4.3.1 Key Participant
When the "is-key-participant" element is set to TRUE, the joining
participant is denoted as a key participant. Entry of a
key-participant may trigger the conference focus to perform certain
tasks, e.g., make a dial-out. If set to FALSE, the participant is
not denoted as a key participant.
If this element is undefined, it has a value of FALSE, causing no key
participant status to be given to the participant.
4.3.2 Floor Moderator
When the "is-floor-moderator" element is set to TRUE, the joining
conference participant is denoted as floor moderator, meaning that
they are privileged to control the floor in the conference. If set
to FALSE, floor moderator privileges are not given to the conference
participant.
If this element is undefined, it has a value of FALSE, causing no
floor moderator privileges to being granted.
4.3.3 Conference Information
The "show-confeence-info" element is of type boolean transformation.
If set to TRUE, conference information is shown to the conference
participant. If set to FALSE, conference information is not shown to
the participant.
If this element is undefined, it has a value of FALSE, causing no
conference information to being shown.
OPEN ISSUE: Do we require more granularity for this element?
Perhaps an enumerated integer type, with defined levels of
information about the conference, or a set of boolean
Niemi Expires November 16, 2004 [Page 7]
Internet-Draft Conference Authorization May 2004
transformations, each granting a single piece of conference
information, like the ability to see "sidebar" elements?
4.3.4 Floor Holder
The "show-floor-holder" element is of type boolean transformation.
If set to TRUE, the conference participant is able to see who is
currently holding the floor. If set to FALSE, the participant is not
able to see the floor holder.
If this element is undefined, it has a value of FALSE, causing the
floor holder to bot being shown to the participant.
4.3.5 Floor Requests
The "show-floor-requests" element is of type boolean transformation.
If set to TRUE, the conference participant is able to see the floor
requests. If set to FALSE, the conference participant is not able to
see floor requests.
If this element is undefined, it has a value of FALSE, causing the
floor requests to not being seen by the conference participant.
5. XML Schema
...
6. Examples
This example shows a rule that would match all authenticated
identities except "joe@example.com", and require moderator input
before accepting them in the conference.
<rule="7a8c">
<conditions>
<identity>
<any />
<except>joe@example.com</except>
</identity>
</conditions>
<actions>
<join-handling>confirm</join-handling>
</actions>
</rule>
This example shows a rule that would match "lisa@example.com", permit
access to the conference, and also name her as a key-participant and
a floor moderator.
Niemi Expires November 16, 2004 [Page 8]
Internet-Draft Conference Authorization May 2004
<rule="ff405">
<conditions>
<identity>
<uri>lisa@example.com</uri>
</identity>
</conditions>
<actions>
<join-handling>accept</join-handling>
</actions>
<transformations>
<is-key-participant>true</is-key-participant>
</transformations>
</rule>
7. Security Considerations
...
8. IANA Considerations
...
9. Acknowledgements
Hisham Khartabil, Petri Koskelainen provided useful comments and
discussion.
10. References
10.1 Normative References
[1] Schulzrinne, H., "Common Policy",
draft-ietf-geopriv-common-policy-00 (work in progress), February
2004.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Koskelainen, P., "Requirements for Conference Policy Control
Protocol", draft-ietf-xcon-cpcp-reqs-02 (work in progress),
February 2004.
[4] Rosenberg, J. and H. Schulzrinne, "A Session Initiation Protocol
(SIP) Event Package for Conference State",
draft-ietf-sipping-conference-package-03 (work in progress),
February 2004.
Niemi Expires November 16, 2004 [Page 9]
Internet-Draft Conference Authorization May 2004
10.2 Informative References
[5] Khartabil, H. and P. Koskelainen, "The Conference Policy Control
Protocol (CPCP)", draft-ietf-xcon-cpcp-xcap-00 (work in
progress), May 2004.
[6] Schulzrinne, H., "Geopriv Policy", draft-ietf-geopriv-policy-01
(work in progress), February 2004.
[7] Rosenberg, J., "Presence Authorization Rules",
draft-ietf-simple-presence-rules-00 (work in progress), May
2004.
[8] Jennings, C., Peterson, J. and M. Watson, "Private Extensions to
the Session Initiation Protocol (SIP) for Asserted Identity
within Trusted Networks", RFC 3325, November 2002.
Author's Address
Aki Niemi
Nokia
P.O. Box 100
NOKIA GROUP, FIN 00045
Finland
Phone: +358 50 389 1644
EMail: aki.niemi@nokia.com
Niemi Expires November 16, 2004 [Page 10]
Internet-Draft Conference Authorization May 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Niemi Expires November 16, 2004 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-22 16:33:49 |