Re: Another Translator for RDF

On 12/30/11 3:01 AM, Peter Williams wrote:
>
> 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 
> <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)

Methinks temporarily faulty since multiple URIs in SAN == a signed 
coreference claim. Basically, if this fails its because our verifier is 
only accepting coreference from the Idp instead of treating this as a 
higher assurance claim. Basically you should be able to have the following:

1. A cert with a single URI in SAN that's in a co-reference relation in 
the IdP space -- imagine a <yorkURI> owl:sameAs <odsURI> in IdP space 
where the Cert. SAN only has <yorkURI> but ACLs for a resource you seek 
to access are scoped to <odsURI>

2. A cert has > 1 URIs in SAN which is signed co-reference in the X.509 
cert -- using scenario above, validation should still be fine too, the 
verifier has to honor co-reference claims

3. A cert has > 1 URIs in SAN which deliver signed co-reference claims 
that are mirrored in IdP space(s)  -- again, verifiers should handle 
this too and exploit an even higher assurance level.

The WebID spec should provide the basic foundation for verifiable 
identity courtesy of mirrored claims. Implementations can collectively 
support the base, but differentiate (especially in the commercial realm) 
themselves via the assurance levels they can either offer or handle.

>
> 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.

Yes.

Using OpenID and WebID is very powerful and full of osmotic pressure :-)


Kingsley
>
>
> ------------------------------------------------------------------------
> 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
> >
> >
> >
> >
> >
> >


-- 

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