Re: CC/PP, RDF and trust issues

Sergey,

Thank you for your comments.

I took a look at the first reference you supplied 
(http://nestroy.wi-inf.uni-essen.de/rdf/sum_rdf_api/), and did not see 
anything there about signing RDF graphs.  The nearest I could find was the 
discussion in section 3.1 about using digests for resource ID 
generation.  Could you direct me more closely?

Generally speaking, I see we concur about the futility of carrying 
signatures of RDF serialization syntax as a way of representing assurances 
in an RDF model.  But we also seem to differ in the need to _sign_ an RDF 
model (as distinct from representing the assurance a signature may convey).


OF SIGNATURES AND ASSURANCES

The view I had taken was that an RDF model, or graph, does not have any 
specific representation.  Thus, it is not necessary to define a form of 
unforgeable _signature_ over an RDF graph, but rather to have a way of 
representing within the graph the type and level of assurance that is 
associated with various sub-graphs.  Mechanisms for resisting forgery 
belong in the serialization layer, not in (what I might call) the semantic 
layer.

For example:  suppose I receive a paper signed by "Alice" stating that "Bob 
has supplied service X".  Alice's signature on the paper allows me to 
assert, as a fact:  "Alice states that Bob has supplied service X".  This 
assertion is a meaning, without physical representation, that I draw from 
the paper supplied and as such is not of itself subject to confirmation of 
protection by Alice's signature.  (If I lose the original paper, I may 
still believe the conclusion drawn from it.)

In our discussions about CC/PP, one scenario we have considered is receipt 
of an RDF expression (in any serialization syntax) on a channel secured 
using SSL.   By virtue of using SSL (into an appropriately secure 
environment), the recipient can have confidence about the authenticity and 
integrity of the received RDF graph, but there is no signature that can be 
used for post-hoc verification of the information.  I believe this 
underlines the idea that an RDF graph (received in any form) should be able 
to convey information about assurances provided by signatures, without 
involvement in the signature mechanisms used for transferring such assurances.


USING REIFICATION

The RDF model provides the basis for a mechanism as described above through 
reification.  But, returning to a theme of my original message, reification 
is like an "assembly language" concept:  it can do the job but can be 
difficult and clumsy to use.  I was seeking a "high level language" form 
for expressing such ideas in RDF that can (in principle) be translated into 
reification, but which can also be handled by "direct interpretation" 
within an application.


USING DIGESTS

I think you are suggesting that a digest of an RDF subgraph can be used to 
construct an identifier that stands for the reification of that 
subgraph.  Then, using that identifier, RDF statements can be made about 
the reified subgraph.

For example, consider the CC/PP profile of some client C:  let the subgraph 
be represented by:

   ([C]...)

Let some serialized form of the digest of this subgraph be represented by:

   Digest([C]....)

Then the identifer:

   reify:Digest([C]....)

may be defined to stand for the RDF subgraph containing reifications of all 
of the RDF statements in ([C]...), and we can make statements like:

   reify:Digest([C]....)--assuredBy-->"Alice"

Is this roughly what you are suggesting?  If so, I have one concern, which 
I think is probably quite solvable.  Given an RDF graph containing:

   ([C]...)
   ([D]...)
   ([E]...)
   reify:Digest([C]....)--assuredBy-->"Alice"

How is a program to determine exactly which RDF statements are assured by 
Alice?  (Short of trying all possible combinations to find one that yields 
the correct digest?)

I did think of some ideas involving additional tagging in the RDF graph, 
but they all seem to have problems when additional statements about the 
same subjects get added to a graph.  Any thoughts?


Regards,

#g


At 01:36 PM 4/27/00 -0700, Sergey Melnik wrote:
>Graham,
>
>there have been some discussion relevant to building a Web of Trust on
>this list, in particularly with respect to signing RDF *content*. It
>seems important to me that the algorithms for signing RDF operate on the
>RDF model rather than using a particular serialization syntax like the
>current XML-based one. Especially, if the syntax evolves over time.
>
>You can find a summary of some ideas of how that can be done at
>
>         http://nestroy.wi-inf.uni-essen.de/rdf/sum_rdf_api/
>
>The above description of the algorithm is based on the working code
>downloadable from
>
>         http://www-db.stanford.edu/~melnik/rdf/api.html
>
>In this approach, a cryptographic digest of a statement or a whole model
>is taken to be the ID of the corresponding statement or model. Thus,
>reification comes "for free", i.e. one can make assertions about models
>directly by using their digest-based IDs.
>
>I believe that RDF is a great way of establishing trust on the Web and
>you are on the right path. I'm looking forward to hearing more about
>your efforts!
>
>Sergey

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

Received on Friday, 28 April 2000 13:19:35 UTC