This document describes an experimental approach for modeling P3P using OWL, i.e., using OWL as a metalanguage for both privacy preferences and policies. A sample implementation of a toy subset of P3P is presented.
An atomic policy is a tuple consisting of a number of properties that identify rights granted by the atomic policy, and obligations that must be fulfilled when the rights are exercised. Policies and preferences are classes of atomic policies. One policy p1 is proven to enforce a policy p2 if and only if the following is proven:
p1 rdfs:subClassOf
p2
Hence, the problem of matching policies and preferences is reduced to proving subclass relationships.
The properties that an atomic policy has can be divided into obligations and rights: The data that a policy applies to represent a right -- a policy that gives access to less data elements enforces another one that provides access to more data elements, but is otherwise the same. On the other hand, a policy that indicates that a service is willing to enter into more obligations enforces one where the service is willing to enter into less obligations.
The difference between rights and obligations has the following
effect on modeling: Every atomic policy corresponds to precisely
one access right (e.g., access a single resource for a single
purpose), described by a number of functional properties.
This enables us to describe the maximum rights granted by a
policy by an owl:allValuesFrom
restriction. On the
other hand, there may be any number of obligations associated
with a single such right. We use relational properties
to model these rights. To describe the obligations that a
service is willing to enter into (or that are required by the
user), the intersection of a number of
owl:someValuesFrom
restrictions can then be used.
We have prepared a sample implementation that models a toy subset of P3P in OWL.
Our toy subset of P3P deals with the following aspects of policies, all modeled as classes:
#Access
#AccessAll
,
#AccessIdentifiable
, #AccessNone
.
Presently, there are no further structural relationships
between these subclasses.
#Data
#click-stream
and #personal
.
#Purpose
#PurposeDelivery
(present
purposes, and possibly delivery of goods) that in turn has a
subclass #PurposeOurs
(present purposes).
These aspects are connected to the base class for policies,
#Policy
, by functional properties
#access
, #data
, and #purpose
.
Every #Policy
has each
of these properties.
A simple example policy:
<owl:Class rdf:ID="samplePolicy"> <owl:intersectionOf rdf:parseType="Collection"> <!-- This is a policy --> <owl:Class rdf:about="&toy;Policy"/> <!-- We grant access to identifiable information --> <owl:Restriction> <owl:onProperty rdf:resource="&toy;access"/> <owl:someValuesFrom rdf:resource="&toy;AccessIdentifiable"/> </owl:Restriction> <!-- It applies to personal information --> <owl:Restriction> <owl:onProperty rdf:resource="&toy;data"/> <owl:allValuesFrom rdf:resource="&toy;personal"/> </owl:Restriction> <!-- Collected for "our" purpose --> <owl:Restriction> <owl:onProperty rdf:resource="&toy;purpose"/> <owl:allValuesFrom rdf:resource="&toy;PurposeOurs"/> </owl:Restriction> </owl:intersectionOf> </owl:Class>
Thomas Roessler
$Id: Overview.html,v 1.13 2005/07/21 15:39:11 roessler Exp $