view Side-By-Side changes
GEOPRIV H. Schulzrinne Internet-Draft Columbia U. Expires:January 19,April 26, 2006 J. Morris CDT H. Tschofenig J. Cuellar Siemens J. Polk Cisco J. RosenbergDynamicSoft July 18,Cisco Systems October 23, 2005 A Document Format for Expressing Privacy Preferencesdraft-ietf-geopriv-common-policy-05.txtdraft-ietf-geopriv-common-policy-06.txt Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire onJanuary 19,April 26, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Schulzrinne, et al. ExpiresJanuary 19,April 26, 2006 [Page 1] Internet-Draft Common PolicyJulyOctober 2005 This document defines a framework for authorization policies controling 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. Expires April 26, 2006 [Page 2] Internet-Draft Common Policy October 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . .3. 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . .5. 6 3. Modes of Operation . . . . . . . . . . . . . . . . . . . . .6 3.1. 7 3.1. Passive Request-Response - PS as Server (Responder) . . .6 3.27 3.2. Active Request-Response - PS as Client (Initiator) . . . .6 3.37 3.3. Event Notification . . . . . . . . . . . . . . . . . . . .67 4. Goals and Assumptions . . . . . . . . . . . . . . . . . . .8. 9 5. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . .10. 11 6. Basic Data Model and Processing . . . . . . . . . . . . . .11 6.1. 12 6.1. Identification of Rules . . . . . . . . . . . . . . . . .12 6.213 6.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . .1213 7. Conditions . . . . . . . . . . . . . . . . . . . . . . . . .13 7.1. 14 7.1. Identity Condition . . . . . . . . . . . . . . . . . . . . 14 7.1.1. Overview . . . . .13 7.2. . . . . . . . . . . . . . . . . . 14 7.1.2. Matching One Entity . . . . . . . . . . . . . . . . . 14 7.1.3. Single Entity . . . . . . . . . . . . . . . . . . . . 15 7.1.4. Matching Multiple Entities . . . . . . . . . . . . . . 16 7.2. Sphere . . . . . . . . . . . . . . . . . . . . . . . . . .17 7.319 7.3. Validity . . . . . . . . . . . . . . . . . . . . . . . . .1821 8. Actions . . . . . . . . . . . . . . . . . . . . . . . . . .20. 22 9. Transformations . . . . . . . . . . . . . . . . . . . . . .21. 23 10. Procedure for Combining Permissions . . . . . . . . . . . .22 10.1. 24 10.1. Introduction . . . . . . . . . . . . . . . . . . . . . .22 10.2. 24 10.2. Algorithm . . . . . . . . . . . . . . . . . . . . . . .22 10.3. 24 10.3. Example . . . . . . . . . . . . . . . . . . . . . . . .23. 25 11. Meta Policies . . . . . . . . . . . . . . . . . . . . . . .26. 28 12. Example . . . . . . . . . . . . . . . . . . . . . . . . . .27. 29 13. XML Schema Definition . . . . . . . . . . . . . . . . . . .28. 30 14. Security Considerations . . . . . . . . . . . . . . . . . .32. 33 15. IANA Considerations . . . . . . . . . . . . . . . . . . . .33 15.1. 34 15.1. Common Policy Namespace Registration . . . . . . . . . .33 15.2. 34 15.2. Content-type registration for 'application/auth-policy+xml' . . . . . . . . . . . . .33 15.3. 34 15.3. Common Policy Schema Registration . . . . . . . . . . .35. 36 16. References . . . . . . . . . . . . . . . . . . . . . . . . .36 16.1. 37 16.1. Normative References . . . . . . . . . . . . . . . . . .36 16.2. 37 16.2. Informative References . . . . . . . . . . . . . . . . .36 Authors' Addresses . . .. 37 Appendix A. Contributors . . . . . . . . . . . . . . . . .37 A. Contributors. . . 38 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . .39 B. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . 40 Intellectual Property and Copyright Statements . . . . . . .41. . . 42 Schulzrinne, et al. ExpiresJanuary 19,April 26, 2006 [Page2]3] Internet-Draft Common PolicyJulyOctober 2005 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 to build a system which enhances the value ofpresencespresence with location information in a natural way and reuses the same underlying authorization mechanism. Second, it encourages a more generic authorization framework with mechanisms for extensibility. The applicability of the framework specified in this document is not limited to policies controling access to presence and location information data, but can be extended to other 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-speific policy documents, including presence [5] and location[6]. This relationship is shown inFigure 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 authorization policy framework, followed by the data model in Section 6. The structure of a rule, namely conditions, actions and transformations, are described in Section 7, in Section 8 and in Section 9. The procedure for combining permissions is explained in Section 10 and used when more than one rule fires. A short Schulzrinne, et al. ExpiresJanuary 19,April 26, 2006 [Page3]4] Internet-Draft Common PolicyJulyOctober 2005 description 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 Section 14. Schulzrinne, et al. ExpiresJanuary 19,April 26, 2006 [Page4]5] Internet-Draft Common PolicyJulyOctober 2005 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT","RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1]. This document introduces the following terms: PT - Presentity / Target: The PT is the entity about whom information has been requested. RM - Rule Maker: RM is an entity which creates the authorization rules which restrict access to data items. PS - (Authorization) Policy Server: This entity has access to both the authorization policies and to the data items. In location- specific applications, the entity PS is labeled as location server (LS). WR - Watcher / Recipient: This entity requests access to data items of the PT. An access operation might be either be a read, write or any other operation. In case of access to location information it might be a read operation. An 'authorization policy' is given by a 'rule set'. A 'rule set' contains an unordered list of 'rules'. A 'rule' has a 'conditions', an 'actions' and a 'transformations' part. The term 'permission' indicates the action and transformation components of a 'rule'. The terms 'authorization policy', 'policy' and 'rule set' are used interchangeably. The terms 'authorization policy rule', 'policy rule' and 'rule' are used interchangeable. The term 'using protocol' is defined in [7]. It refers to the protocol which is used to request access to and to return privacy sensitive data items. Schulzrinne, et al. ExpiresJanuary 19,April 26, 2006 [Page5]6] Internet-Draft Common PolicyJulyOctober 2005 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 provides the identity of the requestor (or more precisely the authentication protocol), either at the time of the query or at the subscription time. The authenticated identity of the WR, together with other information provided by the using protocol or generally available to the server, is then used for searching through the rule set. All matching rules are combined according to a permission combining algorithm described in Section 10. The 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.13.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 or various RPC protocols, including Sun RPC, DCE, DCOM, Corba and SOAP. The PS uses the ruleset to determine whether the WR is authorized to access the PTs information, refusing the request if necessary. Furthermore, the PS might filter information by removing elements or by reducing the resolution of elements.3.23.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.33.3. Event Notification Event notification adds a subscription phase to the "PS as client" mode of operation. A watcher or subscriber asks to be added to the notification list for a particular presentity or event. When the presentity changes state or the event occurs, the PS sends a message to the WR containing the updated state. (Presence is a special case of event notification; thus, we often use the term interchangeably.) In addition, the subscriber may itself add a filter to the subscription, limiting the rate or content of the notifications. If an event, after filtering by the rulemaker-provided rules and by the subscriber-provided rules, only produces the same notification Schulzrinne, et al. ExpiresJanuary 19,April 26, 2006 [Page6]7] Internet-Draft Common PolicyJulyOctober 2005 content that was sent previously, no event notification is sent. 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. Schulzrinne, et al. ExpiresJanuary 19,April 26, 2006 [Page7]8] Internet-Draft Common PolicyJulyOctober 2005 4. Goals and Assumptions Below, we summarize our design goals and constraints. Table representation: Each rule must be representable as a row in a relational database. This design goal should allow efficient policy rule implementation by utilizing standard database optimization techniques. Permit only: Rules only provide permissions rather than denying them. Allowing both 'permit' and 'deny' actions would require some rule ordering which had implications on the update operations executed on these rules. Additionally it would make distributed rule sets more complicated. Hence, only 'permit' actions are allowed which result in more efficient rule processing. This also implies that rule ordering is not important. Consequently, to make a policy decision requires processing all policy rules. Additive permissions: A query for access to data items is matched against the rules in the rule database. If several rules match, then the overall permissions granted to the WR are the union of those permissions. A more detailed discussion is provided inSection 10. Upgradeable: It should be possible to add additional rules later, without breaking PSs that have not been upgraded. Any such upgrades must not degrade privacy constraints, but PSs not yet upgraded may reveal less information than the rulemaker would have chosen. Versioning support: In addition to the previous goal, a RM should be able to determine which types of rules are supported by the PS. The mechanism used to determine the capability of a PS 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. Schulzrinne, et al. ExpiresJanuary 19,April 26, 2006 [Page8]9] Internet-Draft Common PolicyJulyOctober 2005 No false assurance: It appears more dangerous to give the user the impression that the system will prevent disclosure automatically, but fail to do so with a significant probability of operator error or misunderstanding, than to force the user to explicitly invoke simpler rules. For example, rules based on weekday and time-of- day ranges seem particularly subject to misinterpretation and false assumptions on part of the RM. (For example, a non- technical RM would probably assume that the rules are based on the timezone of his current location, which may not be known to other components of the system.) Schulzrinne, et al. ExpiresJanuary 19,April 26, 2006 [Page9]10] Internet-Draft Common PolicyJulyOctober 2005 5. Non-Goals We explicitly decided that a number of possibly worthwhile capabilities are beyond the scope of this first version. Future versions may include these capabilities, using the extension mechanism described in this document. Non-goals include: No external references: Attributes within specific rules cannot refer to external rule sets, databases, directories or other network elements. Any such external reference would make simple database implementation difficult and hence they are not supported in this version. No regular expression or wildcard matching: Conditions are matched on equality or 'greater-than'-style comparisons, not regular expressions, partial matches such as the SQL LIKE operator (e.g., LIKE "%foo%") or glob-style matches ("*@example.com"). Most of these are better expressed as explicit elements. No all-except conditions: It is not possible to express exclusion conditions based on identities such as "everybody except Alice". However, this restriction does not prevent all forms of blacklisting. It is still possible to express an authorization rule like 'I allow access to my location information for everyone of domain example.com except for John'. See the example in Section 7.1 describing how exceptions can be made to work. The reason for this choice is the ease with which identities can be manufactured, and the implication that all-except types of rules are easily subverted. No repeat times: Repeat times are difficult to make work correctly, due to the different time zones that PT, WR, PS and RM may occupy. It appears that suggestions for including time intervals are often based on supporting work/non-work distinctions, which unfortunately are difficult to capture by time alone. Schulzrinne, et al. ExpiresJanuary 19,April 26, 2006 [Page10]11] Internet-Draft Common PolicyJulyOctober 2005 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, i.e. each of which is equipped with a value of either TRUE or FALSE by the PS. When a WR asks for information about a PT, the PS goes through each rule in the rule set. For each rule, it evaluates the expressions in the conditions part. If all of the expressions evaluate to TRUE, then the rule is applicable to this request. Generally, each expression specifies a condition based on some variable that is associated with the context of the request. These variables can include the identity of the WR, the domain of the WR, the time of day, or even external variables, such as the temperature or the mood of the PT. Assuming that the rule is applicable to the request, the actions and transformations (commonly referred to as permissions) in the rule specify how the PS is supposed to handle this request. If the request is to view the location of the PT, or to view its presence, the typical action is "permit", which allows the request to proceed. Assuming the action allows the request to proceed, the transformations part of the rule specifies how the information about the PT - their location information, their presence, etc. - is modified before being presented to the WR. These transformations are in the form of positive permissions. That is, they always specify a piece of information which is allowed to be seen by the WR. When a PS processes a request, it takes the transformations specified across all rules that match, and creates the union of them.The means forFor computing this uniondepend onthe datatype -type, such as Integer, Boolean, Set, or the Undef datatype - and aretype, plays a role. The details of the algorithm for combining permissions is described inmore detail inSection 10. The resulting union effectively represents a "mask" - it defines what information is exposed to the WR. This mask is applied to the actual location or presence data for the PT, and the data which is permitted by the mask is shown to the WR. If the WR request a subset of information only (such as city-level civil location data only, instead of the full civil location information), the information delivered to the WR SHOULD be the intersection of the permissions granted to the WR and the data requested by the WR. In accordance to this document, rules are encoded in XML. To thisend, Section 13 contains an XML schema defining the Common PolicySchulzrinne, et al. ExpiresJanuary 19,April 26, 2006 [Page11]12] Internet-Draft Common PolicyJulyOctober 2005 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 PSmaycan 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.16.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.6.26.2. Extensions The authorization policy framework defined in this document is meant to be extensible towards specific application domains. Such an extension is accomplished by defining conditions, actions and transformations that are specific to the desired application domain. Each extension MUST define its own namespace. Extensions cannot change the schema defined in this document, and this schema is not expected to change excepting a revision to thisspecification.specification, and that no versioning procedures for this schema or namespace are therfore provided. Schulzrinne, et al. ExpiresJanuary 19,April 26, 2006 [Page12]13] Internet-Draft Common PolicyJulyOctober 2005 7. Conditions The access to data items needs to be matched with the rule set stored at the PS. Each instance of a request has different attributes (e.g., the identity of the requestor) which are used for authorization. A rule in a rule set might have a number of conditions which need to be 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 (namely identity, sphere, and validity). Other conditions are left for extensions of this document.7.17.1. Identity Condition 7.1.1. Overview Theauthorization policy framework specified in this document supports the usageidentity condition restricts matching ofidentities as inputa rule either toaccess authorization decision processes. This document, however, abstracts from the particularitiesa single entity or a group of entitites. Only authenticated entities can be matched; acceptable means ofconcreteauthenticationmechanisms employed by different using protocols andare defined in protocol-specific documents. As usual, if the <identity> element istherefore unable to specify explicitly(or all its child elements are) omitted, identities are not considered and, thus, thedetailscondition matches any user, authenticated or not. The <identity> condition is considered TRUE if any ofidentity relevant information. Hence, we only assume that an identity has a structure with a usernameits child elements (i.e., the <one/> anda domain part. Documents that enhancetheschema<many/> elements as defined in thisdocument should, if possible, describe how a particular using protocol is able to provide identity information in a meaningful way. Such an enhancement needsdocument) evaluate tomap the identity used byTRUE, i.e., theauthentication protocol employed inresults of the individual child element are combined usingprotocol to an identity used in the authorization policy. It is necessary to clearly defineamapping betweenlogical OR. 7.1.2. Matching One Entity The <one> element matches the authenticated identityof(as contained in the 'id' attribute) of exactly one entity or user and it MAY contain a 'scheme' attribute. For considerations regarding theidentities used in'id' and theauthorization policies. This mapping needs'scheme' attribute refer toconsiderSection 7.1.3. An example is shown below: Schulzrinne, et al. Expires April 26, 2006 [Page 14] Internet-Draft Common Policy October 2005 <?xml version="1.0" encoding="UTF-8"?> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy"> <rule id="f3g44r1"> <conditions> <identity> <one id="alice@example.com"/> <one id="+1-212-555-1234" scheme="tel"/> <one id="bob@example.net" scheme="sip mailto xmpp"/> </identity> </conditions> <actions/> <transformations/> </rule> </ruleset> This example matches if thelarge numberauthenticated identity ofpossible identities usedthe WR is either alice@example.com, tel:+1-212-555-1234 or bob@example.net. 7.1.3. Single Entity The 'id' attribute used invarious authentication protocols.the <one> and in the <except> element refers to a single entity. Inthis documentthe subsequent text wedistinguish between three different identities: Authenticated Identities: The WR was authenticated byuse thePS. The authenticated identity is usedterm 'single-user' element asinput toa placeholder for therule matching procedure. Unauthenticated Identities:<one> and the <except> element. TheWR was not<single-user> element matches the authenticatedbyidentity (as contained in thePS'id' attribute) of exactly one entity or user, it MAY contain a 'scheme' attribute andthusMUST NOT contain a 'domain' attribute. The content of the 'scheme' attribute of the <one> element MAY contain more than one token representing anyidentity providedURI 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 WRmightMUST 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 bespoofed.differentiated: Schulzrinne, et al. ExpiresJanuary 19,April 26, 2006 [Page13]15] Internet-Draft Common PolicyJulyOctober 2005Asserted Identities:1. TheWR was not directly authenticated by the PS. Insteadscheme in theWR was authenticated by an asserting party that provides an assurance toURI or IRI is not listed in thePS about'scheme' attribute, theauthentication of'single-user' element returns a FALSE - there is no match. 2. The scheme in theWR. ItURI or IRI isassumed thatlisted in thePS and'scheme' attribute, theasserting party have some relationship with each other and that there'id' attribute is converted to acertain degreeURI or IRI oftrustthatthe asserting party does not misbehave (such as lying aboutscheme. The process for such anon- existing authentication of the WR andconversion MUST be defined bymaking an incorrect assertion). An exampleapplications of thisapproach can be found in [8]. These three identities are usedframework for therule matching algorithms whereby no differentiation is made between an authenicated and an asserted identity in this document. However, there is another identity, the anonymous identity, that plays a role in this context. Most using protocols also designate an identifier that denotes an 'anonymous user'. The WR, as such, is not authenticated by the PS nor does an assertion exist that provides the PS with information about the authenticated identity. In order to provide an authorization decision non-identity based (or trait-based authorization) might be applicable. This might be accomplished by an assertion provided by a third party that hides the identity but offers attributes about the WR that are used asparticular URI or IRI scheme. Once thefoundation for an access control decision. Ensuring authorization for anonymous usersconversion isoutside the scope of this document. The following guidelines apply when performing rule matching (related to the identity element in the conditions part ofdone, arule): 1. A rule with no conditions matches any subscription irrelevant whether an authenticatedURI oran unauthenticated was used by the WR to access resources. 2. A rule with an <identity> element assumes that there are either <id> or <domain> elements as child elements. Unauthenticated identities never match the values of the <id> element(s) or the <domain> element(s). 1. If the <identity> element contains one or multiple <id> element(s) then the authenticated identities (as provided by the security protocol used by theIRI comparison is performed usingprotocol) MUST be used for anequalitymatch. 2. If the <identity> element contains the <domain> element consisting of one or more <except> element(s) then the domain part of the authenticated identity MUST be usedrules foran equality match. This allows implementing a simple blacklist mechanism. The <except> element contains the identity Schulzrinne, et al. Expires January 19, 2006 [Page 14] Internet-Draft Common Policy July 2005 without the domain part (i.e., the username part) since it equals the domain of the <domain> element. Only authenticated identities MUST be matched with the username part of the values of the <except> element(s). 3. The <any-identity> conditionthatmatches authenticated and unauthenticated identities. The <any-identity> MAY contain oneURI ormultiple <except-domain> elements and MAY contain one or multiple <domain> elements. 1.IRI. If the<any-identity> element doesscheme attribute was notcontain child elements then the rule matches with any authenticated or unauthenticated identity. 2. Ifpresent, the<any-identity> element contains one or multiple <domain> elements then the domain partvalue ofthe authenticated'id' attribute is converted to a URI orunauthenticated identity MUST be matched against the valuesIRI of the<domain> element(s). 3.scheme used by WR's identity. If such a conversion 1. cannot be done, the<any-identity>'single-user' elementcontains one or multiple <except-domain> element(s) then the domain part ofreturns a FALSE. 2. can be done, theauthenticatedconversion is done and an equivalence comparison made using URI orunauthenticated identity MUST be matched againstIRI scheme specific matching rules. If thevaluesresult of the<except-domain> element(s). Regarding stringURI or IRI comparisonthe following rules apply:is that 1.The <id> elements ofthey are not equivalent, the<identity> condition part'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 therule matches, if'id' element are quite broad - any UTF-8 character excepting theidentity@ sign. As a consequence, there are many values of this 'id' which cannot be represented in a paritcular URI scheme. In such a case, theWR matches,natural thing happens - there will never be a match against an identifier in that URI scheme. 7.1.4. Matching Multiple Entities The <many> element is a mechanism to perform authorization decisions based oncase sensitive string comparison, the user part of the <id>, andthe domain part of the authenticated identity. As such, it allows to match a large and possibly unknown number ofthe <id>, based on case insensitive string comparison. 2. The identity of the WR matchesusers within a<domain> (either listed in the <identity>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 that might include the<any-identity> element) when the domain part of the identity matches, based on case insensitive string comparison, the value'scheme' attribute. The semantic of the<domain> element,'id' and theuser part matches none'scheme' attribute of the <except> elementvalues, based on case sensitive string comparison. The values of a <domain> element MUST be matched withhave thedomain part ofsame meaning as theprovided identity using an equality match. No wildcarding is provided. Next, we list a few examples. The following example illustrates conditions based on an identity.'id' and the 'scheme' attribute of the <one> element (see Section 7.1.3). Excluding users belonging to a specific domain is implemented using Schulzrinne, et al. ExpiresJanuary 19,April 26, 2006 [Page15]16] Internet-Draft Common PolicyJulyOctober 2005 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. 7.1.4.1. Matching Any AuthenticatedIdentitiesEntity 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"> <ruleid="f3g44r2">id="f3g44r5"> <conditions> <identity><id entity="alice@example.com"/> <id entity="bob@example.com"/><many/> </identity> </conditions> <actions/> <transformations/> </rule> </ruleset>Figure 2: Matching authenticated identitiesTheexample shownfollowing rule, inFigure 2 shows a rule that matches if thecomparison, would match any user, authenticatedidentity of the WR is either alice@example.com or bob@example.com. Exceptions within theand unauthenticated: <?xml version="1.0" encoding="UTF-8"?> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy"> <rule id="f3g44r5"> <conditions> <identity/> </conditions> <actions/> <transformations/> </rule> </ruleset> Schulzrinne, et al. Expires April 26, 2006 [Page 17] Internet-Draft Common Policy October 2005 7.1.4.2. Matching Any IdentityElement:Excepting Enumerated Domains and Identities Theexample in Figure 3 shows how exceptions are implemented. For the given example the rule<many> element enclosing one or more <except domain="..."/> elements matchesifany user from any domain except those enumerated. The <except id="..."/> element excludes particular users. The semantic of theauthenticated identity'id' and the 'scheme' attribute of theWR<except> element isfrom the example.com domain butdescribed in Section 7.1.3. The results of theuser identitychild elements of theWR<many> element are combined using a logical OR. An example isneither joe@example.com, toni@example.com nor mike@example.com.shown below: <?xml version="1.0" encoding="UTF-8"?> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy"> <ruleid="f3g44r2">id="f3g44r1"> <conditions> <sphere value="work"/> <identity><domain<many> <except domain="example.com"/> <exceptentity="joe"/>domain="example.org"/> <except id="alice@bad.example.net"/> <except id="bob@good.example.net"/> <exceptentity="tony"/>id="+1-212-555-1234" scheme="tel"/> <exceptentity="mike"/>id="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>Figure 3: UsingThis 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 theDomain/Except Elementsfirst line. 7.1.4.3. Matching Any Identity Within a Domain Excepting Enumerated Identities Schulzrinne, et al. ExpiresJanuary 19,April 26, 2006 [Page16]18] Internet-Draft Common PolicyJulyOctober 2005If a WRThe <many> element withthe identity john@foo.example.com requests access toaresource the above-shown rule is not applied since the case insensitive equality match between'domain' attribute and zero or more <except id="..."/> elements matches any authenticated user from the indicated domainpartexcept those explicitly enumerated. The semantic of theWR identity (namely 'foo.example.com') does not match the value in'id' and thedomain part'scheme' attribute of therule (namely 'example.com'). Any Identity The following<except> element is described in Section 7.1.3. An examplematches any authenticated and any unauthenticated identity.is shown below: <?xml version="1.0" encoding="UTF-8"?> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy"> <ruleid="f3g44r2">id="f3g44r1"> <conditions><any-identity/><identity> <many domain="example.com"> <except id="alice@example.com"/> <except id="bob@example.com"/> </many> </identity> </conditions> <actions/> <transformations/> </rule> </ruleset>Figure 4: The Any-Identity Element The following rule fires for any authenticated andThis example matches anyunauthenticated identity except for WR's from theuser within example.com (such as carol@example.com) except alice@example andthe foo.com domain. The rule would therefore fire for joe@foo.bar.com but not for alice@foo.com. <?xml version="1.0" encoding="UTF-8"?> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy"> <rule id="f3g44r2"> <conditions> <any-identity> <except-domain domain="example.com"/> <except-domain domain="foo.com"/> </any-identity> </conditions> </rule> </ruleset> Figure 5: Any-Identity combined with Except-Domain Element 7.2bob@example.com. 7.2. Sphere The <sphere> element belongs to the group of condition elements. It can be used to indicate a state (e.g., 'work', 'home', 'meeting',Schulzrinne, et al. Expires January 19, 2006 [Page 17] Internet-Draft Common Policy July 2005'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 [9] 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 to switch between different modes of visibility. As a result different subsets of rules might be applicable.An exampleThe 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 the content of the 'value' attribute in the sphere attribute contains two tokens 'work' and 'home' then this part of the rulefragmentmatches if Schulzrinne, et al. Expires April 26, 2006 [Page 19] Internet-Draft Common Policy October 2005 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 string comparison MUST be used for each individual token. There isshown below:no 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><id entity="andrew@example.com"/><one id="andrew@example.com"/> </identity> </conditions> <actions/> <transformations/> </rule> <rule id="y6y55r2"> <conditions> <sphere value="home"/> <identity><id entity="allison@example.com"/><one id="allison@example.com"/> </identity> </conditions> <actions/> <transformations/> </rule> <rule id="z6y55r2"> <conditions> <identity> <one id="john@doe.com"/> </identity> <sphere value="home work"/> </conditions> <actions/> <transformations/> </rule> </ruleset> The rule example above illustrates that the rule with the entity Schulzrinne, et al. Expires April 26, 2006 [Page 20] Internet-Draft Common Policy October 2005 andrew@example.com matches if the sphere is been set to 'work'. In the second rule with the entity allison@example.com matches if the sphere is set to 'home'.7.37.3. Validity The <validity> element is the third condition element specified in this document. It expresses the rule validity period by two attributes, a starting and a ending time. 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 XMLSchulzrinne, et al. Expires January 19, 2006 [Page 18] Internet-Draft Common Policy July 2005dateTimeformat.Aformat. A rule maker might not have always access to the PS to invalidate some rules which grant permissions. Hence this mechanisms allows to invalidate 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. 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="f3g44r3"> <conditions> <validity> <from>2003-08-15T10:20:00.000-05:00</from> <until>2003-09-15T10:20:00.000-05:00</until> </validity> </conditions> <actions/> <transformations/> </rule> </ruleset> The<identity>, the <sphere> and the<validity> element MUSTNOThave the <from> and <until> subelements in pairs. Multiple <from> and <until> elements might appearmore than onceinthe conditions partpairs (i.e., without nesting ofa single rule. The <id><from> and <until> elements). Using multiple <validity> elements as subelements of the <conditions> elementonis not useful since all subelements of theother hand may appear more than once<conditions> element are combined asdescribed in this section.a logical AND. Schulzrinne, et al. ExpiresJanuary 19,April 26, 2006 [Page19]21] Internet-Draft Common PolicyJulyOctober 2005 8. Actions While conditions are the 'if'-part of rules, actions and transformations build the 'then'-part of them. The actions and transformations parts of a rule determine which operations the PS MUST execute after having received from a WR a data access request that matches all conditions of this rule. Actions and transformations only permit certain operations; there is no 'deny' functionality. Transformations exclusively specify PS-side operations that lead to a modification of the data items requested by the WR. Regarding location data items, for instance, a transformation could force the PS to lower the precision of the location information which is returned to the WR. Actions, on the other hand, specify all remaining types of operations the PS is obliged to execute, i.e., all operations that are not of transformation type. Actions are defined by application specific usages of this framework. The reader is referred to the corresponding extensions to see examples of such elements. Schulzrinne, et al. ExpiresJanuary 19,April 26, 2006 [Page20]22] Internet-Draft Common PolicyJulyOctober 2005 9. Transformations Two sub-parts follow the conditions part of a rule: transformations and actions. As defined in Section 8, transformations specify operations that the PS MUST execute and that modify the result which is returned to the WR. This functionality is particularly helpful in reducing the granularity of information provided to the WR, as for example required for location privacy. Transformations are defined by application specific usages of this framework. A simple transformation example is provided in Section 10. Schulzrinne, et al. ExpiresJanuary 19,April 26, 2006 [Page21]23] Internet-Draft Common PolicyJulyOctober 2005 10. Procedure for Combining Permissions10.110.1. Introduction This section describes the mechanism to evaluate the final result of a rule evaluation. The result is reflected in the action and transformation part of a rule. This procedure is sometimes referred as conflict resolution. We use the following terminology (which in parts has already been introduced in previous sections): The term 'permission' stands for an action or a transformation. The notion 'attribute' terms a condition, an action, or a transformation. An attribute has a name, has a certain data type. A value may be assigned to an attribute or it may be undefined, in case it does not have a value associated with the attribute. For example, the name of the <sphere> attribute discussed in Section 7 is 'sphere', its data type is 'string', and its value may be set to 'home'. To evaluate a condition means to associate either TRUE or FALSE to the condition. Please note that the <identity> element is a condition whereas the <id> element is a parameter of that condition. A rule matches if all conditions contained in the conditions part of a rule evaluate to TRUE. When the PS receives a request for access to privacy-sensitive data then it needs to be matched against a rule set. The conditions part of each individual rule is evaluated and as a result one or more rules might match. If only a single rule matches then the result is determined by executing the actions and the transformations part following the conditions part of a rule. However, it can also be the case that two or more matching rules contain a permission of the same name (e.g., two rules contain a permission named 'precision of geospatial location information'), but do not specify the same value for that permission (e.g., the two rule might specify values of '10 km' and '200 km', respectively, for the permission named 'precision of geospatial location information'). This section describes the procedure for combining permissions in such cases.10.210.2. Algorithm The combining rules are simple and depend on the data types of the values of permissions: Let P be a policy. Let M be the subset of P consisting of rules r in P that match with respect to a given request. Let n be a name of a permission contained in a rule r in M, and let M(n) be the subset of M consisting of rules r in M that have a permission of name n. For each rule r in M(n), let v(r,n) and d(r,n) be the value and the data type, respectively, of the attribute of r with name n. Finally, let V(n) be the combined value of all the permissions values v(r,n), r in M(n). The combining rules that lead Schulzrinne, et al. ExpiresJanuary 19,April 26, 2006 [Page22]24] Internet-Draft Common PolicyJulyOctober 2005 to the resulting value V(n) are the following: CR 1: If d(r,n)=Boolean for all r in M(n), then V(n) is given as follows: If there is a r in M(n) with v(r,n)=TRUE, then V(n)=TRUE. Otherwise, V(n)=FALSE. CR 2: If d(r,n)=Integer for all r in M(n), then V(n) is given as follows: If v(r,n)=undefined for all r in M(n), then V(n) is not specified by this specification. Otherwise, V(n)=max{v(r,n) | r in M(n)}. CR 3: If d(r,n)=Set for all r in M(n), then V(n) is given as follows: V(n)=union of all v(r,n), the union to be computed over all r in M(n) with v(r,n)!=undefined. The combining operation will result in the largest value for an Integral type, the Or operation for boolean, and union for set. As a result, applications should define values such that, for integers, the lowest value corresponds to the most privacy, for booleans, false corresponds to the most privacy, and for sets, the empty set corresponds to the most privacy. More10.310.3. Example In the following example we illustrate the process of combining permissions. We will consider three conditions for our purpose, namely those of name identity, sphere, and validity. For editorial reasons the rule set in this example is represented in a table. Furthermore, the domain part of the identity of the WR is omitted. For actions we use two permissions with names X and Y. The values of X and Y are of data types Boolean and Integer, respectively. Permission X might, for example, represent the <sub-handling> action. For transformations we use the attribute with the name Z whose value can be set either to '+'(or 1), 'o' (or 2) or '-' (or 3). Permission Z allows us to show the granularity reduction whereby a value of '+' shows the corresponding information unrestricted and '-' shows nothing. This permission might be related to location information or other presence attributes like mood. Internally we use the data type Integer for computing the permission of this attribute. Schulzrinne, et al. ExpiresJanuary 19,April 26, 2006 [Page23]25] Internet-Draft Common PolicyJulyOctober 2005 Conditions Actions/Transformations +---------------------------------+---------------------+ | Id WR-ID sphere from until | X Y Z | +---------------------------------+---------------------+ | 1 bob home A1 A2 | TRUE 10 o | | 2 alice work A1 A2 | FALSE 5 + | | 3 bob work A1 A2 | TRUE 3 - | | 4 tom work A1 A2 | TRUE 5 + | | 5 bob work A1 A3 | undef 12 o | | 6 bob work B1 B2 | FALSE 10 - | +---------------------------------+---------------------+ Again for editorial reasons, we use the following abbreviations for the two <validity> attributes 'from' and 'until': A1=2003-12-24T17:00:00+01:00 A2=2003-12-24T21:00:00+01:00 A3=2003-12-24T23:30:00+01:00 B1=2003-12-22T17:00:00+01:00 B2=2003-12-23T17:00:00+01:00 Note that B1 < B2 < A1 < A2 < A3. The entity 'bob' acts as a WR and requests data items. The policy P consists of the six rules shown in the table and identified by the values 1 to 6 in the 'Id' column. The PS receives the query at 2003- 12-24T17:15:00+01:00 which falls between A1 and A2. The value of the attribute with name 'sphere' indicating the state the PT is currently in is set to 'work'. Rule 1 does not match since the sphere condition does not match. Rule 2 does not match as the identity of the WR (here 'alice') does not equal 'bob'. Rule 3 matches since all conditions evaluate to TRUE. Rule 4 does not match as the identity of the WR (here 'tom') does not equal 'bob'. Rule 5 matches. Rule 6 does not match since the rule is not valid anymore. Therefore, the set M of matching rules consists of the rules 3 and 5. These two rules are used to compute the combined permission V(X), V(Y), and V(Z) for each of the permissions X, Y, and Z: Actions/Transformations +-----+-----------------------+ | Id | X Y Z | +-----+-----------------------+ | 3 | TRUE 3 - | | 5 | undef 12 o | Schulzrinne, et al. ExpiresJanuary 19,April 26, 2006 [Page24]26] Internet-Draft Common PolicyJulyOctober 2005 +-----+-----------------------+ The results of the permission combining algorithm is shown below. The combined value V(X) regarding the permission with name X equals TRUE according to the first combining rule listed above. The maximum of 3 and 12 is 12, so that V(Y)=12. For the attribute Z in this example the maximum between 'o' and '-' (i.e., between 2 and 3) is '-'. Actions/Transformations +-----+-----------------------+ | Id | X Y Z | +-----+-----------------------+ | 5 | TRUE 12 - | +-----+-----------------------+ Schulzrinne, et al. ExpiresJanuary 19,April 26, 2006 [Page25]27] Internet-Draft Common PolicyJulyOctober 2005 11. Meta Policies Meta policies authorize a rulemaker to insert, update or delete a particular rule or an entire rule set. Some authorization policies are required to prevent unauthorized modification of rule sets. Meta policies are outside the scope of this document. A simple implementation could restrict access to the rule set only to the PT but more sophisticated mechanisms could be useful. As an example of such policies one could think of parents configuring the policies for their children. Schulzrinne, et al. ExpiresJanuary 19,April 26, 2006 [Page26]28] Internet-Draft Common PolicyJulyOctober 2005 12. Example This section gives an example of an XML document valid with respect to the XML schema defined in Section 13. Semantically richer examples can be found in documents which extend this schema with application domain specific data (e.g., location or presence information). Below a rule is shown with a condition that matches for a given authenticated identity (bob@example.com) and within a given time period. Additionally, the rule matches only if the target has set its sphere to 'work'. <?xml version="1.0" encoding="UTF-8"?> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy"> <rule id="f3g44r1"> <conditions> <identity><id entity="bob@example.com"/><one id="bob@example.com"/> </identity> <sphere value="work"/> <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> Schulzrinne, et al. ExpiresJanuary 19,April 26, 2006 [Page27]29] Internet-Draft Common PolicyJulyOctober 2005 13. XML Schema Definition This section provides the XML schema definition for the common policy markup language described in this document. <?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="urn:ietf:params:xml:ns:common-policy" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <!--Rule Set/ruleset --> <xs:element name="ruleset"> <xs:complexType> <xs:complexContent> <xs:restriction base="xs:anyType"> <xs:sequence> <xs:elementname="rule" type="cp:ruleType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> <!-- Rule --> <xs:complexType name="ruleType"> <xs:sequence> <!-- Conditions --> <xs:element name="conditions" minOccurs="0"> <xs:complexType> <xs:sequence> <xs:element name="validity" minOccurs="0"> <xs:complexType> <xs:all> <xs:element name="from" type="xs:dateTime"/> <xs:element name="to" type="xs:dateTime"/> </xs:all> </xs:complexType> </xs:element> <xs:element name="identity" minOccurs="0"> <xs:complexType> Schulzrinne, et al. Expires January 19, 2006 [Page 28] Internet-Draft Common Policy July 2005 <xs:choice> <xs:element name="id" maxOccurs="unbounded"> <xs:complexType> <xs:attribute name="entity" type="xs:string" use="required"/> </xs:complexType> </xs:element> <xs:sequence> <xs:element name="domain" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:attribute name="domain" type="xs:string" use="required"/> </xs:complexType> </xs:element> <xs:element name="except" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:attribute name="entity" type="xs:string" use="required"/> </xs:complexType> </xs:element> </xs:sequence> <xs:element name="any-identity"> <xs:complexType> <xs:sequence> <xs:element name="domain"name="rule" type="cp:ruleType" minOccurs="0"maxOccurs="unbounded"> <xs:complexType> <xs:attribute name="domain" type="xs:string" use="required"/>maxOccurs="unbounded"/> </xs:sequence> </xs:restriction> </xs:complexContent> </xs:complexType> </xs:element> <!-- /ruleset/rule --> <xs:complexType name="ruleType"> <xs:complexContent> <xs:restriction base="xs:anyType"> <xs:sequence> <xs:elementname="except-domain" minOccurs="0" maxOccurs="unbounded"> <xs:complexType>name="conditions" type="cp:conditionsType" minOccurs="0"/> <xs:element name="actions" type="cp:extensibleType" minOccurs="0"/> <xs:element name="transformations" type="cp:extensibleType" minOccurs="0"/> </xs:sequence> <xs:attributename="domain" type="xs:string"name="id" type="xs:ID" use="required"/> </xs:restriction> </xs:complexContent> </xs:complexType></xs:element><!-- //rule/conditions --> <xs:complexType name="conditionsType"> <xs:complexContent> <xs:restriction base="xs:anyType"> <xs:choice maxOccurs="unbounded"> <xs:element name="identity" type="cp:identityType" minOccurs="0"/> <xs:element name="sphere" Schulzrinne, et al. ExpiresJanuary 19,April 26, 2006 [Page29]30] Internet-Draft Common PolicyJulyOctober 2005</xs:sequence> </xs:complexType> </xs:element> </xs:choice> </xs:complexType> </xs:element>type="cp:sphereType" minOccurs="0"/> <xs:elementname="sphere" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:attribute name="value" type="xs:string" use="required"/> </xs:complexType> </xs:element>name="validity" type="cp:validityType" minOccurs="0"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/></xs:sequence></xs:choice> </xs:restriction> </xs:complexContent> </xs:complexType></xs:element><!--Actions//conditions/identity --> <xs:complexType name="identityType"> <xs:complexContent> <xs:restriction base="xs:anyType"> <xs:choice maxOccurs="unbounded"> <xs:elementname="actions" minOccurs="0"> <xs:complexType>name="one" type="cp:oneType"/> <xs:element name="many" type="cp:manyType"/> </xs:choice> </xs:restriction> </xs:complexContent> </xs:complexType> <!-- //identity/one --> <xs:complexType name="oneType"> <xs:complexContent> <xs:restriction base="xs:anyType"> <xs:sequence> <xs:any namespace="##other"processContents="lax"minOccurs="0"maxOccurs="unbounded"/>processContents="lax"/> </xs:sequence> <xs:attribute name="id" type="xs:string" use="required"/> <xs:attribute name="scheme" type="xs:string" use="optional"/> </xs:restriction> </xs:complexContent> </xs:complexType></xs:element><!--Transformations//identity/many --> <xs:complexType name="manyType"> <xs:complexContent> <xs:restriction base="xs:anyType"> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:elementname="transformations" minOccurs="0"> <xs:complexType> <xs:sequence>name="except" type="cp:exceptType"/> <xs:any namespace="##other"processContents="lax"minOccurs="0"maxOccurs="unbounded" /> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence>processContents="lax"/> </xs:choice> <xs:attributename="id" type="xs:string" use="required"/>name="domain" use="optional" type="xs:string"/> </xs:restriction> </xs:complexContent> Schulzrinne, et al. ExpiresJanuary 19,April 26, 2006 [Page30]31] Internet-Draft Common PolicyJulyOctober 2005 </xs:complexType> <!-- //many/except --> <xs:complexType name="exceptType"> <xs:attribute name="domain" type="xs:string" use="optional"/> <xs:attribute name="id" type="xs:string" use="optional"/> <xs:attribute name="scheme" type="xs:string" use="optional"/> </xs:complexType> <!-- //conditions/sphere --> <xs:complexType name="sphereType"> <xs:complexContent> <xs:restriction base="xs:anyType"> <xs:attribute name="value" type="xs:string" use="required"/> </xs:restriction> </xs:complexContent> </xs:complexType> <!-- //conditions/validity --> <xs:complexType name="validityType"> <xs:complexContent> <xs:restriction base="xs:anyType"> <xs:sequence minOccurs="0" maxOccurs="unbounded"> <xs:element name="from" type="xs:dateTime"/> <xs:element name="until" type="xs:dateTime"/> </xs:sequence> </xs:restriction> </xs:complexContent> </xs:complexType> <!-- //rule/actions or //rule/transformations --> <xs:complexType name="extensibleType"> <xs:complexContent> <xs:restriction base="xs:anyType"> <xs:sequence> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:restriction> </xs:complexContent> </xs:complexType> </xs:schema> Schulzrinne, et al. ExpiresJanuary 19,April 26, 2006 [Page31]32] Internet-Draft Common PolicyJulyOctober 2005 14. Security Considerations This document describes a framework for authorization policy rules. This framework is intended to be enhanced elsewhere towards application domain specific data. Security considerations are to a great extent application data dependent, and therefore need to be covered by documents that extend the framework defined in this specification. However, new action and transformation permissions along with their allowed values must be defined in a way so that the usage of the permissions combining rules of Section 10 does not lower the level of privacy protection. See Section 10 for more details on this privacy issue. Schulzrinne, et al. ExpiresJanuary 19,April 26, 2006 [Page32]33] Internet-Draft Common PolicyJulyOctober 2005 15. IANA Considerations 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 procedures in [2].15.115.1. Common Policy Namespace Registration URI: urn:ietf:params:xml:ns:common-policy Registrant Contact: IETF Geopriv Working Group, Henning Schulzrinne (hgs+geopriv@cs.columbia.edu). XML: BEGIN <?xml version="1.0"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="content-type" content="text/html;charset=iso-8859-1"/> <title>Common Policy Namespace</title> </head> <body> <h1>Namespace for Common Authorization Policies</h1> <h2>urn:ietf:params:xml:ns:common-policy</h2> <p>See <a href="[URL of published RFC]">RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this specification.]</a>.</p> </body> </html> END15.215.2. Content-type registration for 'application/auth-policy+xml' This specification requests the registration of a new MIME type according to the procedures of RFC 2048 [3] and guidelines in RFC 3023 [4]. MIME media type name: application Schulzrinne, et al. ExpiresJanuary 19,April 26, 2006 [Page33]34] Internet-Draft Common PolicyJulyOctober 2005 MIME subtype name: auth-policy+xml Mandatory parameters: none Optional parameters: charset Indicates the character encoding of enclosed XML. Default is UTF-8. Encoding considerations: Uses XML, which can employ 8-bit characters, depending on the character encoding used. See RFC 3023 [4], Section 3.2. Security considerations: This content type is designed to carry authorization policies. Appropriate precautions should be adopted to limit disclosure of this information. Please refer to RFCXXXX [NOTE TO IANA/ RFC-EDITOR: Please replace XXXX with the RFC number of this specification.] security considerations section for more information. Interoperability considerations: none Published specification: RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this specification.] this document Applications which use this media type: Presence- and location-based systems Additional information: Magic Number: None Schulzrinne, et al. ExpiresJanuary 19,April 26, 2006 [Page34]35] Internet-Draft Common PolicyJulyOctober 2005 File Extension: .xml Macintosh file type code: 'TEXT' Personal and email address for further information: Hannes Tschofenig, Hannes.Tschofenig@siemens.com Intended usage: LIMITED USE Author/Change controller: This specification is a work item of the IETF GEOPRIV working group, with mailing list address <geopriv@ietf.org>.15.315.3. Common Policy Schema Registration URI: urn:ietf:params:xml:schema:common-policy Registrant Contact: IETF Geopriv Working Group, Henning Schulzrinne (hgs+geopriv@cs.columbia.edu). XML: The XML schema to be registered is contained in Section 13. Its first line is <?xml version="1.0" encoding="UTF-8"?> and its last line is </xs:schema> Schulzrinne, et al. ExpiresJanuary 19,April 26, 2006 [Page35]36] Internet-Draft Common PolicyJulyOctober 2005 16. References16.116.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. [2] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [3] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996. [4] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.16.216.2. Informative References [5] Rosenberg, J., "Presence Authorization Rules",draft-ietf-simple-presence-rules-02draft-ietf-simple-presence-rules-03 (work in progress),FebruaryJuly 2005. [6] Schulzrinne, H., "A Document Format for Expressing Privacy Preferences for Location Information",draft-ietf-geopriv-policy-05draft-ietf-geopriv-policy-06 (work in progress),November 2004.July 2005. [7] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004. [8]Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002., ., "Uniform Resource Identifier (URI) SCHEMES, available at: http://www.iana.org/assignments/uri-schemes", , . [9] Schulzrinne, H., "RPID: Rich Presence Extensions to the PresenceInformation Data Format (PIDF)", draft-ietf-simple-rpid-07 (work in progress), June 2005. Schulzrinne, et al. Expires January 19, 2006 [Page 36] Internet-Draft Common Policy July 2005 Authors' Addresses Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 USA Phone: +1 212 939 7042 Email: schulzrinne@cs.columbia.edu URI: http://www.cs.columbia.edu/~hgs John B. Morris, Jr. Center for DemocracyInformation Data Format (PIDF)", draft-ietf-simple-rpid-09 (work in progress), September 2005. [10] Jennings, C., Peterson, J., andTechnology 1634 I Street NW, Suite 1100 Washington, DC 20006 USA Email: jmorris@cdt.org URI: http://www.cdt.org Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Email: Hannes.Tschofenig@siemens.com URI: http://www.tschofenig.com Jorge R. Cuellar Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Email: Jorge.Cuellar@siemens.comM. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002. Schulzrinne, et al. ExpiresJanuary 19,April 26, 2006 [Page 37] Internet-Draft Common PolicyJuly 2005 James Polk Cisco 2200 East President George Bush Turnpike Richardson, Texas 75082 USA Email: jmpolk@cisco.com Jonathan Rosenberg DynamicSoft 600 Lanidex Plaza Parsippany, New York 07054 USA Email: jdrosen@dynamicsoft.com URI: http://www.jdrosen.net Schulzrinne, et al. Expires January 19, 2006 [Page 38] Internet-Draft Common Policy JulyOctober 2005 Appendix A. Contributors We would like to thank Christian Guenther for his help with this document.Christian Guenther Siemens AG Corporate Technology 81730 Munich Email: christian.guenther@siemens.com GermanySchulzrinne, et al. ExpiresJanuary 19,April 26, 2006 [Page39]38] Internet-Draft Common PolicyJulyOctober 2005 Appendix B. Acknowledgments This document is partially based on the discussions within the IETF GEOPRIV working group. Discussions at the Geopriv Interim Meeting 2003 in Washington, D.C., helped the working group to make progress on the authorization policies based on the discussions among the participants. We particularly want to thank Allison Mankin <mankin@psg.com>, Randall Gellens <rg+ietf@qualcomm.com>, Andrew Newton <anewton@ecotroph.net>, Ted Hardie <hardie@qualcomm.com>, Jon Peterson <jon.peterson@neustar.biz> for discussing a number of details with us. They helped us to improve the quality of this document. Furthermore, we would like to thank the IETF SIMPLE working group for their discussions of J. Rosenberg's draft on XCAP authorization policies. We thank Stefan Berg, Murugaraj Shanmugam, Christian Schmidt, Martin Thomson, Markus Isomaki, Aki Niemi and Eva Maria Leppanen for their comments. Schulzrinne, et al. ExpiresJanuary 19,April 26, 2006 [Page 39] Internet-Draft Common Policy October 2005 Authors' Addresses Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 USA Phone: +1 212 939 7042 Email: schulzrinne@cs.columbia.edu URI: http://www.cs.columbia.edu/~hgs John B. Morris, Jr. Center for Democracy and Technology 1634 I Street NW, Suite 1100 Washington, DC 20006 USA Email: jmorris@cdt.org URI: http://www.cdt.org Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Email: Hannes.Tschofenig@siemens.com URI: http://www.tschofenig.com Jorge R. Cuellar Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Email: Jorge.Cuellar@siemens.com Schulzrinne, et al. Expires April 26, 2006 [Page 40] Internet-Draft Common PolicyJulyOctober 2005 James Polk Cisco 2200 East President George Bush Turnpike Richardson, Texas 75082 USA Email: jmpolk@cisco.com Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, New York 07054 USA Email: jdrosen@cisco.com URI: http://www.jdrosen.net Schulzrinne, et al. Expires April 26, 2006 [Page 41] Internet-Draft Common Policy October 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Schulzrinne, et al. ExpiresJanuary 19,April 26, 2006 [Page41]42] ----