GEOPRIV H. Schulzrinne
Internet-Draft Columbia U.
Expires: August 9, 2004 J. Morris
CDT
H. Tschofenig
J. Cuellar
Siemens
J. Polk
Cisco
J. Rosenberg
DynamicSoft
February 9, 2004
Common Policy
draft-ietf-geopriv-common-policy-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 August 9, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document defines a framework for authorization policies
controling access to application specific data. This framework
combines common location- and SIP-presence-specific authorization
aspects. An XML schema specifies the language in which common policy
Schulzrinne, et al. Expires August 9, 2004 [Page 1]
Internet-Draft Common Policy February 2004
rules are represented. The common policy framework can be extended to
other application domains.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Modes of Operation . . . . . . . . . . . . . . . . . . . . . 6
3.1 Passive Request-Response - PS as Server (Responder) . . . . 6
3.2 Active Request-Response - PS as Client (Initiator) . . . . . 6
3.3 Event Notification . . . . . . . . . . . . . . . . . . . . . 6
4. Goals and Assumptions . . . . . . . . . . . . . . . . . . . 8
5. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Basic Data Model and Processing . . . . . . . . . . . . . . 11
6.1 Identification of Rules . . . . . . . . . . . . . . . . . . 12
6.2 Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Conditions . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1 Identity . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.2 Sphere . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.3 Validity . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9. Transformations . . . . . . . . . . . . . . . . . . . . . . 17
10. Procedure for Combining Permissions . . . . . . . . . . . . 18
11. Meta Policies . . . . . . . . . . . . . . . . . . . . . . . 22
12. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 23
13. XML Schema Definition . . . . . . . . . . . . . . . . . . . 24
14. Security Considerations . . . . . . . . . . . . . . . . . . 27
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 28
15.1 Common Policy Namespace Registration . . . . . . . . . . . . 28
15.2 Common Policy Schema Registration . . . . . . . . . . . . . 28
Normative References . . . . . . . . . . . . . . . . . . . . 30
Informative References . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 31
A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 33
B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . 35
Schulzrinne, et al. Expires August 9, 2004 [Page 2]
Internet-Draft Common Policy February 2004
1. Introduction
This document defines a framework for creating authorization policies
for access to application specific data. This framework is the result
of finding the common aspects of single authorization systems that
more specifically control access to presence [2] and location
information [7] and that previously had been developed separately.
The benefit of combining these two authorization systems is two-fold.
First, it allows to build a system which enhances the value of
presences with location information in a natural way and reuses the
same underlying authorization mechanism. Second, it encourages a more
generic authorization framework with mechanisms for extensibility.
The applicability of the framework specified in this document is not
limited to policies controling access to presence and location
information data, but can be extended to other applications domains.
The general framework defined in this document is intended to be
accompanied and enhanced by application-specific policies specified
elsewhere. Using the 'Location-specific Policy' and the
'Presence-specific Policy' documents [both are currently under
development - references to be included here], figure Figure 1
illustrates the relationship between the 'Common Policy' framework
defined in this document and application-specific enhancements of
this framework.
+-----------------+
| |
| Common |
| Policy |
| |
+---+---------+---+
/|\ /|\
| |
+-------------------+ | | +-------------------+
| | | enhance | | |
| Location-specific | | | | Presence-specific |
| Policy |----+ +----| Policy |
| | | |
+-------------------+ +-------------------+
Figure 1: Common Policy Enhancements
This document starts with an introduction to the terminology in
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)
Schulzrinne, et al. Expires August 9, 2004 [Page 3]
Internet-Draft Common Policy February 2004
of the authorization policy framework, followed by the data model in
Section 6. The structure of a rule, namely conditions, actions and
transformations, are described in Section 7, in Section 8 and in
Section 9. The procedure for combining permissions is explained in
Section 10 and used when more than one rule fires. An example is
provided in Section 12. The XML schema will be discussed in Section
13. IANA considerations in Section 15 follow security considerations
Section 14.
Schulzrinne, et al. Expires August 9, 2004 [Page 4]
Internet-Draft Common Policy February 2004
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT","RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1].
This document introduces the following terms:
PT - Presentity / Target: The PT is the entity about whom information
has been requested.
RM - Rule Maker: RM is an entity which creates the authorization
rules which restrict access to data items.
PS - (Authorization) Policy Server: This entity has access to both
the authorization policies and to the data items. In
location-specific applications, the entity PS is labeled as
location server (LS).
WR - Watcher / Recipient: This entity requests access to data items
of the PT. An access operation might be either be a read, write or
any other operation. In case of access to location information it
might be a read operation.
An 'authorization policy' is given by a 'rule set'. A 'rule set'
contains an unordered list of 'rules'. A 'rule' has a 'conditions',
an 'actions' and a 'transformations' part.
The term 'permission' indicates the action and transformation
components of a 'rule'.
The terms 'authorization policy', 'policy' and 'rule set' are used
interchangable.
The terms 'authorization policy rule', 'policy rule' and 'rule' are
used interchangable.
The term 'using protocol' is defined in [4]. It refers to the
protocol which is used to request access to and to return privacy
sensitive data items.
Schulzrinne, et al. Expires August 9, 2004 [Page 5]
Internet-Draft Common Policy February 2004
3. Modes of Operation
The abstract sequence of operations can roughly be described as
follows. The PS receives either a query for data items for a
particular PT, via the using protocol. The using protocol provides
the identity of the requestor (or more precisely the authentication
protocol), either at the time of the query or at the subscription
time. The authenticated identity of the WR, together with other
information provided by the using protocol or generally available to
the server, is then used for searching through the rule set. All
matching rules are combined according to a permission combining
algorithm described in Section 10. The result is returned to the WR,
possibly modified by transformation policies.
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
modes are supported with a one rule set schema. Specific instances of
the rule set can omit elements that are only applicable to the
subscription model. The three different modes are explained below.
3.1 Passive Request-Response - PS as Server (Responder)
In a passive request-response scenario, the WR queries the PS for
data items about the PT. Examples of protocols following this mode of
operation include HTTP, FTP, LDAP, finger or various RPC protocols,
including Sun RPC, DCE, DCOM, Corba and SOAP. The PS uses the ruleset
to prevent the transmission of information to the WR by refusing the
request. 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)
Alternatively, the PS may contact the WR and convey data items.
Examples include HTTP, SIP session setup (INVITE request), H.323
session setup or SMTP.
3.3 Event Notification
Event notification adds a subscription phase to the "PS as client"
mode of operation. A watcher or subscriber asks to be added to the
notification list for a particular presentity or event. When the
presentity changes state or the event occurs, the PS sends a message
to the WR containing the updated state. (Presence is a special case
of event notification; thus, we often use the term interchangeably.)
In addition, the subscriber may itself add a filter to the
subscription, limiting the rate or content of the notifications. If
an event, after filtering by the rulemaker-provided rules and by the
Schulzrinne, et al. Expires August 9, 2004 [Page 6]
Internet-Draft Common Policy February 2004
subscriber-provided rules, only produces the same notification
content that was sent previously, no event notification is sent.
Schulzrinne, et al. Expires August 9, 2004 [Page 7]
Internet-Draft Common Policy February 2004
4. Goals and Assumptions
Below, we summarize our design goals and constraints.
Table representation: Each rule must be representable as a row in a
relational database. This design goal should allow efficient
policy rule implementation by utilizing standard database
optimization techniques.
Permit only: Rules only provide permissions rather than denying them.
Allowing both 'permit' and 'deny' actions would require some rule
ordering which had implications on the update operations executed
on these rules. Additionally it would make distributed rule sets
more complicated. Hence, only 'permit' actions are allowed which
result in more efficient rule processing. This also implies that
rule ordering is not important. Consequently, to make a policy
decision requires processing all policy rules.
Additive permissions: A query for access to data items is matched
against the rules in the rule database. If several rules match,
then the overall permissions granted to the WR are the union of
those permissions. A more detailed discussion is provided in
Section 10.
Upgradeable: It should be possible to add additional rules later,
without breaking PSs that have not been upgraded. Any such
upgrades must not degrade privacy constraints, but PSs not yet
upgraded may reveal less information than the rulemaker would have
chosen.
Versioning support: In addition to the previous goal, a RM should be
able to determine which types of rules are supported by the PS.
The mechanism used to determine the capability of a PS will be
covered in future versions of the document.
Protocol-independent: The rule set supports constraints on both
notifications or queries as well as subscriptions for event-based
systems such as presence systems.
No false assurance: It appears more dangerous to give the user the
impression that the system will prevent disclosure automatically,
but fail to do so with a significant probability of operator error
or misunderstanding, than to force the user to explicitly invoke
simpler rules. For example, rules based on weekday and time-of-day
ranges seem particularly subject to misinterpretation and false
assumptions on part of the RM. (For example, a non-technical RM
would probably assume that the rules are based on the timezone of
his current location, which may not be known to other components
Schulzrinne, et al. Expires August 9, 2004 [Page 8]
Internet-Draft Common Policy February 2004
of the system.)
Schulzrinne, et al. Expires August 9, 2004 [Page 9]
Internet-Draft Common Policy February 2004
5. Non-Goals
We explicitly decided that a number of possibly worthwhile
capabilities are beyond the scope of this first version. Future
versions may include these capabilities, using the extension
mechanism described in this document. Non-goals include:
No external references: Attributes within specific rules cannot refer
to external rule sets, databases, directories or other network
elements. Any such external reference would make simple database
implementation difficult and hence they are not supported in this
version.
No regular expression or wildcard matching: Conditions are matched on
equality or 'greater-than'-style comparisons, not regular
expressions, partial matches such as the SQL LIKE operator (e.g.,
LIKE "%foo%") or glob-style matches ("*@example.com"). Most of
these are better expressed as explicit elements.
No all-except conditions: It is not possible to express exclusion
conditions based on identities such as "everybody except Alice".
However, this restriction does not prevent all forms of
blacklisting. It is still possible to express an authorization
rule like 'I allow access to my location information for everyone
of domain example.com except for John'. See the example in section
Section 7.1 describing how exceptions can be made work.
No repeat times: Repeat times are difficult to make work correctly,
due to the different time zones that PT, WR, PS and RM may occupy.
It appears that suggestions for including time intervals are often
based on supporting work/non-work distinctions, which
unfortunately are difficult to capture by time alone.
Schulzrinne, et al. Expires August 9, 2004 [Page 10]
Internet-Draft Common Policy February 2004
6. Basic Data Model and Processing
A rule set (or synonymously, a policy) consists of zero or more
rules. The ordering of these rules is immaterial. The rule set can 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 -
conditions (see section Section 7), actions (see Section 8), and
transformations (see Section 9).
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
of either TRUE or FALSE by the PS. When a WR asks for information
about a PT, the PS goes through each rule in the rule set. For each
rule, it evaluates the expressions in the conditions part. If all of
the expressions evaluate to TRUE, then the rule is applicable to this
request. Generally, each expression specifies a condition based on
some variable that is associated with the context of the request.
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
temperature or the mood of the PT.
Assuming that the rule is applicable to the request, the actions and
transformations (commonly referred to as permissions) in the rule
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, the
typical action is "permit", which allows the request to proceed.
Assuming the action allows the request to proceed, the
transformations part of the rule specifies how the information about
the PT - their location information, their presence, etc. - is
modified before being presented to the WR. These transformations are
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 PS
processes a request, it takes the transformations specified across
all rules that match, and creates the union of them. The means for
computing this union depend on the data type - Integer, Boolean, Set,
or the Undef data type - and are described in more detail in section
Section 10. The resulting union effectively represents a "mask" - it
defines what information 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 is shown to the WR. If the WR request
a subset of information only (such as city-level civil location data
only, instead of the full civil location information), the
information delivered to the WR SHOULD be the intersection of the
permissions granted to the WR and the data requested by the WR.
In accordance to this document, rules are encoded in XML. To this
end, section Section 13 contains an XML schema defining the Common
Schulzrinne, et al. Expires August 9, 2004 [Page 11]
Internet-Draft Common Policy February 2004
Policy Markup Language. This, however, is purely an exchange format
between RM and PS. The format does not imply that the RM or the PS
use this format internally, e.g., in matching a query with the policy
rules. The rules are designed so that a PS may translate the rules
into a relational database table, with each rule represented by one
row in the database. The database representation is by no means
mandatory; we will use it as a convenient and widely-understood
example of an internal representation. The database model has the
advantage that operations on rows have tightly defined meanings. In
addition, it appears plausible that larger-scale implementations will
employ a backend database to store and query rules, as they can then
benefit from existing optimized indexing, access control, scaling and
integrity constraint mechanisms. Smaller-scale implementations may
well choose different implementations, e.g., a simple traversal of
the set of rules.
6.1 Identification of Rules
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 NOT
use the same identifier for two rules that are available to the PS at
the same time for a given PT. The combination <PT identity, RM
identity, rule identity> uniquely identifies a rule.
6.2 Extensions
The authorization policy framework defined in this document is meant
to be extensible towards specific application domains. Such an
extension is accomplished by defining conditions, actions and
transformations that are specific to the desired application domain.
Each extension MUST define its own namespace and indicate its version
number.
Schulzrinne, et al. Expires August 9, 2004 [Page 12]
Internet-Draft Common Policy February 2004
7. Conditions
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 (e.g.,
the identity of the requestor) which are used for authorization. A
rule in a rule set might have a number of conditions which need to be
verified before executing the remaining parts of a rule (i.e.,
actions and transformations). Details about rule matching are
described in Section 10. This document specifies only a few
conditions (namely identity, sphere, and validity). Other conditions
are left for extensions of this document.
7.1 Identity
The policy framework specified in this document supports the usage of
authenticated identities as input to access authorization decision
processes. This framework, however, abstracts from the
particularities of concrete authentication mechanisms employed by
different using protocols and is therefore unable to specify
explicitly the details of identity relevant information. Documents
that enhance this framework should describe how a particular using
protocol is able to provide identity information in a meaningful way.
Such an enhancement needs to map the identity used by the
authentication protocol employed in the using protocol to an identity
used in the authorization policy. It is necessary to clearly define a
mapping between the authenticated identity of the user (and the
domain of the user) and the identities used in the authorization
policies. This mapping needs to consider the large number of possible
identities used in various authentication protocols and also to
consider identities in using protocols. Furthermore, it is important
to designate an identifier that denotes an 'anonymous user', i.e., a
user that has not authenticated itself to the PS. The authors suggest
to treat anonymous users by omitting this attribute in the rule which
causes a 'NULL' value to be created in the ruleset table of a
relational database. Any request for a data item (for a given PT)
would match with respect to this attribute in a rule. Furthermore,
pseudonyms need to be addressed as part of this mapping process.
This specification provides an <identity> element which belongs to
the group of condition elements. It can have either the <uri> or the
<domain> element as child elements. The <domain> element contains a
list of <except> elements and allows to implement a simple blacklist
mechanism. The domain value of the <domain> element MUST match the
value in the domain part of the URI in the <except> element. The
following example illustrates conditions based on an identity.
Schulzrinne, et al. Expires August 9, 2004 [Page 13]
Internet-Draft Common Policy February 2004
<identity>
<uri>jack@example.com</uri>
</identity>
The next example shows how exceptions are implemented. A request MUST
match the domain part and all three exceptions parts in an atomic
fashion to be a successful match.
<identity>
<domain>example.com</domain>
<except>joe@example.com</except>
<except>tony@example.com</except>
<except>mike@example.com</except>
</identity>
7.2 Sphere
The <sphere> element belongs to the group of condition elements. It
can be used to indicate a state (e.g., 'work', 'home', 'meeting',
'travel') the PT is currently in. A sphere condition matches only if
the PT is currently in the state indicated. The state may be conveyed
by manual configuration or by some protocol. For example, RPID [5]
provides the ability to inform the PS of its current sphere.
Switching from one sphere to another causes to switch between
different modes of visibility. As a result different subsets of rules
might be applicable. An example of a rule fragment is shown below:
<rule id="f3g44r1">
<conditions>
<sphere>work</sphere>
<identity>
<uri>bob@example.com</uri>
</identity>
</conditions>
</rule>
<rule id="y6y55r2">
<conditions>
<sphere>home</sphere>
<identity>
<uri>alice@example.com</uri>
</identity>
</conditions>
</rule>
Schulzrinne, et al. Expires August 9, 2004 [Page 14]
Internet-Draft Common Policy February 2004
The code snippet above illustrates that the rule with the entity
bob@example.com matches if the sphere is been set to 'work'. In the
second rule with the entity alice@example.com matches if the sphere
is set to 'home'.
7.3 Validity
The <validity> element is the third condition element specified in
this document. It expresses the rule validity period by two
attributes, a starting and a ending time. Times are expressed in XML
dateTime format. Expressing the lifetime of a rule implements a
garbage collection mechanism. A rule maker might not have always
access to the PS to remove some rules which grant permissions. Hence
this mechanisms allows to remove or invalidate granted permissions
automatically without further interaction between the rule maker and
the PS.
An example of a rule fragment is shown below:
<validity>
<from>2003-08-15T10:20:00.000-05:00</from>
<to>2003-09-15T10:20:00.000-05:00</to>
</validity>
Schulzrinne, et al. Expires August 9, 2004 [Page 15]
Internet-Draft Common Policy February 2004
8. Actions
While conditions are the 'if'-part of rules, actions and
transformations build the 'then'-part of them. The actions and
transformations parts of a rule determine which operations the PS
MUST execute after having received from a WR a data access request
that matches all conditions of this rule. Actions and transformations
only permit certain operations; there is no 'deny' functionality.
Transformations exclusively specify PS-side operations that lead to a
modification of the data items requested by the WR. Regarding
location data items, for instance, a transformation could force the
PS to lower the precision of the location information which is
returned to the WR.
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
transformation type. For example, this document introduces the
'confirmation' action for using protocols that follow the
subscription model. To this end, the common policy markup language
contains the <confirmation> element of boolean type. If it is set to
'true', the PS MUST bring in a subscription approval or disapproval
from the PT and grant subscription to the requesting WR only in case
of an approval. In case of 'false' or if this element is omitted, the
PS SHOULD NOT ask the PT for subscription approval or disapproval.
The subscription is marked as 'pending' while the PS waits for the PT
to decide. The approval mechanism depends on the using protocol and
is beyond the scope of this document. As an example, SIP defines a
mechanism where the presentity is notified of a subscription attempt
[3] and then either allows or refuses the subscription.
Schulzrinne, et al. Expires August 9, 2004 [Page 16]
Internet-Draft Common Policy February 2004
9. Transformations
Two sub-parts follow the conditions part of a rule: transformations
and actions. As defined in section Section 8, transformations specify
operations that the PS MUST execute and that modify the result which
is returned to the WR. This functionality is particularly helpful in
reducing the granularity of information provided to the WR, as for
example required by location information. This document does not
define any transformations since they depend on the application
domain.
A simple transformation example is provided in Section 10.
Schulzrinne, et al. Expires August 9, 2004 [Page 17]
Internet-Draft Common Policy February 2004
10. Procedure for Combining Permissions
We use the following terminology (which in parts has already been
introduced in previous sections): The term 'permission' stands for an
action or a transformation. The notion 'attribute' terms a condition,
an action, or a transformation. An attribute MUST specify its name.
An attribute MUST either be equipped with a value of a certain data
type or it is not equipped with a value. In the latter case the value
of this attribute automatically equals 'undef' of data type 'Undef'.
For example, the name of the <sphere> attribute discussed in section
Section 7 is 'sphere', its data type is 'string', and its value may
be set to 'home'. The values of attributes of the same name MUST all
be of the same data type or of the Undef data type. To evaluate a
condition means to associate either TRUE or FALSE to the 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. The values of
permissions MUST be of either Boolean, Integer, Set, or Undef data
type. Attributes with values of data type Integer can also be used
for enumerations. For example, you can enumerate different levels of
civil location information precision (e.g., level 0 "country, city,
street" vs. level 1 "country, city") by associating integers to these
levels.
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:
Schulzrinne, et al. Expires August 9, 2004 [Page 18]
Internet-Draft Common Policy February 2004
CR 1: If d(r,n)=Boolean or d(r,n)=Undef 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 or d(r,n)=Undef for all r in M(n), then V(n)
is given as follows: If v(r,n)=undef 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 or d(r,n)=Undef for all r in M(n), then V(n) is
given as follows: V(n)=intersection of all v(r,n), the intersection
to be computed over all r in M(n) with v(r,n)!=undef.
In the following example we illustrate the process of combining
permissions. We will consider three conditions for our purpose,
namely those of name identity, sphere, and validity. For editorial
reasons the rule set in this example is represented in a table.
Furthermore, the domain part of the identity of the WR is omitted.
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.
Permission X might, for example, represent the <confirmation> action.
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
Z allows us to show the granularity reduction whereby a value of '+'
shows the corresponding information unrestricted and '-' shows
nothing. This permission might be related to location information or
other presence attributes like mood. Internally we use the data type
Integer for computing the permission of this attribute.
Conditions Actions/Transformations
+--------------------------------+---------------------+
| Id WR-ID sphere from to | X Y Z |
+--------------------------------+---------------------+
| 1 bob home A1 A2 | TRUE 10 o |
| 2 alice work A1 A2 | FALSE 5 + |
| 3 bob work A1 A2 | TRUE 3 - |
| 4 tom work A1 A2 | TRUE 5 + |
| 5 bob work A1 A3 | undef 12 o |
| 6 bob work B1 B2 | FALSE 10 - |
+--------------------------------+---------------------+
Again for editorial reasons, we use the following abbreviations for
the two <validity> attributes 'from' and 'to':
A1=2003-12-24T17:00:00+01:00
A2=2003-12-24T21:00:00+01:00
Schulzrinne, et al. Expires August 9, 2004 [Page 19]
Internet-Draft Common Policy February 2004
A3=2003-12-24T23:30:00+01:00
B1=2003-12-22T17:00:00+01:00
B2=2003-12-23T17:00:00+01:00
The entity 'bob' acts as a WR and requests data items. The policy P
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-12-24T17:15:00+01:00. The value of the attribute with name
'sphere' indicating the state the PT is curretnly in is set to
'work'.
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 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') 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 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 permissions X, Y, and
Z:
Actions/Transformations
+-----------------------+
| X Y Z |
+-----------------------+
| TRUE 3 - |
| undef 12 o |
+-----------------------+
The results of the permission combining algorithm is shown below. The
combined value V(X) regarding the permission with name X equals TRUE
according to the first combining rule listed above. The maximum of 3
and 12 is 12, so that V(Y)=12. For the attribute Z in this example
the maximum between 'o' and '-' (i.e., between 2 and 3) is '-'.
Actions/Transformations
+-----------------------+
| X Y Z |
+-----------------------+
| TRUE 12 - |
+-----------------------+
Documents that extend the authorization policy framework defined here
by introducing application specific actions and transformation MUST
NOT define permissions whose values are of data type other than
Boolean, Integer, Set, and Undef. Furthermore, permissions and the
Schulzrinne, et al. Expires August 9, 2004 [Page 20]
Internet-Draft Common Policy February 2004
meaning of their values MUST be defined in such a way that the usage
of the combining rules CR 1, CR2, and CR 3 always preserves or
increases the level of privacy protection for the PT. In other words,
the definition of new permissions MUST respect the way in which CR 1,
CR 2, and CF 3 have been formulated in order to guarantee an
appropriate level of privacy protection.
Explicitly, it is not allowed to introduce a new permission whose
value is of data type ...
... Boolean and the PS-side operation corresponding to the
permission value TRUE has a lower privacy protection level than
that operation that corresponds to the value FALSE.
... Integer and for any two permission values v1 and v2, v1 > v2,
the PS-side operation corresponding to the value v1 has a lower
privacy protection level than that operation that corresponds to
the value v2.
... Set and for any two permission values s1 and s2, the PS-side
operation corresponding to the intersection of s1 and s2 has a
lower privacy protection level than those operations that
correspond to s1 or s2.
Schulzrinne, et al. Expires August 9, 2004 [Page 21]
Internet-Draft Common Policy February 2004
11. Meta Policies
Meta policies authorize a rulemaker to insert, update or delete a
particular rule or an entire rule set. Some authorization policies
are required to prevent unauthorized modification of rule sets. Meta
policies are outside the scope of this document.
A simple implementation could restrict access to the rule set only to
the PT but more sophisticated mechanisms are useful. Hence, in this
case the rule maker is the PT.
Schulzrinne, et al. Expires August 9, 2004 [Page 22]
Internet-Draft Common Policy February 2004
12. Example
This section gives a basic example of an XML document valid with
respect to the XML schema defined in Section 13. More useful examples
can be found in documents which extend this schema with application
domain specific data (e.g., location information).
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<rule id="f3g44r1">
<conditions>
<identity>
<uri>bob@example.com</uri>
</identity>
<validity>
<from>2003-12-24T17:00:00+01:00</from>
<to>2003-12-24T19:00:00+01:00</to>
</validity>
</conditions>
<actions>
<confirmation>true</confirmation>
</actions>
</rule>
</ruleset>
Schulzrinne, et al. Expires August 9, 2004 [Page 23]
Internet-Draft Common Policy February 2004
13. XML Schema Definition
This section provides the XML schema definition for the common policy
markup language described in this document.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:common-policy"
xmlns:cp="urn:ietf:params:xml:ns:common-policy"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:element name="ruleset">
<xs:complexType>
<xs:sequence>
<xs:element name="rule" type="cp:ruleType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:complexType name="ruleType">
<xs:sequence>
<xs:element name="conditions" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element ref="cp:condition"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="actions" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element ref="cp:action"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="transformations" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element ref="cp:transformation"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
Schulzrinne, et al. Expires August 9, 2004 [Page 24]
Internet-Draft Common Policy February 2004
</xs:element>
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/>
</xs:complexType>
<xs:element name="condition" abstract="true"/>
<xs:element name="action" abstract="true"/>
<xs:element name="transformation" abstract="true"/>
<xs:element name="validity" substitutionGroup="cp:condition">
<xs:complexType>
<xs:all>
<xs:element name="from" type="xs:dateTime"/>
<xs:element name="to" type="xs:dateTime"/>
</xs:all>
</xs:complexType>
</xs:element>
<xs:element name="sphere" type="xs:string"
substitutionGroup="cp:condition"/>
<xs:element name="identity" substitutionGroup="cp:condition">
<xs:complexType>
<xs:choice>
<xs:element name="uri" type="xs:anyURI"/>
<xs:sequence>
<xs:element name="domain" type="xs:string"/>
<xs:sequence minOccurs="0">
<xs:element name="except" type="xs:anyURI"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:sequence>
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="confirmation" type="xs:boolean"
substitutionGroup="cp:action"/>
</xs:schema>
Although the XML schema does not require detailed explanations the
following issues are worth to be mentioned: Each of the <conditions>,
<actions>, and <transformations> (plural!) elements consists of zero
or more child elements that belong to the substitution groups
'condition', 'action', and 'transformation', respectively. The
respective heads of these substitution groups are the elements
<condition>, <action>, and <transformation> (singular!). These
Schulzrinne, et al. Expires August 9, 2004 [Page 25]
Internet-Draft Common Policy February 2004
elements cannot be used directly in an instance document since they
are labeled as abstract.
XML schemas that extend this common policy schema by introducing new
conditions, actions, and transformations MUST declare to which of
these three substitution group the respective attribute belongs.
These new attribute elements can then be used as immediate child
elements of the <conditions>, <actions>, and <transformations>
elements, depending on to which substitution group they belong.
Schulzrinne, et al. Expires August 9, 2004 [Page 26]
Internet-Draft Common Policy February 2004
14. Security Considerations
This document describes a framework for authorization policy rules.
This framework is intended to be enhanced elsewhere towards
application domain specific data. Security considerations are to a
great extent application data dependent, and need therefore to be
covered by documents that extend the framework defined in this
specification. However, new action and transformation permissions
along with their allowed values must be defined in a way so that the
usage of the permissions combining rules of section Section 10 does
not lower the level of privacy protection. See section Section 10 for
more details on this privacy issue.
Schulzrinne, et al. Expires August 9, 2004 [Page 27]
Internet-Draft Common Policy February 2004
15. IANA Considerations
This section registers a new XML namespace and a new XML schema with
IANA.
15.1 Common Policy Namespace Registration
URI: urn:ietf:params:xml:ns:common-policy
Registrant Contact: IETF Geopriv Working Group, Henning Schulzrinne
(hgs+geopriv@cs.columbia.edu).
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Common Policy Namespace</title>
</head>
<body>
<h1>Namespace for Common Authorization Policies</h1>
<h2>urn:ietf:params:xml:ns:common-policy</h2>
<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body>
</html>
END
15.2 Common Policy Schema Registration
URI: Please assign.
Registrant Contact: IETF Geopriv Working Group, Henning Schulzrinne
(hgs+geopriv@cs.columbia.edu).
XML: The XML schema to be registered is contained in section Section
13. Its first line is
<?xml version="1.0" encoding="UTF-8"?>
Schulzrinne, et al. Expires August 9, 2004 [Page 28]
Internet-Draft Common Policy February 2004
and its last line is
</xs:schema>
Schulzrinne, et al. Expires August 9, 2004 [Page 29]
Internet-Draft Common Policy February 2004
Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", March 1997.
Schulzrinne, et al. Expires August 9, 2004 [Page 30]
Internet-Draft Common Policy February 2004
Informative References
[2] Rosenberg, J., "Extensible Markup Language (XML) Configuration
Access Protocol (XCAP) Usages for Setting Presence
Authorization", draft-ietf-simple-xcap-auth-usage-01 (work in
progress), October 2003.
[3] Rosenberg, J., "A Watcher Information Event Template-Package for
the Session Initiation Protocol (SIP)",
draft-ietf-simple-winfo-package-05 (work in progress), January
2003.
[4] Cuellar, J., Morris, J., Mulligan, D., Peterson, J. and J. Polk,
"Geopriv Requirements", draft-ietf-geopriv-reqs-04 (work in
progress), October 2003.
[5] Sugano, H., Fujimoto, S. and J. Peterson, "Presence Information
Data Format (PIDF)", draft-ietf-impp-cpim-pidf-08 (work in
progress), May 2003.
[6] Schulzrinne, H., Morris, J., Tschofenig, H. and J. Polk,
"Geopriv Authorization Rules", draft-ietf-geopriv-rules-00 (work
in progress), January 2004.
[7] Tschofenig, H., Morris, J., Cuellar, J., Polk, J. and H.
Schulzrinne, "Policy Rules for Disclosure and Modification of
Geographic Information", draft-ietf-geopriv-policy-00 (work in
progress), October 2003.
Authors' Addresses
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
USA
Phone: +1 212 939 7042
EMail: schulzrinne@cs.columbia.edu
URI: http://www.cs.columbia.edu/~hgs
Schulzrinne, et al. Expires August 9, 2004 [Page 31]
Internet-Draft Common Policy February 2004
John B. Morris, Jr.
Center for Democracy and Technology
1634 I Street NW, Suite 1100
Washington, DC 20006
USA
EMail: jmorris@cdt.org
URI: http://www.cdt.org
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bayern 81739
Germany
EMail: Hannes.Tschofenig@siemens.com
Jorge R. Cuellar
Siemens
Otto-Hahn-Ring 6
Munich, Bayern 81739
Germany
EMail: Jorge.Cuellar@siemens.com
James Polk
Cisco
2200 East President George Bush Turnpike
Richardson, Texas 75082
USA
EMail: jmpolk@cisco.com
Jonathan Rosenberg
DynamicSoft
600 Lanidex Plaza
Parsippany, New York 07054
USA
EMail: jdrosen@dynamicsoft.com
URI: http://www.jdrosen.net
Schulzrinne, et al. Expires August 9, 2004 [Page 32]
Internet-Draft Common Policy February 2004
Appendix A. Contributors
We would like to thank Christian Guenther for his help with this
document.
Christian Guenther
Siemens AG
Corporate Technology
81730 Munich
Email: christian.guenther@siemens.com
Germany
Schulzrinne, et al. Expires August 9, 2004 [Page 33]
Internet-Draft Common Policy February 2004
Appendix B. Acknowledgments
This document is partially based on the discussions within the IETF
GEOPRIV working group. Discussions at the Geopriv Interim Meeting
2003 in Washington, D.C., helped the working group to make progress
on the authorization policies based on the discussions among the
participants.
We particularly want to thank Allison Mankin <mankin@psg.com>,
Randall Gellens <rg+ietf@qualcomm.com>, Andrew Newton
<anewton@ecotroph.net>, Ted Hardie <hardie@qualcomm.com>, Jon
Peterson <jon.peterson@neustar.biz> for discussing a number of
details with us. They helped us to improve the quality of this
document.
Furthermore, we would like to thank the IETF SIMPLE working group for
their discussions of J. Rosenberg's draft on XCAP authorization
policies.
Schulzrinne, et al. Expires August 9, 2004 [Page 34]
Internet-Draft Common Policy February 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Schulzrinne, et al. Expires August 9, 2004 [Page 35]
Internet-Draft Common Policy February 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Schulzrinne, et al. Expires August 9, 2004 [Page 36]
