SANSUNG 1031
`
`1
`
`Network Working Group H. Schulzrinne
`Request for Comments: 4745 Columbia U.
`Category: Standards Track H. Tschofenig
`Siemens Networks GmbH & Co KG
`J. Morris
`CDT
`J. Cuellar
`Siemens
`J. Polk
`J. Rosenberg
`Cisco
`February 2007
`Common Policy: A Document Format for Expressing Privacy Preferences
`Status of This Memo
`This document specifies an Internet standards track protocol for the
`Internet community, and requests discussion and suggestions for
`improvements. Please refer to the current edition of the "Internet
`Official Protocol Standards" (STD 1) for the standardization state
`and status of this protocol. Distribution of this memo is unlimited.
`Copyright Notice
`Copyright (C) The IETF Trust (2007).
`Abstract
`This document defines a framework for authorization policies
`controlling access to application-specific data. This framework
`combines common location- and presence-specific authorization
`aspects. An XML schema specifies the language in which common policy
`rules are represented. The common policy framework can be extended
`to other application domains.
`Schulzrinne, et al. Standards Track [Page 1]
`

`

`2
`
`RFC 4745 Common Policy February 2007
`Table of Contents
`1. Introduction ....................................................3
`2. Terminology .....................................................4
`3. Modes of Operation ..............................................4
`3.1. Passive Request-Response - PS as Server (Responder) ........5
`3.2. Active Request-Response - PS as Client (Initiator) .........5
`3.3. Event Notification .........................................5
`4. Goals and Assumptions ...........................................6
`5. Non-Goals .......................................................7
`6. Basic Data Model and Processing .................................8
`6.1. Identification of Rules ....................................9
`6.2. Extensions .................................................9
`7. Conditions .....................................................10
`7.1. Identity Condition ........................................10
`7.1.1. Overview ...........................................10
`7.1.2. Matching One Entity ................................11
`7.1.3. Matching Multiple Entities .........................11
`7.2. Single Entity .............................................14
`7.3. Sphere ....................................................15
`7.4. Validity ..................................................16
`8. Actions ........................................................17
`9. Transformations ................................................18
`10. Procedure for Combining Permissions ...........................18
`10.1. Introduction .............................................18
`10.2. Combining Rules (CRs) ....................................18
`10.3. Example ..................................................19
`11. Meta Policies .................................................21
`12. Example .......................................................21
`13. XML Schema Definition .........................................22
`14. Security Considerations .......................................25
`15. IANA Considerations ...........................................25
`15.1. Common Policy Namespace Registration .....................25
`15.2. Content-type Registration for
`'application/auth-policy+xml' ............................26
`15.3. Common Policy Schema Registration ........................27
`16. References ....................................................27
`16.1. Normative References .....................................27
`16.2. Informative References ...................................28
`Appendix A. Contributors ..........................................29
`Appendix B. Acknowledgments .......................................29
`Schulzrinne, et al. Standards Track [Page 2]
`

`

`3
`
`RFC 4745 Common Policy February 2007
`1. Introduction
`This document defines a framework for creating authorization policies
`for access to application-specific data. This framework is the
`result of combining the common aspects of single authorization
`systems that more specifically control access to presence and
`location information and that previously had been developed
`separately. The benefit of combining these two authorization systems
`is two-fold. First, it allows building a system that enhances the
`value of presence with location information in a natural way and
`reuses the same underlying authorization mechanism. Second, it
`encourages a more generic authorization framework with mechanisms for
`extensibility. The applicability of the framework specified in this
`document is not limited to policies controlling access to presence
`and location information data, but can be extended to other
`application domains.
`The general framework defined in this document is intended to be
`accompanied and enhanced by application-specific policies specified
`elsewhere. The common policy framework described here is enhanced by
`domain-specific policy documents, including presence [7] and location
`[8]. This relationship is shown in Figure 1.
`+-----------------+
`| |
`| Common |
`| Policy |
`| |
`+---+---------+---+
`/|\ /|\
`| |
`+-------------------+ | | +-------------------+
`| | | enhance | | |
`| Location-specific | | | | Presence-specific |
`| Policy |----+ +----| Policy |
`| | | |
`+-------------------+ +-------------------+
`Figure 1: Common Policy Enhancements
`This document starts with an introduction to the terminology in
`Section 2, an illustration of basic modes of operation in Section 3,
`a description of goals (see Section 4) and non-goals (see Section 5)
`of the policy framework, followed by the data model in Section 6.
`The structure of a rule, namely, conditions, actions, and
`transformations, is described in Sections 7, 8, and 9. The procedure
`for combining permissions is explained in Section 10 and used when
`conditions for more than one rule are satisfied. A short description
`Schulzrinne, et al. Standards Track [Page 3]
`

`

`4
`
`RFC 4745 Common Policy February 2007
`of meta policies is given in Section 11. An example is provided in
`Section 12. The XML schema will be discussed in Section 13. IANA
`considerations in Section 15 follow security considerations in
`Section 14.
`2. Terminology
`The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
`"SHOULD", "SHOULD NOT","RECOMMENDED", "MAY", and "OPTIONAL" in this
`document are to be interpreted as described in [1].
`This document introduces the following terms:
`PT - Presentity / Target: The PT is the entity about whom
`information has been requested.
`RM - Rule Maker: The RM is an entity that creates the authorization
`rules that restrict access to data items.
`PS - (Authorization) Policy Server: This entity has access to both
`the authorization policies and the data items. In location-
`specific applications, the entity PS is labeled as location
`server (LS).
`WR - Watcher / Recipient: This entity requests access to data items
`of the PT. An access operation might be a read, a write, or any
`other operation.
`A policy is given by a 'rule set' that contains an unordered list of
`'rules'. A 'rule' has a 'conditions', an 'actions', and a
`'transformations' part.
`The term 'permission' indicates the action and transformation
`components of a 'rule'.
`The term 'using protocol' is defined in [9]. It refers to the
`protocol used to request access to and to return privacy-sensitive
`data items.
`3. Modes of Operation
`The abstract sequence of operations can roughly be described as
`follows. The PS receives a query for data items for a particular PT,
`via the using protocol. The using protocol (or more precisely, the
`authentication protocol) provides the identity of the requestor,
`either at the time of the query or at the subscription time. The
`authenticated identity of the WR, together with other information
`provided by the using protocol or generally available to the server,
`Schulzrinne, et al. Standards Track [Page 4]
`

`

`5
`
`RFC 4745 Common Policy February 2007
`is then used for searching through the rule set. All matching rules
`are combined according to a permission combining algorithm described
`in Section 10. The combined rules are applied to the application
`data, resulting in the application of privacy based on the
`transformation policies. The resulting application data is returned
`to the WR.
`Three different modes of operation can be distinguished:
`3.1. Passive Request-Response - PS as Server (Responder)
`In a passive request-response mode, the WR queries the PS for data
`items about the PT. Examples of protocols following this mode of
`operation include HTTP, FTP, LDAP, finger, and various remote
`procedure call (RPC) protocols, including Sun RPC, Distributed
`Computing Environment (DCE), Distributed Component Object Model
`(DCOM), common object request broker architecture (Corba), and Simple
`Object Access Protocol (SOAP). The PS uses the rule set to determine
`whether the WR is authorized to access the PT's information, refusing
`the request if necessary. Furthermore, the PS might filter
`information by removing elements or by reducing the resolution of
`elements.
`3.2. Active Request-Response - PS as Client (Initiator)
`Alternatively, the PS may contact the WR and convey data items.
`Examples include HTTP, SIP session setup (INVITE request), H.323
`session setup or SMTP.
`3.3. Event Notification
`Event notification adds a subscription phase to the "Active Request-
`Response - PS as Client (Initiator)" mode of operation. A watcher or
`subscriber asks to be added to the notification list for a particular
`presentity or event. When the presentity changes state or the event
`occurs, the PS sends a message to the WR containing the updated
`state. (Presence is a special case of event notification; thus, we
`often use the term interchangeably.)
`In addition, the subscriber may itself add a filter to the
`subscription, limiting the rate or content of the notifications. If
`an event, after filtering by the rule-maker-provided rules and by the
`subscriber-provided rules, only produces the same notification
`content that was sent previously, no event notification is sent.
`Schulzrinne, et al. Standards Track [Page 5]
`

`

`6
`
`RFC 4745 Common Policy February 2007
`A single PS may authorize access to data items in more than one mode.
`Rather than having different rule sets for different modes all three
`modes are supported with a one rule set schema. Specific instances
`of the rule set can omit elements that are only applicable to the
`subscription model.
`4. Goals and Assumptions
`Below, we summarize our design goals and constraints.
`Table representation:
`Each rule must be representable as a row in a relational database.
`This design goal should allow efficient policy implementation by
`utilizing standard database optimization techniques.
`Permit only:
`Rules only provide permissions rather than denying them. Removing
`a rule can never increase permissions. Depending on the
`interpretation of 'deny' and 'permit' rules, the ordering of rules
`might matter, making updating rule sets more complicated since
`such update mechanisms would have to support insertion at specific
`locations in the rule set. Additionally, it would make
`distributed rule sets more complicated. Hence, only 'permit'
`actions are allowed that result in more efficient rule processing.
`This also implies that rule ordering is not important.
`Consequently, to make a policy decision requires processing all
`rules.
`Additive permissions:
`A query for access to data items is matched against the rules in
`the rule database. If several rules match, then the overall
`permissions granted to the WR are the union of those permissions.
`A more detailed discussion is provided in Section 10.
`Upgradeable:
`It should be possible to add additional rules later, without
`breaking PSs that have not been upgraded. Any such upgrades must
`not degrade privacy constraints, but PSs not yet upgraded may
`reveal less information than the rule maker would have chosen.
`Schulzrinne, et al. Standards Track [Page 6]
`

`

`7
`
`RFC 4745 Common Policy February 2007
`Capability support:
`In addition to the previous goal, a RM should be able to determine
`which extensions 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 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
`time zone of his current location, which may not be known to other
`components of the system.)
`5. Non-Goals
`We explicitly decided that a number of possibly worthwhile
`capabilities are beyond the scope of this first version. Future
`versions may include these capabilities, using the extension
`mechanism described in this document. Non-goals include:
`No external references:
`Attributes within specific rules cannot refer to external rule
`sets, databases, directories, or other network elements. Any such
`external reference would make simple database implementation
`difficult and hence they are not supported in this version.
`No regular expressions:
`Conditions are matched on equality or 'greater-than'-style
`comparisons, not regular expressions, partial matches such as the
`SQL LIKE operator (e.g., LIKE "%foo%"), or glob-style matches
`("*@example.com"). Most of these are better expressed as explicit
`elements.
`Schulzrinne, et al. Standards Track [Page 7]
`

`

`8
`
`RFC 4745 Common Policy February 2007
`No repeat times:
`Repeat times (e.g., every day from 9 am to 4 pm) are difficult to
`make work correctly, due to the different time zones that PT, WR,
`PS, and RM may occupy. It appears that suggestions for including
`time intervals are often based on supporting work/non-work
`distinctions, which unfortunately are difficult to capture by time
`alone. Note that this feature must not be confused with the
`'Validity' element that provides a mechanism to restrict the
`lifetime of a rule.
`6. Basic Data Model and Processing
`A rule set (or synonymously, a policy) consists of zero or more
`rules. The ordering of these rules is irrelevant. The rule set can
`be stored at the PS and conveyed from RM to PS as a single document,
`in subsets or as individual rules. A rule consists of three parts:
`conditions (see
`Section 7), actions (see Section 8), and
`transformations (see Section 9).
`The conditions part is a set of expressions, each of which evaluates
`to either TRUE or FALSE. When a WR asks for information about a PT,
`the PS goes through each rule in the rule set. For each rule, it
`evaluates the expressions in the conditions part. If all of the
`expressions evaluate to TRUE, then the rule is applicable to this
`request. Generally, each expression specifies a condition based on
`some variable that is associated with the context of the request.
`These variables can include the identity of the WR, the domain of the
`WR, the time of day, or even external variables, such as the
`temperature or the mood of the PT.
`Assuming that the rule is applicable to the request, the actions and
`transformations (commonly referred to as permissions) in the rule
`specify how the PS is supposed to handle this request. If the
`request is to view the location of the PT, or to view its presence,
`the typical action is "permit", which allows the request to proceed.
`Assuming the action allows the request to proceed, the
`transformations part of the rule specifies how the information about
`the PT -- their location information, their presence, etc. -- is
`modified before being presented to the WR. These transformations are
`in the form of positive permissions. That is, they always specify a
`piece of information that is allowed to be seen by the WR. When a PS
`processes a request, it takes the transformations specified across
`all rules that match, and creates the union of them. For computing
`this union, the data type, such as Integer, Boolean, Set, or the
`Undef data type, plays a role. The details of the algorithm for
`combining permissions is described in Section 10. The resulting
`Schulzrinne, et al. Standards Track [Page 8]
`

`

`9
`
`RFC 4745 Common Policy February 2007
`union effectively represents a "mask" -- it defines what information
`is exposed to the WR. This mask is applied to the actual location or
`presence data for the PT, and the data that is permitted by the mask
`is shown to the WR. If the WR requests a subset of information only
`(such as city-level civic location data only, instead of the full
`civic location information), the information delivered to the WR MUST
`be the intersection of the permissions granted to the WR and the data
`requested by the WR.
`Rules are encoded in XML. To this end, Section 13 contains an XML
`schema defining the Common Policy Markup Language. This, however, is
`purely an exchange format between RM and PS. The format does not
`imply that the RM or the PS use this format internally, e.g., in
`matching a query with the policy rules. The rules are designed so
`that a PS can translate the rules into a relational database table,
`with each rule represented by one row in the database. The database
`representation is by no means mandatory; we will use it as a
`convenient and widely-understood example of an internal
`representation. The database model has the advantage that operations
`on rows have tightly defined meanings. In addition, it appears
`plausible that larger-scale implementations will employ a backend
`database to store and query rules, as they can then benefit from
`existing optimized indexing, access control, scaling, and integrity
`constraint mechanisms. Smaller-scale implementations may well choose
`different implementations, e.g., a simple traversal of the set of
`rules.
`6.1. Identification of Rules
`Each rule is equipped with a parameter that identifies the rule.
`This rule identifier is an opaque token chosen by the RM. A RM MUST
`NOT use the same identifier for two rules that are available to the
`PS at the same time for a given PT. If more than one RM modifies the
`same rule set, then it needs to be ensured that a unique identifier
`is chosen for each rule. A RM can accomplish this goal by retrieving
`the already specified rule set and choosing a new identifier for a
`rule that is different from the existing rule set.
`6.2. Extensions
`The policy framework defined in this document is meant to be
`extensible towards specific application domains. Such an extension
`is accomplished by defining conditions, actions, and transformations
`that are specific to the desired application domain. Each extension
`MUST define its own namespace.
`Schulzrinne, et al. Standards Track [Page 9]
`

`

`10
`
`RFC 4745 Common Policy February 2007
`Extensions cannot change the schema defined in this document, and
`this schema is not expected to change except via revision to this
`specification. Therefore, no versioning procedures for this schema
`or namespace are provided.
`7. Conditions
`The access to data items needs to be matched with the rule set stored
`at the PS. Each instance of a request has different attributes
`(e.g., the identity of the requestor) that are used for
`authorization. A rule in a rule set might have a number of
`conditions that need to be met before executing the remaining parts
`of a rule (i.e., actions and transformations). Details about rule
`matching are described in Section 10. This document specifies only a
`few conditions (i.e., identity, sphere, and validity). Further
`condition elements can be added via extensions to this document. If
`a child element of the <conditions> element is in a namespace that is
`not known or not supported, then this child element evaluates to
`FALSE.
`As noted in Section 5, conditions are matched on equality or "greater
`than" style comparisons, rather than regular expressions. Equality
`is determined according to the rules for the data type associated
`with the element in the schema given in Section 13, unless explicit
`comparison steps are included in this document. For xs:anyURI types,
`readers may wish to consult [2] for its discussion xs:anyURI, as well
`as the text in Section 13.
`7.1. Identity Condition
`7.1.1. Overview
`The identity condition restricts matching of a rule either to a
`single entity or a group of entities. Only authenticated entities
`can be matched; acceptable means of authentication are defined in
`protocol-specific documents. If the <identity> element is absent,
`identities are not considered, and thus, other conditions in the rule
`apply to any user, authenticated or not.
`The <identity> condition is considered TRUE if any of its child
`elements (e.g., the <one/> and the <many/> elements defined in this
`document) evaluate to TRUE, i.e., the results of the individual child
`element are combined using a logical OR.
`If a child element of the <identity> element is in a namespace that
`is not known or not supported, then this child element evaluates to
`FALSE.
`Schulzrinne, et al. Standards Track [Page 10]
`

`

`11
`
`RFC 4745 Common Policy February 2007
`7.1.2. Matching One Entity
`The <one> element matches the authenticated identity (as contained in
`the 'id' attribute) of exactly one entity or user. For
`considerations regarding the 'id' attribute, refer to Section 7.2.
`An example is shown below:
`<?xml version="1.0" encoding="UTF-8"?>
`<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
`<rule id="f3g44r1">
`<conditions>
`<identity>
`<one id="sip:alice@example.com"/>
`<one id="tel:+1-212-555-1234" />
`<one id="mailto:bob@example.net" />
`</identity>
`</conditions>
`<actions/>
`<transformations/>
`</rule>
`</ruleset>
`This example matches if the authenticated identity of the WR is
`either sip:alice@example.com, tel:+1-212-555-1234, or
`mailto:bob@example.net.
`7.1.3. Matching Multiple Entities
`The <many> element is a mechanism to perform authorization decisions
`based on the domain part of the authenticated identity. As such, it
`allows matching a large and possibly unknown number of users within a
`domain.
`Furthermore, it is possible to include one or multiple <except>
`elements to exclude either individual users or users belonging to a
`specific domain. Excluding individual entities is implemented using
`a <except id="..."/> statement. The semantic of the 'id' attribute
`of the <except> element has the same meaning as the 'id' attribute of
`the <one> element (see Section 7.2). Excluding users belonging to a
`specific domain is implemented using the <except domain="..."/>
`element that excludes any user from the indicated domain.
`If multiple <except> elements are listed as child elements of the
`<many> element, then the result of each <except> element is combined
`using a logical OR.
`Schulzrinne, et al. Standards Track [Page 11]
`

`

`12
`
`RFC 4745 Common Policy February 2007
`Common policy MUST either use UTF-8 or UTF-16 to store domain names
`in the 'domain' attribute. For non-IDNs (Internationalized Domain
`Names), lowercase 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 to as "protocol
`domain identifier"), the following rules are applicable:
`1. Translate percent-encoding for either string.
`2. Convert both domain strings using the ToASCII operation described
`in RFC 3490 [3].
`3. Compare the two domain strings for ASCII equality, for each
`label. If the string comparison for each label indicates
`equality, the comparison succeeds. Otherwise, the domains are
`not equal.
`If the conversion fails in step (2), the domains are not equal.
`7.1.3.1. Matching Any Authenticated Identity
`The <many/> element without any child elements or attributes matches
`any authenticated user.
`The following example shows such a rule that matches any
`authenticated user:
`<?xml version="1.0" encoding="UTF-8"?>
`<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
`<rule id="f3g44r5">
`<conditions>
`<identity>
`<many/>
`</identity>
`</conditions>
`<actions/>
`<transformations/>
`</rule>
`</ruleset>
`Schulzrinne, et al. Standards Track [Page 12]
`

`

`13
`
`RFC 4745 Common Policy February 2007
`7.1.3.2. Matching Any Authenticated Identity Except Enumerated
` Domains/Identities
`The <many> element enclosing one or more <except domain="..."/>
`elements matches any user from any domain except those enumerated.
`The <except id="..."/> element excludes particular users. The
`semantics of the 'id' attribute of the <except> element is described
`in Section 7.2. The results of the child elements of the <many>
`element are combined using a logical OR.
`An example is shown below:
`<?xml version="1.0" encoding="UTF-8"?>
`<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
`<rule id="f3g44r1">
`<conditions>
`<sphere value="work"/>
`<identity>
`<many>
`<except domain="example.com"/>
`<except domain="example.org"/>
`<except id="sip:alice@bad.example.net"/>
`<except id="sip:bob@good.example.net"/>
`<except id="tel:+1-212-555-1234" />
`<except id="sip:alice@example.com"/>
`</many>
`</identity>
`<validity>
`<from>2003-12-24T17:00:00+01:00</from>
`<until>2003-12-24T19:00:00+01:00</until>
`</validity>
`</conditions>
`<actions/>
`<transformations/>
`</rule>
`</ruleset>
`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,
`bob@good.example.net, and the user with the telephone number
`'tel:+1-212-555-1234'. The last 'except' element is redundant since
`alice@example.com is already excluded through the first line.
`Schulzrinne, et al. Standards Track [Page 13]
`

`

`14
`
`RFC 4745 Common Policy February 2007
`7.1.3.3. Matching Any Authenticated Identity within a Domain Except
` Enumerated Identities
`The <many> element with a 'domain' attribute and zero or more <except
`id="..."/> elements matches any authenticated user from the indicated
`domain except those explicitly enumerated. The semantics of the 'id'
`attribute of the <except> element is described in Section 7.2.
`It is nonsensical to have domains in the 'id' attribute that do not
`match the value of the 'domain' attribute in the enclosing <many>
`element.
`An example is shown below:
`<?xml version="1.0" encoding="UTF-8"?>
`<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
`<rule id="f3g44r1">
`<conditions>
`<identity>
`<many domain="example.com">
`<except id="sip:alice@example.com"/>
`<except id="sip:bob@example.com"/>
`</many>
`</identity>
`</conditions>
`<actions/>
`<transformations/>
`</rule>
`</ruleset>
`This example matches any user within example.com (such as
`carol@example.com) except alice@example.com and bob@example.com.
`7.2. Single Entity
`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
`'single-user entity' as a placeholder for the <one> and the <except>
`element. The <except> element fulfills the purpose of excluding
`elements from the solution set.
`A single-user entity matches the authenticated identity (as contained
`in the 'id' attribute) of exactly one entity or user. If there is a
`match, the single-user entity is considered TRUE. The single-user
`entity MUST NOT contain a 'domain' attribute.
`Schulzrinne, et al. Standards Track [Page 14]
`

`

`15
`
`RFC 4745 Common Policy February 2007
`The 'id' attribute contains an identity that MUST first be expressed
`as a URI. Applications using this framework must describe how the
`identities they are using can be expressed as URIs.
`7.3. Sphere
`The <sphere> element belongs to the group of condition elements. It
`can be used to indicate a state (e.g., 'work', 'home', 'meeting',
`'travel') the PT is currently in. A sphere condition matches only if
`the PT is currently in the state indicated. The state may be
`conveyed by manual configuration or by some protocol. For example,
`RPID [10] provides the ability to inform the PS of its current
`sphere. The application domain needs to describe in more detail how
`the sphere state is determined. Switching from one sphere to another
`causes a switch between different modes of visibility. As a result,
`different subsets of rules might be applicable.
`The content of the 'value' attribute of the <sphere> element MAY
`contain more than one token. The individual tokens MUST be separated
`by a blank character. A logical OR is used for the matching the
`tokens against the sphere settings of the PT. As an example, if the
`content of the 'value' attribute in the sphere attribute contains two
`tokens 'work' and 'home' then this part of the rule matches if the
`sphere for a particular PT is either 'work' OR 'home'. To compare
`the content of the 'value' attribute in the <sphere> element with the
`stored state information about the PT's sphere setting a
`case-insensitive string comparison MUST be used for each individual
`token. There is neither a registry for these values nor a language-
`specific indication of the sphere content. As such, the tokens are
`treated as opaque strings.
`<?xml version="1.0" encoding="UTF-8"?>
`<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
`<rule id="f3g44r2">
`<conditions>
`<sphere value="work"/>
`<identity>
`<one id="sip:andrew@example.com"/>
`</identity>
`</conditions>
`<actions/>
`<transformations/>
`</rule>
`Schulzrinne, et al. Standards Track [Page 15]
`

`

`16
`
`RFC 4745 Common Policy February 2007
`<rule id="y6y55r2">
`<conditions>
`<sphere value="home"/>
`<identity>
`<one id="sip:allison@example.com"/>
`</identity>
`</conditions>
`<actions/>
`<transformations/>
`</rule>
`<rule id="z6y55r2">
`<conditions>
`<identity>
`<one id="sip:john@doe.example.com"/>
`</identity>
`<sphere value="home work"/>
`</conditions>
`<actions/>
`<transformations/>
`</rule>
`</ruleset>
`The rule example above illustrates that the rule with the entity
`andrew@example.com matches if the sphere is been set to 'work'. In
`the second rule, the entity allison@example.com matches if the sphere
`is set to 'home'. The third rule also matches since the value in the
`sphere element also contains the token 'home'.
`7.4. Validity
`The <validity> element is the third condition element specified in
`this document. It expresses the rule validity period by two
`attributes, a starting and an ending time. The validity condition is
`TRUE if the current time is greater than or equal to at least one
`<from> child, but less than the <until> child after it. This
`represents a logical OR operation across each <from> and <until>
`pair. Times are expressed in XML dateTime format. A rule maker
`might not always have access to the PS to invalidate some rules that
`grant permissions. Hence, this mechanism allows invalidating granted
`permissions automatically without further interaction between the
`rule maker and the PS. The PS does not remove the rules; instead the
`rule maker has to clean them up.
`Schulzrinne, et al. Standards Track [Page 16]
`

`

`17
`
`RFC 4745 Common Policy February 2007
`An example of a rule fragment is shown below:
`<?xml version="1.0" encoding="UTF-8"?>
`<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
`<rule id="