W3C home > Mailing lists > Public > public-rdf-wg@w3.org > June 2011

Re: Need for a canonical byte stream for an RDF graph

From: Steve Harris <steve.harris@garlik.com>
Date: Wed, 29 Jun 2011 11:54:26 +0100
Cc: public-rdf-wg@w3.org
Message-Id: <D8397073-29C3-453F-8DB3-A4FFAC5F9E97@garlik.com>
To: Jeremy Carroll <jeremy@topquadrant.com>

On 2011-06-29, at 02:04, Jeremy Carroll wrote:

> On 6/28/2011 3:45 AM, Steve Harris wrote:
>> 
>> That's what I meant about only being able to do the verification at retrieval time.
>> 
>> The process we followed was: (from memory)
>> 
>> 1) fetch document from URL
>> 2) check for WoT data
>> 3) fetch WoT data [if present]
>> 4) verify fetched document against WoT data [if present]
>> 5) assert 1 into triplestore [if 4 passed]
>> 
> 
> Yes this is a good process but has little to do with RDF since it is just about verifying the signatures on the source documents.
> If this process suffices for the use case it is clearly better to use this.

OK, thanks, that clears up some questions I had - so, to check my understanding, a C14N-based signing process isn't inherently superior, but it does meet other usecases?

Regards,
   Steve

>> At that point, we know that as long as the graph that the data was asserted into isn't disturbed (enforced in the application layer in our case), that the document in 1 has been signed as per 2.
>> 
>> That's probably not sufficient for all usecases, but it suited ours fine, and it doesn't have complexity issues.
>> 
>> For OAuth and HTTPS steps 1-4 are done as part of the implementation of the standard, but for WoT we did them manually.
>> 
>> There's also WebID which maybe fits in there somewhere, as it uses x509 certificates, but I'm not au fait with it.
>> 
>> - Steve
>> 
> 
> 

-- 
Steve Harris, CTO, Garlik Limited
1-3 Halford Road, Richmond, TW10 6AW, UK
+44 20 8439 8203  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD
Received on Wednesday, 29 June 2011 10:54:59 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:44 GMT