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:53:30 -0500
Message-ID: <4EFA84AA.6000708@openlinksw.com>
To: public-xg-webid@w3.org
On 12/27/11 9:48 PM, Kingsley Idehen wrote:
> 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:
> http://uriburner.com/describe/?url=http%3A%2F%2Furiburner.com%2Fabout%2Fid%2Fentity%2Fhttp%2Fb3d0c8f68475422784748b65f76b1642.cloudapp.net%3A8080%2FAbout.aspx%23me 
> .

Also remember, you can also SPARQL ASK in the form:

PREFIX : <http://www.w3.org/ns/auth/cert#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

#Pragma for forcing retrieval from source that overrides default cache 
invalidation scheme, so remove comment from line below if required.

# DEFINE get:soft "replace"

:key [
:modulus ?mod ;
:exponent ?exp ;
] .



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:53:53 UTC

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