draft-ietf-geopriv-common-policy-11.txt   rfc4745.txt 
GEOPRIV H. Schulzrinne Network Working Group H. Schulzrinne
Internet-Draft Columbia U. Request for Comments: 4745 Columbia U.
Intended status: Standards Track H. Tschofenig Category: Standards Track H. Tschofenig
Expires: February 11, 2007 Siemens Siemens Networks GmbH & Co KG
J. Morris J. Morris
CDT CDT
J. Cuellar J. Cuellar
Siemens Siemens
J. Polk J. Polk
Cisco
J. Rosenberg J. Rosenberg
Cisco Systems Cisco
August 10, 2006 February 2007
Common Policy: A Document Format for Expressing Privacy Preferences Common Policy: A Document Format for Expressing Privacy Preferences
draft-ietf-geopriv-common-policy-11.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any Status of This Memo
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 February 11, 2007. This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document defines a framework for authorization policies This document defines a framework for authorization policies
controlling access to application specific data. This framework controlling access to application-specific data. This framework
combines common location- and presence-specific authorization combines common location- and presence-specific authorization
aspects. An XML schema specifies the language in which common policy aspects. An XML schema specifies the language in which common policy
rules are represented. The common policy framework can be extended rules are represented. The common policy framework can be extended
to other application domains. to other application domains.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology .....................................................4
3. Modes of Operation . . . . . . . . . . . . . . . . . . . . . . 7 3. Modes of Operation ..............................................4
3.1. Passive Request-Response - PS as Server (Responder) . . . 7 3.1. Passive Request-Response - PS as Server (Responder) ........5
3.2. Active Request-Response - PS as Client (Initiator) . . . . 7 3.2. Active Request-Response - PS as Client (Initiator) .........5
3.3. Event Notification . . . . . . . . . . . . . . . . . . . . 7 3.3. Event Notification .........................................5
4. Goals and Assumptions . . . . . . . . . . . . . . . . . . . . 9 4. Goals and Assumptions ...........................................6
5. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Non-Goals .......................................................7
6. Basic Data Model and Processing . . . . . . . . . . . . . . . 12 6. Basic Data Model and Processing .................................8
6.1. Identification of Rules . . . . . . . . . . . . . . . . . 13 6.1. Identification of Rules ....................................9
6.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 13 6.2. Extensions .................................................9
7. Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Conditions .....................................................10
7.1. Identity Condition . . . . . . . . . . . . . . . . . . . . 14 7.1. Identity Condition ........................................10
7.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 14 7.1.1. Overview ...........................................10
7.1.2. Matching One Entity . . . . . . . . . . . . . . . . . 14 7.1.2. Matching One Entity ................................11
7.1.3. Matching Multiple Entities . . . . . . . . . . . . . . 15 7.1.3. Matching Multiple Entities .........................11
7.2. Single Entity . . . . . . . . . . . . . . . . . . . . . . 19 7.2. Single Entity .............................................14
7.3. Sphere . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.3. Sphere ....................................................15
7.4. Validity . . . . . . . . . . . . . . . . . . . . . . . . . 21 7.4. Validity ..................................................16
8. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 8. Actions ........................................................17
9. Transformations . . . . . . . . . . . . . . . . . . . . . . . 24 9. Transformations ................................................18
10. Procedure for Combining Permissions . . . . . . . . . . . . . 25 10. Procedure for Combining Permissions ...........................18
10.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 25 10.1. Introduction .............................................18
10.2. Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 25 10.2. Combining Rules (CRs) ....................................18
10.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 26 10.3. Example ..................................................19
11. Meta Policies . . . . . . . . . . . . . . . . . . . . . . . . 29 11. Meta Policies .................................................21
12. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 12. Example .......................................................21
13. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 31 13. XML Schema Definition .........................................22
14. Security Considerations . . . . . . . . . . . . . . . . . . . 34 14. Security Considerations .......................................25
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 15. IANA Considerations ...........................................25
15.1. Common Policy Namespace Registration . . . . . . . . . . . 35 15.1. Common Policy Namespace Registration .....................25
15.2. Content-type registration for 15.2. Content-type Registration for
'application/auth-policy+xml' . . . . . . . . . . . . . . 35 'application/auth-policy+xml' ............................26
15.3. Common Policy Schema Registration . . . . . . . . . . . . 37 15.3. Common Policy Schema Registration ........................27
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 16. References ....................................................27
16.1. Normative References . . . . . . . . . . . . . . . . . . . 38 16.1. Normative References .....................................27
16.2. Informative References . . . . . . . . . . . . . . . . . . 38 16.2. Informative References ...................................28
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 39 Appendix A. Contributors ..........................................29
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 40 Appendix B. Acknowledgments .......................................29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
Intellectual Property and Copyright Statements . . . . . . . . . . 43
1. Introduction 1. Introduction
This document defines a framework for creating authorization policies This document defines a framework for creating authorization policies
for access to application specific data. This framework is the for access to application-specific data. This framework is the
result of combining the common aspects of single authorization result of combining the common aspects of single authorization
systems that more specifically control access to presence and systems that more specifically control access to presence and
location information and that previously had been developed location information and that previously had been developed
separately. The benefit of combining these two authorization systems separately. The benefit of combining these two authorization systems
is two-fold. First, it allows to build a system which enhances the is two-fold. First, it allows building a system that enhances the
value of presence with location information in a natural way and value of presence with location information in a natural way and
reuses the same underlying authorization mechanism. Second, it reuses the same underlying authorization mechanism. Second, it
encourages a more generic authorization framework with mechanisms for encourages a more generic authorization framework with mechanisms for
extensibility. The applicability of the framework specified in this extensibility. The applicability of the framework specified in this
document is not limited to policies controling access to presence and document is not limited to policies controlling access to presence
location information data, but can be extended to other application and location information data, but can be extended to other
domains. application domains.
The general framework defined in this document is intended to be The general framework defined in this document is intended to be
accompanied and enhanced by application-specific policies specified accompanied and enhanced by application-specific policies specified
elsewhere. The common policy framework described here is enhanced by elsewhere. The common policy framework described here is enhanced by
domain-speific policy documents, including presence [7] and location domain-specific policy documents, including presence [7] and location
[8]. This relationship is shown in Figure 1. [8]. This relationship is shown in Figure 1.
+-----------------+ +-----------------+
| | | |
| Common | | Common |
| Policy | | Policy |
| | | |
+---+---------+---+ +---+---------+---+
/|\ /|\ /|\ /|\
| | | |
skipping to change at page 4, line 49 skipping to change at page 3, line 49
| Policy |----+ +----| Policy | | Policy |----+ +----| Policy |
| | | | | | | |
+-------------------+ +-------------------+ +-------------------+ +-------------------+
Figure 1: Common Policy Enhancements Figure 1: Common Policy Enhancements
This document starts with an introduction to the terminology in This document starts with an introduction to the terminology in
Section 2, an illustration of basic modes of operation in Section 3, Section 2, an illustration of basic modes of operation in Section 3,
a description of goals (see Section 4) and non-goals (see Section 5) a description of goals (see Section 4) and non-goals (see Section 5)
of the policy framework, followed by the data model in Section 6. of the policy framework, followed by the data model in Section 6.
The structure of a rule, namely conditions, actions and The structure of a rule, namely, conditions, actions, and
transformations, are described in Section 7, in Section 8 and in transformations, is described in Sections 7, 8, and 9. The procedure
Section 9. The procedure for combining permissions is explained in for combining permissions is explained in Section 10 and used when
Section 10 and used when more than one rule fires. A short conditions for more than one rule are satisfied. A short description
description of meta policies is given in Section 11. An example is of meta policies is given in Section 11. An example is provided in
provided in Section 12. The XML schema will be discussed in Section 12. The XML schema will be discussed in Section 13. IANA
Section 13. IANA considerations in Section 15 follow security considerations in Section 15 follow security considerations in
considerations Section 14. Section 14.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT","RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT","RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1]. document are to be interpreted as described in [1].
This document introduces the following terms: This document introduces the following terms:
PT - Presentity / Target: The PT is the entity about whom PT - Presentity / Target: The PT is the entity about whom
information has been requested. information has been requested.
RM - Rule Maker: RM is an entity which creates the authorization RM - Rule Maker: The RM is an entity that creates the authorization
rules which restrict access to data items. rules that restrict access to data items.
PS - (Authorization) Policy Server: This entity has access to both PS - (Authorization) Policy Server: This entity has access to both
the authorization policies and to the data items. In location- the authorization policies and the data items. In location-
specific applications, the entity PS is labeled as location server specific applications, the entity PS is labeled as location
(LS). server (LS).
WR - Watcher / Recipient: This entity requests access to data items WR - Watcher / Recipient: This entity requests access to data items
of the PT. An access operation might be either be a read, write of the PT. An access operation might be a read, a write, or any
or be any other operation. In case of access to location other operation.
information it might be a read operation.
A policy is given by a 'rule set' that contains an unordered list of A policy is given by a 'rule set' that contains an unordered list of
'rules'. A 'rule' has a 'conditions', an 'actions' and a 'rules'. A 'rule' has a 'conditions', an 'actions', and a
'transformations' part. 'transformations' part.
The term 'permission' indicates the action and transformation The term 'permission' indicates the action and transformation
components of a 'rule'. components of a 'rule'.
The term 'using protocol' is defined in [9]. It refers to the The term 'using protocol' is defined in [9]. It refers to the
protocol which is used to request access to and to return privacy protocol used to request access to and to return privacy-sensitive
sensitive data items. data items.
3. Modes of Operation 3. Modes of Operation
The abstract sequence of operations can roughly be described as The abstract sequence of operations can roughly be described as
follows. The PS receives a query for data items for a particular PT, follows. The PS receives a query for data items for a particular PT,
via the using protocol. The using protocol (or more precisely the via the using protocol. The using protocol (or more precisely, the
authentication protocol) provides the identity of the requestor, authentication protocol) provides the identity of the requestor,
either at the time of the query or at the subscription time. The either at the time of the query or at the subscription time. The
authenticated identity of the WR, together with other information authenticated identity of the WR, together with other information
provided by the using protocol or generally available to the server, provided by the using protocol or generally available to the server,
is then used for searching through the rule set. All matching rules is then used for searching through the rule set. All matching rules
are combined according to a permission combining algorithm described are combined according to a permission combining algorithm described
in Section 10. The combined rules are applied to the application in Section 10. The combined rules are applied to the application
data, resulting in the application of privacy based on the data, resulting in the application of privacy based on the
transformation policies. The resulting application data is returned transformation policies. The resulting application data is returned
to the WR. to the WR.
Three different modes of operation can be distinguished: Three different modes of operation can be distinguished:
3.1. Passive Request-Response - PS as Server (Responder) 3.1. Passive Request-Response - PS as Server (Responder)
In a passive request-response mode, the WR queries the PS for data In a passive request-response mode, the WR queries the PS for data
items about the PT. Examples of protocols following this mode of items about the PT. Examples of protocols following this mode of
operation include HTTP, FTP, LDAP, finger or various RPC protocols, operation include HTTP, FTP, LDAP, finger, and various remote
including Sun RPC, DCE, DCOM, Corba and SOAP. The PS uses the procedure call (RPC) protocols, including Sun RPC, Distributed
ruleset to determine whether the WR is authorized to access the PTs Computing Environment (DCE), Distributed Component Object Model
information, refusing the request if necessary. Furthermore, the PS (DCOM), common object request broker architecture (Corba), and Simple
might filter information by removing elements or by reducing the Object Access Protocol (SOAP). The PS uses the rule set to determine
resolution of elements. whether the WR is authorized to access the PT's information, refusing
the request if necessary. Furthermore, the PS might filter
information by removing elements or by reducing the resolution of
elements.
3.2. Active Request-Response - PS as Client (Initiator) 3.2. Active Request-Response - PS as Client (Initiator)
Alternatively, the PS may contact the WR and convey data items. Alternatively, the PS may contact the WR and convey data items.
Examples include HTTP, SIP session setup (INVITE request), H.323 Examples include HTTP, SIP session setup (INVITE request), H.323
session setup or SMTP. session setup or SMTP.
3.3. Event Notification 3.3. Event Notification
Event notification adds a subscription phase to the "Active Request- Event notification adds a subscription phase to the "Active Request-
Response - PS as Client (Initiator)" mode of operation. A watcher or Response - PS as Client (Initiator)" mode of operation. A watcher or
subscriber asks to be added to the notification list for a particular subscriber asks to be added to the notification list for a particular
presentity or event. When the presentity changes state or the event presentity or event. When the presentity changes state or the event
occurs, the PS sends a message to the WR containing the updated occurs, the PS sends a message to the WR containing the updated
state. (Presence is a special case of event notification; thus, we state. (Presence is a special case of event notification; thus, we
often use the term interchangeably.) often use the term interchangeably.)
In addition, the subscriber may itself add a filter to the In addition, the subscriber may itself add a filter to the
subscription, limiting the rate or content of the notifications. If subscription, limiting the rate or content of the notifications. If
an event, after filtering by the rulemaker-provided rules and by the an event, after filtering by the rule-maker-provided rules and by the
subscriber-provided rules, only produces the same notification subscriber-provided rules, only produces the same notification
content that was sent previously, no event notification is sent. content that was sent previously, no event notification is sent.
A single PS may authorize access to data items in more than one mode. A single PS may authorize access to data items in more than one mode.
Rather than having different rule sets for different modes all three Rather than having different rule sets for different modes all three
modes are supported with a one rule set schema. Specific instances modes are supported with a one rule set schema. Specific instances
of the rule set can omit elements that are only applicable to the of the rule set can omit elements that are only applicable to the
subscription model. subscription model.
4. Goals and Assumptions 4. Goals and Assumptions
skipping to change at page 9, line 18 skipping to change at page 6, line 24
Table representation: Table representation:
Each rule must be representable as a row in a relational database. Each rule must be representable as a row in a relational database.
This design goal should allow efficient policy implementation by This design goal should allow efficient policy implementation by
utilizing standard database optimization techniques. utilizing standard database optimization techniques.
Permit only: Permit only:
Rules only provide permissions rather than denying them. Removing Rules only provide permissions rather than denying them. Removing
a rule can never increase permissions. Allowing both 'permit' and a rule can never increase permissions. Depending on the
'deny' actions would require some rule ordering which had interpretation of 'deny' and 'permit' rules, the ordering of rules
implications on the update operations executed on these rules. might matter, making updating rule sets more complicated since
Additionally, it would make distributed rule sets more such update mechanisms would have to support insertion at specific
complicated. Hence, only 'permit' actions are allowed which locations in the rule set. Additionally, it would make
result in more efficient rule processing. This also implies that distributed rule sets more complicated. Hence, only 'permit'
rule ordering is not important. Consequently, to make a policy actions are allowed that result in more efficient rule processing.
decision requires processing all rules. This also implies that rule ordering is not important.
Consequently, to make a policy decision requires processing all
rules.
Additive permissions: Additive permissions:
A query for access to data items is matched against the rules in A query for access to data items is matched against the rules in
the rule database. If several rules match, then the overall the rule database. If several rules match, then the overall
permissions granted to the WR are the union of those permissions. permissions granted to the WR are the union of those permissions.
A more detailed discussion is provided inSection 10. A more detailed discussion is provided inSection 10.
Upgradeable: Upgradeable:
skipping to change at page 11, line 15 skipping to change at page 7, line 41
5. Non-Goals 5. Non-Goals
We explicitly decided that a number of possibly worthwhile We explicitly decided that a number of possibly worthwhile
capabilities are beyond the scope of this first version. Future capabilities are beyond the scope of this first version. Future
versions may include these capabilities, using the extension versions may include these capabilities, using the extension
mechanism described in this document. Non-goals include: mechanism described in this document. Non-goals include:
No external references: No external references:
Attributes within specific rules cannot refer to external rule Attributes within specific rules cannot refer to external rule
sets, databases, directories or other network elements. Any such sets, databases, directories, or other network elements. Any such
external reference would make simple database implementation external reference would make simple database implementation
difficult and hence they are not supported in this version. difficult and hence they are not supported in this version.
No regular expression: No regular expressions:
Conditions are matched on equality or 'greater-than'-style Conditions are matched on equality or 'greater-than'-style
comparisons, not regular expressions, partial matches such as the comparisons, not regular expressions, partial matches such as the
SQL LIKE operator (e.g., LIKE "%foo%") or glob-style matches SQL LIKE operator (e.g., LIKE "%foo%"), or glob-style matches
("*@example.com"). Most of these are better expressed as explicit ("*@example.com"). Most of these are better expressed as explicit
elements. elements.
No repeat times: No repeat times:
Repeat times (e.g., every day from 9am to 4pm) are difficult to Repeat times (e.g., every day from 9am to 4pm) are difficult to
make work correctly, due to the different time zones that PT, WR, make work correctly, due to the different time zones that PT, WR,
PS and RM may occupy. It appears that suggestions for including PS, and RM may occupy. It appears that suggestions for including
time intervals are often based on supporting work/non-work time intervals are often based on supporting work/non-work
distinctions, which unfortunately are difficult to capture by time distinctions, which unfortunately are difficult to capture by time
alone. Note that this feature must not be confused with the alone. Note that this feature must not be confused with the
'Validity' element that provides a mechanism to restrict the 'Validity' element that provides a mechanism to restrict the
lifetime of a rule. lifetime of a rule.
6. Basic Data Model and Processing 6. Basic Data Model and Processing
A rule set (or synonymously, a policy) consists of zero or more A rule set (or synonymously, a policy) consists of zero or more
rules. The ordering of these rules is irrelevant. The rule set can rules. The ordering of these rules is irrelevant. The rule set can
be stored at the PS and conveyed from RM to PS as a single document, be stored at the PS and conveyed from RM to PS as a single document,
in subsets or as individual rules. A rule consists of three parts - in subsets or as individual rules. A rule consists of three parts:
conditions (see Section 7), actions (see Section 8), and conditions (see Section 7), actions (see Section 8), and
transformations (see Section 9). transformations (see Section 9).
The conditions part is a set of expressions, each of which evaluates The conditions part is a set of expressions, each of which evaluates
to either TRUE or FALSE, i.e. each of which is equipped with a value to either TRUE or FALSE. When a WR asks for information about a PT,
of either TRUE or FALSE by the PS. When a WR asks for information the PS goes through each rule in the rule set. For each rule, it
about a PT, the PS goes through each rule in the rule set. For each evaluates the expressions in the conditions part. If all of the
rule, it evaluates the expressions in the conditions part. If all of expressions evaluate to TRUE, then the rule is applicable to this
the expressions evaluate to TRUE, then the rule is applicable to this
request. Generally, each expression specifies a condition based on request. Generally, each expression specifies a condition based on
some variable that is associated with the context of the request. some variable that is associated with the context of the request.
These variables can include the identity of the WR, the domain of the These variables can include the identity of the WR, the domain of the
WR, the time of day, or even external variables, such as the WR, the time of day, or even external variables, such as the
temperature or the mood of the PT. temperature or the mood of the PT.
Assuming that the rule is applicable to the request, the actions and Assuming that the rule is applicable to the request, the actions and
transformations (commonly referred to as permissions) in the rule transformations (commonly referred to as permissions) in the rule
specify how the PS is supposed to handle this request. If the specify how the PS is supposed to handle this request. If the
request is to view the location of the PT, or to view its presence, request is to view the location of the PT, or to view its presence,
the typical action is "permit", which allows the request to proceed. the typical action is "permit", which allows the request to proceed.
Assuming the action allows the request to proceed, the Assuming the action allows the request to proceed, the
transformations part of the rule specifies how the information about transformations part of the rule specifies how the information about
the PT - their location information, their presence, etc. - is the PT -- their location information, their presence, etc. -- is
modified before being presented to the WR. These transformations are modified before being presented to the WR. These transformations are
in the form of positive permissions. That is, they always specify a in the form of positive permissions. That is, they always specify a
piece of information which is allowed to be seen by the WR. When a piece of information that is allowed to be seen by the WR. When a PS
PS processes a request, it takes the transformations specified across processes a request, it takes the transformations specified across
all rules that match, and creates the union of them. For computing all rules that match, and creates the union of them. For computing
this union the data type, such as Integer, Boolean, Set, or the Undef this union, the data type, such as Integer, Boolean, Set, or the
data type, plays a role. The details of the algorithm for combining Undef data type, plays a role. The details of the algorithm for
permissions is described in Section 10. The resulting union combining permissions is described in Section 10. The resulting
effectively represents a "mask" - it defines what information is union effectively represents a "mask" -- it defines what information
exposed to the WR. This mask is applied to the actual location or is exposed to the WR. This mask is applied to the actual location or
presence data for the PT, and the data which is permitted by the mask presence data for the PT, and the data that is permitted by the mask
is shown to the WR. If the WR request a subset of information only is shown to the WR. If the WR requests a subset of information only
(such as city-level civil location data only, instead of the full (such as city-level civic location data only, instead of the full
civil location information), the information delivered to the WR MUST civic location information), the information delivered to the WR MUST
be the intersection of the permissions granted to the WR and the data be the intersection of the permissions granted to the WR and the data
requested by the WR. requested by the WR.
In accordance to this document, rules are encoded in XML. To this Rules are encoded in XML. To this end, Section 13 contains an XML
end, Section 13 contains an XML schema defining the Common Policy schema defining the Common Policy Markup Language. This, however, is
Markup Language. This, however, is purely an exchange format between purely an exchange format between RM and PS. The format does not
RM and PS. The format does not imply that the RM or the PS use this imply that the RM or the PS use this format internally, e.g., in
format internally, e.g., in matching a query with the policy rules. matching a query with the policy rules. The rules are designed so
The rules are designed so that a PS can translate the rules into a that a PS can translate the rules into a relational database table,
relational database table, with each rule represented by one row in with each rule represented by one row in the database. The database
the database. The database representation is by no means mandatory; representation is by no means mandatory; we will use it as a
we will use it as a convenient and widely-understood example of an convenient and widely-understood example of an internal
internal representation. The database model has the advantage that representation. The database model has the advantage that operations
operations on rows have tightly defined meanings. In addition, it on rows have tightly defined meanings. In addition, it appears
appears plausible that larger-scale implementations will employ a plausible that larger-scale implementations will employ a backend
backend database to store and query rules, as they can then benefit database to store and query rules, as they can then benefit from
from existing optimized indexing, access control, scaling and existing optimized indexing, access control, scaling, and integrity
integrity constraint mechanisms. Smaller-scale implementations may constraint mechanisms. Smaller-scale implementations may well choose
well choose different implementations, e.g., a simple traversal of different implementations, e.g., a simple traversal of the set of
the set of rules. rules.
6.1. Identification of Rules 6.1. Identification of Rules
Each rule is equipped with a parameter that identifies the rule. Each rule is equipped with a parameter that identifies the rule.
This rule identifier is an opaque token chosen by the RM. A RM MUST This rule identifier is an opaque token chosen by the RM. A RM MUST
NOT use the same identifier for two rules that are available to the NOT use the same identifier for two rules that are available to the
PS at the same time for a given PT. If more than one RM modifies the PS at the same time for a given PT. If more than one RM modifies the
same rule set then it needs to be ensured that a unique identifier is same rule set, then it needs to be ensured that a unique identifier
chosen for each rule. A RM can accomplish this goal by retrieving is chosen for each rule. A RM can accomplish this goal by retrieving
the already specified ruleset and to choose a new identifier for a the already specified rule set and choosing a new identifier for a
rule that is different from the existing rule set. rule that is different from the existing rule set.
6.2. Extensions 6.2. Extensions
The policy framework defined in this document is meant to be The policy framework defined in this document is meant to be
extensible towards specific application domains. Such an extension extensible towards specific application domains. Such an extension
is accomplished by defining conditions, actions and transformations is accomplished by defining conditions, actions, and transformations
that are specific to the desired application domain. Each extension that are specific to the desired application domain. Each extension
MUST define its own namespace. MUST define its own namespace.
Extensions cannot change the schema defined in this document, and Extensions cannot change the schema defined in this document, and
this schema is not expected to change excepting a revision to this this schema is not expected to change except via revision to this
specification, and that no versioning procedures for this schema or specification. Therefore, no versioning procedures for this schema
namespace are therfore provided. or namespace are provided.
7. Conditions 7. Conditions
The access to data items needs to be matched with the rule set stored The access to data items needs to be matched with the rule set stored
at the PS. Each instance of a request has different attributes at the PS. Each instance of a request has different attributes
(e.g., the identity of the requestor) that are used for (e.g., the identity of the requestor) that are used for
authorization. A rule in a rule set might have a number of authorization. A rule in a rule set might have a number of
conditions that need to be met before executing the remaining parts conditions that need to be met before executing the remaining parts
of a rule (i.e., actions and transformations). Details about rule of a rule (i.e., actions and transformations). Details about rule
matching are described in Section 10. This document specifies only a matching are described in Section 10. This document specifies only a
few conditions (i.e., identity, sphere, and validity). Further few conditions (i.e., identity, sphere, and validity). Further
condition elements can be added via extensions to this document. condition elements can be added via extensions to this document. If
a child element of the <conditions> element is in a namespace that is
not known or not supported, then this child element evaluates to
FALSE.
As noted in Section 5, conditions are matched on equality or "greater As noted in Section 5, conditions are matched on equality or "greater
than" style comparisons, rather than regular expressions. Equality than" style comparisons, rather than regular expressions. Equality
is determined according to the rules for the data type associated is determined according to the rules for the data type associated
with the element in the schema given in Section 13, unless explicit with the element in the schema given in Section 13, unless explicit
comparison steps are included in this document. For xs:anyURI types, comparison steps are included in this document. For xs:anyURI types,
readers may wish to consult [2] for its discussion xs:anyURI, as well readers may wish to consult [2] for its discussion xs:anyURI, as well
as the text in Section 13. as the text in Section 13.
7.1. Identity Condition 7.1. Identity Condition
7.1.1. Overview 7.1.1. Overview
The identity condition restricts matching of a rule either to a The identity condition restricts matching of a rule either to a
single entity or a group of entitites. Only authenticated entities single entity or a group of entities. Only authenticated entities
can be matched; acceptable means of authentication are defined in can be matched; acceptable means of authentication are defined in
protocol-specific documents. If the <identity> element is absent, or protocol-specific documents. If the <identity> element is absent,
it is present but is empty (meaning that there are no child identities are not considered, and thus, other conditions in the rule
elements), identities are not considered, and thus, other conditions apply to any user, authenticated or not.
in the rule apply to any user, authenticated or not.
The <identity> condition is considered TRUE if any of its child The <identity> condition is considered TRUE if any of its child
elements (e.g., the <one/> and the <many/> elements defined in this elements (e.g., the <one/> and the <many/> elements defined in this
document) evaluate to TRUE, i.e., the results of the individual child document) evaluate to TRUE, i.e., the results of the individual child
element are combined using a logical OR. element are combined using a logical OR.
If a child element of <identity> is in a namespace that is not known If a child element of the <identity> element is in a namespace that
or not supported, it can be ignored. is not known or not supported, then this child element evaluates to
FALSE.
7.1.2. Matching One Entity 7.1.2. Matching One Entity
The <one> element matches the authenticated identity (as contained in The <one> element matches the authenticated identity (as contained in
the 'id' attribute) of exactly one entity or user. For the 'id' attribute) of exactly one entity or user. For
considerations regarding the 'id' attribute refer to Section 7.2. considerations regarding the 'id' attribute, refer to Section 7.2.
An example is shown below: An example is shown below:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<rule id="f3g44r1"> <rule id="f3g44r1">
<conditions> <conditions>
<identity> <identity>
<one id="sip:alice@example.com"/> <one id="sip:alice@example.com"/>
skipping to change at page 15, line 23 skipping to change at page 11, line 31
<one id="mailto:bob@example.net" /> <one id="mailto:bob@example.net" />
</identity> </identity>
</conditions> </conditions>
<actions/> <actions/>
<transformations/> <transformations/>
</rule> </rule>
</ruleset> </ruleset>
This example matches if the authenticated identity of the WR is This example matches if the authenticated identity of the WR is
either sip:alice@example.com, tel:+1-212-555-1234 or either sip:alice@example.com, tel:+1-212-555-1234, or
mailto:bob@example.net. mailto:bob@example.net.
7.1.3. Matching Multiple Entities 7.1.3. Matching Multiple Entities
The <many> element is a mechanism to perform authorization decisions The <many> element is a mechanism to perform authorization decisions
based on the domain part of the authenticated identity. As such, it based on the domain part of the authenticated identity. As such, it
allows to match a large and possibly unknown number of users within a allows matching a large and possibly unknown number of users within a
domain. domain.
Furthermore, it is possible to include one or multiple <except> Furthermore, it is possible to include one or multiple <except>
elements to exclude either individual users or users belonging to a elements to exclude either individual users or users belonging to a
specific domain. Excluding individual entities is implemented using specific domain. Excluding individual entities is implemented using
a <except id="..."/> statement. The semantic of the 'id' attribute a <except id="..."/> statement. The semantic of the 'id' attribute
of the <except> element has the same meaning as the 'id' attribute of of the <except> element has the same meaning as the 'id' attribute of
the <one> element (see Section 7.2). Excluding users belonging to a the <one> element (see Section 7.2). Excluding users belonging to a
specific domain is implemented using the <except domain="..."/> specific domain is implemented using the <except domain="..."/>
element that excludes any user from the indicated domain. element that excludes any user from the indicated domain.
If multiple <except> elements are listed as child elements of the If multiple <except> elements are listed as child elements of the
<many> element then the result of each <except> element is combined <many> element, then the result of each <except> element is combined
using a logical OR. using a logical OR.
Common policy MUST either use UTF-8 or UTF-16 to store domain names Common policy MUST either use UTF-8 or UTF-16 to store domain names
in the 'domain' attribute. For non-IDNs, lower-case ASCII SHOULD be in the 'domain' attribute. For non-IDNs (Internationalized Domain
used. For the comparison operation between the value stored in the Names), lowercase ASCII SHOULD be used. For the comparison operation
'domain' attribute and the domain value provided via the using between the value stored in the 'domain' attribute and the domain
protocol (referred as "protocol domain identifier") the following value provided via the using protocol (referred to as "protocol
rules are applicable: domain identifier"), the following rules are applicable:
1. Translate percent-encoding for either string. 1. Translate percent-encoding for either string.
2. Convert both domain strings using the toASCII operation described 2. Convert both domain strings using the ToASCII operation described
in RFC 3490 [3]. in RFC 3490 [3].
3. Compare the two domain strings for ASCII equality, for each 3. Compare the two domain strings for ASCII equality, for each
label. If the string comparison for each label indicates label. If the string comparison for each label indicates
equality, the comparison succeeds. Otherwise, the domains are equality, the comparison succeeds. Otherwise, the domains are
not equal. not equal.
If the conversion fails in step (2), the domains are not equal. If the conversion fails in step (2), the domains are not equal.
7.1.3.1. Matching Any Authenticated Identity 7.1.3.1. Matching Any Authenticated Identity
skipping to change at page 16, line 40 skipping to change at page 13, line 5
<identity> <identity>
<many/> <many/>
</identity> </identity>
</conditions> </conditions>
<actions/> <actions/>
<transformations/> <transformations/>
</rule> </rule>
</ruleset> </ruleset>
The following rule, in comparison, would match any user, 7.1.3.2. Matching Any Authenticated Identity Except Enumerated
authenticated and unauthenticated:
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<rule id="f3g44r5">
<conditions>
<identity/>
</conditions>
<actions/>
<transformations/>
</rule>
</ruleset>
7.1.3.2. Matching Any Authenticated Identity Excepting Enumerated
Domains/Identities Domains/Identities
The <many> element enclosing one or more <except domain="..."/> The <many> element enclosing one or more <except domain="..."/>
elements matches any user from any domain except those enumerated. elements matches any user from any domain except those enumerated.
The <except id="..."/> element excludes particular users. The The <except id="..."/> element excludes particular users. The
semantic of the 'id' attribute of the <except> element is described semantics of the 'id' attribute of the <except> element is described
in Section 7.2. The results of the child elements of the <many> in Section 7.2. The results of the child elements of the <many>
element are combined using a logical OR. element are combined using a logical OR.
An example is shown below: An example is shown below:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<rule id="f3g44r1"> <rule id="f3g44r1">
<conditions> <conditions>
skipping to change at page 18, line 34 skipping to change at page 13, line 46
</validity> </validity>
</conditions> </conditions>
<actions/> <actions/>
<transformations/> <transformations/>
</rule> </rule>
</ruleset> </ruleset>
This example matches all users except any user in example.com, or any This example matches all users except any user in example.com, or any
user in example.org or the particular users alice@bad.example.net, user in example.org or the particular users alice@bad.example.net,
bob@good.example.net and the user with the telephone number bob@good.example.net, and the user with the telephone number
'tel:+1-212-555-1234'. The last 'except' element is redundant since 'tel:+1-212-555-1234'. The last 'except' element is redundant since
alice@example.com is already excluded through the first line. alice@example.com is already excluded through the first line.
7.1.3.3. Matching Any Authenticated Identity Within a Domain Excepting 7.1.3.3. Matching Any Authenticated Identity within a Domain Except
Enumerated Identities Enumerated Identities
The <many> element with a 'domain' attribute and zero or more <except The <many> element with a 'domain' attribute and zero or more <except
id="..."/> elements matches any authenticated user from the indicated id="..."/> elements matches any authenticated user from the indicated
domain except those explicitly enumerated. The semantic of the 'id' domain except those explicitly enumerated. The semantics of the 'id'
attribute of the <except> element is described in Section 7.2. attribute of the <except> element is described in Section 7.2.
It is nonsensical to have domains in the 'id' attribute that do not It is nonsensical to have domains in the 'id' attribute that do not
match the value of the 'domain' attribute in the enclosing <many> match the value of the 'domain' attribute in the enclosing <many>
element. element.
An example is shown below: An example is shown below:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
skipping to change at page 19, line 24 skipping to change at page 14, line 38
</many> </many>
</identity> </identity>
</conditions> </conditions>
<actions/> <actions/>
<transformations/> <transformations/>
</rule> </rule>
</ruleset> </ruleset>
This example matches any user within example.com (such as This example matches any user within example.com (such as
carol@example.com) except alice@example and bob@example.com. carol@example.com) except alice@example.com and bob@example.com.
7.2. Single Entity 7.2. Single Entity
The 'id' attribute used in the <one> and in the <except> element The 'id' attribute used in the <one> and in the <except> element
refers to a single entity. In the subsequent text we use the term refers to a single entity. In the subsequent text, we use the term
'single-user' entity as a placeholder for the <one> and the <except> 'single-user entity' as a placeholder for the <one> and the <except>
element. The <except> element fulfills the purpose of excluding element. The <except> element fulfills the purpose of excluding
elements from the solution set. elements from the solution set.
A single-user entity matches the authenticated identity (as contained A single-user entity matches the authenticated identity (as contained
in the 'id' attribute) of exactly one entity or user. If there is a in the 'id' attribute) of exactly one entity or user. If there is a
match, the single-user entity is considered TRUE. The single- user match, the single-user entity is considered TRUE. The single- user
entity MUST NOT contain a 'domain' attribute. entity MUST NOT contain a 'domain' attribute.
The 'id' attribute contains an identity that MUST first be expressed The 'id' attribute contains an identity that MUST first be expressed
as a URI. Applications using this framework must describe how the as a URI. Applications using this framework must describe how the
identities they are using can be expressed as a URIs. identities they are using can be expressed as URIs.
7.3. Sphere 7.3. Sphere
The <sphere> element belongs to the group of condition elements. It The <sphere> element belongs to the group of condition elements. It
can be used to indicate a state (e.g., 'work', 'home', 'meeting', can be used to indicate a state (e.g., 'work', 'home', 'meeting',
'travel') the PT is currently in. A sphere condition matches only if 'travel') the PT is currently in. A sphere condition matches only if
the PT is currently in the state indicated. The state may be the PT is currently in the state indicated. The state may be
conveyed by manual configuration or by some protocol. For example, conveyed by manual configuration or by some protocol. For example,
RPID [10] provides the ability to inform the PS of its current RPID [10] provides the ability to inform the PS of its current
sphere. The application domain needs to describe in more detail how sphere. The application domain needs to describe in more detail how
the sphere state is determined. Switching from one sphere to another the sphere state is determined. Switching from one sphere to another
causes a switch between different modes of visibility. As a result causes a switch between different modes of visibility. As a result,
different subsets of rules might be applicable. different subsets of rules might be applicable.
The content of the 'value' attribute of the <sphere> element MAY The content of the 'value' attribute of the <sphere> element MAY
contain more than one token. The individual tokens MUST be separated contain more than one token. The individual tokens MUST be separated
by a blank character. A logical OR is used for the matching the by a blank character. A logical OR is used for the matching the
tokens against the sphere settings of the PT. As an example, if the tokens against the sphere settings of the PT. As an example, if the
the content of the 'value' attribute in the sphere attribute contains content of the 'value' attribute in the sphere attribute contains two
two tokens 'work' and 'home' then this part of the rule matches if tokens 'work' and 'home' then this part of the rule matches if the
the sphere for a particular PT is either 'work' OR 'home'. To sphere for a particular PT is either 'work' OR 'home'. To compare
compare the content of the 'value' attribute in the <sphere> element the content of the 'value' attribute in the <sphere> element with the
with the stored state information about the PT's sphere setting a stored state information about the PT's sphere setting a
case insensitive string comparison MUST be used for each individual case-insensitive string comparison MUST be used for each individual
token. There is no registry for these values nor a language specific token. There is neither a registry for these values nor a language-
indication of the sphere content. As such, the tokens are treated as specific indication of the sphere content. As such, the tokens are
opaque strings. treated as opaque strings.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<rule id="f3g44r2"> <rule id="f3g44r2">
<conditions> <conditions>
<sphere value="work"/> <sphere value="work"/>
<identity> <identity>
<one id="sip:andrew@example.com"/> <one id="sip:andrew@example.com"/>
</identity> </identity>
skipping to change at page 21, line 44 skipping to change at page 16, line 29
</identity> </identity>
<sphere value="home work"/> <sphere value="home work"/>
</conditions> </conditions>
<actions/> <actions/>
<transformations/> <transformations/>
</rule> </rule>
</ruleset> </ruleset>
The rule example above illustrates that the rule with the entity The rule example above illustrates that the rule with the entity
andrew@example.com matches if the sphere is been set to 'work'. In andrew@example.com matches if the sphere is been set to 'work'. In
the second rule with the entity allison@example.com matches if the the second rule, the entity allison@example.com matches if the sphere
sphere is set to 'home'. The third rule also matches since the the is set to 'home'. The third rule also matches since the value in the
value in the sphere element also contains the token 'home'. sphere element also contains the token 'home'.
7.4. Validity 7.4. Validity
The <validity> element is the third condition element specified in The <validity> element is the third condition element specified in
this document. It expresses the rule validity period by two this document. It expresses the rule validity period by two
attributes, a starting and a ending time. The validity condition is attributes, a starting and an ending time. The validity condition is
TRUE if the current time is greater than or equal to at least one TRUE if the current time is greater than or equal to at least one
<from> child, but less than the <until> child after it. This <from> child, but less than the <until> child after it. This
represents a logical OR operation across each <from> and <until> represents a logical OR operation across each <from> and <until>
pair. Times are expressed in XML dateTime format. A rule maker pair. Times are expressed in XML dateTime format. A rule maker
might not have always access to the PS to invalidate some rules which might not always have access to the PS to invalidate some rules that
grant permissions. Hence this mechanism allows to invalidate granted grant permissions. Hence, this mechanism allows invalidating granted
permissions automatically without further interaction between the permissions automatically without further interaction between the
rule maker and the PS. The PS does not remove the rules instead the rule maker and the PS. The PS does not remove the rules; instead the
rule maker has to clean them up. rule maker has to clean them up.
An example of a rule fragment is shown below: An example of a rule fragment is shown below:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<rule id="f3g44r3"> <rule id="f3g44r3">
<conditions> <conditions>
<validity> <validity>
skipping to change at page 23, line 8 skipping to change at page 17, line 32
The <validity> element MUST have the <from> and <until> subelements The <validity> element MUST have the <from> and <until> subelements
in pairs. Multiple <from> and <until> elements might appear in pairs in pairs. Multiple <from> and <until> elements might appear in pairs
(i.e., without nesting of <from> and <until> elements). Using (i.e., without nesting of <from> and <until> elements). Using
multiple <validity> elements as subelements of the <conditions> multiple <validity> elements as subelements of the <conditions>
element is not useful since all subelements of the <conditions> element is not useful since all subelements of the <conditions>
element are combined as a logical AND. element are combined as a logical AND.
8. Actions 8. Actions
While conditions are the 'if'-part of rules, actions and While conditions are the 'if'-part of rules, actions and
transformations build the 'then'-part of them. The actions and transformations form their 'then'-part. The actions and
transformations parts of a rule determine which operations the PS transformations parts of a rule determine which operations the PS
MUST execute after having received from a WR a data access request MUST execute after having received from a WR a data access request
that matches all conditions of this rule. Actions and that matches all conditions of this rule. Actions and
transformations only permit certain operations; there is no 'deny' transformations only permit certain operations; there is no 'deny'
functionality. Transformations exclusively specify PS-side functionality. Transformations exclusively specify PS-side
operations that lead to a modification of the data items requested by operations that lead to a modification of the data items requested by
the WR. Regarding location data items, for instance, a the WR. Regarding location data items, for instance, a
transformation could force the PS to lower the precision of the transformation could force the PS to lower the precision of the
location information which is returned to the WR. location information that is returned to the WR.
Actions, on the other hand, specify all remaining types of operations Actions, on the other hand, specify all remaining types of operations
the PS is obliged to execute, i.e., all operations that are not of the PS is obliged to execute, i.e., all operations that are not of
transformation type. Actions are defined by application specific transformation type. Actions are defined by application-specific
usages of this framework. The reader is referred to the usages of this framework. The reader is referred to the
corresponding extensions to see examples of such elements. corresponding extensions to see examples of such elements.
9. Transformations 9. Transformations
Two sub-parts follow the conditions part of a rule: transformations Two sub-parts follow the conditions part of a rule: transformations
and actions. As defined in Section 8, transformations specify and actions. As defined in Section 8, transformations specify
operations that the PS MUST execute and that modify the result which operations that the PS MUST execute and that modify the result that
is returned to the WR. This functionality is particularly helpful in is returned to the WR. This functionality is particularly helpful in
reducing the granularity of information provided to the WR, as for reducing the granularity of information provided to the WR, as, for
example required for location privacy. Transformations are defined example, required for location privacy. Transformations are defined
by application specific usages of this framework. by application-specific usages of this framework.
A simple transformation example is provided in Section 10. A simple transformation example is provided in Section 10.
10. Procedure for Combining Permissions 10. Procedure for Combining Permissions
10.1. Introduction 10.1. Introduction
This section describes the mechanism to evaluate the final result of This section describes how rules are selected and how actions and
a rule evaluation. The result is reflected in the action and permissions are determined. When a PS receives a request for access
transformation part of a rule. This procedure is sometimes referred to privacy-sensitive data, the request is matched against the rule
as conflict resolution. set. A rule matches if all conditions contained as child elements in
the <conditions> element of a rule evaluate to TRUE. Each type of
We use the following terminology (which in parts has already been condition defines when it is TRUE. All rules where the conditions
introduced in previous sections): The term 'permission' stands for an match the request form the matching rule set. The permissions in the
action or a transformation. The notion 'attribute' terms a matching rule set are combined using a set of combining rules (CRs)
condition, an action, or a transformation. An attribute has a name, described in Section 10.2.
and a certain data type. A value may be assigned to an attribute or
it may be undefined, in case it does not have a value associated with
the attribute. For example, the name of the <sphere> attribute
discussed in Section 7 is 'sphere', its data type is 'string', and
its value may be set to 'home'. To evaluate a condition means to
associate either TRUE or FALSE to the condition. Please note that
the <identity> element is a condition whereas the <id> element is a
parameter of that condition. A rule matches if all conditions
contained in the conditions part of a rule evaluate to TRUE.
When the PS receives a request for access to privacy-sensitive data
then it needs to be matched against a rule set. The conditions part
of each individual rule is evaluated and as a result one or more
rules might match. If only a single rule matches then the result is
determined by executing the actions and the transformations part
following the conditions part of a rule. However, it can also be the
case that two or more matching rules contain a permission of the same
name (e.g., two rules contain a permission named 'precision of
geospatial location information'), but do not specify the same value
for that permission (e.g., the two rule might specify values of '10
km' and '200 km', respectively, for the permission named 'precision
of geospatial location information'). This section describes the
procedure for combining permissions in such cases.
10.2. Algorithm
The combining rules are simple and depend on the data types of the
values of permissions: Let P be a policy. Let M be the subset of P
consisting of rules r in P that match with respect to a given
request. Let n be a name of a permission contained in a rule r in M,
and let M(n) be the subset of M consisting of rules r in M that have
a permission of name n. For each rule r in M(n), let v(r,n) and
d(r,n) be the value and the data type, respectively, of the attribute
of r with name n. Finally, let V(n) be the combined value of all the
permissions values v(r,n), r in M(n). The combining rules that lead
to the resulting value V(n) are the following:
CR 1: If d(r,n)=Boolean for all r in M(n), then V(n) is given as
follows: If there is a r in M(n) with v(r,n)=TRUE, then V(n)=TRUE.
Otherwise, V(n)=FALSE.
CR 2: If d(r,n)=Integer for all r in M(n), then V(n) is given as
follows: If v(r,n)=undefined for all r in M(n), then V(n) is not
specified by this specification. Otherwise, V(n)=max{v(r,n) | r
in M(n)}.
CR 3: If d(r,n)=Set for all r in M(n), then V(n) is given as 10.2. Combining Rules (CRs)
follows: V(n)=union of all v(r,n), the union to be computed over all
r in M(n) with v(r,n)!=undefined.
The combining operation will result in the largest value for an Each type of permission is combined across all matching rules. Each
Integral type, the OR operation for boolean, and union for set. type of action or transformation is combined separately and
independently. The combining rules generate a combined permission.
The combining rules depend only on the data type of permission. If a
particular permission type has no value in a rule, it assumes the
lowest possible value for that permission for the purpose of
computing the combined permission. That value is given by the data
type for booleans (FALSE) and sets (empty set), and MUST be defined
by any extension to the Common Policy for other data types.
As a result, applications should define values such that, for For boolean permissions, the resulting permission is TRUE if and only
integers, the lowest value corresponds to the most privacy, for if at least one permission in the matching rule set has a value of
booleans, false corresponds to the most privacy, and for sets, the TRUE and FALSE otherwise. For integer, real-valued and date-time
empty set corresponds to the most privacy. permissions, the resulting permission is the maximum value across the
permission values in the matching set of rules. For sets, it is the
union of values across the permissions in the matching rule set.
10.3. Example 10.3. Example
In the following example we illustrate the process of combining In the following example we illustrate the process of combining
permissions. We will consider three conditions for our purpose, permissions. We will consider three conditions for our purpose,
namely those of name identity, sphere, and validity. For editorial namely those of name identity (WR-ID), sphere, and validity
reasons the rule set in this example is represented in a table. (from,until). The ID column is used as a rule identifier. For
Furthermore, the domain part of the identity of the WR is omitted. editorial reasons we omit the domain part of the WR's identity.
For actions we use two permissions with names X and Y. The values of
X and Y are of data types Boolean and Integer, respectively. We use two actions in our example, namely X and Y. The values of X
Permission X might, for example, represent the <sub-handling> action. and Y are of data types Boolean and Integer, respectively.
For transformations we use the attribute with the name Z whose value
can be set either to '+'(or 1), 'o' (or 2) or '-' (or 3). Permission The transformation, referred to as Z, uses values that can be set
Z allows us to show the granularity reduction whereby a value of '+' either to '+' (or 3), 'o' (or 2) or '-' (or 1). Permission Z allows
shows the corresponding information unrestricted and '-' shows us to show the granularity reduction whereby a value of '+' shows the
nothing. This permission might be related to location information or corresponding information unrestricted, and '-' shows nothing. This
other presence attributes like mood. Internally we use the data type permission might be related to location information or other presence
Integer for computing the permission of this attribute. attributes like mood. Internally, we use the data type Integer for
computing the permission of this attribute.
The label 'NULL' in the table indicates that no value is available
for a particular cell.
Conditions Actions/Transformations Conditions Actions/Transformations
+---------------------------------+---------------------+ +---------------------------------+---------------------+
| Id WR-ID sphere from until | X Y Z | | Id WR-ID sphere from until | X Y Z |
+---------------------------------+---------------------+ +---------------------------------+---------------------+
| 1 bob home A1 A2 | TRUE 10 o | | 1 bob home A1 A2 | TRUE 10 o |
| 2 alice work A1 A2 | FALSE 5 + | | 2 alice work A1 A2 | FALSE 5 + |
| 3 bob work A1 A2 | TRUE 3 - | | 3 bob work A1 A2 | TRUE 3 - |
| 4 tom work A1 A2 | TRUE 5 + | | 4 tom work A1 A2 | TRUE 5 + |
| 5 bob work A1 A3 | undef 12 o | | 5 bob work A1 A3 | NULL 12 o |
| 6 bob work B1 B2 | FALSE 10 - | | 6 bob work B1 B2 | FALSE 10 - |
+---------------------------------+---------------------+ +---------------------------------+---------------------+
Again for editorial reasons, we use the following abbreviations for Again for editorial reasons, we use the following abbreviations for
the two <validity> attributes 'from' and 'until': the two <validity> attributes 'from' and 'until':
A1=2003-12-24T17:00:00+01:00 A1=2003-12-24T17:00:00+01:00
A2=2003-12-24T21:00:00+01:00 A2=2003-12-24T21:00:00+01:00
A3=2003-12-24T23:30:00+01:00 A3=2003-12-24T23:30:00+01:00
B1=2003-12-22T17:00:00+01:00 B1=2003-12-22T17:00:00+01:00
B2=2003-12-23T17:00:00+01:00 B2=2003-12-23T17:00:00+01:00
Note that B1 < B2 < A1 < A2 < A3. Note that B1 < B2 < A1 < A2 < A3.
The entity 'bob' acts as a WR and requests data items. The policy P The entity 'bob' acts as a WR and requests data items. The rule set
consists of the six rules shown in the table and identified by the consists of the six rules shown in the table and identified by the
values 1 to 6 in the 'Id' column. The PS receives the query at 2003- values 1 to 6 in the 'Id' column. The PS receives the query at
12-24T17:15:00+01:00 which falls between A1 and A2. The value of the 2003-12-24T17:15:00+01:00, which falls between A1 and A2. In our
attribute with name 'sphere' indicating the state the PT is currently example, we assume that the sphere value of the PT is currently set
in is set to 'work'. to 'work'.
As a first step, it is necessary to determine which rules fire by
evaluating the conditions part of each of them.
Rule 1 does not match since the sphere condition does not match. Rule 1 does not match since the sphere condition does not match.
Rule 2 does not match as the identity of the WR (here 'alice') does Rule 2 does not match as the identity of the WR (here 'alice') does
not equal 'bob'. Rule 3 matches since all conditions evaluate to not equal 'bob'. Rule 3 matches since all conditions evaluate to
TRUE. Rule 4 does not match as the identity of the WR (here 'tom') TRUE. Rule 4 does not match as the identity of the WR (here 'tom')
does not equal 'bob'. Rule 5 matches. Rule 6 does not match since does not equal 'bob'. Rule 5 matches. Rule 6 does not match since
the rule is not valid anymore. Therefore, the set M of matching the rule is not valid anymore.
rules consists of the rules 3 and 5. These two rules are used to
compute the combined permission V(X), V(Y), and V(Z) for each of the Only rules 3 and 5 fire. We use the actions and transformations part
permissions X, Y, and Z: of these two rules to determine the combined permission, as shown
below.
Actions/Transformations Actions/Transformations
+-----+-----------------------+ +-----+-----------------------+
| Id | X Y Z | | Id | X Y Z |
+-----+-----------------------+ +-----+-----------------------+
| 3 | TRUE 3 - | | 3 | TRUE 3 - |
| 5 | undef 12 o | | 5 | NULL 12 o |
+-----+-----------------------+ +-----+-----------------------+
The results of the permission combining algorithm is shown below. Each column is treated independently. The combined value of X is set
The combined value V(X) regarding the permission with name X equals to TRUE since the NULL value equals FALSE according to the
TRUE according to the first combining rule listed above. The maximum description in Section 10.2. For the column with the name Y, we
of 3 and 12 is 12, so that V(Y)=12. For the attribute Z in this apply the maximum of 3 and 12, so that the combined value of Y is 12.
example the maximum between 'o' and '-' (i.e., between 2 and 3) is For column Z, we again compute the maximum of 'o' and '-' (i.e., 2
'-'. and 1) which is 'o' (2).
The combined permission for all three columns is therefore:
Actions/Transformations Actions/Transformations
+-----+-----------------------+ +-----------------------+
| Id | X Y Z | | X Y Z |
+-----+-----------------------+ +-----------------------+
| 5 | TRUE 12 - | | TRUE 12 o |
+-----+-----------------------+ +-----------------------+
11. Meta Policies 11. Meta Policies
Meta policies authorize a rulemaker to insert, update or delete a Meta policies authorize a rule maker to insert, update, or delete a
particular rule or an entire rule set. Some authorization policies particular rule or an entire rule set. Some authorization policies
are required to prevent unauthorized modification of rule sets. Meta are required to prevent unauthorized modification of rule sets. Meta
policies are outside the scope of this document. policies are outside the scope of this document.
A simple implementation could restrict access to the rule set only to A simple implementation could restrict access to the rule set only to
the PT but more sophisticated mechanisms could be useful. As an the PT but more sophisticated mechanisms could be useful. As an
example of such policies one could think of parents configuring the example of such policies, one could think of parents configuring the
policies for their children. policies for their children.
12. Example 12. Example
This section gives an example of an XML document valid with respect This section gives an example of an XML document valid with respect
to the XML schema defined in Section 13. Semantically richer to the XML schema defined in Section 13. Semantically richer
examples can be found in documents which extend this schema with examples can be found in documents that extend this schema with
application domain specific data (e.g., location or presence application-domain-specific data (e.g., location or presence
information). information).
Below a rule is shown with a condition that matches for a given Below a rule is shown with a condition that matches for a given
authenticated identity (bob@example.com) and within a given time authenticated identity (bob@example.com) and within a given time
period. Additionally, the rule matches only if the target has set period. Additionally, the rule matches only if the target has set
its sphere to 'work'. its sphere to 'work'.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
skipping to change at page 32, line 17 skipping to change at page 23, line 16
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:choice> </xs:choice>
</xs:restriction> </xs:restriction>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- //conditions/identity --> <!-- //conditions/identity -->
<xs:complexType name="identityType"> <xs:complexType name="identityType">
<xs:complexContent> <xs:complexContent>
<xs:restriction base="xs:anyType"> <xs:restriction base="xs:anyType">
<xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:choice minOccurs="1" maxOccurs="unbounded">
<xs:element name="one" type="cp:oneType"/> <xs:element name="one" type="cp:oneType"/>
<xs:element name="many" type="cp:manyType"/> <xs:element name="many" type="cp:manyType"/>
<xs:any namespace="##other" processContents="lax"/> <xs:any namespace="##other" processContents="lax"/>
</xs:choice> </xs:choice>
</xs:restriction> </xs:restriction>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- //identity/one --> <!-- //identity/one -->
<xs:complexType name="oneType"> <xs:complexType name="oneType">
<xs:complexContent> <xs:complexContent>
skipping to change at page 33, line 22 skipping to change at page 24, line 21
<xs:restriction base="xs:anyType"> <xs:restriction base="xs:anyType">
<xs:attribute name="value" <xs:attribute name="value"
type="xs:string" use="required"/> type="xs:string" use="required"/>
</xs:restriction> </xs:restriction>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- //conditions/validity --> <!-- //conditions/validity -->
<xs:complexType name="validityType"> <xs:complexType name="validityType">
<xs:complexContent> <xs:complexContent>
<xs:restriction base="xs:anyType"> <xs:restriction base="xs:anyType">
<xs:sequence minOccurs="0" maxOccurs="unbounded"> <xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="from" type="xs:dateTime"/> <xs:element name="from" type="xs:dateTime"/>
<xs:element name="until" type="xs:dateTime"/> <xs:element name="until" type="xs:dateTime"/>
</xs:sequence> </xs:sequence>
</xs:restriction> </xs:restriction>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- //rule/actions or //rule/transformations --> <!-- //rule/actions or //rule/transformations -->
<xs:complexType name="extensibleType"> <xs:complexType name="extensibleType">
<xs:complexContent> <xs:complexContent>
<xs:restriction base="xs:anyType"> <xs:restriction base="xs:anyType">
<xs:sequence> <xs:sequence>
<xs:any namespace="##other" <xs:any namespace="##other" processContents="lax"
processContents="lax" minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:restriction> </xs:restriction>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
</xs:schema> </xs:schema>
14. Security Considerations 14. Security Considerations
This document describes a framework for policies. This framework is This document describes a framework for policies. This framework is
intended to be enhanced elsewhere towards application domain specific intended to be enhanced elsewhere by application-domain-specific
data. Security considerations are to a great extent application data data. Security considerations are to a great extent application-data
dependent, and therefore need to be covered by documents that extend dependent, and therefore need to be covered by documents that extend
the framework defined in this specification. However, new action and the framework defined in this specification. However, new action and
transformation permissions along with their allowed values must be transformation permissions along with their allowed values must be
defined in a way so that the usage of the permissions combining rules defined in a way so that the usage of the permissions combining rules
of Section 10 does not lower the level of privacy protection. See of Section 10 does not lower the level of privacy protection. See
Section 10 for more details on this privacy issue. Section 10 for more details on this privacy issue.
15. IANA Considerations 15. IANA Considerations
This section registers a new XML namespace, a new XML schema and a This section registers a new XML namespace, a new XML schema, and a
new MIME-type. This section registers a new XML namespace per the new MIME type. This section registers a new XML namespace per the
procedures in [4]. procedures in [4].
15.1. Common Policy Namespace Registration 15.1. Common Policy Namespace Registration
URI: urn:ietf:params:xml:ns:common-policy URI: urn:ietf:params:xml:ns:common-policy
Registrant Contact: IETF Geopriv Working Group, Henning Schulzrinne Registrant Contact: IETF GEOPRIV working group, Henning Schulzrinne
(hgs+geopriv@cs.columbia.edu). (hgs+geopriv@cs.columbia.edu).
XML: XML:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"> <html xmlns="http://www.w3.org/1999/xhtml">
<head> <head>
<meta http-equiv="content-type" <meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/> content="text/html;charset=iso-8859-1"/>
<title>Common Policy Namespace</title> <title>Common Policy Namespace</title>
</head> </head>
<body> <body>
<h1>Namespace for Common Authorization Policies</h1> <h1>Namespace for Common Authorization Policies</h1>
<h2>urn:ietf:params:xml:ns:common-policy</h2> <h2>urn:ietf:params:xml:ns:common-policy</h2>
<p>See <a href="[URL of published RFC]">RFCXXXX <p>See <a href="ftp://ftp.rfc-editor.org/in-notes/rfc4745.txt">
[NOTE TO IANA/RFC-EDITOR: RFC 4745</a>.</p>
Please replace XXXX with the RFC number of this
specification.]</a>.</p>
</body> </body>
</html> </html>
END END
15.2. Content-type registration for 'application/auth-policy+xml' 15.2. Content-type Registration for 'application/auth-policy+xml'
This specification requests the registration of a new MIME type This specification requests the registration of a new MIME type
according to the procedures of RFC 4288 [5] and guidelines in RFC according to the procedures of RFC 4288 [5] and guidelines in RFC
3023 [6]. 3023 [6].
MIME media type name: application MIME media type name: application
MIME subtype name: auth-policy+xml MIME subtype name: auth-policy+xml
Mandatory parameters: none Mandatory parameters: none
Optional parameters: charset Optional parameters: charset
Indicates the character encoding of enclosed XML. Indicates the character encoding of enclosed XML.
Encoding considerations: Encoding considerations:
skipping to change at page 36, line 21 skipping to change at page 26, line 30
Encoding considerations: Encoding considerations:
Uses XML, which can employ 8-bit characters, depending on the Uses XML, which can employ 8-bit characters, depending on the
character encoding used. See RFC 3023 [6], Section 3.2. character encoding used. See RFC 3023 [6], Section 3.2.
Security considerations: Security considerations:
This content type is designed to carry authorization policies. This content type is designed to carry authorization policies.
Appropriate precautions should be adopted to limit disclosure of Appropriate precautions should be adopted to limit disclosure of
this information. Please refer to Section 14 of RFCXXXX [NOTE TO this information. Please refer to Section 14 of RFC 4745 and to
IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this the security considerations described in Section 10 of RFC 3023
specification.] and to the security considerations described in [6] for more information.
Section 10 of RFC 3023 [6] for more information.
Interoperability considerations: None Interoperability considerations: None
Published specification: RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please Published specification: RFC 4745
replace XXXX with the RFC number of this specification.] this
document
Applications which use this media type: Applications which use this media type:
Presence- and location-based systems Presence- and location-based systems
Additional information: Additional information:
Magic Number: None Magic Number: None
File Extension: .apxml File Extension: .apxml
Macintosh file type code: 'TEXT' Macintosh file type code: 'TEXT'
Personal and email address for further information: Hannes Personal and email address for further information:
Tschofenig, Hannes.Tschofenig@siemens.com Hannes Tschofenig, Hannes.Tschofenig@siemens.com
Intended usage: LIMITED USE Intended usage: LIMITED USE
Author: Author:
This specification is a work item of the IETF GEOPRIV working This specification is a work item of the IETF GEOPRIV working
group, with mailing list address <geopriv@ietf.org>. group, with mailing list address <geopriv@ietf.org>.
Change controller: Change controller:
The IESG <iesg@ietf.org> The IESG <iesg@ietf.org>
15.3. Common Policy Schema Registration 15.3. Common Policy Schema Registration
URI: urn:ietf:params:xml:schema:common-policy URI: urn:ietf:params:xml:schema:common-policy
Registrant Contact: IETF Geopriv Working Group, Henning Schulzrinne Registrant Contact: IETF GEOPRIV working group, Henning Schulzrinne
(hgs+geopriv@cs.columbia.edu). (hgs+geopriv@cs.columbia.edu).
XML: The XML schema to be registered is contained in Section 13. XML: The XML schema to be registered is contained in Section 13.
Its first line is Its first line is
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
and its last line is and its last line is
</xs:schema> </xs:schema>
16. References 16. References
16.1. Normative References 16.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Duerst, M. and M. Suignard, "Internationalized Resource [2] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, January 2005. Identifiers (IRIs)", RFC 3987, January 2005.
[3] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing [3] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing
Domain Names in Applications (IDNA)", RFC 3490, March 2003. Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[4] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [4] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[5] Freed, N. and J. Klensin, "Media Type Specifications and [5] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005. Registration Procedures", BCP 13, RFC 4288, December 2005.
[6] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", [6] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
RFC 3023, January 2001. RFC 3023, January 2001.
16.2. Informative References 16.2. Informative References
[7] Rosenberg, J., "Presence Authorization Rules", [7] Rosenberg, J., "Presence Authorization Rules", Work in Progress,
draft-ietf-simple-presence-rules-07 (work in progress),
June 2006. June 2006.
[8] Schulzrinne, H., "A Document Format for Expressing Privacy [8] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., and J.
Preferences for Location Information", Polk, "A Document Format for Expressing Privacy Preferences for
draft-ietf-geopriv-policy-08 (work in progress), February 2006. Location Information", Work in Progress, February 2006.
[9] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. [9] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.
Polk, "Geopriv Requirements", RFC 3693, February 2004. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[10] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg, [10] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg,
"RPID: Rich Presence Extensions to the Presence Information "RPID: Rich Presence Extensions to the Presence Information Data
Data Format (PIDF)", RFC 4480, July 2006. Format (PIDF)", RFC 4480, July 2006.
Appendix A. Contributors Appendix A. Contributors
We would like to thank Christian Guenther for his help with initial We would like to thank Christian Guenther for his help with initial
versions of this document. versions of this document.
Appendix B. Acknowledgments Appendix B. Acknowledgments
This document is partially based on the discussions within the IETF This document is partially based on the discussions within the IETF
GEOPRIV working group. Discussions at the Geopriv Interim Meeting GEOPRIV working group. Discussions at the Geopriv Interim Meeting
2003 in Washington, D.C., helped the working group to make progress 2003 in Washington, D.C., helped the working group to make progress
on the authorization policies based on the discussions among the on the authorization policies based on the discussions among the
participants. participants.
We particularly want to thank Allison Mankin <mankin@psg.com>, We particularly want to thank Allison Mankin <mankin@psg.com>,
Randall Gellens <rg+ietf@qualcomm.com>, Andrew Newton Randall Gellens <rg+ietf@qualcomm.com>, Andrew Newton
<anewton@ecotroph.net>, Ted Hardie <hardie@qualcomm.com> and Jon <anewton@ecotroph.net>, Ted Hardie <hardie@qualcomm.com>, and Jon
Peterson <jon.peterson@neustar.biz> for discussing a number of Peterson <jon.peterson@neustar.biz> for discussing a number of
details with us. They helped us to improve the quality of this details with us. They helped us to improve the quality of this
document. Allison, Ted and Andrew also helped us to make good document. Allison, Ted, and Andrew also helped us to make good
progress with the internationalization support of the identifier/ progress with the internationalization support of the identifier/
domain attributes. domain attributes.
Furthermore, we would like to thank the IETF SIMPLE working group for Furthermore, we would like to thank the IETF SIMPLE working group for
their discussions of J. Rosenberg's draft on presence authorization their discussions of J. Rosenberg's draft on presence authorization
policies. We would also like to thank Stefan Berg, Murugaraj policies. We would also like to thank Stefan Berg, Murugaraj
Shanmugam, Christian Schmidt, Martin Thomson, Markus Isomaki, Aki Shanmugam, Christian Schmidt, Martin Thomson, Markus Isomaki, Aki
Niemi, Eva Maria Leppanen and Mark Baker for their comments. Martin Niemi, Eva Maria Leppanen, Josip Matanovic, and Mark Baker for their
Thomson helped us with the XML schema. Mark Baker provided a review comments. Martin Thomson helped us with the XML schema. Mark Baker
of the media type. Scott Brim provided a review on behalf of the provided a review of the media type. Scott Brim provided a review on
General Area Review Team. behalf of the General Area Review Team.
Authors' Addresses Authors' Addresses
Henning Schulzrinne Henning Schulzrinne
Columbia University Columbia University
Department of Computer Science Department of Computer Science
450 Computer Science Building 450 Computer Science Building
New York, NY 10027 New York, NY 10027
USA USA
Phone: +1 212 939 7042 Phone: +1 212 939 7042
Email: schulzrinne@cs.columbia.edu EMail: schulzrinne@cs.columbia.edu
URI: http://www.cs.columbia.edu/~hgs URI: http://www.cs.columbia.edu/~hgs
Hannes Tschofenig Hannes Tschofenig
Siemens Siemens Networks GmbH & Co KG
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bavaria 81739 Munich, Bavaria 81739
Germany Germany
Email: Hannes.Tschofenig@siemens.com EMail: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.com URI: http://www.tschofenig.com
John B. Morris, Jr. John B. Morris, Jr.
Center for Democracy and Technology Center for Democracy and Technology
1634 I Street NW, Suite 1100 1634 I Street NW, Suite 1100
Washington, DC 20006 Washington, DC 20006
USA USA
Email: jmorris@cdt.org EMail: jmorris@cdt.org
URI: http://www.cdt.org URI: http://www.cdt.org
Jorge R. Cuellar Jorge R. Cuellar
Siemens Siemens
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bavaria 81739 Munich, Bavaria 81739
Germany Germany
Email: Jorge.Cuellar@siemens.com EMail: Jorge.Cuellar@siemens.com
James Polk James Polk
Cisco Cisco
2200 East President George Bush Turnpike 2200 East President George Bush Turnpike
Richardson, Texas 75082 Richardson, Texas 75082
USA USA
Email: jmpolk@cisco.com EMail: jmpolk@cisco.com
Jonathan Rosenberg Jonathan Rosenberg
Cisco Systems Cisco Systems
600 Lanidex Plaza 600 Lanidex Plaza
Parsippany, New York 07054 Parsippany, New York 07054
USA USA
Email: jdrosen@cisco.com EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net URI: http://www.jdrosen.net
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
skipping to change at page 43, line 45 skipping to change at page 32, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment Acknowledgement
Funding for the RFC Editor function is provided by the IETF Funding for the RFC Editor function is currently provided by the
Administrative Support Activity (IASA). Internet Society.
 End of changes. 112 change blocks. 
382 lines changed or deleted 318 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/