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

Re: neither FCNS nor FOAFSSL can read a new foaf card (hosted in Azure). RDFa validators at W3C and RDFachecker say its fine...

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Tue, 27 Dec 2011 21:48:20 -0500
Message-ID: <4EFA8374.6030107@openlinksw.com>
To: public-xg-webid@w3.org
On 12/27/11 9:35 PM, Kingsley Idehen wrote:
> On 12/27/11 5:14 PM, Peter Williams wrote:
>> Ive reached screaming point, despite it sort of working: See 
>> http://tinyurl.com/7zjf77v
>> It only works in what I assume are "advanced validators" - those able 
>> to deal with proxying. Which is not to say that the advanced 
>> validators can use my own data source (and validated against it). 
>> But, assuming Kingsleys system SOMEHOW cleans up my data source (and 
>> turns it into a linked data set), putting the proxy URI in the SAN 
>> alongside the URI does make something work, in some places, sometimes.
> Some things to treat as key rules:
> 1. only put URIs in SAN that are Object/Entity Names (> 1 level of 
> indirection re. data access i.e., name.address.data) rather than 
> Object/Entity descriptor resource  Addresses ( 1 level of indirection 
> re. data access i.e., address.data)
> 2. the resource to which the Name resolves must be comprised of an 
> eav/spo directed graph (serialization formats may vary) in which 
> attribute=value or predicate=object pairs coalesce around the URI 
> based Object/Entity Name re., Public Key relations.
> What URIBurner (a Virtuoso instance with its Linked Data Deployment 
> middlware module enabled) does is generate a proxy/wrapper Linked Data 
> URI because of ambiguity its detects when dealing the the URIs used in 
> your Certs. SAN.
> In my earlier response I forgot to tell you to also place the #me URI 
> in your Certs. SAN. Thus you would have had the following:
> 1. 
> http://b3d0c8f68475422784748b65f76b1642.cloudapp.net:8080/Home/About 
> -- descriptor resource address
> 2. 
> http://b3d0c8f68475422784748b65f76b1642.cloudapp.net:8080/Home/About#me -- 
> object/entity name that resolves to its descriptor via de-reference 
> (an act of >1 level of indirection) .
> If you want to have >1 URIs in SAN, ensure you have two Object/Entity 
> Names rather than an Object/Entity Name and a Descriptor Address.
> Your exercise is demonstrating why Name/Address disambiguation is 
> important when HTTP URIs are used as Object/Entity Names. You aren't 
> the first to scream, but you might be one of the last as this exercise 
> may ultimately reveal a new way of explaining what's dogged many for 
> years in this realm.
>> I think I learned something, about where webid will get too. ANd, 
>> now, I can at least SEE/CONTEMPLATE the full power of the linke data 
>> model (as it relates to just webid, never mind the rest). Its rather 
>> BETTER than the X.500 subobject/instancing model, particularly if 
>> such as Henrys validator can cast its query to suit the linked data 
>> view (of my data source).
>> What this means for security I dont know; as the traditional notions 
>> of authority have gone out of the window.
> Out of the old Window into a new one where logic prevails :-)

Here is another form of descriptor document for looking at the 
description (relations graph) of the referents of the URIs in your 
certs. san:




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, 28 December 2011 02:48:47 UTC

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