Internet DRAFT - draft-ietf-simple-common-policy-caps
draft-ietf-simple-common-policy-caps
SIMPLE J. Rosenberg
Internet-Draft Cisco Systems
Expires: December 28, 2006 June 26, 2006
An Extensible Markup Language (XML) Representation for Expressing Policy
Capabilities
draft-ietf-simple-common-policy-caps-01
Status of this Memo
By submitting this Internet-Draft, each 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 becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 December 28, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
An important component of presence and location services is policy.
Policy systems allow the presentity or location target to grant
access to specific pieces of information to specific watchers or
requestors. These policy systems can be extremely simple, allowing a
user to accept or block requests based solely on the identity of the
requestor, to extremely complex, allowing for time based rules that
grant or deny specific pieces of information. Policy systems often
support vendor proprietary features. To allow for interoperability
Rosenberg Expires December 28, 2006 [Page 1]
Internet-Draft Common Policy Capabilities June 2006
between clients which set such policies, and servers which execute
them, it is necessary for clients to be able to determine the
capabilities of the server to which it is connected. This
specification defines an Extensible Markup Language (XML) based
format for expressing such capabilities.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3
4. Structure of Policy Capabilities . . . . . . . . . . . . . . . 4
5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Example Document . . . . . . . . . . . . . . . . . . . . . . . 7
7. Usage with XCAP . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Application Unique ID . . . . . . . . . . . . . . . . . . 7
7.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 7
7.3. Default Namespace . . . . . . . . . . . . . . . . . . . . 8
7.4. MIME Type . . . . . . . . . . . . . . . . . . . . . . . . 8
7.5. Validation Constraints . . . . . . . . . . . . . . . . . . 8
7.6. Data Semantics . . . . . . . . . . . . . . . . . . . . . . 8
7.7. Naming Conventions . . . . . . . . . . . . . . . . . . . . 8
7.8. Resource Interdependencies . . . . . . . . . . . . . . . . 8
7.9. Authorization Policies . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9.1. XCAP Application Usage ID . . . . . . . . . . . . . . . . 9
9.2. MIME Type Registration . . . . . . . . . . . . . . . . . . 9
9.3. URN Sub-Namespace Registrations . . . . . . . . . . . . . 10
9.4. XML Schema Registration . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Rosenberg Expires December 28, 2006 [Page 2]
Internet-Draft Common Policy Capabilities June 2006
1. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and
indicate requirement levels for compliant implementations.
2. Introduction
An important component of presence [10] and location services [11] is
policy. Policy systems allow the presentity or location target
(referred to generically as the Presentity Target (PT)) to grant
access to specific pieces of information to specific watchers or
requestors (referred to as a WR) [5]. These policy systems can be
extremely simple, allowing a PT to accept or block requests based
solely on the identity of the WR, to extremely complex, allowing for
time based rules that grant or deny specific pieces of information.
[5] specifies a generic format for representing these policies, using
the Extensible Markup Language (XML). These policies consist of
conditions, actions, and transformations. That specification defines
very few actual conditions, actions or transformations. Rather, it
leaves such definitions to actual policy systems, such as [12] for
location services, and [13] for presence services.
In addition to the conditions, actions and transformations specificed
in the documents referenced above, policy systems often support
vendor proprietary features. It is also anticipated that future
specifications will be continually developed that add new types of
policies. This presents an interoperability challenge. Clients may
support policies that are not supported by the servers they are
using. This could lead to protocol failures or poor user
experiences.
To address this problem, it is necessary for a capability declaration
system to be put in place. This specification defines a general
purpose format for representing policy capabilities within the
framework established in [5].
3. Overview of Operation
This specification defines an XML-based document format that allows a
server to represent its capabilities. When a client, acting as an
agent of a PT, starts up, it obtains this document from its policy
server. This specification does not prescribe a singular means of
transporting such a document between the server and the client. It
is anticipated that different systems may use different techniques.
Rosenberg Expires December 28, 2006 [Page 3]
Internet-Draft Common Policy Capabilities June 2006
However, for systems that make use of the XML Configuration Access
Protocol (XCAP) [4], Section 7 defines an application usage that
allows for the transfer of the document using XCAP.
Once the document has been obtained by the client, it can determine
which actions, conditions and transformations are understood by the
server. This set is matched against those supported by the client.
Those actions, conditions and transformations supported by the
client, but not by the server, can be "greyed out" from a user
interface, for example.
It is anticipated that the capabilities of the server can change over
time. As a result, it is RECOMMENDED that clients obtain a fresh
copy of the capabilities document each time they start.
4. Structure of Policy Capabilities
A policy capabilities document is an XML [6] document that MUST be
well-formed and SHOULD be valid. Policy capabilities documents MUST
be based on XML 1.0 and MUST be encoded using UTF-8. This
specification makes use of XML namespaces for identifying policy
capabilities documents and document fragments. The namespace URI for
elements defined for this purpose is a URN [2], using the namespace
identifier 'ietf' defined by [3] and extended by [7]. This URN is:
urn:ietf:params:xml:ns:policy-capabilities
A policy capabilities document is structured much like a policy
document [5]. The root element is <policy-capabilities>. This
element has three children - <conditions>, <actions>, and
<transformations>. Each of these contain a list of the condition,
action, and transformation capabilities, respectively. Generally
speaking, each specific condition, action or transformation element
(referred to as a capability element) is empty, unless it requires
additional content to further refine the capability.
This specification defines three capability elements - <identity>,
<validity>, and <sphere> matching the three conditions defined in
[5]. Other specifications that define additional policies MUST also
define matching capability elements. When such elements are defined,
that specification MUST indicate, for each capability element, the
corresponding action, condition, or permission elements which can be
placed into a common policy document [5]. The name of the capability
element need not match the name of the corresponding condition,
action or transformation, although using a matching name is
RECOMMENDED.
Rosenberg Expires December 28, 2006 [Page 4]
Internet-Draft Common Policy Capabilities June 2006
A server constructing a document to represent its capabilities MUST
include all of its capabilities, even if those capabilities represent
mandatory-to-implement features. However, the server MAY indicate
differing sets of capabilities to different users. As such, the set
of capabilities combines both the ability and the willingness to
support those capabilities.
Rosenberg Expires December 28, 2006 [Page 5]
Internet-Draft Common Policy Capabilities June 2006
5. XML Schema
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:policy-capabilities"
xmlns="urn:ietf:params:xml:ns:policy-capabilities"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="policy-capabilities">
<xs:complexType>
<xs:sequence>
<xs:element name="conditions" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element ref="identity"/>
<xs:element ref="sphere"/>
<xs:element ref="validity"/>
<xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="actions" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="transformations" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:complexType name="emptyType">
<xs:complexContent>
<xs:restriction base="xs:anyType"/>
</xs:complexContent>
</xs:complexType>
<xs:element name="validity" type="emptyType"/>
<xs:element name="sphere" type="emptyType"/>
<xs:element name="identity" type="emptyType"/>
</xs:schema>
Rosenberg Expires December 28, 2006 [Page 6]
Internet-Draft Common Policy Capabilities June 2006
6. Example Document
The following document indicates that the identity, validity and
sphere conditions are supported. It also indicates that a vendor-
specific capability, called <happy>, is supported, a vendor specific
action capability, <log>, is supported, and a vendor-specific
transformation capability - <min-security> is supported. The
specification which defines these capabilities would indicate the
specific elements which could be included in a policy document.
<?xml version="1.0" encoding="UTF-8"?>
<policy-capabilities
xmlns="urn:ietf:params:xml:ns:policy-capabilities"
xmlns:cp="urn:ietf:params:xml:ns:policy-capabilities"
xmlns:vpp="urn:ietf:params:xml:ns:vpp"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<conditions>
<identity/>
<sphere/>
<validity/>
<vpp:happy/>
</conditions>
<actions>
<vpp:log/>
</actions>
<transformations>
<vpp:min-security/>
</transformations>
</policy-capabilities>
7. Usage with XCAP
The following section defines the details necessary for clients to
read supported permissions documents from a server using XCAP.
7.1. Application Unique ID
XCAP requires application usages to define an application unique ID
(AUID) in either the IETF tree or a vendor tree. This specification
defines the "policy-capabilities" AUID within the IETF tree, via the
IANA registration in Section 9.
7.2. XML Schema
The schema is defined in Section 5.
Rosenberg Expires December 28, 2006 [Page 7]
Internet-Draft Common Policy Capabilities June 2006
7.3. Default Namespace
The default namespace used in evaluating a URI is
urn:ietf:params:xml:ns:policy-capabilities.
7.4. MIME Type
The MIME type for this document is "application/policy-caps+xml".
7.5. Validation Constraints
This specification does not introduce any additional validation
constraints beyond those defined in the schema.
7.6. Data Semantics
Semantics for the document content are provided in Section 4.
7.7. Naming Conventions
When a client starts, it can fetch the capabilities of the server in
one of two places. If the server capabilities differ on a user by
user basis, the capabilities for user foo can be found in the
document with filename "cap.xml" in the user's home directory for
this application usage. A client SHOULD check this file first. If
this document doesn't exist, the client should next check for the
system wide permissions by reading the document with filename
"cap.xml" in the global directory for this application usage.
7.8. Resource Interdependencies
Policy capability documents are usually either created automatically
by the server, or modified by administrator to reflect the features
of a server. For those users that have access to the full
capabilities of the server, a change in the server-wide capabilities,
expressed in the "cap.xml" file in the global directory, MUST be
reflected in any "cap.xml" documents in user's home directories.
7.9. Authorization Policies
This application usage does not use the default XCAP authorization
policies.
A user cannot modify the supported permissions document, they can
only read it. Write access is granted only to administrators.
A user can read the "cap.xml" document in the global directory, but
cannot modify it. Write access is granted only to administrators.
Rosenberg Expires December 28, 2006 [Page 8]
Internet-Draft Common Policy Capabilities June 2006
8. Security Considerations
Policy capability documents reveal capability information about a
server. This information can potentially be used by an enterprise to
determine the features found in competitive products. However, such
information could just as easily be obtained through other means, for
example, by signing up as a legitimate user of the competitive
service. Because supported permission documents can vary by user to
user, they can also reveal information about the grade of service
offered to a particular user. However, this information does not
appear particularly sensitive. As a result, encryption of these
documents is not terribly important.
If an attacker can modify the contents of a supported permission
document as it passes from client to server, the attacker can remove
capability elements, therefore reducing the level of service received
by the client. This can therefore form a type of denial-of-service
attack. As a result, systems which transfer these documents SHOULD
provide for message integrity.
9. IANA Considerations
There are several IANA considerations associated with this
specification.
9.1. XCAP Application Usage ID
This section registers an XCAP Application Unique ID (AUID) according
to the IANA procedures defined in [4].
Name of the AUID: policy-capabilities
Description: Policy capability documents describe the capabilities
of a policy server to support different conditions, actions, and
transformations, as defined in [5].
9.2. MIME Type Registration
This specification requests the registration of a new MIME type
according to the procedures of RFC 2048 [8] and guidelines in RFC
3023 [9].
MIME media type name: application
Rosenberg Expires December 28, 2006 [Page 9]
Internet-Draft Common Policy Capabilities June 2006
MIME subtype name: policy-caps+xml
Mandatory parameters: none
Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [9].
Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [9].
Security considerations: See Section 10 of RFC 3023 [9] and
Section 8 of RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace
XXXX with the RFC number of this specification]].
Interoperability considerations: none.
Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR:
Please replace XXXX with the RFC number of this specification]]
Applications which use this media type: This document type has
been used to support capabilities for presence and geolocation.
Additional Information:
Magic Number: None
File Extension: .pcp
Macintosh file type code: "TEXT"
Personal and email address for further information: Jonathan
Rosenberg, jdrosen@jdrosen.net
Intended usage: COMMON
Author/Change controller: The IETF.
9.3. URN Sub-Namespace Registrations
This section registers a new XML namespace, as per the guidelines in
[7]
URI: The URI for this namespace is
urn:ietf:params:xml:ns:policy-capabilities.
Rosenberg Expires December 28, 2006 [Page 10]
Internet-Draft Common Policy Capabilities June 2006
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
Jonathan Rosenberg (jdrosen@jdrosen.net).
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Policy Capabilities Namespace</title>
</head>
<body>
<h1>Namespace for Policy Capabilities</h1>
<h2>urn:ietf:params:xml:ns:policy-capabilities</h2>
<p>See <a href="[URL of published RFC]">RFCXXXX[[NOTE
TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number for this
specification.</a>.</p>
</body>
</html>
END
9.4. XML Schema Registration
This section registers an XML schema as per the procedures in [7].
URI: urn:ietf:params:xml:schema:policy-capabilities
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
Jonathan Rosenberg (jdrosen@jdrosen.net).
The XML for this schema can be found as the sole content of
Section 5.
10. References
10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Moats, R., "URN Syntax", RFC 2141, May 1997.
Rosenberg Expires December 28, 2006 [Page 11]
Internet-Draft Common Policy Capabilities June 2006
[3] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
August 1999.
[4] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)", draft-ietf-simple-xcap-11
(work in progress), May 2006.
[5] Schulzrinne, H., "Common Policy: An XML Document Format for
Expressing Privacy Preferences",
draft-ietf-geopriv-common-policy-10 (work in progress),
May 2006.
[6] Sperberg-McQueen, C., Paoli, J., Maler, E., and T. Bray,
"Extensible Markup Language (XML) 1.0 (Second Edition)", World
Wide Web Consortium
FirstEdition http://www.w3.org/TR/2000/REC-xml-20001006,
October 2000.
[7] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[8] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet
Mail Extensions (MIME) Part Four: Registration Procedures",
BCP 13, RFC 2048, November 1996.
[9] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
RFC 3023, January 2001.
10.2. Informative References
[10] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence
and Instant Messaging", RFC 2778, February 2000.
[11] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.
Polk, "Geopriv Requirements", RFC 3693, February 2004.
[12] Schulzrinne, H., "A Document Format for Expressing Privacy
Preferences for Location Information",
draft-ietf-geopriv-policy-08 (work in progress), February 2006.
[13] Rosenberg, J., "Presence Authorization Rules",
draft-ietf-simple-presence-rules-07 (work in progress),
June 2006.
Rosenberg Expires December 28, 2006 [Page 12]
Internet-Draft Common Policy Capabilities June 2006
Author's Address
Jonathan Rosenberg
Cisco Systems
600 Lanidex Plaza
Parsippany, NJ 07054
US
Phone: +1 973 952-5000
Email: jdrosen@cisco.com
URI: http://www.jdrosen.net
Rosenberg Expires December 28, 2006 [Page 13]
Internet-Draft Common Policy Capabilities June 2006
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 (2006). 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.
Rosenberg Expires December 28, 2006 [Page 14]
