W3C home > Mailing lists > Public > public-xg-webid@w3.org > January 2012

RE: How To Handle WebIDs for (X)HTML based Claim Bearing Resources

From: Peter Williams <home_pw@msn.com>
Date: Mon, 2 Jan 2012 09:19:08 -0800
Message-ID: <SNT143-W12BB21BE76F3D946F22F1F92910@phx.gbl>
To: <mo.mcroberts@bbc.co.uk>, <kidehen@openlinksw.com>
CC: "public-xg-webid@w3.org" <public-xg-webid@w3.org>

I dont pretend to understand owl or its identity model. but it did make entirely intuitive sense that the sameAs had to be mirrored. My logic was purely rational though ( not calculating ). In our world, we are about  controlling URIs (otherwise the whole thesis of the "decentralized identity framework" falls apart). I have to show I control all those entities in the equivalence class.


This is why in my examples I had yorkporc2 (RDFa) and windows-blob (B3) refer to each other. The intent was that one MIGHT infer that I had control over each. But, I also made each refr to a cert too - cast as a data URI. INtending that the signed cert acts as a canonical identity when describing the particular equivalence class (acting in a role that foaf:mbox was once intended to play), This introduce "transitivity" into the otherwise bilateral equivalence.


What I was trying to do say was: the bilateral equivalence is only valid in the context of webid SSL handshake (presenting this particular cert).


In this way, owl was now describing what Kingsely asserts the bag of URIs in the SAN field on a cert says (that really it doesnt, in any formalist intepretation). Now a collection of URIs in the SAN is more than a bag: the profiles bear relationships becuase of their being posted together in a particular cert.


Obviously, one demonstrate "control" of the cert as URI (a data URI, remember), USING the SSL handshake - which proves possession of the private key.


Now, this is how a crypto person thinks - always tying I&A back to a secret, at the end of the day. How you guys think is what matters, though. 		 	   		  
Received on Monday, 2 January 2012 17:19:39 UTC

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