[foaf-protocols] WebID for signing RDF graphs

Dave Longley dlongley at digitalbazaar.com
Thu Sep 23 17:55:50 CEST 2010


On 09/23/2010 10:53 AM, Henry Story wrote:
> On 23 Sep 2010, at 16:24, Dave Longley wrote:
>
>    
>> On 09/23/2010 03:16 AM, Henry Story wrote:
>>      
>>> On 22 Sep 2010, at 12:49, Toby Inkster wrote:
>>>
>>>
>>>        
>>>> On Wed, 22 Sep 2010 09:14:14 +0200
>>>> Henry Story<henry.story at bblfish.net>   wrote:
>>>>
>>>>
>>>>          
>>>>> Where do you place the signature? Inside the graph or outside?
>>>>>
>>>>>            
>>>> There are three main methods that the library allows:
>>>>
>>>> 1. Given an RDF model, it just returns a string signature and doesn't
>>>> modify the model in any way.
>>>>
>>>> 2. Given an RDF document formatted in RDF/XML or Turtle, it adds the
>>>> signature using an XML-comment or Turtle comment as appropriate; given
>>>> an RDFa document, it adds the signature to a non-RDFa attribute on the
>>>> document root node. Thus the signature is inside the document, but
>>>> outside the graph.
>>>>
>>>>          
>>> If you place it in a comment outside or outside the graph you are likely
>>> to make it very difficult to parse, as a wholly new parser will be needed
>>> just to find the signature. Would it make sense to alter the algorith to
>>> do the signature on the graph minus any<>   signature "XYZ" . statement ?
>>>
>>>        
>> The problem with that is that it disables you from having cascading signatures (ie: signing a graph with WebID 1 and then signing the new graph (including the signature node) with Web ID 2). This is can be useful for indicating that one party trusts both the graph and another user that has likewise signed it. If the signature nodes could indicate order and it were possible to specify which signature you're trying to verify then this feature could be preserved.
>>      
> That is indeed the correct way of doing things, I agree.
>
>    
>> Other options include being specific about which parts of the graph are signed based on what the graph represents. For example, the ASN.1 structure of an X.509 certificate has a very specific part of it that is signed (referred to as TBSCertificate or "To Be Signed Certificate").
>>      
> But the correct way in rdf is to use graphs.
>    

I wasn't suggesting anything different. If you thought I was suggesting 
that we store RDF data in ASN.1 -- absolutely not. That would be 
atrocious in my view :). I am in no way suggesting that we move away 
from graphs.

It was merely an analogy: There are subparts of a data structure that 
are signed according to the specifics of the data involved. If an ASN.1 
structure represents a PKI Certificate of type T then only part X of the 
whole structure is the signed. If a graph represents a Forest of type F 
then only Tree nodes Y are signed. Like I said, which parts of the graph 
are signed could depend on what the graph represents. For example, a 
"friend signature" on a collection of your friends should include nodes 
Y, a different graph/signature might include other nodes. To be clear, I 
am not suggesting that we actualize something called a "friend 
signature". These are only examples of the thought process here.

I realize that this might require a specification for every type of 
signed graph (even though we could create "component" specs). Perhaps to 
avoid this we could specify which parts of the graph are signed by 
attaching another node that is linked to the applicable signature node. 
This way it could be programmatically determined during verification 
which parts of the graph are applicable to a given signature.

Clearly this isn't a robustly-considered solution to the problem, but 
hopefully it can help ensure flexibility with signed graphs.

> { a r b } sig "XYZ .
>
> Then you can also have cascading signatures
>
> { { a r b } sig "XYZ . } sig "ZYWE" .
>
> So I think for the moment this means that the proper encoding for signature
> requires (named or not) graphs, ie notations such as N3 or Trig I  think.
>
> This is what the RDF 2 working group are working on, I believe.
>
> Sadly few RDF tools are ready to accept this out of the box.
> For this to become mainstream, we will have to wait
> for the RDF 2 group to be finished.
> We could present this as a very important and useful use case for that
> group, and could get their feedback on what an implementation should
> look like. Perhaps they would not be so difficult to do. One would need
> to be able to adapt a turtle parser for graphs as above, and work out
> some way to create graphs so that starting from the enclosing graph
> (the full statement), one could re serialise it into the semantically
> equivalent one.
>
>
>
>
>
>    
>>      
>>>
>>>        
>>>> 3. Given a list of URIs which dereference to RDF graphs, it generates a
>>>> brand new RDF graph which lists the signatures for the RDF graphs.
>>>>
>>>> -- 
>>>> Toby A Inkster
>>>> <mailto:mail at tobyinkster.co.uk>
>>>> <http://tobyinkster.co.uk>
>>>>
>>>>
>>>>          
>> -- 
>> Dave Longley
>> CTO
>> Digital Bazaar, Inc.
>> Phone: 540-961-4469
>>
>>      
> Social Web Architect
> http://bblfish.net/
>
>    


-- 
Dave Longley
CTO
Digital Bazaar, Inc.
Phone: 540-961-4469



More information about the foaf-protocols mailing list