[foaf-protocols] W3C Social Web Incubator proposal

peter williams home_pw at msn.com
Wed Dec 8 18:51:05 CET 2010

There is another important topic, I think - considering the browser-based
web of 2010 (vs the web of the 1994 era breakout).

The original web proxies helped mosaic work on IPX nets, where the proxy
would bridge to SPX fragments into TCP fragment to join the user to the web.
Those agents rapidly evolved into control points, on the edge of corporate
networks (and isps). Often, the controls would leverage firewall
technologies of the era, requiring user authentication to open the bridge
and authenticate HTTP connections initiated by HTTP proxies "acting for" the
user. Discovery protocols enabled browser to locate the proxy agents on the
enterprise edge typically, using DNS and DHCP (e.g. http://wpad/wspad.dat
for those in IE-land using DNS name servers as the control plane vector)

As I tried to discuss earlier in the year when building a FOAF+SSL demo,
modern HTTP auth headers allow the tunneling of challenge headers that are
protected indirectly by ssl's state machine - specifically to enable
detection of un-authorized proxies (which don't have the end-end crypto
keys). This is only one mechanism to address proxy
insertion/spoofing/falsification - which still enables contamination of the
trustworthiness of data triples being received at a browser. Another way
might be to make proxy discovery in browsers APPLY the semweb itself for the
configuration information of proxy(s), requiring application of signed
triples and supporting key management. This would be a limited bootstrap for
a wider application of signed triples stores (and supporting keys)

-----Original Message-----
From: foaf-protocols-bounces at lists.foaf-project.org
[mailto:foaf-protocols-bounces at lists.foaf-project.org] On Behalf Of peter
Sent: Tuesday, December 07, 2010 12:48 PM
To: 'Dan Brickley'
Cc: 'Henry Story'; foaf-protocols at lists.foaf-project.org
Subject: Re: [foaf-protocols] W3C Social Web Incubator proposal

Ok. So we don't need an IETF TLS WG "dependency", essential or otherwise.
It's the IETF hookup I want to avoid, vs the "TLS community" involvement.
TLS Community should mean anyone, not only those who participate in IETF TLS

There are perhaps 3 observations about modern https and SSL/TLS that W3C
wants to explore further in an incubator context):

1. Delivery of foaf-centric names via client certs - that induce web servers
to de-reference those names automatically using HTTP operations

2. deliver the implied name resolution request early in the SSL handshake
(in the first datagram, essentially), so as to enable the recipient's data
center hardware to: (a) perform HTTP operations specifically in parallel
with the remaining steps of SSL handshakes and/or SSL sessionid management,
and (b) contemplate that ssl engines performing name loookup and handshakes
processes may be distinct and distant from the SSL engine performing (ssl)
session management

3. leverage SSL handshake tunneling (perform a second handshake, under the
protection of the security association of an existing handshake) to protect
the confidentiality of the names. This is exploiting the meaning of stateful
webid protocols

These are all 3 useful topics. 

1 may be considered distinct from the equivalent DNS name and RR lookup
problem, if one argues that  that the resources required to process a
"reasoning-required" FOAF file are  very different to the processing of an
binary RR with a few fixed fields. At the same time, since fast storage gets
ever cheaper by the day, one can see SSL offloaders soon having access to a
terabyte flash cache of foaf cards, whose triples are suitably encoded for
ASIC-speed lookup...

2 has been through IETF TLS WG before and stagnated (due to some patent
conflicts, and failure to disclose the conflicts of interest). The
engineering issues are still valid though: allow different SSL functions to
operate in different protection rings [of the data center]; and exploit
hardware parallelism of the name resolver vs crypto state machine

3 is very solid (being how the USG originally enforced its crypto-export
controls) but these days underused for either enabling confidentiality of
associations, or as an enforcement mechanism.

-----Original Message-----
From: Dan Brickley [mailto:danbri at danbri.org]
Sent: Tuesday, December 07, 2010 11:25 AM
To: peter williams
Cc: Henry Story; foaf-protocols at lists.foaf-project.org
Subject: Re: [foaf-protocols] W3C Social Web Incubator proposal

On Tue, Dec 7, 2010 at 8:08 PM, peter williams <home_pw at msn.com> wrote:
> The problem is, under IETF rules, folks are going to argue that the 
> topic ought to be subject of an IETF WG

That's the joy of the Incubator mechanism. Officially they're just little
preliminary investigations, and so long as the topic isn't obviously
ridiculous or super-controversial (eg. Web standards for illegal
filesharing? markup for Govt Cables etc.), then W3C effectively says "so
long as a few Members support the idea, then the forum gets created'. And
new W3C efforts (towards "Community groups") will be taking this further.

Now once the group is created, it can create docs including proposals for
future work. That's where the IETF/W3C/etc 'where should this live'
discussion happens.

IETF folk might reasonably object to W3C creating a Recommendation-track
standards effort in this area; however I don't expect objections to an
incubator  group to explore the design space...



foaf-protocols mailing list
foaf-protocols at lists.foaf-project.org

More information about the foaf-protocols mailing list