draft-ietf-geopriv-common-policy-03.txt   draft-ietf-geopriv-common-policy-04.txt 
GEOPRIV H. Schulzrinne GEOPRIV H. Schulzrinne
Internet-Draft Columbia U. Internet-Draft Columbia U.
Expires: April 24, 2005 J. Morris Expires: August 22, 2005 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
October 24, 2004 February 21, 2005
A Document Format for Expressing Privacy Preferences A Document Format for Expressing Privacy Preferences
draft-ietf-geopriv-common-policy-03.txt draft-ietf-geopriv-common-policy-04.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, I certify that any applicable
of section 3 of RFC 3667. By submitting this Internet-Draft, each patent or other IPR claims of which I am aware have been disclosed,
author represents that any applicable patent or other IPR claims of and any of which I become aware will be disclosed, in accordance with
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
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-Drafts. Internet-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 April 24, 2005. This Internet-Draft will expire on August 22, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005). All Rights Reserved.
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 26 skipping to change at page 2, line 25
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.2 Sphere . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.3 Validity . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.3 Validity . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9. Transformations . . . . . . . . . . . . . . . . . . . . . . 18 9. Transformations . . . . . . . . . . . . . . . . . . . . . . 19
10. Procedure for Combining Permissions . . . . . . . . . . . . 19 10. Procedure for Combining Permissions . . . . . . . . . . . . 20
10.1 Introduction . . . . . . . . . . . . . . . . . . . . . . 19 10.1 Introduction . . . . . . . . . . . . . . . . . . . . . . 20
10.2 Algorithm . . . . . . . . . . . . . . . . . . . . . . . 19 10.2 Algorithm . . . . . . . . . . . . . . . . . . . . . . . 20
10.3 Example . . . . . . . . . . . . . . . . . . . . . . . . 20 10.3 Example . . . . . . . . . . . . . . . . . . . . . . . . 21
11. Meta Policies . . . . . . . . . . . . . . . . . . . . . . . 23 11. Meta Policies . . . . . . . . . . . . . . . . . . . . . . . 24
12. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 24 12. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 25
13. XML Schema Definition . . . . . . . . . . . . . . . . . . . 25 13. XML Schema Definition . . . . . . . . . . . . . . . . . . . 27
14. Security Considerations . . . . . . . . . . . . . . . . . . 28 14. Security Considerations . . . . . . . . . . . . . . . . . . 30
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 29 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 31
15.1 Common Policy Namespace Registration . . . . . . . . . . 29 15.1 Common Policy Namespace Registration . . . . . . . . . . 31
15.2 Content-type registration for 15.2 Content-type registration for
'application/auth-policy+xml' . . . . . . . . . . . . . 29 'application/auth-policy+xml' . . . . . . . . . . . . . 31
15.3 Common Policy Schema Registration . . . . . . . . . . . 31 15.3 Common Policy Schema Registration . . . . . . . . . . . 33
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
16.1 Normative References . . . . . . . . . . . . . . . . . . . 32 16.1 Normative References . . . . . . . . . . . . . . . . . . . 34
16.2 Informative References . . . . . . . . . . . . . . . . . . 32 16.2 Informative References . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 35
A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 35 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 37
B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 36 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 38
Intellectual Property and Copyright Statements . . . . . . . 37 Intellectual Property and Copyright Statements . . . . . . . 39
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 3, line 25 skipping to change at page 3, line 25
reuses the same underlying authorization mechanism. Second, it reuses the same underlying authorization mechanism. Second, it
encourages a more generic authorization framework with mechanisms for encourages a more generic authorization framework with mechanisms for
extensibility. The applicability of the framework specified in this extensibility. The applicability of the framework specified in this
document is not limited to policies controling access to presence and document is not limited to policies controling access to presence and
location information data, but can be extended to other application location information data, but can be extended to other application
domains. domains.
The general framework defined in this document is intended to be The general framework defined in this document is intended to be
accompanied and enhanced by application-specific policies specified accompanied and enhanced by application-specific policies specified
elsewhere. The common policy framework described here is enhanced by elsewhere. The common policy framework described here is enhanced by
domain-speific policy documents, including presence domain-speific policy documents, including presence [5] and
[I-D.ietf-simple-presence-rules] and location[6]. This relationship is shown inFigure 1.
location[I-D.ietf-geopriv-policy]. This relationship is shown
inFigure 1.
+-----------------+ +-----------------+
| | | |
| Common | | Common |
| Policy | | Policy |
| | | |
+---+---------+---+ +---+---------+---+
/|\ /|\ /|\ /|\
| | | |
+-------------------+ | | +-------------------+ +-------------------+ | | +-------------------+
skipping to change at page 5, line 9 skipping to change at page 5, line 9
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 Section
13. IANA considerations in Section 15 follow security considerations 13. IANA considerations in Section 15 follow security considerations
Section 14. Section 14.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT","RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT","RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. 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
skipping to change at page 5, line 42 skipping to change at page 5, line 42
The term 'permission' indicates the action and transformation The term 'permission' indicates the action and transformation
components of a 'rule'. components of a 'rule'.
The terms 'authorization policy', 'policy' and 'rule set' are used The terms 'authorization policy', 'policy' and 'rule set' are used
interchangeably. interchangeably.
The terms 'authorization policy rule', 'policy rule' and 'rule' are The terms 'authorization policy rule', 'policy rule' and 'rule' are
used interchangeable. used interchangeable.
The term 'using protocol' is defined in [RFC3693]. It refers to the The term 'using protocol' is defined in [7]. It refers to the
protocol which is used to request access to and to return privacy protocol which is used to request access to and to return privacy
sensitive data items. sensitive data items.
3. Modes of Operation 3. Modes of Operation
The abstract sequence of operations can roughly be described as The abstract sequence of operations can roughly be described as
follows. The PS receives a query for data items for a particular PT, follows. The PS receives a query for data items for a particular PT,
via the using protocol. The using protocol provides the identity of via the using protocol. The using protocol provides the identity of
the requestor (or more precisely the authentication protocol), either the requestor (or more precisely the authentication protocol), either
at the time of the query or at the subscription time. The at the time of the query or at the subscription time. The
skipping to change at page 13, line 20 skipping to change at page 13, line 20
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 policy framework specified in this document supports the usage of
authenticated identities as input to access authorization decision identities as input to access authorization decision processes. This
processes. This framework, however, abstracts from the framework, however, abstracts from the particularities of concrete
particularities of concrete authentication mechanisms employed by authentication mechanisms employed by different using protocols and
different using protocols and is therefore unable to specify is therefore unable to specify explicitly the details of identity
explicitly the details of identity relevant information. This relevant information. This document only assumes that the identity
document only assumes that the identity has a username part and a has a username part and a domain part. Documents that enhance this
domain part. Documents that enhance this framework should describe framework should describe how a particular using protocol is able to
how a particular using protocol is able to provide identity provide identity information in a meaningful way.
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 domain of the user) and the identities used in the authorization
policies. This mapping needs to consider the large number of policies. This mapping needs to consider the large number of
possible identities used in various authentication protocols and also possible identities used in various authentication protocols and also
to consider identities in using protocols. Furthermore, it is to consider identities in using protocols. Most using protocols also
important to designate an identifier that denotes an 'anonymous designate an identifier that denotes an 'anonymous user', i.e., a
user', i.e., a user that has not authenticated itself to the PS. The user that has not authenticated directly to the PS but to another
authors suggest to treat anonymous users by omitting this attribute party (asserting party) that provides an assertion to the PS that
in the rule which causes a 'NULL' value to be created in the ruleset this user has been authenticated. It is assumed that PS and the
table of a relational database. Any request for a data item (for a asserting party have some relationship with each other and there is a
given PT) would match with respect to this attribute in a rule. certain degree of trust. An example of this approach can be found in
Furthermore, pseudonyms need to be addressed as part of this mapping [8]. For this purpose this document defines the element <anonymous>.
process. 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 This specification provides an <identity> element which belongs to
the group of condition elements. It can have either the <id> or the the group of condition elements. It can have either the <id> or the
<domain> element as child elements. The <domain> element contains a <domain> element as child elements. The <domain> element contains a
list of <except> elements and allows to implement a simple blacklist list of <except> elements and allows to implement a simple blacklist
mechanism. The <except> element contains the identity without the mechanism. The <except> element contains the identity without the
domain part since it equals the domain of the <domain> element. The domain part since it equals the domain of the <domain> element. The
following example illustrates conditions based on an identity. following example illustrates conditions based on an identity.
<identity> <identity>
skipping to change at page 14, line 41 skipping to change at page 14, line 43
the domain element, and the user part matches none of the <except> the domain element, and the user part matches none of the <except>
element values, based on case sensitive string comparison. element values, based on case sensitive string comparison.
<identity> <identity>
<domain>example.com</domain> <domain>example.com</domain>
<except>joe</except> <except>joe</except>
<except>tony</except> <except>tony</except>
<except>mike</except> <except>mike</except>
</identity> </identity>
The following guidelines apply when matching the identity with the
rules:
A rule with no conditions matches any subscription (authenticated
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
request is authenticated. Unauthenticated identities do not match
the <anonymous> condition.
The <any-identity> condition that matches any authenticated
identity.
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 [I-D.ietf-simple-rpid] provides the ability to inform the PS of RPID [9] provides the ability to inform the PS of its current sphere.
its current sphere. The application domain needs to describe in more The application domain needs to describe in more detail how the
detail how the sphere state is determined. Switching from one sphere sphere state is determined. Switching from one sphere to another
to another causes to switch between different modes of visibility. causes to switch between different modes of visibility. As a result
As a result different subsets of rules might be applicable. An different subsets of rules might be applicable. An example of a rule
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>work</sphere>
<identity> <identity>
<id>andrew@example.com</id> <id>andrew@example.com</id>
</identity> </identity>
skipping to change at page 24, line 7 skipping to change at page 25, 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 a basic example of an XML document valid with This section gives two basic example of an XML document valid with
respect to the XML schema defined in Section 13. Semantically richer respect 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
authenticated identity (bob@example.com) and within a given time
period.
<?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>bob@example.com</id>
</identity> </identity>
<validity> <validity>
skipping to change at page 25, line 5 skipping to change at page 25, line 38
<to>2003-12-24T19:00:00+01:00</to> <to>2003-12-24T19:00:00+01:00</to>
</validity> </validity>
</conditions> </conditions>
<actions/> <actions/>
</rule> </rule>
</ruleset> </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>
</conditions>
<actions/>
</rule>
</ruleset>
13. XML Schema Definition 13. XML Schema Definition
This section provides the XML schema definition for the common policy This section provides the XML schema definition for the common policy
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"
skipping to change at page 26, line 37 skipping to change at page 28, line 37
<xs:choice> <xs:choice>
<xs:element name="id" type="xs:string" <xs:element name="id" type="xs:string"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
<xs:sequence> <xs:sequence>
<xs:element name="domain" type="xs:string"/> <xs:element name="domain" type="xs:string"/>
<xs:sequence minOccurs="0"> <xs:sequence minOccurs="0">
<xs:element name="except" type="xs:string" <xs:element name="except" type="xs:string"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:sequence> </xs:sequence>
<xs:element name="anonymous" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:sequence minOccurs="0">
<xs:element name="domain" type="xs:string"/>
</xs:sequence>
<xs:element name="any-identity" type="xs:string"
minOccurs="0" maxOccurs="1"/>
</xs:choice> </xs:choice>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
</xs:schema> </xs:schema>
Although the XML schema does not require detailed explanations the Although the XML schema does not require detailed explanations the
following issues are worth mentioning: Each of the <conditions>, following issues are worth mentioning: Each of the <conditions>,
<actions>, and <transformations> (plural!) elements consists of zero <actions>, and <transformations> (plural!) elements consists of zero
or more child elements that belong to the substitution groups or more child elements that belong to the substitution groups
skipping to change at page 29, line 9 skipping to change at page 31, line 9
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
usage of the permissions combining rules of Section 10 does not lower usage of the permissions combining rules of Section 10 does not lower
the level of privacy protection. See Section 10 for more details on the level of privacy protection. See Section 10 for more details on
this privacy issue. this privacy issue.
15. IANA Considerations 15. IANA Considerations
This section registers a new XML namespace, a new XML schema and a This section registers a new XML namespace, a new XML schema and a
new MIME-type. This section registers a new XML namespace per the new MIME-type. This section registers a new XML namespace per the
procedures in [RFC3688]. procedures in [2].
15.1 Common Policy Namespace Registration 15.1 Common Policy Namespace Registration
URI: urn:ietf:params:xml:ns:common-policy URI: urn:ietf:params:xml:ns:common-policy
Registrant Contact: IETF Geopriv Working Group, Henning Schulzrinne Registrant Contact: IETF Geopriv Working Group, Henning Schulzrinne
(hgs+geopriv@cs.columbia.edu). (hgs+geopriv@cs.columbia.edu).
XML: XML:
skipping to change at page 29, line 44 skipping to change at page 31, line 44
[NOTE TO IANA/RFC-EDITOR: [NOTE TO IANA/RFC-EDITOR:
Please replace XXXX with the RFC number of this Please replace XXXX with the RFC number of this
specification.]</a>.</p> specification.]</a>.</p>
</body> </body>
</html> </html>
END END
15.2 Content-type registration for 'application/auth-policy+xml' 15.2 Content-type registration for 'application/auth-policy+xml'
This specification requests the registration of a new MIME type This specification requests the registration of a new MIME type
according to the procedures of RFC 2048 [RFC2048] and guidelines in according to the procedures of RFC 2048 [3] and guidelines in RFC
RFC 3023 [RFC3023]. 3023 [4].
MIME media type name: application MIME media type name: application
MIME subtype name: auth-policy+xml MIME subtype name: auth-policy+xml
Mandatory parameters: none Mandatory parameters: none
Optional parameters: charset Optional parameters: charset
Indicates the character encoding of enclosed XML. Default is Indicates the character encoding of enclosed XML. Default is
UTF-8. UTF-8.
Encoding considerations: Encoding considerations:
Uses XML, which can employ 8-bit characters, depending on the Uses XML, which can employ 8-bit characters, depending on the
character encoding used. See RFC 3023 [RFC3023], Section 3.2. character encoding used. See RFC 3023 [4], Section 3.2.
Security considerations: Security considerations:
This content type is designed to carry authorization policies. This content type is designed to carry authorization policies.
Appropriate precautions should be adopted to limit disclosure of Appropriate precautions should be adopted to limit disclosure of
this information. Please refer to RFCXXXX [NOTE TO IANA/ this information. Please refer to RFCXXXX [NOTE TO IANA/
RFC-EDITOR: Please replace XXXX with the RFC number of this RFC-EDITOR: Please replace XXXX with the RFC number of this
specification.] security considerations section for more specification.] security considerations section for more
information. information.
skipping to change at page 32, line 9 skipping to change at page 34, line 9
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
and its last line is and its last line is
</xs:schema> </xs:schema>
16. References 16. References
16.1 Normative References 16.1 Normative References
[RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Internet Mail Extensions (MIME) Part Four: Registration Levels", March 1997.
Procedures", BCP 13, RFC 2048, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [2] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January
Requirement Levels", March 1997. 2004.
[RFC3023] Murata, M., St. Laurent, S. and D. Kohn, "XML Media [3] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet
Types", RFC 3023, January 2001. Mail Extensions (MIME) Part Four: Registration Procedures", BCP
13, RFC 2048, November 1996.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [4] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC
January 2004. 3023, January 2001.
16.2 Informative References 16.2 Informative References
[I-D.ietf-geopriv-policy] [5] Rosenberg, J., "Presence Authorization Rules",
Schulzrinne, H., "A Document Format for Expressing Privacy draft-ietf-simple-presence-rules-01 (work in progress), October
Preferences for Location Information",
draft-ietf-geopriv-policy-03 (work in progress), October
2004. 2004.
[I-D.ietf-simple-presence-rules] [6] Schulzrinne, H., "A Document Format for Expressing Privacy
Rosenberg, J., "Presence Authorization Rules", Preferences for Location Information",
draft-ietf-simple-presence-rules-00 (work in progress), draft-ietf-geopriv-policy-05 (work in progress), November 2004.
May 2004.
[I-D.ietf-simple-rpid] [7] Cuellar, J., Morris, J., Mulligan, D., Peterson, J. and J. Polk,
Schulzrinne, H., Gurbani, V., Kyzivat, P. and J. "Geopriv Requirements", RFC 3693, February 2004.
Rosenberg, "RPID: Rich Presence: Extensions to the
Presence Information Data Format (PIDF)",
draft-ietf-simple-rpid-03 (work in progress), March 2004.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J. and J. [8] Jennings, C., Peterson, J. and M. Watson, "Private Extensions to
Polk, "Geopriv Requirements", RFC 3693, February 2004. the Session Initiation Protocol (SIP) for Asserted Identity
within Trusted Networks", RFC 3325, November 2002.
[9] Schulzrinne, H., Gurbani, V., Kyzivat, P. and J. Rosenberg,
"RPID: Rich Presence: Extensions to the Presence Information
Data Format (PIDF)", draft-ietf-simple-rpid-04 (work in
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
skipping to change at page 33, line 30 skipping to change at page 35, line 30
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, Bayern 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, Bayern 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
skipping to change at page 37, line 41 skipping to change at page 39, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

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