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

RE: Another Translator for RDF

From: Peter Williams <home_pw@msn.com>
Date: Fri, 30 Dec 2011 00:01:32 -0800
Message-ID: <SNT143-W35DDBC4AE7C58E5CFA31EF92920@phx.gbl>
To: <kidehen@openlinksw.com>, "public-xg-webid@w3.org" <public-xg-webid@w3.org>
CC: <imitko@openlinksw.com>


Let's give an example. I make a cert, with mod. I create a blogspot site (yorkporc3), into whose first blog (i.e. homepage) I post a webid profile. Its not even a PPD. The certs mod is in cert:key.modulus I goto ODS and use my existing home_pw account, with attendenf foaf card and PPD, and associated webid profile within. It has 3 keys, one generated locally by ODS. I renew the cert, so its SAN contains 2 URIs: ODS:home_pw and blogspot:yorkporc3. I post it into the ODS account, which issues an additional cert:key element in the webid profile at ODS. I go back to blogspot and _follow_ yorkporc3, using the openid associated with my ODS webid. To authenticate the follower. google leverages the openid server at ODS that asserts back to google, who duly makes me an authenticated follower of yorkporc3. Logged in as administrator of blogspot:yorkporc3, I add "blogspot:yorkporc3 owl:sameAs ODS:home_pw" to my webid profile. Logged in as admin of ODS:home_pw, I add ODS:home_pw owl:sameAs blogspot:yorkporc3, for bilateral reciprocity. Logged in as administrator of blogspot:yorkporc3, I add the likes of http://ods.openidproxy?url=ODS:home_pw as my openid delegate, in the metadata link (rel=openid.delegation) for such things. I then goto ANY ANY ANY openid relying party, and claim to be blogspot:yorkporc3 (not the awful http://ods.openidproxy?url=ODS:home_pw ) This will induce an openid _delegation_ protocol run, which will induces ODS's openid webid-proxying server to induce ODS to issue a webid challenge, AND VALIDATE IT. Lets say I respond with my SSL client cert, the one bearing 2 SAN URIs both of which match into my ODS:homepe profile (either as named owner of said profile, or owl:sameAs) Because I picked the right cert, with the right SAN URIs in the collection, AND there are owl:sameAs (reciprocal?) relations between the names, the openid proxy will now formulate a correct assertion returned to the openid consumer, which will consider me to be blogspot:yorkporc2. Without the owl;sameAs, the assertion is faulty (and delegation fails, back at the consuming party, as happens in practice with my yorkporc2 experiment) one way for an arbitary (openid) consumer site to know what level of validation assurance was performed by the IDP is for the openid assertion to signal some kind of policy URI (Ive forgotten its formal name) that declares the assurance level. If we create 3 labels (URIs in an ontology for an "levels of validation" Enum). these can be the values used in that assurance-signal ...in the returned assertion. This is kind of frightening, as it actually works en vivo, before the spec is written up.  From: home_pw@msn.com
To: kidehen@openlinksw.com; public-xg-webid@w3.org
CC: imitko@openlinksw.com
Subject: RE: Another Translator for RDF
Date: Thu, 29 Dec 2011 22:59:09 -0800








Lets take this rather more slowly (or perhaps, have a phone call with folks at your level). This is way over my head. I'm down at compiling against crypt32.dll, marshalling bytes across DLL calls so dot net can call windows binary crypto and cert libs (from 1995 era). Thats all Im good for, these days.
 
To me, I saw a translator of formats, from RDFa serialization to TTL serialization. This was a layer 6 function, from one presentation data value to another, in different syntax/format. It made an output that visually looked just like an old LDIF file. It was very natural. There were facts about the object, and facts about the container. The object has an X.500-like object class (with some schematically-correct attributes, with types and syntaxes), and the container has an implied object class (container). Furthermore, the schema of object classes is also in the directory (I mean web). ONe could even determine that cert:certificate is an improper attribute for the object class of the whose distinguished RDN is "me"
 
This is how I think. It has nothing to do with how Im supposed to think (which is just too hard for me).  But, me and a million others can think like this, now TTL is making it all look like an LDIF fie.
 
 
Then there is X500 information model, which gets us into names vs address, and dualities. The X500 world was easy: white pages with real objects on the heap, and yellow pages pointers on the stack making references to the heap. Thats it. The web is more complex in its identity model, facilitating theorem proving. This is beyond me, these days, however.
 
When I considered putting the translator URI in the SAN cert pointing to a TTL stream  - rather than the pointer to an RDFa stream - it was to engender clarity. I was not Infact intending to be making a identity statement, about 2 SAN URIs, or what such double referencing SHOULD/MUST/OUGHT to mean (in a object theory sense). I think this is what you did, though.
 
I think I have just learned (and im leaping here) that there is just like in C++ a magic #fragment name called "this". I dont have a literal in my stream named #this, though - any more than I have such a literal in C++ structure. OK. Wonderful. That makes sense (by analogy with C++). I now have a way to always name what is otherwise an address (causing endless fuss).
 
So, now I have a collection of SAN URIs in a signed cert blob. The original idea was: mr validtor, pick one, any one, and do your de-ferencing trick. Oh, and then do a sparql query to run a matching rule. In my mind, this was no different to getting the X.500 object at a DN from a DSA (that might chain off elsewhere), and running the X.500 matching rules for the attribute once the entry was provided, where the value of said attribute (cert:key) is a compound ASN.1 type of definition SEQ { int mod, int exp }. The matching rule is able to match values of compound types. You have on this list in David Chadwick a world expert in doing just such definitions. To my mind, what Henry now has is directly equivalent.
 
But you went further. You invite me in my yorkporc entry to assert an owl:sameAs relation (hope thats the right term, and not "property") to what I though of as an onthe fly transacltion of bit formats. But, you are saying, in web identity theory, no : go futher. Its not just a codec translation. What OPTIONALLY some validator (with the optional OWL reasoner) can do is be more calculating. I can be making equivalency assertions between identity names, and not just locatiing service endpoints which transform bit formats, much like a UNIX pipeline.
 
Ok I can buy that. And, I see how Im getting what our OASIS friends were offering with the XDI graph model, when talking about XRI synonyms in a non RDF basis. Here, we OPTIONALLY stay within (I think) the RDF theory of EAV, but for security/key management purposes, we get to apply some of the synonym theory (to help address practical life issues, and some of the needs of security doctrine). Perhaps, it will sort out the apparent mess I described in my blog post recently, concerning 7 layers of identity following, in the openid world. it becomes something that one CAN reason with.
 
So, if I add that owl:sameAs as relation to the yorkporc2 entity pointing at (referring to?) the translation service's URI (agumented by the magical #this), to a validation agent that is RUNNING OWL, it gets to offer a higher assurance validation logic. This goes beyond (1) the matching rule of the spec, and goes beyond (2) Bergi's walking a triple collection.
 
Ok. Do we have 3 levels of identity assurance, executed at different validation agents with different levels of sophistication for reasoning. (Hmm. I lost a million dollars in the ValiCert startup for certs, becuase evidently it was 7 years too early in its business plan!)
 
If ODS says its valid, there is more assured than if Bergi say its valid.
 
Providing we agument the spec so the requestor of validation can KNOW which class of assurance during validation was used, Im sold.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
> Date: Thu, 29 Dec 2011 22:28:54 -0500
> From: kidehen@openlinksw.com
> To: public-xg-webid@w3.org
> CC: imitko@openlinksw.com
> Subject: Re: Another Translator for RDF
> 
> On 12/29/11 9:12 PM, Kingsley Idehen wrote:
> > On 12/29/11 12:32 PM, Kingsley Idehen wrote:
> >> On 12/29/11 12:26 PM, Kingsley Idehen wrote:
> >>> I meant:
> >>>
> >>> <http://rdf-translator.appspot.com/parse?url=http%3A%2F%2Fyorkporc2.blogspot.com%2F&of=n3#this> 
> >>>
> >>> wdrs:describedby
> >>> <http://rdf-translator.appspot.com/parse?url=http%3A%2F%2Fyorkporc2.blogspot.com%2F&of=n3> 
> >>> .
> >>>
> >>>
> >>> Put this in your browser for implicit indirection effect:
> >>> http://rdf-translator.appspot.com/parse?url=http%3A%2F%2Fyorkporc2.blogspot.com%2F&of=n3#this 
> >>> .
> >> Peter,
> >>
> >> seeAlso:
> >>
> >> 1.  
> >> http://linkeddata.informatik.hu-berlin.de/uridbg/index.php?url=http%3A%2F%2Frdf-translator.appspot.com%2Fparse%3Furl%3Dhttp%253A%252F%252Fyorkporc2.blogspot.com%252F%26of%3Dn3%23this&useragentheader=&acceptheader= 
> >> -- URI Debugger output
> >>
> >> 2. 
> >> http://validator.linkeddata.org/vapour?vocabUri=http%3A%2F%2Frdf-translator.appspot.com%2Fparse%3Furl%3Dhttp%253A%252F%252Fyorkporc2.blogspot.com%252F%26of%3Dn3%23this&classUri=http%3A%2F%2F&propertyUri=http%3A%2F%2F&instanceUri=http%3A%2F%2F&defaultResponse=dontmind&userAgent=vapour.sourceforge.net 
> >> -- another Debugger (but it suffers from RDF/XML specificity so jump 
> >> to its conclusion re. Object/Entity Name / Descriptor Resource 
> >> Address disambiguation) .
> >>
> > Peter,
> >
> > A correction to the above.
> >
> > URI in SAN: 
> > http://rdf-translator.appspot.com/parse?url=http%3A%2F%2Fyorkporc2.blogspot.com%2F&of=n3&html=1 
> > <http://rdf-translator.appspot.com/parse?url=http%3A%2F%2Fyorkporc2.blogspot.com%2F&of=n3&html=1>#this 
> >
> >
> > Means that in your (X)HTML you need to add the relation:
> >
> > <http://yorkporc2.blogspot.com/#me> owl:sameAs 
> > <http://rdf-translator.appspot.com/parse?url=http%3A%2F%2Fyorkporc2.blogspot.com%2F&of=n3&html=1 
> > <http://rdf-translator.appspot.com/parse?url=http%3A%2F%2Fyorkporc2.blogspot.com%2F&of=n3&html=1>#this>  
> > .
> 
> First off, cut and past fix for the relation. It should be:
> 
> <http://yorkporc2.blogspot.com/#me> owl:sameAs 
> <http://rdf-translator.appspot.com/parse?url=http%3A%2F%2Fyorkporc2.blogspot.com%2F&of=n3&html=1#this> 
> 
> 
> >
> > Please add that to your posts and repeat your tests with our 
> > validator. The relation above is crucial, I completely forget to 
> > mention that :-(
> >
> 
> In addition to the above, if you have two HTTP URIs in SAN:
> 
> 1. http://yorkporc2.blogspot.com/#me
> 2. 
> http://rdf-translator.appspot.com/parse?url=http%3A%2F%2Fyorkporc2.blogspot.com%2F&of=n3&html=1#this 
> .
> 
> A WebID verifier should really assume that you are claiming that:
> <http://yorkporc2.blogspot.com/#me> and 
> <http://rdf-translator.appspot.com/parse?url=http%3A%2F%2Fyorkporc2.blogspot.com%2F&of=n3&html=1#this> 
> are co-references for the certificate's subject .
> 
> Basically, that claim is signed and verifiable. One could go the extra 
> mile on the IdP side and also sign the claim. But that's for another 
> time, once we are beyond the basics :-)
> 
> 
> Hopefully, no cut and paste craziness this time around .
> 
> 
> Kingsley
> 
> 
> -- 
> 
> Regards,
> 
> 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 Friday, 30 December 2011 08:02:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 30 December 2011 08:02:16 GMT