draft-ietf-geopriv-common-policy-04.txt   draft-ietf-geopriv-common-policy-05.txt 
GEOPRIV H. Schulzrinne GEOPRIV H. Schulzrinne
Internet-Draft Columbia U. Internet-Draft Columbia U.
Expires: August 22, 2005 J. Morris Expires: January 19, 2006 J. Morris
CDT CDT
H. Tschofenig H. Tschofenig
J. Cuellar J. Cuellar
Siemens Siemens
J. Polk J. Polk
Cisco Cisco
J. Rosenberg J. Rosenberg
DynamicSoft DynamicSoft
February 21, 2005 July 18, 2005
A Document Format for Expressing Privacy Preferences A Document Format for Expressing Privacy Preferences
draft-ietf-geopriv-common-policy-04.txt draft-ietf-geopriv-common-policy-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which I am aware have been disclosed, applicable patent or other IPR claims of which he or she is aware
and any of which I become aware will be disclosed, in accordance with have been or will be disclosed, and any of which he or she becomes
RFC 3668. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 22, 2005. This Internet-Draft will expire on January 19, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright (C) The Internet Society (2005).
Abstract Abstract
This document defines a framework for authorization policies This document defines a framework for authorization policies
controling access to application specific data. This framework controling 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
skipping to change at page 2, line 25 skipping to change at page 2, line 26
3.1 Passive Request-Response - PS as Server (Responder) . . . 6 3.1 Passive Request-Response - PS as Server (Responder) . . . 6
3.2 Active Request-Response - PS as Client (Initiator) . . . . 6 3.2 Active Request-Response - PS as Client (Initiator) . . . . 6
3.3 Event Notification . . . . . . . . . . . . . . . . . . . . 6 3.3 Event Notification . . . . . . . . . . . . . . . . . . . . 6
4. Goals and Assumptions . . . . . . . . . . . . . . . . . . . 8 4. Goals and Assumptions . . . . . . . . . . . . . . . . . . . 8
5. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Basic Data Model and Processing . . . . . . . . . . . . . . 11 6. Basic Data Model and Processing . . . . . . . . . . . . . . 11
6.1 Identification of Rules . . . . . . . . . . . . . . . . . 12 6.1 Identification of Rules . . . . . . . . . . . . . . . . . 12
6.2 Extensions . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2 Extensions . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Conditions . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Conditions . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1 Identity . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1 Identity . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.2 Sphere . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.2 Sphere . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.3 Validity . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.3 Validity . . . . . . . . . . . . . . . . . . . . . . . . . 18
8. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Transformations . . . . . . . . . . . . . . . . . . . . . . 19 9. Transformations . . . . . . . . . . . . . . . . . . . . . . 21
10. Procedure for Combining Permissions . . . . . . . . . . . . 20 10. Procedure for Combining Permissions . . . . . . . . . . . . 22
10.1 Introduction . . . . . . . . . . . . . . . . . . . . . . 20 10.1 Introduction . . . . . . . . . . . . . . . . . . . . . . 22
10.2 Algorithm . . . . . . . . . . . . . . . . . . . . . . . 20 10.2 Algorithm . . . . . . . . . . . . . . . . . . . . . . . 22
10.3 Example . . . . . . . . . . . . . . . . . . . . . . . . 21 10.3 Example . . . . . . . . . . . . . . . . . . . . . . . . 23
11. Meta Policies . . . . . . . . . . . . . . . . . . . . . . . 24 11. Meta Policies . . . . . . . . . . . . . . . . . . . . . . . 26
12. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 25 12. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 27
13. XML Schema Definition . . . . . . . . . . . . . . . . . . . 27 13. XML Schema Definition . . . . . . . . . . . . . . . . . . . 28
14. Security Considerations . . . . . . . . . . . . . . . . . . 30 14. Security Considerations . . . . . . . . . . . . . . . . . . 32
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 31 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 33
15.1 Common Policy Namespace Registration . . . . . . . . . . 31 15.1 Common Policy Namespace Registration . . . . . . . . . . 33
15.2 Content-type registration for 15.2 Content-type registration for
'application/auth-policy+xml' . . . . . . . . . . . . . 31 'application/auth-policy+xml' . . . . . . . . . . . . . 33
15.3 Common Policy Schema Registration . . . . . . . . . . . 33 15.3 Common Policy Schema Registration . . . . . . . . . . . 35
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
16.1 Normative References . . . . . . . . . . . . . . . . . . . 34 16.1 Normative References . . . . . . . . . . . . . . . . . . 36
16.2 Informative References . . . . . . . . . . . . . . . . . . 34 16.2 Informative References . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 37
A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 37 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 39
B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 38 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 40
Intellectual Property and Copyright Statements . . . . . . . 39 Intellectual Property and Copyright Statements . . . . . . . 41
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 to build a system which enhances the
skipping to change at page 4, line 5 skipping to change at page 4, line 5
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 authorization policy framework, followed by the data model in of the authorization policy framework, followed by the data model in
Section 6. The structure of a rule, namely conditions, actions and Section 6. The structure of a rule, namely conditions, actions and
transformations, are described in Section 7, in Section 8 and in transformations, are described in Section 7, in Section 8 and in
Section 9. The procedure for combining permissions is explained in Section 9. The procedure for combining permissions is explained in
Section 10 and used when more than one rule fires. A short Section 10 and used when more than one rule fires. A short
description of meta policies is given in Section 11. An example is description of meta policies is given in Section 11. An example is
provided in Section 12. The XML schema will be discussed in Section provided in Section 12. The XML schema will be discussed in
13. IANA considerations in Section 15 follow security considerations Section 13. IANA considerations in Section 15 follow security
Section 14. considerations 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 information PT - Presentity / Target: The PT is the entity about whom information
has been requested. has been requested.
RM - Rule Maker: RM is an entity which creates the authorization RM - Rule Maker: RM is an entity which creates the authorization
rules which restrict access to data items. rules which 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 the authorization policies and to the data items. In location-
location-specific applications, the entity PS is labeled as specific applications, the entity PS is labeled as location server
location server (LS). (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 either be a read, write
or any other operation. In case of access to location information or any other operation. In case of access to location information
it might be a read operation. it might be a read operation.
An 'authorization policy' is given by a 'rule set'. A 'rule set' An 'authorization policy' is given by a 'rule set'. A 'rule set'
contains an unordered list of 'rules'. A 'rule' has a 'conditions', contains an unordered list of 'rules'. A 'rule' has a 'conditions',
an 'actions' and a 'transformations' part. an 'actions' and a 'transformations' part.
skipping to change at page 8, line 9 skipping to change at page 8, line 9
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
Below, we summarize our design goals and constraints. Below, we summarize our design goals and constraints.
Table representation: Each rule must be representable as a row in a Table representation:
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. Each rule must be representable as a row in a relational database.
Allowing both 'permit' and 'deny' actions would require some rule This design goal should allow efficient policy rule implementation
ordering which had implications on the update operations executed by utilizing standard database optimization techniques.
on these rules. Additionally it would make distributed rule sets
more complicated. Hence, only 'permit' actions are allowed which 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 result in more efficient rule processing. This also implies that
rule ordering is not important. Consequently, to make a policy rule ordering is not important. Consequently, to make a policy
decision requires processing all policy rules. decision requires processing all policy rules.
Additive permissions: A query for access to data items is matched Additive permissions:
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
inSection 10.
Upgradeable: It should be possible to add additional rules later, A query for access to data items is matched against the rules in
without breaking PSs that have not been upgraded. Any such the rule database. If several rules match, then the overall
upgrades must not degrade privacy constraints, but PSs not yet permissions granted to the WR are the union of those permissions.
upgraded may reveal less information than the rulemaker would have A more detailed discussion is provided inSection 10.
chosen.
Versioning support: In addition to the previous goal, a RM should be Upgradeable:
able to determine which types of rules are supported by the PS.
The mechanism used to determine the capability of a PS is outside
the scope of this specification.
Protocol-independent: The rule set supports constraints on both It should be possible to add additional rules later, without
notifications or queries as well as subscriptions for event-based breaking PSs that have not been upgraded. Any such upgrades must
systems such as presence systems. not degrade privacy constraints, but PSs not yet upgraded may
reveal less information than the rulemaker would have chosen.
No false assurance: It appears more dangerous to give the user the Versioning support:
impression that the system will prevent disclosure automatically,
but fail to do so with a significant probability of operator error In addition to the previous goal, a RM should be able to determine
or misunderstanding, than to force the user to explicitly invoke which types of rules are supported by the PS. The mechanism used
simpler rules. For example, rules based on weekday and to determine the capability of a PS is outside the scope of this
time-of-day ranges seem particularly subject to misinterpretation specification.
and false assumptions on part of the RM. (For example, a
non-technical RM would probably assume that the rules are based on Protocol-independent:
the timezone of his current location, which may not be known to
other components of the system.) 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 of the system.)
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: Attributes within specific rules cannot refer No external references:
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 Attributes within specific rules cannot refer to external rule
equality or 'greater-than'-style comparisons, not regular sets, databases, directories or other network elements. Any such
expressions, partial matches such as the SQL LIKE operator (e.g., external reference would make simple database implementation
LIKE "%foo%") or glob-style matches ("*@example.com"). Most of difficult and hence they are not supported in this version.
these are better expressed as explicit elements.
No all-except conditions: It is not possible to express exclusion No regular expression or wildcard matching:
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 7.1 describing how exceptions can be made to work. The
reason for this choice is the ease with which identities can be
manufactured, and the implication that all-except types of rules
are easily subverted.
No repeat times: Repeat times are difficult to make work correctly, Conditions are matched on equality or 'greater-than'-style
due to the different time zones that PT, WR, PS and RM may occupy. comparisons, not regular expressions, partial matches such as the
It appears that suggestions for including time intervals are often 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 7.1
describing how exceptions can be made to work. The reason for
this choice is the ease with which identities can be manufactured,
and the implication that all-except types of rules are easily
subverted.
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 based on supporting work/non-work distinctions, which
unfortunately are difficult to capture by time alone. unfortunately are difficult to capture by time alone.
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
skipping to change at page 11, line 41 skipping to change at page 11, line 41
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 which is allowed to be seen by the WR. When a
PS processes a request, it takes the transformations specified across PS processes a request, it takes the transformations specified across
all rules that match, and creates the union of them. The means for all rules that match, and creates the union of them. The means for
computing this union depend on the data type - Integer, Boolean, Set, computing this union depend on the data type - Integer, Boolean, Set,
or the Undef data type - and are described in more detail in Section or the Undef data type - and are described in more detail in
10. The resulting union effectively represents a "mask" - it defines Section 10. The resulting union effectively represents a "mask" - it
what information is exposed to the WR. This mask is applied to the defines what information is exposed to the WR. This mask is applied
actual location or presence data for the PT, and the data which is to the actual location or presence data for the PT, and the data
permitted by the mask is shown to the WR. If the WR request a subset which is permitted by the mask is shown to the WR. If the WR request
of information only (such as city-level civil location data only, a subset of information only (such as city-level civil location data
instead of the full civil location information), the information only, instead of the full civil location information), the
delivered to the WR SHOULD be the intersection of the permissions information delivered to the WR SHOULD be the intersection of the
granted to the WR and the data requested by the WR. permissions granted to the WR and the data requested by the WR.
In accordance to this document, rules are encoded in XML. To this In accordance to this document, rules are encoded in XML. To this
end, Section 13 contains an XML schema defining the Common Policy end, Section 13 contains an XML schema defining the Common Policy
Markup Language. This, however, is purely an exchange format between 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 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. 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 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 relational database table, with each rule represented by one row in
the database. The database representation is by no means mandatory; the database. The database representation is by no means mandatory;
we will use it as a convenient and widely-understood example of an we will use it as a convenient and widely-understood example of an
skipping to change at page 13, line 19 skipping to change at page 13, line 19
(e.g., the identity of the requestor) which are used for (e.g., the identity of the requestor) which 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 which need to be met before executing the remaining parts conditions which 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 (namely identity, sphere, and validity). Other few conditions (namely identity, sphere, and validity). Other
conditions are left for extensions of this document. conditions are left for extensions of this document.
7.1 Identity 7.1 Identity
The policy framework specified in this document supports the usage of The authorization policy framework specified in this document
identities as input to access authorization decision processes. This supports the usage of identities as input to access authorization
framework, however, abstracts from the particularities of concrete decision processes. This document, however, abstracts from the
authentication mechanisms employed by different using protocols and particularities of concrete authentication mechanisms employed by
is therefore unable to specify explicitly the details of identity different using protocols and is therefore unable to specify
relevant information. This document only assumes that the identity explicitly the details of identity relevant information. Hence, we
has a username part and a domain part. Documents that enhance this only assume that an identity has a structure with a username and a
framework should describe how a particular using protocol is able to domain part. Documents that enhance the schema defined in this
provide identity information in a meaningful way. document should, if possible, 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 Such an enhancement needs to map the identity used by the
authentication protocol employed in the using protocol to an identity authentication protocol employed in the using protocol to an identity
used in the authorization policy. It is necessary to clearly define used in the authorization policy. It is necessary to clearly define
a mapping between the authenticated identity of the user (and the a mapping between the authenticated identity of the user and the
domain of the user) and the identities used in the authorization identities used in the authorization policies. This mapping needs to
policies. This mapping needs to consider the large number of consider the large number of possible identities used in various
possible identities used in various authentication protocols and also authentication protocols.
to consider identities in using protocols. Most using protocols also
designate an identifier that denotes an 'anonymous user', i.e., a
user that has not authenticated directly to the PS but to another
party (asserting party) that provides an assertion to the PS that
this user has been authenticated. It is assumed that PS and the
asserting party have some relationship with each other and there is a
certain degree of trust. An example of this approach can be found in
[8]. For this purpose this document defines the element <anonymous>.
The <anonymous> element MAY contain a <domain> element to restrict
the assertion to be signed from a particular domain. To express
policies that are valid for all users (including unauthenticated
users) the <any-identity> is used and matches always.
This specification provides an <identity> element which belongs to In this document we distinguish between three different identities:
the group of condition elements. It can have either the <id> 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 <except> element contains the identity without the
domain part since it equals the domain of the <domain> element. The
following example illustrates conditions based on an identity.
<identity> Authenticated Identities:
<id>jack@example.com</id>
</identity>
The identity condition part of the rule matches, if the identity of The WR was authenticated by the PS. The authenticated identity is
the WR matches, based on case sensitive string comparison, the user used as input to the rule matching procedure.
part of the <id>, and the domain part of the of the <id>, based on
case insensitive string comparison.
A single <identity> element can contain multiple <id> elements. If Unauthenticated Identities:
multiple identities are provided in a single rule then the rule
matches if at least one of the listed identities in a rule matches
the authenticated identity of the WR.
For the given example the rule matches if the WR is either The WR was not authenticated by the PS and thus any identity
alice@example.com or bob@example.com. provided by the WR might be spoofed.
Asserted Identities:
The WR was not directly authenticated by the PS. Instead the WR
was authenticated by an asserting party that provides an assurance
to the PS about the authentication of the WR. It is assumed that
the PS and the asserting party have some relationship with each
other and that there is a certain degree of trust that the
asserting party does not misbehave (such as lying about a non-
existing authentication of the WR and by making an incorrect
assertion). An example of this approach can be found in [8].
These three identities are used for the rule matching algorithms
whereby no differentiation is made between an authenicated and an
asserted identity in this document. However, there is another
identity, the anonymous identity, that plays a role in this context.
Most using protocols also designate an identifier that denotes an
'anonymous user'. The WR, as such, is not authenticated by the PS
nor does an assertion exist that provides the PS with information
about the authenticated identity. In order to provide an
authorization decision non-identity based (or trait-based
authorization) might be applicable. This might be accomplished by an
assertion provided by a third party that hides the identity but
offers attributes about the WR that are used as the foundation for an
access control decision. Ensuring authorization for anonymous users
is outside the scope of this document.
The following guidelines apply when performing rule matching (related
to the identity element in the conditions part of a rule):
1. A rule with no conditions matches any subscription irrelevant
whether an authenticated or an unauthenticated was used by the WR
to access resources.
2. A rule with an <identity> element assumes that there are either
<id> or <domain> elements as child elements. Unauthenticated
identities never match the values of the <id> element(s) or the
<domain> element(s).
1. If the <identity> element contains one or multiple <id>
element(s) then the authenticated identities (as provided by
the security protocol used by the using protocol) MUST be
used for an equality match.
2. If the <identity> element contains the <domain> element
consisting of one or more <except> element(s) then the domain
part of the authenticated identity MUST be used for an
equality match. This allows implementing a simple blacklist
mechanism. The <except> element contains the identity
without the domain part (i.e., the username part) since it
equals the domain of the <domain> element. Only
authenticated identities MUST be matched with the username
part of the values of the <except> element(s).
3. The <any-identity> condition that matches authenticated and
unauthenticated identities. The <any-identity> MAY contain one
or multiple <except-domain> elements and MAY contain one or
multiple <domain> elements.
1. If the <any-identity> element does not contain child elements
then the rule matches with any authenticated or
unauthenticated identity.
2. If the <any-identity> element contains one or multiple
<domain> elements then the domain part of the authenticated
or unauthenticated identity MUST be matched against the
values of the <domain> element(s).
3. If the <any-identity> element contains one or multiple
<except-domain> element(s) then the domain part of the
authenticated or unauthenticated identity MUST be matched
against the values of the <except-domain> element(s).
Regarding string comparison the following rules apply:
1. The <id> elements of the <identity> condition part of the rule
matches, if the identity of the WR matches, based on case
sensitive string comparison, the user part of the <id>, and the
domain part of the of the <id>, based on case insensitive string
comparison.
2. The identity of the WR matches a <domain> (either listed in the
<identity> or the <any-identity> element) when the domain part of
the identity matches, based on case insensitive string
comparison, the value of the <domain> element, and the user part
matches none of the <except> element values, based on case
sensitive string comparison. The values of a <domain> element
MUST be matched with the domain part of the provided identity
using an equality match. No wildcarding is provided.
Next, we list a few examples. The following example illustrates
conditions based on an identity.
Authenticated Identities
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<rule id="f3g44r2">
<conditions>
<identity> <identity>
<id>alice@example.com</id> <id entity="alice@example.com"/>
<id>bob@example.com</id> <id entity="bob@example.com"/>
</identity> </identity>
</conditions>
</rule>
</ruleset>
The next example shows how exceptions are implemented. The identity Figure 2: Matching authenticated identities
of the WR matches a <domain> when the domain part of the identity
matches, based on case insensitive string comparison, the value of The example shown in Figure 2 shows a rule that matches if the
the domain element, and the user part matches none of the <except> authenticated identity of the WR is either alice@example.com or
element values, based on case sensitive string comparison. bob@example.com.
Exceptions within the Identity Element:
The example in Figure 3 shows how exceptions are implemented. For
the given example the rule matches if the authenticated identity
of the WR is from the example.com domain but the user identity of
the WR is neither joe@example.com, toni@example.com nor
mike@example.com.
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<rule id="f3g44r2">
<conditions>
<identity> <identity>
<domain>example.com</domain> <domain domain="example.com"/>
<except>joe</except> <except entity="joe"/>
<except>tony</except> <except entity="tony"/>
<except>mike</except> <except entity="mike"/>
</identity> </identity>
</conditions>
</rule>
</ruleset>
The following guidelines apply when matching the identity with the Figure 3: Using the Domain/Except Elements
rules: If a WR with the identity john@foo.example.com requests access to
a resource the above-shown rule is not applied since the case
insensitive equality match between the domain part of the WR
identity (namely 'foo.example.com') does not match the value in
the domain part of the rule (namely 'example.com').
A rule with no conditions matches any subscription (authenticated Any Identity
or unauthenticated, anonymous or not)
A rule with an <identity> element assumes that the identity listed
is authenticated; unauthenticated identities do not match those
conditions.
A rule with an <anonymous> element assumes that the anonymous The following example matches any authenticated and any
request is authenticated. Unauthenticated identities do not match unauthenticated identity.
the <anonymous> condition.
The <any-identity> condition that matches any authenticated <?xml version="1.0" encoding="UTF-8"?>
identity. <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<rule id="f3g44r2">
<conditions>
<any-identity/>
</conditions>
</rule>
</ruleset>
Figure 4: The Any-Identity Element
The following rule fires for any authenticated and any
unauthenticated identity except for WR's from the example.com and
the foo.com domain. The rule would therefore fire for
joe@foo.bar.com but not for alice@foo.com.
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<rule id="f3g44r2">
<conditions>
<any-identity>
<except-domain domain="example.com"/>
<except-domain domain="foo.com"/>
</any-identity>
</conditions>
</rule>
</ruleset>
Figure 5: Any-Identity combined with Except-Domain Element
7.2 Sphere 7.2 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 [9] provides the ability to inform the PS of its current sphere. RPID [9] provides the ability to inform the PS of its current sphere.
The application domain needs to describe in more detail how the The application domain needs to describe in more detail how the
sphere state is determined. Switching from one sphere to another sphere state is determined. Switching from one sphere to another
causes to switch between different modes of visibility. As a result causes to switch between different modes of visibility. As a result
different subsets of rules might be applicable. An example of a rule different subsets of rules might be applicable. An example of a rule
fragment is shown below: 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="f3g44r2"> <rule id="f3g44r2">
<conditions> <conditions>
<sphere>work</sphere> <sphere value="work"/>
<identity> <identity>
<id>andrew@example.com</id> <id entity="andrew@example.com"/>
</identity> </identity>
</conditions> </conditions>
<actions/> <actions/>
<transformations/> <transformations/>
</rule> </rule>
<rule id="y6y55r2"> <rule id="y6y55r2">
<conditions> <conditions>
<sphere>home</sphere> <sphere value="home"/>
<identity> <identity>
<id>allison@example.com</id> <id entity="allison@example.com"/>
</identity> </identity>
</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
skipping to change at page 17, line 12 skipping to change at page 19, line 20
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>
<from>2003-08-15T10:20:00.000-05:00</from> <from>2003-08-15T10:20:00.000-05:00</from>
<to>2003-09-15T10:20:00.000-05:00</to> <until>2003-09-15T10:20:00.000-05:00</until>
</validity> </validity>
</conditions> </conditions>
<actions/> <actions/>
<transformations/> <transformations/>
</rule> </rule>
</ruleset> </ruleset>
The <identity>, the <sphere> and the <validity> element MUST NOT The <identity>, the <sphere> and the <validity> element MUST NOT
appear more than once in the conditions part of a single rule. The appear more than once in the conditions part of a single rule. The
<id> element on the other hand may appear more than once as described <id> element on the other hand may appear more than once as described
skipping to change at page 21, line 15 skipping to change at page 23, line 15
CR 1: If d(r,n)=Boolean for all r in M(n), then V(n) is given as 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. follows: If there is a r in M(n) with v(r,n)=TRUE, then V(n)=TRUE.
Otherwise, V(n)=FALSE. Otherwise, V(n)=FALSE.
CR 2: If d(r,n)=Integer for all r in M(n), then V(n) is given as 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 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 specified by this specification. Otherwise, V(n)=max{v(r,n) | r
in M(n)}. in M(n)}.
CR 3: If d(r,n)=Set for all r in M(n), then V(n) is given as follows: CR 3: If d(r,n)=Set for all r in M(n), then V(n) is given as
V(n)=union of all v(r,n), the union to be computed over all r in follows: V(n)=union of all v(r,n), the union to be computed over all
M(n) with v(r,n)!=undefined. r in M(n) with v(r,n)!=undefined.
The combining operation will result in the largest value for an The combining operation will result in the largest value for an
Integral type, the Or operation for boolean, and union for set. Integral type, the Or operation for boolean, and union for set.
As a result, applications should define values such that, for As a result, applications should define values such that, for
integers, the lowest value corresponds to the most privacy, for integers, the lowest value corresponds to the most privacy, for
booleans, false corresponds to the most privacy, and for sets, the booleans, false corresponds to the most privacy, and for sets, the
empty set corresponds to the most privacy. More empty set corresponds to the most privacy. More
10.3 Example 10.3 Example
skipping to change at page 22, line 6 skipping to change at page 24, line 6
Permission X might, for example, represent the <sub-handling> action. Permission X might, for example, represent the <sub-handling> action.
For transformations we use the attribute with the name Z whose value 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 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 '+' Z allows us to show the granularity reduction whereby a value of '+'
shows the corresponding information unrestricted and '-' shows shows the corresponding information unrestricted and '-' shows
nothing. This permission might be related to location information or nothing. This permission might be related to location information or
other presence attributes like mood. Internally we use the data type other presence attributes like mood. Internally we use the data type
Integer for computing the permission of this attribute. Integer for computing the permission of this attribute.
Conditions Actions/Transformations Conditions Actions/Transformations
+--------------------------------+---------------------+ +---------------------------------+---------------------+
| Id WR-ID sphere from to | 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 | undef 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 'to': 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 policy P
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 values 1 to 6 in the 'Id' column. The PS receives the query at 2003-
2003-12-24T17:15:00+01:00 which falls between A1 and A2. The value 12-24T17:15:00+01:00 which falls between A1 and A2. The value of the
of the attribute with name 'sphere' indicating the state the PT is attribute with name 'sphere' indicating the state the PT is currently
currently in is set to 'work'. in is set to 'work'.
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. Therefore, the set M of matching
rules consists of the rules 3 and 5. These two rules are used to 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 compute the combined permission V(X), V(Y), and V(Z) for each of the
permissions X, Y, and Z: permissions X, Y, and Z:
skipping to change at page 25, line 7 skipping to change at page 27, line 7
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 two basic example of an XML document valid with This section gives an example of an XML document valid with respect
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 which extend this schema with
application domain specific data (e.g., location or presence application domain specific data (e.g., location or presence
information). information).
The first rule example shows 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. period. Additionally, the rule matches only if the target has set
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">
<rule id="f3g44r1"> <rule id="f3g44r1">
<conditions> <conditions>
<identity> <identity>
<id>bob@example.com</id> <id entity="bob@example.com"/>
</identity> </identity>
<sphere value="work"/>
<validity> <validity>
<from>2003-12-24T17:00:00+01:00</from> <from>2003-12-24T17:00:00+01:00</from>
<to>2003-12-24T19:00:00+01:00</to> <until>2003-12-24T19:00:00+01:00</until>
</validity>
</conditions>
<actions/>
</rule>
</ruleset>
The rule below matches if a request was provided to the PS (for
example using the privacy extensions for the SIP protocol using the
P-Asserted-Identity header) but no authenticated identity was
specified. The entity that asserted the identity must be from
example.com.
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<rule id="g3h44r1">
<conditions>
<identity>
<anonymous>
<domain>example.com</domain>
</anonymous>
</identity>
<validity>
<from>2004-12-24T17:00:00+01:00</from>
<to>2004-12-24T19:00:00+01:00</to>
</validity>
</conditions>
<actions/>
</rule>
</ruleset>
Finally a rule is shown that matches only with regard to the validity
period. Any identity would be accepted (unauthenticated,
authenticated, anonymous or not).
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<rule id="g3h466a2">
<conditions>
<identity>
<any-identity/>
</identity>
<validity>
<from>2005-12-24T17:00:00+01:00</from>
<to>2005-12-24T19:00:00+01:00</to>
</validity> </validity>
</conditions> </conditions>
<actions/> <actions/>
</rule> </rule>
</ruleset> </ruleset>
13. XML Schema Definition 13. XML Schema Definition
skipping to change at page 27, line 18 skipping to change at page 28, line 18
markup language described in this document. markup language described in this document.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema <xs:schema
targetNamespace="urn:ietf:params:xml:ns:common-policy" targetNamespace="urn:ietf:params:xml:ns:common-policy"
xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:cp="urn:ietf:params:xml:ns:common-policy"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> attributeFormDefault="unqualified">
<!-- Rule Set -->
<xs:element name="ruleset"> <xs:element name="ruleset">
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element name="rule" type="cp:ruleType" <xs:element name="rule" type="cp:ruleType"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<!-- Rule -->
<xs:complexType name="ruleType"> <xs:complexType name="ruleType">
<xs:sequence> <xs:sequence>
<!-- Conditions -->
<xs:element name="conditions" minOccurs="0"> <xs:element name="conditions" minOccurs="0">
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element ref="cp:condition"
minOccurs="0" maxOccurs="unbounded"/> <xs:element name="validity" minOccurs="0">
</xs:sequence> <xs:complexType>
<xs:all>
<xs:element name="from" type="xs:dateTime"/>
<xs:element name="to" type="xs:dateTime"/>
</xs:all>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name="actions" minOccurs="0">
<xs:element name="identity" minOccurs="0">
<xs:complexType>
<xs:choice>
<xs:element name="id" maxOccurs="unbounded">
<xs:complexType> <xs:complexType>
<xs:attribute name="entity"
type="xs:string" use="required"/>
</xs:complexType>
</xs:element>
<xs:sequence> <xs:sequence>
<xs:element ref="cp:action" <xs:element name="domain"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded">
</xs:sequence> <xs:complexType>
<xs:attribute name="domain"
type="xs:string" use="required"/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name="transformations" minOccurs="0"> <xs:element name="except"
minOccurs="0" maxOccurs="unbounded">
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:attribute name="entity"
<xs:element ref="cp:transformation" type="xs:string" use="required"/>
minOccurs="0" maxOccurs="unbounded"/> </xs:complexType>
</xs:element>
</xs:sequence> </xs:sequence>
<xs:element name="any-identity">
<xs:complexType>
<xs:sequence>
<xs:element name="domain"
minOccurs="0" maxOccurs="unbounded">
<xs:complexType>
<xs:attribute name="domain"
type="xs:string" use="required"/>
</xs:complexType>
</xs:element>
<xs:element name="except-domain"
minOccurs="0" maxOccurs="unbounded">
<xs:complexType>
<xs:attribute name="domain"
type="xs:string" use="required"/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
</xs:sequence> </xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/>
</xs:complexType> </xs:complexType>
</xs:element>
<xs:element name="condition" abstract="true"/> </xs:choice>
<xs:element name="action" abstract="true"/> </xs:complexType>
<xs:element name="transformation" abstract="true"/> </xs:element>
<xs:element name="validity" substitutionGroup="cp:condition"> <xs:element name="sphere"
minOccurs="0" maxOccurs="unbounded">
<xs:complexType> <xs:complexType>
<xs:all> <xs:attribute name="value"
<xs:element name="from" type="xs:dateTime"/> type="xs:string" use="required"/>
<xs:element name="to" type="xs:dateTime"/>
</xs:all>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name="sphere" type="xs:string" <xs:any namespace="##other" processContents="lax"
substitutionGroup="cp:condition"/> minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="identity" substitutionGroup="cp:condition"> </xs:sequence>
</xs:complexType>
</xs:element>
<!-- Actions -->
<xs:element name="actions" minOccurs="0">
<xs:complexType> <xs:complexType>
<xs:choice>
<xs:element name="id" type="xs:string"
maxOccurs="unbounded"/>
<xs:sequence> <xs:sequence>
<xs:element name="domain" type="xs:string"/> <xs:any namespace="##other" processContents="lax"
<xs:sequence minOccurs="0"> minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="except" type="xs:string"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:sequence> </xs:sequence>
<xs:element name="anonymous" type="xs:string" </xs:complexType>
minOccurs="0" maxOccurs="1"/> </xs:element>
<xs:sequence minOccurs="0">
<xs:element name="domain" type="xs:string"/> <!-- Transformations -->
<xs:element name="transformations" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded" />
</xs:sequence> </xs:sequence>
<xs:element name="any-identity" type="xs:string"
minOccurs="0" maxOccurs="1"/>
</xs:choice>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
</xs:schema> </xs:sequence>
Although the XML schema does not require detailed explanations the <xs:attribute name="id" type="xs:string" use="required"/>
following issues are worth mentioning: Each of the <conditions>, </xs:complexType>
<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
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 </xs:schema>
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.
14. Security Considerations 14. Security Considerations
This document describes a framework for authorization policy rules. This document describes a framework for authorization policy rules.
This framework is intended to be enhanced elsewhere towards This framework is intended to be enhanced elsewhere towards
application domain specific data. Security considerations are to a application domain specific data. Security considerations are to a
great extent application data dependent, and therefore need to be great extent application data dependent, and therefore need to be
covered by documents that extend the framework defined in this covered by documents that extend the framework defined in this
specification. However, new action and transformation permissions specification. However, new action and transformation permissions
along with their allowed values must be defined in a way so that the along with their allowed values must be defined in a way so that the
skipping to change at page 34, line 12 skipping to change at page 36, line 12
</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", March 1997.
[2] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January [2] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
2004. January 2004.
[3] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet [3] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet
Mail Extensions (MIME) Part Four: Registration Procedures", BCP Mail Extensions (MIME) Part Four: Registration Procedures",
13, RFC 2048, November 1996. BCP 13, RFC 2048, November 1996.
[4] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC [4] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
3023, January 2001. RFC 3023, January 2001.
16.2 Informative References 16.2 Informative References
[5] Rosenberg, J., "Presence Authorization Rules", [5] Rosenberg, J., "Presence Authorization Rules",
draft-ietf-simple-presence-rules-01 (work in progress), October draft-ietf-simple-presence-rules-02 (work in progress),
2004. February 2005.
[6] Schulzrinne, H., "A Document Format for Expressing Privacy [6] Schulzrinne, H., "A Document Format for Expressing Privacy
Preferences for Location Information", Preferences for Location Information",
draft-ietf-geopriv-policy-05 (work in progress), November 2004. draft-ietf-geopriv-policy-05 (work in progress), November 2004.
[7] Cuellar, J., Morris, J., Mulligan, D., Peterson, J. and J. Polk, [7] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.
"Geopriv Requirements", RFC 3693, February 2004. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[8] Jennings, C., Peterson, J. and M. Watson, "Private Extensions to [8] Jennings, C., Peterson, J., and M. Watson, "Private Extensions
the Session Initiation Protocol (SIP) for Asserted Identity to the Session Initiation Protocol (SIP) for Asserted Identity
within Trusted Networks", RFC 3325, November 2002. within Trusted Networks", RFC 3325, November 2002.
[9] Schulzrinne, H., Gurbani, V., Kyzivat, P. and J. Rosenberg, [9] Schulzrinne, H., "RPID: Rich Presence Extensions to the Presence
"RPID: Rich Presence: Extensions to the Presence Information Information Data Format (PIDF)", draft-ietf-simple-rpid-07 (work
Data Format (PIDF)", draft-ietf-simple-rpid-04 (work in in progress), June 2005.
progress), October 2004.
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
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
Hannes Tschofenig Hannes Tschofenig
Siemens Siemens
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
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
DynamicSoft DynamicSoft
600 Lanidex Plaza 600 Lanidex Plaza
Parsippany, New York 07054 Parsippany, New York 07054
USA USA
EMail: jdrosen@dynamicsoft.com Email: jdrosen@dynamicsoft.com
URI: http://www.jdrosen.net URI: http://www.jdrosen.net
Appendix A. Contributors Appendix A. Contributors
We would like to thank Christian Guenther for his help with this We would like to thank Christian Guenther for his help with this
document. document.
Christian Guenther Christian Guenther
Siemens AG Siemens AG
Corporate Technology Corporate Technology
skipping to change at page 38, line 22 skipping to change at page 40, line 22
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>, Jon <anewton@ecotroph.net>, Ted Hardie <hardie@qualcomm.com>, 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. document.
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 XCAP authorization their discussions of J. Rosenberg's draft on XCAP authorization
policies. We thank Stefan Berg, Christian Schmidt, Markus Isomaki policies. We thank Stefan Berg, Christian Schmidt, Markus Isomaki,
and Eva Maria Leppanen for their comments. Aki Niemi and Eva Maria Leppanen for their comments.
Intellectual Property Statement Intellectual Property Statement
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
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
 End of changes. 

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