[foaf-protocols] dtls + DNSsec + FOAF+SSL + google + Dane

peter williams home_pw at msn.com
Sun Dec 12 17:44:40 CET 2010


If the incubator project is to attract the interest of the TLS types, as
sought, it has to be on grounds other than: isn't the semweb/foaf so special
that you all come flock to our shores begging us for the implications of its
special relativity that facilitate scalable identity management for all. If
foaf theory was that special, that would have happened by now.

 

As it stands, the next big think in the commercial web is probably going to
be microsoft cloud-hosting activeDirectory instances for all comers, much as
they added sql instance hosting. Google/Yahoo + internet2/USG
websso/trust-policy crowd are trying to compete against ldaps with
signed-XRDs, profiling the old XRDS/XRI protocol to meet web2.0 culture  -
much as netscape updated IETF's ldapv1  into ldapv3 - enabling
(paradoxically) microsoft's AD to go mainstream. All these cloud hosted
images of "zones" and partitions of classes/attributes work of course with
multi-mastering, replication and caching. The local LAN can also host a
blade in the edge router at home, which supports either a multi-mastered
image of the zone/partition, or locally-resigned secondary resources (more
likely, using suitably-designed counter-signature technology). The
technology to do all this is here, and economic in about 1 more year (once
the wifi router's USB ports convert the router into a home "blade servers").

 

Im not sure why you think a webid with IP address is a world "without DNS".
Each IP address is just a reverse-DNS name. Its bound to the name at the
ISP, when authorizing the flow of IP packets onto the public net. Consumer
PCs using broadband don't get any choice whether this name exists or not, or
whether its published (or what records exist binding that name at time t to
the very real ATM path over the local loop from ISP to the
uniquely-identified DSL modem ASIC in the particular router). 

 

I think of FOAF (the project) as distinct from semweb generally, as it
assume everyone hosts their own [named\addressed] website, on their own
access point. That is, it's the opposite of centralizing huge triple stores
in a google or Microsoft cloud -  which divorces folks from control over
their own data. In the true FOAF space, one has to harmonize that political
theory with trends that make it PRACTICAL for grandma now to run her own
website hosting her foaf card (and its got to be no harder than the tech
installing the home DSL modem talking ATM to the ISP, while also setting up
the other ATM path to the digital TV content provider..)

 

From: foaf-protocols-bounces at lists.foaf-project.org
[mailto:foaf-protocols-bounces at lists.foaf-project.org] On Behalf Of Kingsley
Idehen
Sent: Sunday, December 12, 2010 7:55 AM
To: foaf-protocols at lists.foaf-project.org
Subject: Re: [foaf-protocols] dtls + DNSsec + FOAF+SSL + google + Dane

 

On 12/12/10 1:22 AM, Peter Williams wrote: 

Assuming FOAF+SSL does have the strategic goal of migrating to DNSsec, I
think I'm starting to see where that IETF WG (dane) would fit into an W3C
incubation project - which focuses more on the FOAF side of FOAF+SSL
(assuming dane would work on a supporting class of DTLS+DNS+zone concepts
that specifically support huge numbers of semweb clients dereffing countless
webids).

Peter,

WebID protocol (nee. FOAF+SSL), isn't migrating to DNSsec. 

DNSsec is a complimentary effort at best.

WebID works without DNS i.e. you can use a raw IP address in the absolute
worst case. That said, "man in the middle" attacks don't really affect WebID
since public key lookup (when de-referencing structured profile graph) will
ultimately fail.




-- 
 
Regards,
 
Kingsley Idehen       
President & CEO 
OpenLink Software     
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen 
 
 
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20101212/0d577f9e/attachment.htm 


More information about the foaf-protocols mailing list