Common Policy: A Document Format for Expressing Privacy Preferences
Extracted elements (26)
Complex conditions such as time-of-day ranges were avoided due to the 'no false assurance' principle: it is more dangerous to give the RM the impression that privacy is automatically enforced when the rule may be misinterpreted, than to require simpler explicit rules. Non-technical users often assume time rules apply to their local time zone, which may be unknown to the PS.
Repeat time intervals (e.g., daily 9am–4pm) were explicitly excluded because different time zones occupied by PT, WR, PS, and RM make correct interpretation difficult and error-prone. The 'Validity' element provides one-shot time windows instead. Work/non-work distinctions are poorly captured by time alone.
Rules are designed to map to rows in a relational database table (one rule per row) to enable efficient policy implementation using standard database indexing, access control, and integrity mechanisms. This is a design goal, not a mandatory internal representation.
Rules only provide permissions (permit-only); there is no deny functionality. This eliminates rule-ordering dependencies, simplifies update operations, avoids complications in distributed rule sets, and results in more efficient processing. The consequence is that to make a policy decision all rules must be processed.
All three operation modes (passive request-response, active request-response, and event notification) are supported by a single rule set schema. Instances of the rule set can omit elements only applicable to the subscription model, allowing the same policy document to serve multiple protocol interaction patterns.
The Common Policy XML format is an exchange format between RM and PS only; it does not mandate any internal representation. The PS may translate rules to a relational database, use simple traversal, or any other mechanism. The XML schema uses 'lax' processing for unknown namespace elements in conditions, actions, and transformations to support forward compatibility.
A Rule Maker MUST NOT use the same identifier for two rules that are available to the PS at the same time for a given PT. If multiple RMs modify the same rule set, each rule must receive a unique identifier, e.g., by retrieving the existing rule set and choosing a non-conflicting ID.
Comparison of the 'value' attribute of <sphere> against the PT's stored sphere setting MUST use case-insensitive string comparison for each individual token. There is no registry for sphere values and they are treated as opaque strings.
Domain names in the 'domain' attribute MUST be stored in UTF-8 or UTF-16; for non-IDNs, lowercase ASCII SHOULD be used. Domain comparison requires: (1) decode percent-encoding, (2) apply ToASCII (RFC 3490) to both strings, (3) compare per-label for ASCII equality. If ToASCII conversion fails, domains are not equal.
Each extension to the Common Policy framework MUST define its own XML namespace. Extensions cannot change the schema defined in this document, and no versioning procedures are provided for this schema or namespace.
Extensions to Common Policy MUST define the lowest possible value for any permission data types other than boolean and set, since the combining algorithm uses this value when a permission is absent from a matching rule.
If a child element of the <conditions> element is in a namespace that is not known or not supported, that child element evaluates to FALSE. Similarly, unknown child elements of <identity> evaluate to FALSE.
If the WR requests only a subset of data, the information delivered MUST be the intersection of the permissions granted to the WR and the data actually requested by the WR. This prevents over-disclosure when the WR requests less than what is permitted.
The 'id' attribute of a single-user entity (<one> or <except>) MUST NOT contain a 'domain' attribute. The 'id' attribute value MUST be expressed as a URI; applications using this framework must describe how their identities map to URIs.
The <validity> element MUST have <from> and <until> subelements in pairs. Multiple <from>/<until> pairs may appear but must not be nested. Using multiple <validity> elements under <conditions> is not useful since all <conditions> children are combined with logical AND.
A rule set (policy) consists of zero or more unordered rules. Each rule has three parts: conditions (evaluated TRUE/FALSE), actions (PS operations to execute), and transformations (data modifications returned to the WR). All matching rules' permissions are combined additively.
Actions specify all PS operations that are not data transformations; they are defined by application-specific extensions and constitute the permit-side of a rule. Transformations specify PS-side operations that modify data items before returning them to the WR, such as reducing location precision. There is no deny functionality.
The <identity> condition restricts rule matching to one or more authenticated entities using <one> (exact URI match) and <many> (domain-wide match with optional <except> exclusions) child elements. The <identity> condition is TRUE if any child element evaluates to TRUE (logical OR). If <identity> is absent, other conditions apply to any user regardless of authentication.
The permission-combining procedure evaluates all rules in the rule set; matching rules are those where all conditions evaluate to TRUE. Permissions across matching rules are combined per type: boolean permissions yield TRUE if any matching rule is TRUE; integer/real/datetime permissions yield the maximum; set permissions yield the union. A missing (NULL) permission value assumes the lowest value for its type.
The <sphere> condition element matches a rule only when the PT is currently in the named state (e.g., 'work', 'home', 'meeting'). The 'value' attribute MAY contain multiple whitespace-separated tokens combined with logical OR. Sphere state may be conveyed by manual configuration or a protocol such as RPID.
The <validity> condition element restricts a rule to specific time windows expressed as one or more <from>/<until> pairs in XML dateTime format. The condition is TRUE if the current time falls within at least one from/until pair (logical OR across pairs). The PS does not remove expired rules; the rule maker must clean them up.
Registers MIME type 'application/auth-policy+xml' for carrying Common Policy authorization documents. Optional 'charset' parameter indicates XML character encoding. Intended usage is LIMITED USE; applicable to presence- and location-based systems. File extension is '.apxml'.
Registers XML namespace 'urn:ietf:params:xml:ns:common-policy' in the IETF XML Registry per BCP 81 (RFC 3688). Registrant contact is the IETF GEOPRIV working group.
Registers XML schema 'urn:ietf:params:xml:schema:common-policy' in the IETF XML Registry per BCP 81. The schema is the one defined in Section 13 of this document and covers ruleset, rule, conditions, identity, one, many, except, sphere, validity, and extensibleType elements.
Security considerations are largely application-data dependent and must be addressed by documents that extend this framework. However, new action and transformation permissions along with their allowed values must be defined such that the combining rules of Section 10 do not lower the level of privacy protection.
The Common Policy Markup Language is an XML format under namespace 'urn:ietf:params:xml:ns:common-policy'. A <ruleset> contains zero or more <rule> elements each with a required xs:ID 'id' attribute and optional <conditions>, <actions>, and <transformations> children. Condition types include <identity>, <sphere> (string 'value' attribute), and <validity> (<from>/<until> xs:dateTime pairs). Identity types use xs:anyURI for the 'id' attribute.