draft-ietf-geopriv-common-policy-06.txt   draft-ietf-geopriv-common-policy-07.txt 
GEOPRIV H. Schulzrinne GEOPRIV H. Schulzrinne
Internet-Draft Columbia U. Internet-Draft Columbia U.
Expires: April 26, 2006 J. Morris Expires: August 15, 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
Cisco Systems Cisco Systems
October 23, 2005 February 11, 2006
A Document Format for Expressing Privacy Preferences A Document Format for Expressing Privacy Preferences
draft-ietf-geopriv-common-policy-06.txt draft-ietf-geopriv-common-policy-07.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. 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
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 26, 2006. This Internet-Draft will expire on August 15, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
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
skipping to change at page 3, line 23 skipping to change at page 3, line 23
4. Goals and Assumptions . . . . . . . . . . . . . . . . . . . . 9 4. Goals and Assumptions . . . . . . . . . . . . . . . . . . . . 9
5. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Basic Data Model and Processing . . . . . . . . . . . . . . . 12 6. Basic Data Model and Processing . . . . . . . . . . . . . . . 12
6.1. Identification of Rules . . . . . . . . . . . . . . . . . 13 6.1. Identification of Rules . . . . . . . . . . . . . . . . . 13
6.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 13 6.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Identity Condition . . . . . . . . . . . . . . . . . . . . 14 7.1. Identity Condition . . . . . . . . . . . . . . . . . . . . 14
7.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 14 7.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 14
7.1.2. Matching One Entity . . . . . . . . . . . . . . . . . 14 7.1.2. Matching One Entity . . . . . . . . . . . . . . . . . 14
7.1.3. Single Entity . . . . . . . . . . . . . . . . . . . . 15 7.1.3. Single Entity . . . . . . . . . . . . . . . . . . . . 15
7.1.4. Matching Multiple Entities . . . . . . . . . . . . . . 16 7.1.4. Matching Multiple Entities . . . . . . . . . . . . . . 15
7.2. Sphere . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.2. Sphere . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.3. Validity . . . . . . . . . . . . . . . . . . . . . . . . . 21 7.3. Validity . . . . . . . . . . . . . . . . . . . . . . . . . 20
8. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 8. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9. Transformations . . . . . . . . . . . . . . . . . . . . . . . 23 9. Transformations . . . . . . . . . . . . . . . . . . . . . . . 23
10. Procedure for Combining Permissions . . . . . . . . . . . . . 24 10. Procedure for Combining Permissions . . . . . . . . . . . . . 24
10.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 24 10.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 24
10.2. Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 24 10.2. Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 24
10.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 25 10.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 25
11. Meta Policies . . . . . . . . . . . . . . . . . . . . . . . . 28 11. Meta Policies . . . . . . . . . . . . . . . . . . . . . . . . 28
12. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 12. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
13. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 30 13. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 30
14. Security Considerations . . . . . . . . . . . . . . . . . . . 33 14. Security Considerations . . . . . . . . . . . . . . . . . . . 33
skipping to change at page 4, line 25 skipping to change at page 4, 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 [5] and domain-speific policy documents, including presence [6] and
location[6]. This relationship is shown inFigure 1. location[7]. This relationship is shown inFigure 1.
+-----------------+ +-----------------+
| | | |
| Common | | Common |
| Policy | | Policy |
| | | |
+---+---------+---+ +---+---------+---+
/|\ /|\ /|\ /|\
| | | |
+-------------------+ | | +-------------------+ +-------------------+ | | +-------------------+
skipping to change at page 6, line 42 skipping to change at page 6, 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 [7]. It refers to the The term 'using protocol' is defined in [8]. 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 14, line 37 skipping to change at page 14, line 37
or not. or not.
The <identity> condition is considered TRUE if any of its child The <identity> condition is considered TRUE if any of its child
elements (i.e., the <one/> and the <many/> elements as defined in elements (i.e., the <one/> and the <many/> elements as defined in
this document) evaluate to TRUE, i.e., the results of the individual this document) evaluate to TRUE, i.e., the results of the individual
child element are combined using a logical OR. child element are combined using a logical OR.
7.1.2. Matching One Entity 7.1.2. Matching One Entity
The <one> element matches the authenticated identity (as contained in The <one> element matches the authenticated identity (as contained in
the 'id' attribute) of exactly one entity or user and it MAY contain the 'id' attribute) of exactly one entity or user. For
a 'scheme' attribute. For considerations regarding the 'id' and the considerations regarding the 'id' attribute refer to Section 7.1.3.
'scheme' attribute refer to Section 7.1.3.
An example is shown below: An example is shown below:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<rule id="f3g44r1"> <rule id="f3g44r1">
<conditions> <conditions>
<identity> <identity>
<one id="alice@example.com"/> <one id="sip:alice@example.com"/>
<one id="+1-212-555-1234" scheme="tel"/> <one id="tel:+1-212-555-1234" />
<one id="bob@example.net" scheme="sip mailto xmpp"/> <one id="mailto:bob@example.net" />
</identity> </identity>
</conditions> </conditions>
<actions/> <actions/>
<transformations/> <transformations/>
</rule> </rule>
</ruleset> </ruleset>
This example matches if the authenticated identity of the WR is This example matches if the authenticated identity of the WR is
either alice@example.com, tel:+1-212-555-1234 or bob@example.net. either sip:alice@example.com, tel:+1-212-555-1234 or
mailto:bob@example.net.
7.1.3. Single Entity 7.1.3. Single Entity
The 'id' attribute used in the <one> and in the <except> element The 'id' attribute used in the <one> and in the <except> element
refers to a single entity. In the subsequent text we use the term refers to a single entity. In the subsequent text we use the term
'single-user' element as a placeholder for the <one> and the <except> 'single-user' element as a placeholder for the <one> and the <except>
element. element.
The <single-user> element matches the authenticated identity (as The <single-user> element matches the authenticated identity (as
contained in the 'id' attribute) of exactly one entity or user, it contained in the 'id' attribute) of exactly one entity or user. The
MAY contain a 'scheme' attribute and MUST NOT contain a 'domain' <single-user> element MUST NOT contain a 'domain' attribute.
attribute.
The content of the 'scheme' attribute of the <one> element MAY
contain more than one token representing any URI scheme registered in
the URI schemes registry [8]. The individual tokens MUST be
separated by a blank character.
Whether the 'scheme' attribute is present or not, the identity of the
WR MUST first be expressed as a URI or IRI. Applications using this
framework must describe how this is done for a particular using
protocol. Once the identity of the WR is expressed as a URI or IRI,
the scheme of that URI is compared to the schemes in the 'scheme'
attribute, if one is present.
If the 'scheme' attribute is present then two cases can be
differentiated:
1. The scheme in the URI or IRI is not listed in the 'scheme'
attribute, the 'single-user' element returns a FALSE - there is
no match.
2. The scheme in the URI or IRI is listed in the 'scheme' attribute,
the 'id' attribute is converted to a URI or IRI of that scheme.
The process for such a conversion MUST be defined by applications
of this framework for the particular URI or IRI scheme. Once the
conversion is done, a URI or IRI comparison is performed using
equality rules for that URI or IRI.
If the scheme attribute was not present, the value of 'id' attribute
is converted to a URI or IRI of the scheme used by WR's identity. If
such a conversion
1. cannot be done, the 'single-user' element returns a FALSE.
2. can be done, the conversion is done and an equivalence comparison
made using URI or IRI scheme specific matching rules. If the
result of the URI or IRI comparison is that
1. they are not equivalent, the 'single-user' element returns a
FALSE.
2. they are equivalent, it returns a TRUE.
It is important to note that the set of characters permitted for the The 'id' attribute contains an identity that MUST first be expressed
'id' element are quite broad - any UTF-8 character excepting the @ as a URI. Applications using this framework must describe how the
sign. As a consequence, there are many values of this 'id' which identities they are using can be expressed as a URIs.
cannot be represented in a paritcular URI scheme. In such a case,
the natural thing happens - there will never be a match against an
identifier in that URI scheme.
7.1.4. Matching Multiple Entities 7.1.4. Matching Multiple Entities
The <many> element is a mechanism to perform authorization decisions The <many> element is a mechanism to perform authorization decisions
based on the domain part of the authenticated identity. As such, it based on the domain part of the authenticated identity. As such, it
allows to match a large and possibly unknown number of users within a allows to match a large and possibly unknown number of users within a
domain. domain.
Furthermore, it is possible to include one or multiple <except> Furthermore, it is possible to include one or multiple <except>
elements to exclude either individual users or users belonging to a elements to exclude either individual users or users belonging to a
specific domain. Excluding individual entities is implemented using specific domain. Excluding individual entities is implemented using
a <except id="..."/> statement that might include the 'scheme' a <except id="..."/> statement. The semantic of the 'id' attribute
attribute. The semantic of the 'id' and the 'scheme' attribute of of the <except> element has the same meaning as the 'id' attribute of
the <except> element have the same meaning as the 'id' and the the <one> element (see Section 7.1.3). Excluding users belonging to
'scheme' attribute of the <one> element (see Section 7.1.3). a specific domain is implemented using the <except domain="..."/>
Excluding users belonging to a specific domain is implemented using element that excludes any user from the indicated domain.
the <except domain="..."/> element that excludes any user from the
indicated domain.
If multiple <except> elements are listed as child elements of the If multiple <except> elements are listed as child elements of the
<many> element then the result of each <except> element is combined <many> element then the result of each <except> element is combined
using a logical OR. using a logical OR.
Common policy MUST either use UTF-8 or UTF-16 to store domain names
in the 'domain' attribute. For non-IDNs, lower-case ASCII SHOULD be
used. For the comparison operation between the value stored in the
'domain' attribute and the domain value provided via the using
protocol (referred as "protocol domain identifier") the following
rules are applicable:
1. If the values of the 'domain' attribute and the value of the
protocol domain identifier does not begin with xn--, attempt a
string comparison. If the string comparison indicates equality,
the comparison succeeds and the remaining steps are skipped.
2. Translate percent-encoding for either string and repeat (1).
3. Convert both domain strings using the toASCII operation described
in RFC 3490 [2]. (Naturally, if one of the strings already
begins with the ACE prefix xn--, the conversion operation has
already been performed.)
4. Compare the two domain strings for ASCII equality, for each
label.
If the conversion fails in step (3), the domains are not equal.
7.1.4.1. Matching Any Authenticated Entity 7.1.4.1. Matching Any Authenticated Entity
The <many/> element without any child elements or attributes matches The <many/> element without any child elements or attributes matches
any authenticated user. any authenticated user.
The following example shows such a rule that matches any The following example shows such a rule that matches any
authenticated user: authenticated user:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
skipping to change at page 18, line 11 skipping to change at page 17, line 42
</rule> </rule>
</ruleset> </ruleset>
7.1.4.2. Matching Any Identity Excepting Enumerated Domains and 7.1.4.2. Matching Any Identity Excepting Enumerated Domains and
Identities Identities
The <many> element enclosing one or more <except domain="..."/> The <many> element enclosing one or more <except domain="..."/>
elements matches any user from any domain except those enumerated. elements matches any user from any domain except those enumerated.
The <except id="..."/> element excludes particular users. The The <except id="..."/> element excludes particular users. The
semantic of the 'id' and the 'scheme' attribute of the <except> semantic of the 'id' attribute of the <except> element is described
element is described in Section 7.1.3. The results of the child in Section 7.1.3. The results of the child elements of the <many>
elements of the <many> element are combined using a logical OR. element are combined using a logical OR.
An example is shown below: An example is shown below:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<rule id="f3g44r1"> <rule id="f3g44r1">
<conditions> <conditions>
<sphere value="work"/> <sphere value="work"/>
<identity> <identity>
<many> <many>
<except domain="example.com"/> <except domain="example.com"/>
<except domain="example.org"/> <except domain="example.org"/>
<except id="alice@bad.example.net"/> <except id="sip:alice@bad.example.net"/>
<except id="bob@good.example.net"/> <except id="sip:bob@good.example.net"/>
<except id="+1-212-555-1234" scheme="tel"/> <except id="tel:+1-212-555-1234" />
<except id="alice@example.com"/> <except id="sip:alice@example.com"/>
</many> </many>
</identity> </identity>
<validity> <validity>
<from>2003-12-24T17:00:00+01:00</from> <from>2003-12-24T17:00:00+01:00</from>
<until>2003-12-24T19:00:00+01:00</until> <until>2003-12-24T19:00:00+01:00</until>
</validity> </validity>
</conditions> </conditions>
<actions/> <actions/>
<transformations/> <transformations/>
</rule> </rule>
skipping to change at page 19, line 4 skipping to change at page 18, line 40
</ruleset> </ruleset>
This example matches all users except any user in example.com, or any This example matches all users except any user in example.com, or any
user in example.org or the particular users alice@bad.example.net, user in example.org or the particular users alice@bad.example.net,
bob@good.example.net and the user with the telephone number bob@good.example.net and the user with the telephone number
'tel:+1-212-555-1234'. The last 'except' element is redundant since 'tel:+1-212-555-1234'. The last 'except' element is redundant since
alice@example.com is already excluded through the first line. alice@example.com is already excluded through the first line.
7.1.4.3. Matching Any Identity Within a Domain Excepting Enumerated 7.1.4.3. Matching Any Identity Within a Domain Excepting Enumerated
Identities Identities
The <many> element with a 'domain' attribute and zero or more <except The <many> element with a 'domain' attribute and zero or more <except
id="..."/> elements matches any authenticated user from the indicated id="..."/> elements matches any authenticated user from the indicated
domain except those explicitly enumerated. The semantic of the 'id' domain except those explicitly enumerated. The semantic of the 'id'
and the 'scheme' attribute of the <except> element is described in attribute of the <except> element is described in Section 7.1.3.
Section 7.1.3.
An example is shown below: An example is shown below:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<rule id="f3g44r1"> <rule id="f3g44r1">
<conditions> <conditions>
<identity> <identity>
<many domain="example.com"> <many domain="example.com">
<except id="alice@example.com"/> <except id="sip:alice@example.com"/>
<except id="bob@example.com"/> <except id="sip:bob@example.com"/>
</many> </many>
</identity> </identity>
</conditions> </conditions>
<actions/> <actions/>
<transformations/> <transformations/>
</rule> </rule>
</ruleset> </ruleset>
This example matches any user within example.com (such as This example matches any user within example.com (such as
skipping to change at page 20, line 19 skipping to change at page 20, line 12
the sphere content. As such, the tokens are treated as opaque the sphere content. As such, the tokens are treated as opaque
strings. strings.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<rule id="f3g44r2"> <rule id="f3g44r2">
<conditions> <conditions>
<sphere value="work"/> <sphere value="work"/>
<identity> <identity>
<one id="andrew@example.com"/> <one id="sip:andrew@example.com"/>
</identity> </identity>
</conditions> </conditions>
<actions/> <actions/>
<transformations/> <transformations/>
</rule> </rule>
<rule id="y6y55r2"> <rule id="y6y55r2">
<conditions> <conditions>
<sphere value="home"/> <sphere value="home"/>
<identity> <identity>
<one id="allison@example.com"/> <one id="sip:allison@example.com"/>
</identity> </identity>
</conditions> </conditions>
<actions/> <actions/>
<transformations/> <transformations/>
</rule> </rule>
<rule id="z6y55r2"> <rule id="z6y55r2">
<conditions> <conditions>
<identity> <identity>
<one id="john@doe.com"/> <one id="sip:john@doe.com"/>
</identity> </identity>
<sphere value="home work"/> <sphere value="home work"/>
</conditions> </conditions>
<actions/> <actions/>
<transformations/> <transformations/>
</rule> </rule>
</ruleset> </ruleset>
The rule example above illustrates that the rule with the entity The rule example above illustrates that the rule with the entity
andrew@example.com matches if the sphere is been set to 'work'. In andrew@example.com matches if the sphere is been set to 'work'. In
skipping to change at page 29, line 24 skipping to change at page 29, line 24
authenticated identity (bob@example.com) and within a given time authenticated identity (bob@example.com) and within a given time
period. Additionally, the rule matches only if the target has set period. Additionally, the rule matches only if the target has set
its sphere to 'work'. its sphere to 'work'.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<rule id="f3g44r1"> <rule id="f3g44r1">
<conditions> <conditions>
<identity> <identity>
<one id="bob@example.com"/> <one id="sip:bob@example.com"/>
</identity> </identity>
<sphere value="work"/> <sphere value="work"/>
<validity> <validity>
<from>2003-12-24T17:00:00+01:00</from> <from>2003-12-24T17:00:00+01:00</from>
<until>2003-12-24T19:00:00+01:00</until> <until>2003-12-24T19:00:00+01:00</until>
</validity> </validity>
</conditions> </conditions>
<actions/> <actions/>
<transformations/> <transformations/>
</rule> </rule>
skipping to change at page 31, line 17 skipping to change at page 31, line 17
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:choice> </xs:choice>
</xs:restriction> </xs:restriction>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- //conditions/identity --> <!-- //conditions/identity -->
<xs:complexType name="identityType"> <xs:complexType name="identityType">
<xs:complexContent> <xs:complexContent>
<xs:restriction base="xs:anyType"> <xs:restriction base="xs:anyType">
<xs:choice maxOccurs="unbounded"> <xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="one" type="cp:oneType"/> <xs:element name="one" type="cp:oneType"/>
<xs:element name="many" type="cp:manyType"/> <xs:element name="many" type="cp:manyType"/>
</xs:choice> </xs:choice>
</xs:restriction> </xs:restriction>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- //identity/one --> <!-- //identity/one -->
<xs:complexType name="oneType"> <xs:complexType name="oneType">
<xs:complexContent> <xs:complexContent>
<xs:restriction base="xs:anyType"> <xs:restriction base="xs:anyType">
<xs:sequence> <xs:sequence>
<xs:any namespace="##other" <xs:any namespace="##other"
minOccurs="0" processContents="lax"/> minOccurs="0" processContents="lax"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="id" <xs:attribute name="id"
type="xs:string" use="required"/> type="xs:anyURI" use="required"/>
<xs:attribute name="scheme"
type="xs:string" use="optional"/>
</xs:restriction> </xs:restriction>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- //identity/many --> <!-- //identity/many -->
<xs:complexType name="manyType"> <xs:complexType name="manyType">
<xs:complexContent> <xs:complexContent>
<xs:restriction base="xs:anyType"> <xs:restriction base="xs:anyType">
<xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="except" type="cp:exceptType"/> <xs:element name="except" type="cp:exceptType"/>
<xs:any namespace="##other" <xs:any namespace="##other"
minOccurs="0" processContents="lax"/> minOccurs="0" processContents="lax"/>
</xs:choice> </xs:choice>
<xs:attribute name="domain" <xs:attribute name="domain"
use="optional" type="xs:string"/> use="optional" type="xs:string"/>
</xs:restriction> </xs:restriction>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- //many/except --> <!-- //many/except -->
<xs:complexType name="exceptType"> <xs:complexType name="exceptType">
<xs:attribute name="domain" type="xs:string" use="optional"/> <xs:attribute name="domain" type="xs:string" use="optional"/>
<xs:attribute name="id" type="xs:string" use="optional"/> <xs:attribute name="id" type="xs:anyURI" use="optional"/>
<xs:attribute name="scheme" type="xs:string" use="optional"/>
</xs:complexType> </xs:complexType>
<!-- //conditions/sphere --> <!-- //conditions/sphere -->
<xs:complexType name="sphereType"> <xs:complexType name="sphereType">
<xs:complexContent> <xs:complexContent>
<xs:restriction base="xs:anyType"> <xs:restriction base="xs:anyType">
<xs:attribute name="value" <xs:attribute name="value"
type="xs:string" use="required"/> type="xs:string" use="required"/>
</xs:restriction> </xs:restriction>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
skipping to change at page 34, line 9 skipping to change at page 34, 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 [2]. procedures in [3].
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 34, line 44 skipping to change at page 34, 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 [3] and guidelines in RFC according to the procedures of RFC 2048 [4] and guidelines in RFC
3023 [4]. 3023 [5].
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 [4], Section 3.2. character encoding used. See RFC 3023 [5], 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 37, line 12 skipping to change at page 37, 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, [2] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing
Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[3] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[3] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet [4] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet
Mail Extensions (MIME) Part Four: Registration Procedures", Mail Extensions (MIME) Part Four: Registration Procedures",
BCP 13, RFC 2048, November 1996. BCP 13, RFC 2048, November 1996.
[4] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", [5] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
RFC 3023, January 2001. RFC 3023, January 2001.
16.2. Informative References 16.2. Informative References
[5] Rosenberg, J., "Presence Authorization Rules", [6] Rosenberg, J., "Presence Authorization Rules",
draft-ietf-simple-presence-rules-03 (work in progress), draft-ietf-simple-presence-rules-04 (work in progress),
July 2005. October 2005.
[6] Schulzrinne, H., "A Document Format for Expressing Privacy [7] Schulzrinne, H., "A Document Format for Expressing Privacy
Preferences for Location Information", Preferences for Location Information",
draft-ietf-geopriv-policy-06 (work in progress), July 2005. draft-ietf-geopriv-policy-07 (work in progress), October 2005.
[7] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. [8] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.
Polk, "Geopriv Requirements", RFC 3693, February 2004. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[8] , ., "Uniform Resource Identifier (URI) SCHEMES, available
at: http://www.iana.org/assignments/uri-schemes", , .
[9] Schulzrinne, H., "RPID: Rich Presence Extensions to the [9] Schulzrinne, H., "RPID: Rich Presence Extensions to the
Presence Information Data Format (PIDF)", Presence Information Data Format (PIDF)",
draft-ietf-simple-rpid-09 (work in progress), September 2005. draft-ietf-simple-rpid-10 (work in progress), December 2005.
[10] Jennings, C., Peterson, J., and M. Watson, "Private Extensions [10] Jennings, C., Peterson, J., and M. Watson, "Private Extensions
to 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.
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 initial
document. versions of this document.
Appendix B. Acknowledgments Appendix B. Acknowledgments
This document is partially based on the discussions within the IETF This document is partially based on the discussions within the IETF
GEOPRIV working group. Discussions at the Geopriv Interim Meeting GEOPRIV working group. Discussions at the Geopriv Interim Meeting
2003 in Washington, D.C., helped the working group to make progress 2003 in Washington, D.C., helped the working group to make progress
on the authorization policies based on the discussions among the on the authorization policies based on the discussions among the
participants. participants.
We particularly want to thank Allison Mankin <mankin@psg.com>, We particularly want to thank Allison Mankin <mankin@psg.com>,
Randall Gellens <rg+ietf@qualcomm.com>, Andrew Newton Randall Gellens <rg+ietf@qualcomm.com>, Andrew Newton
<anewton@ecotroph.net>, Ted Hardie <hardie@qualcomm.com>, 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. Allison, Ted and Andrew helped us to make good progress
with the internationalization support of the identifier/domain
attributes.
Furthermore, we would like to thank the IETF SIMPLE working group for Furthermore, we would like to thank the IETF SIMPLE working group for
their discussions of J. Rosenberg's draft on XCAP authorization their discussions of J. Rosenberg's draft on presence authorization
policies. We thank Stefan Berg, Murugaraj Shanmugam, Christian policies. We would also like to thank Stefan Berg, Murugaraj
Schmidt, Martin Thomson, Markus Isomaki, Aki Niemi and Eva Maria Shanmugam, Christian Schmidt, Martin Thomson, Markus Isomaki, Aki
Leppanen for their comments. Niemi and Eva Maria Leppanen for their comments. Martin Thomson
helped us with the XML schema.
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 42, line 41 skipping to change at page 42, 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 (2005). This document is subject Copyright (C) The Internet Society (2006). 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. 44 change blocks. 
120 lines changed or deleted 97 lines changed or added

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