W3C home > Mailing lists > Public > public-xg-webid@w3.org > December 2011

Re: Important Question re. WebID Verifiers & Linked Data

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Wed, 21 Dec 2011 13:08:34 -0500
Message-ID: <4EF220A2.60406@openlinksw.com>
To: public-xg-webid@w3.org
On 12/21/11 12:55 PM, Mo McRoberts wrote:
> On 21 Dec 2011, at 17:47, Kingsley Idehen wrote:
>> I used to think so until Henry expressed questionable suggestions about URI handling that breaks the abstraction re. WebID verifiers.
> I’m think it was actually Peter initially, but I could be wrong; Henry just revisited the issue, and took a safe (from a security perspective, if broken from a web arch angle) default position.
> I’m not sure why that prompted this whole thread. Just saying “redirection (and indirection!) are a fundamental part of web architecture, we just need to settle on how they’re handled from a security perspective” would’ve been a perfectly decent answer to Henry’s question…
> M.

Here is how I would frame a security problem (something I've done in the 

An owl:sameAs relation exists in a graph somewhere along the 
de-reference trails. A verifier follows the link and finds match. Or 
said verifier applies inference and makes a union and then gets a match. 
In either case, one deftly placed relation have tipped the apple cart.

Solution: implementers of WebID verifiers have to factor in crawl depths 
and relation semantics. Suggestion could go as far as seeking signed 
claims for specific relations. BTW -- this doesn't have to be part of 
the WebID spec, it's just a note for engineers.

The ultimate challenge for WebID is this, you are going to have 
variation re. product quality. That's fine, a spec can't control actual 
engineering, it can only provide the specs for the act of engineering.

The Internet was broken security wise before the WWW came along. WebID 
has a great shot of fixing this problem, but it really has to understand 
and honor the age-old practice known as separation of powers.

The WebID spec shouldn't be about encouraging implementations that are 
fundamentally technology Camels -- the usual product of attempting 
innovation by committee. A spec must sit distinct from implementation 



Kingsley Idehen	
Founder&  CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen

Received on Wednesday, 21 December 2011 18:09:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:50 UTC