Showing content from https://www.rfc-editor.org/rfc/rfc4745.txt below:
Namespace for Common Authorization Policies
element MUST have the and subelements in pairs. Multiple and elements might appear in pairs (i.e., without nesting of and elements). Using multiple elements as subelements of the element is not useful since all subelements of the element are combined as a logical AND. 8. Actions While conditions are the 'if'-part of rules, actions and transformations form their 'then'-part. 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 that 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. Standards Track [Page 17] RFC 4745 Common Policy February 2007 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 that 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. 10. Procedure for Combining Permissions 10.1. Introduction This section describes how rules are selected and how actions and permissions are determined. When a PS receives a request for access to privacy-sensitive data, the request is matched against the rule set. A rule matches if all conditions contained as child elements in the element of a rule evaluate to TRUE. Each type of condition defines when it is TRUE. All rules where the conditions match the request form the matching rule set. The permissions in the matching rule set are combined using a set of combining rules (CRs) described in Section 10.2. 10.2. Combining Rules (CRs) Each type of permission is combined across all matching rules. Each type of action or transformation is combined separately and independently. The combining rules generate a combined permission. The combining rules depend only on the data type of permission. If a particular permission type has no value in a rule, it assumes the lowest possible value for that permission for the purpose of computing the combined permission. That value is given by the data type for booleans (FALSE) and sets (empty set), and MUST be defined by any extension to the Common Policy for other data types. For boolean permissions, the resulting permission is TRUE if and only if at least one permission in the matching rule set has a value of TRUE and FALSE otherwise. For integer, real-valued and date-time permissions, the resulting permission is the maximum value across the permission values in the matching set of rules. For sets, it is the union of values across the permissions in the matching rule set. Schulzrinne, et al. Standards Track [Page 18] RFC 4745 Common Policy February 2007 10.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 (WR-ID), sphere, and validity (from,until). The ID column is used as a rule identifier. For editorial reasons we omit the domain part of the WR's identity. We use two actions in our example, namely X and Y. The values of X and Y are of data types Boolean and Integer, respectively. The transformation, referred to as Z, uses values that can be set either to '+' (or 3), 'o' (or 2) or '-' (or 1). 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. The label 'NULL' in the table indicates that no value is available for a particular cell. 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 | NULL 12 o | | 6 bob work B1 B2 | FALSE 10 - | +---------------------------------+---------------------+ Again for editorial reasons, we use the following abbreviations for the two 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 rule set 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 Schulzrinne, et al. Standards Track [Page 19] RFC 4745 Common Policy February 2007 2003-12-24T17:15:00+01:00, which falls between A1 and A2. In our example, we assume that the sphere value of the PT is currently set to 'work'. As a first step, it is necessary to determine which rules fire by evaluating the conditions part of each of them. 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. Only rules 3 and 5 fire. We use the actions and transformations part of these two rules to determine the combined permission, as shown below. Actions/Transformations +-----+-----------------------+ | Id | X Y Z | +-----+-----------------------+ | 3 | TRUE 3 - | | 5 | NULL 12 o | +-----+-----------------------+ Each column is treated independently. The combined value of X is set to TRUE since the NULL value equals FALSE according to the description in Section 10.2. For the column with the name Y, we apply the maximum of 3 and 12, so that the combined value of Y is 12. For column Z, we again compute the maximum of 'o' and '-' (i.e., 2 and 1) which is 'o' (2). The combined permission for all three columns is therefore: Actions/Transformations +-----------------------+ | X Y Z | +-----------------------+ | TRUE 12 o | +-----------------------+ Schulzrinne, et al. Standards Track [Page 20] RFC 4745 Common Policy February 2007 11. Meta Policies Meta policies authorize a rule maker 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. 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 that 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'. 2003-12-24T17:00:00+01:00 2003-12-24T19:00:00+01:00 Schulzrinne, et al. Standards Track [Page 21] RFC 4745 Common Policy February 2007 13. XML Schema Definition This section provides the XML schema definition for the common policy markup language described in this document. Schulzrinne, et al. Standards Track [Page 22] RFC 4745 Common Policy February 2007 Schulzrinne, et al. Standards Track [Page 23] RFC 4745 Common Policy February 2007 Schulzrinne, et al. Standards Track [Page 24] RFC 4745 Common Policy February 2007 14. Security Considerations This document describes a framework for policies. This framework is intended to be enhanced elsewhere by 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. 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 [4]. 15.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 Common Policy Namespace Namespace for Common Authorization Policies urn:ietf:params:xml:ns:common-policy
See RFC 4745.
END Schulzrinne, et al. Standards Track [Page 25] RFC 4745 Common Policy February 2007 15.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 4288 [5] and guidelines in RFC 3023 [6]. MIME media type name: application MIME subtype name: auth-policy+xml Mandatory parameters: none Optional parameters: charset Indicates the character encoding of enclosed XML. Encoding considerations: Uses XML, which can employ 8-bit characters, depending on the character encoding used. See RFC 3023 [6], 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 Section 14 of RFC 4745 and to the security considerations described in Section 10 of RFC 3023 [6] for more information. Interoperability considerations: None Published specification: RFC 4745 Applications which use this media type: Presence- and location-based systems Additional information: Magic Number: None File Extension: .apxml Macintosh file type code: 'TEXT' Personal and email address for further information: Hannes Tschofenig, Hannes.Tschofenig@siemens.com Schulzrinne, et al. Standards Track [Page 26] RFC 4745 Common Policy February 2007 Intended usage: LIMITED USE Author: This specification is a work item of the IETF GEOPRIV working group, with mailing list address . Change controller: The IESG 15.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 and its last line is 16. References 16.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005. [3] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003. [4] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [5] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005. [6] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001. Schulzrinne, et al. Standards Track [Page 27] RFC 4745 Common Policy February 2007 16.2. Informative References [7] Rosenberg, J., "Presence Authorization Rules", Work in Progress, June 2006. [8] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., and J. Polk, "A Document Format for Expressing Privacy Preferences for Location Information", Work in Progress, February 2006. [9] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004. [10] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg, "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)", RFC 4480, July 2006. Schulzrinne, et al. Standards Track [Page 28] RFC 4745 Common Policy February 2007 Appendix A. Contributors We would like to thank Christian Guenther for his help with initial versions of this document. 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 , Randall Gellens , Andrew Newton , Ted Hardie , and Jon Peterson for discussing a number of details with us. They helped us to improve the quality of this document. Allison, Ted, and Andrew also helped us to make good progress with the internationalization support of the identifier/ domain attributes. Furthermore, we would like to thank the IETF SIMPLE working group for their discussions of J. Rosenberg's draft on presence authorization policies. We would also like to thank Stefan Berg, Murugaraj Shanmugam, Christian Schmidt, Martin Thomson, Markus Isomaki, Aki Niemi, Eva Maria Leppanen, Josip Matanovic, and Mark Baker for their comments. Martin Thomson helped us with the XML schema. Mark Baker provided a review of the media type. Scott Brim provided a review on behalf of the General Area Review Team. Schulzrinne, et al. Standards Track [Page 29] RFC 4745 Common Policy February 2007 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 Hannes Tschofenig Siemens Networks GmbH & Co KG Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany EMail: Hannes.Tschofenig@siemens.com URI: http://www.tschofenig.com 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 Jorge R. Cuellar Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany EMail: Jorge.Cuellar@siemens.com Schulzrinne, et al. Standards Track [Page 30] RFC 4745 Common Policy February 2007 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. Standards Track [Page 31] RFC 4745 Common Policy February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Schulzrinne, et al. Standards Track [Page 32]
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4