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

RE: incubating profiles, and webid-powered sparql server endpoints as trust network "routers"

From: Peter Williams <home_pw@msn.com>
Date: Wed, 28 Dec 2011 11:54:22 -0800
Message-ID: <SNT143-W489C69FDB702897FE5036592AC0@phx.gbl>
To: <kidehen@openlinksw.com>, "public-xg-webid@w3.org" <public-xg-webid@w3.org>


 Lets not lose the protocol knowhow, though. It's not all logic, and naming. At the end of the day, real security is like real war: boots on the ground. For example, in the phone call routing world (for pure peer2peer protocol designs like ITU's H323 and SIP [probably]), the endpoint's interaction with a local layer 7 router (which would be represented as a webid-session to a sparql server in our world) utlimately causes a transport connection - to the __next hop__ TRANSPORT bridge, at layer 4. While the gatekeepers are negotiating capabilities and constraints and perfrming admittance controls on access to the trust network, the endpoitns must talk to real transport endpoints - whose security properties ACTUALLY realize the negotiated security context/policy. This is where IETF got it right, in the TLS WG, in making SSL CONNECTS part of the layer 4 bridging world. in the web world, this is where the browser talks not to the reousrce server directly but to a proxied endpoing, for said resouce. Which one? The one directed by the trust routing decision, in the gatekeeper. as part of routing 2 TERMINAL endpoints together through the trust network to which both are registered, the routing function makes forwarding decisions. These are not packet forwarders! These are instructions back to the endpoint (a browser ) to forward layer 7 PDUs through a particular layer 4 endpoint, that is a layer 4 bridge. IN our world what is that? its a CONNECT Proxy, for SSL doing back to back SSL tunnels. The routing decision (effected by the sparql server to which the browser has a registrtation- session) becomes a decision mechanism to direct WHICH https proxy the browser then to talk to for a given target resource (so trust nbased routing directs transport hops, so the security policy is DELIVERED at endpoints that use appropriate media and CAN do the required ciphers and have suitable SSL endpoint certs/CAs).  > Date: Wed, 28 Dec 2011 14:04:14 -0500
> From: kidehen@openlinksw.com
> To: public-xg-webid@w3.org
> Subject: Re: incubating profiles, and webid-powered sparql server endpoints  as  trust network "routers"
> 
> On 12/28/11 1:47 PM, Peter Williams wrote:
> > It was fun playing with ODS (and looking at it from modern goals), and 
> > at some point seeing it present in my proxy profile facts listing me 
> > as being POTENTIALLY linked to several other Peter Williams', in 
> > gmail+. I started to see trust networking happen (facebook style). 
> > but, I have a split personality. With one cert (and multiple SAN 
> > URIs), I want trust network A to be in effect for SAN.A, and not B. So 
> > I want to register with several gatekeeper (i.e. sparql servers 
> > webid/https session), so my "call" can be differently routed, through 
> > different briding points, ending up with a different trust chain, 
> > suiting the (security label) requirements expressed in the endpoint 
> > foaf cards.
> And that's how it should work. This is the Superman and 'Clark Kent' 
> paradox. The basic test applied to our interest and implementations re. 
> WebID :-)
> 
> Linked Data -- at InterWeb scale -- plus the semantic fidelity that OWL 
> brings to relations is the key to making this all happen.
> 
> 
> -- 
> 
> 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 Wednesday, 28 December 2011 19:54:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 28 December 2011 19:54:58 GMT