- From: Graham Klyne <GK@dial.pipex.com>
- Date: Thu, 27 Apr 2000 16:20:24 +0100
- To: <www-rdf-interest@w3.org>, CC/PP WG list <w3c-ccpp-wg@w3.org>
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