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

On 12/28/11 2:54 PM, Peter Williams wrote:
>
>  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.

Sure, the protocol is an application of the fundamentals. We have 
identifiers, referents, descriptor resources, resource addresses, 
claims, data access, relation semantics, logic, syntax, data 
representation formats, and transmission protocols.

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

Yes.

Goal is for the spec to ultimately make protocol implementation clearer 
by accentuating the expectation of critical components. This is the hard 
part, and these exercises are beginning to provide context for these 
matters. This is fundamental QA that is common on the enterprise side of 
things.

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


-- 

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