CC/PP, RDF and trust issues

Folks,

The W3C CC/PP group are exploring trust issues in RDF, which we believe to 
be an important issue for CC/PP and also of general relevance to RDF 
applications.  Below are some thoughts on this matter.

#g
--


1. Background

CC/PP is working to define an RDF-based format ("client profile") to 
describe client capabilities and preferences, which may be used by an 
origin server (or transcoding proxies) to adapt content for the 
client.  Clearly, incorrect information supplied to the server may result 
in unusable content, so issues of accuracy and authentication are significant.

Further, proxies may choose to modify the client profile to take account of 
additional capabilities or policies that the client does not express, so 
there exists a possibility of conflicting information from different 
sources.  We anticipate that such additional information may be expressed 
as differences applied to the original client profile.


2. Resolving conflicts

RDF has been conceived with the expectation that conflicting information 
may be expressed, and that "web of trust" ideas may be used in resolving 
such conflicts.  For CC/PP, this implies that trust information is 
associated with elements of the client profile.


3. Deducing and transferring trust

It is presumed that "trust" (on the part of an information user) is 
inferred by a combination authentication and knowledge of the principal 
identified.  For example, it seems reasonable that a server would trust 
information about a client's capabilities that is known to have originated 
from the client itself.

The client profile transferred from client to server is an RDF graph, which 
may be augmented and/or modified by proxies along the way.  But (it is 
assumed that) authentication of the information will be by some digital 
signature mechanism (e.g. XMLDSIG) applied to a specific XML serialization 
of the RDF graph.  This raises two questions:

(a) is the authentication information to be represented as part of the RDF 
graph?  I think this is how it should be, which leads to...

(b) how is authentication information to be represented within an RDF 
graph?  Also, how are multiple authentications to be handled (e.g. 
additional capabilities added by proxies)?

In private discussions, a model has emerged in which an "assurance" 
property can be applied to a reification of the RDF statements, whose 
object is [an identifier of] the principal who signed the original expression.

It seems that the shift from "signature" to "assurance" parallels the 
distinction between the serialization of an RDF graph, and the abstract 
graph itself.  A signature, by its nature, applies to the serialized form, 
not the graph, but it does confer information that is meaningful as part of 
the knowledge potentially represented by the graph.


4. Challenges for CC/PP and RDF

(a) is the above approach a reasonable use of the RDF framework, or a 
horrible abuse?  (The phrase "sharp tools" comes to mind here with respect 
to RDF.)

(b) if the approach is reasonable, how can we incorporate it into the CC/PP 
framework in a way that does not create confusion for users and developers 
who must work with it?

Implicit in this question is the idea that dealing directly with 
reification in the CC/PP model will create a significant barrier to its 
adoption.  The CC/PP requirements document has already attracted some 
public comment that it is over-complex;  irrespective of whether such 
comments are justified, they send a signal that employing the full 
expressive power of RDF will likely be problematic.

Some of our thinking has followed a path where we could define a new RDF 
property, say "signedby", that conveys information about authentication 
information applied to the RDF statements, rather than their reification, 
but whose meaning can be defined in terms of a reification.  E.g. to define 
a graph form:

     [client]
     [      ]
     [      ] --property1--> [ ... ]
     [      ] --property2--> [ ... ]
     [      ] --property3--> [ ... ]
     [      ]
     [      ] --signedby--> [signer-id]

which can be expressed as a combination of the statements made about 
"client", and an assurance statement applied to the reifications of each of 
those statements.  The hope would be that, in normal use, the reification 
would not need to be made explicit for typical CC/PP processing.

(c) if such an approach is to be adopted, or indeed any other approach, it 
may be that this is something that is going to be a common requirement for 
all sorts of RDF applications.  Therefore, it seems appropriate that it is 
defined as a common RDF facility rather than something that is specific to 
CC/PP.  Has any substantial work in this area already tackled by the RDF 
community?


5. Conclusion

These are some kinds of issues and ideas that we wish to explore.  If the 
ideas sketched are inappropriate, or if there are better ideas in common 
use, this would be a good time to find out.

Given that CC/PP is committed to be built upon RDF, it seems desirable to 
engage as much RDF expertise as we can in the CC/PP design.  It is 
important for us to find a design for CC/PP that is direct and intuitive 
for developers and users, and that also does not violate the RDF model or 
common usage.  One area where this seems to be particularly important is 
that the trust issues are resolved cleanly and carefully.

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

Received on Thursday, 27 April 2000 13:35:04 UTC