CCPP and P3P compatibility concerns

Folks,

Writing as an individual who also happens to be a participant in the CC/PP 
working group, and having a growing interest in RDF applications, I have 
some concerns about compatibility between CC/PP and P3P.


1. How does CCPP/P3P compatibility matter?
------------------------------------------

CCPP is defining a framework for describing client capabilities that may be 
used by a server (or possibly a proxy) in the selection and/or generation 
of content tailored to the client.

Some of this information may have implications for privacy;  for example, a 
particular type of client device may be generally used by a user with 
certain disabilities.  Choice of language might indicate the ethnic origin 
of a person.

Thus, when interacting with a CC/PP and P3P enabled systems, we wish to be 
able to contract that the server will appropriately limit its use of any 
sensitive elements of capability information provided.

For effective take-up of CCPP and P3P, we believe that it is important that 
the introduction of new vocabulary for identifying client capabilities is 
as simple as possible.


2. CCPP background
------------------

CCPP is an application of RDF.

The CCPP specification, and all the earlier work on which it is based 
[http://www.w3.org/TR/NOTE-CCPP, 
http://www1.wapforum.org/tech/terms.asp?doc=SPEC-UAProf-19991110.pdf], uses 
RDF property arcs to denote attributes (capabilities, features) of a client 
device.  Thus, individual capabilities are identified by URIs:

So an RDF statement describing a particular feature of a client looks like 
this:

   (Client-profile) ---attribute URI---> [attribute-value]

    {RDF-resource}     {RDF property}    {RDF resource or literal}


3. My understanding of P3P
--------------------------

P3P makes assertions about the purposes for which identified pieces of 
information will be used, and information about other parties to which said 
information may be disclosed, among other things.  The pieces of 
information are identified by a P3P data schema, which defines strings that 
may appear in a <DATA> element.

The P3P specification does not use RDF.  Instead, it uses XML to construct 
a data structure that denotes a privacy contract.

The P3P model can be modelled in RDF, as demonstrated in appendix 4 of the 
P3P specification.


4. My concerns about P3P compatibility with CCPP
------------------------------------------------

Unfortunately, I don't believe that the ability to model P3P data in RDF is 
sufficient;  the style of model also seems to be important.

In the RDF model given for P3P data, the information item identifiers (that 
appear in <DATA> elements) are modelled as RDF literals, with a particular 
format defined by the P3P specification (section 3.3.6).

Conversly, the CCPP model requires that client capabilities are described 
using RDF properties, which are identified by arbitrary URIs.

It seems to me, then, that P3P does not provide an automatic way to refer 
to an arbitrary client capability that may be introduced into CCPP, without 
also defining an explicit mapping to a P3P data schema.  This goes against 
the need for minimal overhead to introduce new capabilities into CCPP.


--

So those are my concerns.  Comments?

#g

------------
Graham Klyne
(GK@ACM.ORG)

Received on Friday, 17 March 2000 06:12:42 UTC