RFC 4745
Common Policy: A Document Format for Expressing Privacy Preferences
Common Policy: A Document Format for Expressing Privacy Preferences 🦋
Okay bestie, this is RFC 4745 💜 It's a Standards Track doc from the Network Working Group, dated February 2007. The authors are H. Schulzrinne (Columbia U.), H. Tschofenig (Siemens Networks GmbH & Co KG), J. Morris (CDT), J. Cuellar (Siemens), J. Polk (no affiliation listed), and J. Rosenberg (Cisco). The header doesn't list any RFCs it obsoletes or updates, so there's nothing to tag there 💅
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 🌸
Okay so this doc defines a framework for authorization policies that control access to application-specific data. It mashes together the common location and presence authorization stuff into one framework, and an XML schema spells out the language used to write the common policy rules. The common policy framework can be extended to other application domains, which is very main character of it 👑
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 .......................................291. Introduction ✨
Okay so the big idea here is a framework for making authorization policies that control access to application-specific data. It came from combining the shared parts of two separate authorization systems, the ones that handle presence and location info and had been built on their own. Combining them is a glow-up for two reasons 💖 First, you get a system that makes presence plus location way more valuable, and it reuses the same underlying authorization mechanism. Second, you get a more generic authorization framework with extensibility built in. It's not just for presence and location data, either. It can be extended to other application domains too 🌈
The general framework here is meant to be paired with application-specific policies defined somewhere else. The common policy framework gets enhanced by domain-specific policy documents, including presence [7] and location [8]. Here's how that relationship looks, iykyk 🦋
+-----------------+
| |
| Common |
| Policy |
| |
+---+---------+---+
/|\ /|\
| |
+-------------------+ | | +-------------------+
| | | enhance | | |
| Location-specific | | | | Presence-specific |
| Policy |----+ +----| Policy |
| | | |
+-------------------+ +-------------------+
Figure 1: Common Policy EnhancementsSo this doc starts with terminology in Section 2, then shows the basic modes of operation in Section 3. After that come the goals (see Section 4) and non-goals (see Section 5) of the policy framework, followed by the data model in Section 6. A rule is made of conditions, actions, and transformations, which get covered in Sections 7, 8, and 9. The procedure for combining permissions is explained in Section 10, and it's used whenever conditions for more than one rule are satisfied. Meta policies get a short description in Section 11, there's an example in Section 12, and the XML schema is discussed in Section 13. Last but not least, IANA considerations in Section 15 come after the 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 read as described in [1]. Bestie, these words are the real deal, so pay attention 🙈
This doc introduces a few terms you'll see all over the place:
- 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 holds an unordered list of 'rules'. Each 'rule' has a 'conditions' part, an 'actions' part, and a 'transformations' part. The term 'permission' means the action and transformation components of a 'rule'. And the term 'using protocol' is defined in [9]. It refers to the protocol used to request access to, and return, privacy-sensitive data items ✨
3. Modes of Operation 💜
Here's the abstract sequence of operations, roughly speaking. The PS gets a query for data items about a particular PT, through the using protocol. The using protocol (or more precisely, the authentication protocol) provides the identity of the requestor, either when the query happens or at subscription time. Then the authenticated identity of the WR, plus any other info the using protocol provides or the server can generally access, gets used to search through the rule set. All the matching rules are combined using a permission combining algorithm described in Section 10. The combined rules are applied to the application data, which applies privacy based on the transformation policies. Finally, the resulting application data is sent back to the WR 🫶
There are three different modes of operation you should know about 🎀
3.1. Passive Request-Response - PS as Server (Responder) 🌷
In passive request-response mode, the WR queries the PS for data items about the PT. Protocols that follow this mode include HTTP, FTP, LDAP, finger, and a bunch of remote procedure call (RPC) protocols, like 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 figure out whether the WR is authorized to access the PT's information, and it refuses the request if it has to 🙅♀️ It can also 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. 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 happens, the PS sends a message to the WR with the updated state. (Presence is a special case of event notification, so people often use the terms interchangeably, and honestly same 😭)
The subscriber can also add its own filter to the subscription, which limits the rate or content of the notifications. Here's the tea: if an event, after getting filtered by both the rule-maker-provided rules and the subscriber-provided rules, only produces the same notification content that was sent before, then no event notification is sent. Lowkey genius 🧠
A single PS may authorize access to data items in more than one mode. Instead of having different rule sets for different modes, all three modes are supported with one rule set schema. Specific instances of the rule set can leave out elements that only apply to the subscription model ✨
4. Goals and Assumptions 🎀
Okay bestie, so here are the design goals and constraints we're working with. Let's go! 💅
Table representation:
Every rule has to be representable as a row in a relational database. 🗃️ This goal is so we can get efficient policy implementation by using standard database optimization techniques. Iconic. ✨
Permit only:
Rules only give permissions, they never deny anything. 🙅♀️ Removing a rule can never increase permissions. Depending on how you read 'deny' and 'permit' rules, the ordering of rules might matter, and that makes updating rule sets way messier, because the update mechanisms would have to support inserting at specific spots in the rule set. Distributed rule sets get more complicated too. 😭 So only 'permit' actions are allowed, which makes rule processing more efficient. This also means rule ordering isn't important. The consequence is that making a policy decision means processing all the rules. 🔍
Additive permissions:
A query for access to data items gets matched against the rules in the rule database. If several rules match, the overall permissions granted to the WR are the union of those permissions. 🧩 There's a more detailed discussion in Section 10, so go check that out if you're curious. 🌸
Upgradeable:
You should be able to add more rules later without breaking PSs that haven't been upgraded. 🆙 Any such upgrades must not degrade privacy constraints, but PSs that aren't upgraded yet might reveal less information than the rule maker would've picked. Not ideal, but it's safe! 🫶
Capability support:
On top of the last goal, an RM should be able to figure out which extensions the PS supports. 🔎 How the RM works out the capability of a PS is outside the scope of this specification, so that's a different story. 🤷♀️
Protocol-independent:
The rule set can put constraints on notifications or queries, and also on subscriptions for event-based systems like presence systems. 🦋 It's giving flexibility!
No false assurance:
Okay this one is so real. 🥺 It's way more dangerous to make the user think the system will stop disclosure automatically, and then have it fail with a significant chance of operator error or misunderstanding, than to make the user explicitly use simpler rules. For example, weekday and time-of-day ranges seem especially prone to misinterpretation and false assumptions on the RM's part. (Like, a non-technical RM would probably assume the rules are based on the time zone of their current location, which might not be known to the other components of the system. 🙈 Not it!)
5. Non-Goals 🚫
We made a deliberate call that a bunch of possibly worthwhile capabilities are out of scope for this first version. 🫠 Future versions might include them through the extension mechanism described in this document. Here's what's NOT happening (yet):
No external references:
Attributes within specific rules cannot refer to external rule sets, databases, directories, or other network elements. 🙅♀️ Any external reference would make a simple database implementation difficult, so they're not supported in this version.
No regular expressions:
Conditions are matched on equality or 'greater-than'-style comparisons. They are not matched with regular expressions, partial matches like the SQL LIKE operator (e.g., LIKE "%foo%"), or glob-style matches ("*@example.com"). Most of these are better expressed as explicit elements. 💅
No repeat times:
Repeat times (e.g., every day from 9 am to 4 pm) are hard to make work correctly, because of the different time zones that PT, WR, PS, and RM might be in. 🌍 It seems like suggestions for including time intervals are often based on supporting work/non-work distinctions, which are unfortunately hard to capture with time alone. 💼 Note that this feature must not be confused with the 'Validity' element, which gives a mechanism to restrict the lifetime of a rule. ⏳ Different thing, bestie!
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 has three parts: conditions (see Section 7), actions (see Section 8), and transformations (see Section 9). 🎀
The conditions part is a set of expressions, and each one 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, the rule is applicable to this request. 🔑 Generally, each expression specifies a condition based on some variable 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, like the temperature or the mood of the PT. 🌡️ (The mood, lol. Iconic.)
If the rule is applicable to the request, the actions and transformations (commonly called 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 lets the request proceed. 🚪
If the action lets the request proceed, the transformations part of the rule specifies how the information about the PT (their location information, their presence, etc.) gets modified before it's presented to the WR. ✂️ These transformations are in the form of positive permissions. That means they always specify a piece of information that's 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 are described in Section 10. 🧮 The resulting union effectively represents a "mask", which 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 the mask permits is shown to the WR. If the WR requests only a subset of information (like 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. 💖 This one's a MUST, so no skipping!
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 doesn't imply that the RM or the PS use this format internally, e.g., when matching a query with the policy rules. 🙃 The rules are designed so that a PS can translate them into a relational database table, with each rule represented by one row in the database. The database representation is by no means mandatory. We 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. It also seems plausible that larger-scale implementations will use a backend database to store and query rules, since they can then benefit from existing optimized indexing, access control, scaling, and integrity constraint mechanisms. 📈 Smaller-scale implementations may well pick different approaches, like a simple traversal of the set of rules. 🧚
6.1. Identification of Rules 🏷️
Each rule has a parameter that identifies it. 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 by retrieving the already specified rule set and choosing a new identifier for a rule that's different from the ones in the existing rule set. 🧁
6.2. Extensions 🧩
The policy framework defined in this document is meant to be extensible toward 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. 🌈 (Non-negotiable, periodt.)
Extensions cannot change the schema defined in this document, and this schema isn't expected to change except via a 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 the remaining parts of a rule (i.e., actions and transformations) get executed. Details about rule matching are described in Section 10. 🦋 This document specifies only a few conditions (i.e., identity, sphere, and validity). More condition elements can be added through extensions to this document. If a child element of the <conditions> element is in a namespace that is not known or not supported, then that 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 of 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 to 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 so 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. In other words, the results of the individual child elements 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 that child element evaluates to FALSE. 💀
7.1.2. Matching One Entity ✨
okay so the <one> element matches the authenticated identity (the one in the 'id' attribute) of exactly one entity or user 🫶 for the 'id' attribute stuff, go peek at Section 7.2, it's giving detail 💅
here's an example, bestie 🎀
<?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>so this one 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 the mechanism for making authorization decisions based on the domain part of the authenticated identity 😭 which means it can match a huge (possibly unknown!) number of users inside a domain, iconic
you can also drop in one or more <except> elements to kick out either individual users or everyone from a specific domain. excluding single people looks like <except id="..."/>, and the 'id' attribute of <except> means the same thing as the 'id' on <one> (see Section 7.2). excluding a whole domain looks like <except domain="..."/>, which bounces any user from that domain 🚫
if you stack multiple <except> elements under one <many>, each result gets combined with a logical OR 💜
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. 🍓 when you're comparing the 'domain' value against the domain the using protocol hands over (the "protocol domain identifier"), follow these steps, no cap:
- Translate percent-encoding for either string.
- Convert both domain strings using the ToASCII operation described in RFC 3490 [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. periodt 💀
7.1.3.1. Matching Any Authenticated Identity 🧚
the <many/> element with no child elements or attributes matches any authenticated user. main character energy 👑
here's 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>7.1.3.2. Matching Any Authenticated Identity Except Enumerated Domains/Identities 🌈
a <many> element holding one or more <except domain="..."/> elements matches any user from any domain except the ones you listed 🙈 the <except id="..."/> element kicks out particular users (the 'id' semantics are in Section 7.2). the results of the <many> element's children get combined with a logical OR, the way that it works 💅
here's the example:
<?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>so this matches all users except anyone in example.com, anyone 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' is redundant since alice@example.com is already excluded by the first line 😭 (not me reading redundant code 🥲)
7.1.3.3. Matching Any Authenticated Identity within a Domain Except Enumerated Identities 🦋
a <many> element with a 'domain' attribute plus zero or more <except id="..."/> elements matches any authenticated user from that domain, except the ones explicitly listed. the 'id' semantics of <except> are in Section 7.2 🫶
it's nonsensical to have domains in the 'id' attribute that don't match the 'domain' value on the enclosing <many> element 💀
example time:
<?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 one matches any user within example.com (like carol@example.com) except alice@example.com and bob@example.com ✨
7.2. Single Entity 🎀
the 'id' attribute used in <one> and <except> refers to a single entity. from here on, we call that a 'single-user entity' as a placeholder for either <one> or <except> 🍓 the <except> element's whole job is to exclude things from the solution set, bye bye 👋
a single-user entity matches the authenticated identity (in its 'id' attribute) of exactly one entity or user. if there's a match, the single-user entity counts as TRUE 💖 A single-user entity MUST NOT contain a 'domain' attribute. no domain attribute, period 🙅♀️
the 'id' attribute holds an identity that MUST first be expressed as a URI. applications using this framework need to describe how their identities can be written as URIs, so be explicit, bestie 🌸
7.3. Sphere 🌙
the <sphere> element is part of the condition elements crew 🧚 it shows a state the PT is currently in, like 'work', 'home', 'meeting', or 'travel' ✨ a sphere condition only matches if the PT is in the state named. the state can come from manual configuration or from some protocol. for example, RPID [10] lets the PS know the PT's current sphere 💜 the application domain has to explain in more detail how the sphere state gets determined. switching from one sphere to another flips between different visibility modes, so different sets of rules might apply, iykyk 👀
The content of the 'value' attribute of the <sphere> element MAY contain more than one token. the tokens MUST be separated by a blank character. a logical OR is used to match the tokens against the PT's sphere settings. so if the 'value' has two tokens, 'work' and 'home', the rule matches when the PT's sphere is either 'work' OR 'home' 🌈 when comparing, a case-insensitive string comparison MUST be used for each individual token. there's no registry for these values and no language-specific indication of the sphere content, so 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>
<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>so the rule with andrew@example.com matches if the sphere is set to 'work' 💼 the second one has allison@example.com matching if the sphere is set to 'home' 🏡 the third rule also matches, since its sphere value contains the token 'home' 🎉
7.4. Validity ⏰
the <validity> element is the third condition element in this document 💅 it sets the rule's validity period with two values, a start and an end time. the validity condition is TRUE when the current time is greater than or equal to at least one <from> child, but less than the <until> child after it. that's a logical OR across each <from> and <until> pair 💖 times are written in XML dateTime format.
here's the vibe: a rule maker might not always have access to the PS to switch off permissions they granted, so this lets granted permissions expire on their own, no back-and-forth needed 🥹 The PS does not remove the rules; instead the rule maker has to clean them up. so the PS isn't deleting anything, the rule maker has to do the tidying 🧹
a rule fragment looks like this:
<?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 <validity> element MUST have the <from> and <until> subelements in pairs. multiple <from> and <until> elements can show up in pairs, as long as they aren't nested inside each other 🌸 using multiple <validity> elements as subelements of <conditions> isn't useful, because all subelements of <conditions> get combined as a logical AND, so one <validity> is plenty 🫶
8. Actions ✨
okay so bestie, conditions are the "if" part of a rule, and actions plus transformations are the "then" part 💅. Once the PS has a data access request from a WR that matches all the conditions of a rule, the actions and transformations tell it which operations it MUST execute. There's no "deny" button here, just operations that grant or modify things 🦋.
Transformations are the PS-side operations that change the data items the WR asked for. Like, for location data, a transformation could make the PS lower the precision of the location info it sends back to the WR 📍. Actions are basically everything else the PS is obligated to do, so anything that isn't a transformation 🎀. Actions get defined by the application-specific usages of this framework, so if you want examples, go check out the corresponding extensions 🌸.
9. Transformations 🌈
okay, so a rule has two sub-parts after its conditions: transformations and actions 💖. Like we said in Section 8, transformations are operations the PS MUST execute, and they modify the result that gets returned to the WR 🫶. This is SO helpful for reducing how granular the info is, which is literally what you need for location privacy 🔥. Transformations are defined by application-specific usages of this framework too 🧚.
There's a simple transformation example in Section 10 👑.
10. Procedure for Combining Permissions 💜
10.1. Introduction 🌸
this section is about how rules get picked and how actions and permissions get figured out 😭. When a PS gets a request for access to privacy-sensitive data, the request gets matched against the rule set 🍓. A rule matches if ALL the conditions in its <conditions> element evaluate to TRUE 💅. Each condition type defines when it's TRUE. All the rules where the conditions match the request form the matching rule set ✨. Then the permissions in that matching set get combined using the combining rules (CRs) from Section 10.2 🦋.
10.2. Combining Rules (CRs) 🎀
each type of permission gets combined across all the matching rules 💖. Each type of action or transformation is combined separately and independently, no mixing ✨. The combining rules produce one combined permission 🌈, and they depend only on the data type of the permission 💅. If a permission type has no value in a rule, it assumes the lowest possible value for that permission when computing the combined permission 🙈. That lowest value is set by the data type: FALSE for booleans, the empty set for sets. And any extension to the Common Policy for other data types MUST define its own lowest value 🫶.
For boolean permissions, the result is TRUE if and only if at least one permission in the matching rule set is TRUE, otherwise it's FALSE 🔥. For integer, real-valued, and date-time permissions, the result is the maximum value across the permission values in the matching set 👑. For sets, it's the union of the values across the permissions in the matching rule set 🌸.
10.3. Example 🧚
okay this example is SO good for seeing how combining works 😭. We're using three conditions: name identity (WR-ID), sphere, and validity (from, until) 💜. The ID column is just a rule identifier 🍓. For editorial reasons, the domain part of the WR's identity is left out 🙈.
We have two actions, X and Y, with data types Boolean and Integer 🦋. The transformation Z uses values that can be + (or 3), o (or 2), or - (or 1) 💖. Z shows the granularity reduction: + shows the info unrestricted and - shows nothing 🌈. This permission could relate to location info or other presence attributes like mood ✨. Internally, Z uses the Integer data type for computing its permission 💅.
The label NULL in the table means no value is available for that 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 - |
+---------------------------------+---------------------+For editorial reasons, the two <validity> attributes 'from' and 'until' get abbreviations too 📅:
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:00So B1 < B2 < A1 < A2 < A3 ⏰.
'bob' is the WR here, requesting data items 💅. The rule set has the six rules in the table, identified by 1 to 6 in the 'Id' column 🌈. The PS gets the query at 2003-12-24T17:15:00+01:00, which falls between A1 and A2 ✨. We're assuming the PT's sphere is currently set to 'work' 🫶.
First step: figure out which rules fire by checking each one's conditions 🔥.
Rule 1 doesn't match because the sphere doesn't match 🙈. Rule 2 doesn't match because the WR ('alice') isn't 'bob' 💀. Rule 3 matches since all conditions are TRUE 🎀. Rule 4 doesn't match because the WR ('tom') isn't 'bob' 😭. Rule 5 matches 💖. Rule 6 doesn't match because the rule isn't valid anymore 🦋.
Only rules 3 and 5 fire 🔥. Now we use the actions and transformations parts of those two rules to get the combined permission:
Actions/Transformations
+-----+-----------------------+
| Id | X Y Z |
+-----+-----------------------+
| 3 | TRUE 3 - |
| 5 | NULL 12 o |
+-----+-----------------------+Each column is treated independently 💅. X ends up TRUE, since NULL counts as FALSE according to Section 10.2 🌸. For column Y, we take the maximum of 3 and 12, so the combined Y is 12 👑. For column Z, we take the maximum of 'o' and '-' (that's 2 and 1), which is 'o' (2) 🧚.
So the combined permission for all three columns is:
Actions/Transformations
+-----------------------+
| X Y Z |
+-----------------------+
| TRUE 12 o |
+-----------------------+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 stop unauthorized changes to rule sets 🫶. Meta policies are outside the scope of this document 🌸.
A simple implementation could limit access to the rule set to just the PT, but more sophisticated mechanisms could be useful 💖. As an example, picture parents configuring the policies for their kids 🥹.
12. Example 🎀
this section has an example of an XML document that's valid against the XML schema in Section 13 ✨. Semantically richer examples live in documents that extend this schema with application-domain-specific data, like location or presence info 🦋.
Here, a rule has a condition that matches a given authenticated identity (bob@example.com) and a given time period 🌈. The rule only matches 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>
<one id="sip: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>13. XML Schema Definition 🧚
okay this section has the XML schema definition for the common policy markup language in this doc 💜. Let's get into it 🫶.
<?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">
<!-- /ruleset -->
<xs:element name="ruleset">
<xs:complexType>
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="rule" type="cp:ruleType"
minOccurs="0" 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:element 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:attribute name="id" type="xs:ID" use="required"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- //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"
type="cp:sphereType" minOccurs="0"/>
<xs:element name="validity"
type="cp:validityType" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:choice>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- //conditions/identity -->
<xs:complexType name="identityType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:choice minOccurs="1" maxOccurs="unbounded">
<xs:element name="one" type="cp:oneType"/>
<xs:element name="many" type="cp:manyType"/>
<xs:any namespace="##other" processContents="lax"/>
</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"
minOccurs="0" processContents="lax"/>
</xs:sequence>
<xs:attribute name="id"
type="xs:anyURI" use="required"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- //identity/many -->
<xs:complexType name="manyType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="except" type="cp:exceptType"/>
<xs:any namespace="##other"
minOccurs="0" processContents="lax"/>
</xs:choice>
<xs:attribute name="domain"
use="optional" type="xs:string"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- //many/except -->
<xs:complexType name="exceptType">
<xs:attribute name="domain" type="xs:string" use="optional"/>
<xs:attribute name="id" type="xs:anyURI" 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="1" 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>14. Security Considerations 🔐💀
Okay, this section is SERIOUS, bestie 😭. This document just describes a framework for policies 📋. The whole point is that other documents will extend it with their own application-specific data 🧩. And honestly? The security stuff depends a LOT on that application data, so it has to be covered by whatever documents extend this framework 📚. BUT here's the big warning 🚨: any new action or transformation permissions, plus their allowed values, MUST be defined in a way where using the permissions combining rules from Section 10 does NOT lower the level of privacy protection 🙅♀️. Go check Section 10 for more on this privacy issue, it's a whole thing 🔍.
15. IANA Considerations 📝✨
This section registers a new XML namespace, a new XML schema, and a new MIME type 🎀. The namespace registration follows 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
<?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="ftp://ftp.rfc-editor.org/in-notes/rfc4745.txt">
RFC 4745</a>.</p>
</body>
</html>
END15.2. Content-type Registration for 'application/auth-policy+xml' 🦋
This specification asks for a brand new MIME type 🙌, registered following RFC 4288 [5] and the 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 💜
Intended usage: LIMITED USE
Author:
This specification is a work item of the IETF GEOPRIV working group, with mailing list address <geopriv@ietf.org> 🌈.
Change controller:
The IESG <iesg@ietf.org> 👑
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
<?xml version="1.0" encoding="UTF-8"?>and its last line is
</xs:schema>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.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.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 <mankin@psg.com>, Randall Gellens <rg+ietf@qualcomm.com>, Andrew Newton <anewton@ecotroph.net>, Ted Hardie <hardie@qualcomm.com>, and Jon Peterson <jon.peterson@neustar.biz> 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 👑.
Authors' Addresses ✨
okay bestie, here are the humans behind this doc 🧚 they're the squad who wrote it, and these are how you can reach them 💌
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/~hgsHannes Tschofenig
Siemens Networks GmbH & Co KG
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
EMail: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.comJohn 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.orgJorge R. Cuellar
Siemens
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
EMail: Jorge.Cuellar@siemens.comJames Polk
Cisco
2200 East President George Bush Turnpike
Richardson, Texas 75082
USA
EMail: jmpolk@cisco.comJonathan Rosenberg
Cisco Systems
600 Lanidex Plaza
Parsippany, New York 07054
USA
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.netFull Copyright Statement 💅
The legal bits, bestie 📜 This is Copyright (C) The IETF Trust (2007). The document is covered by the rights, licenses, and restrictions in BCP 78, and apart from what that says, the authors keep all their rights 🦋
It's also provided on an "AS IS" basis. The contributor, the organization they represent or are sponsored by (if any), the Internet Society, the IETF Trust, and the Internet Engineering Task Force all disclaim all warranties, express or implied 🙈 That includes, but isn't limited to, any promise that using the info here won't infringe anyone's rights, plus implied warranties of merchantability or fitness for a particular purpose. Not gonna lie, it's a lot, but it's important 💀
Intellectual Property 🔥
The IETF doesn't take a side on whether any Intellectual Property Rights (or other rights) that someone might claim over this tech are valid or how far they reach 🌸 It also doesn't say whether licenses for those rights are available, and it hasn't independently gone hunting for any such rights either. If you want the rules on rights in RFC documents, check out BCP 78 and BCP 79 💜
Copies of IPR disclosures sent to the IETF Secretariat, plus any assurances of licenses that are supposed to be available, or the results of anyone trying to get a general license or permission for implementers or users to use these proprietary rights, can be found in the IETF's online IPR repository at http://www.ietf.org/ipr 🧚
Also, the IETF invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org ✨
Acknowledgement 🫶
Funding for the RFC Editor function is currently provided by the Internet Society 🌈 Thank you, Internet Society, you're literally keeping the lights on 💖
📦 where this page comes from
- ietf: rfc4745 2007-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms