[foaf-protocols] issue of initiating client auth for parallel SSL sessionids

peter williams home_pw at msn.com
Tue Mar 1 16:41:13 CET 2011

In what was asserted (snip below), I said nothing about webid loosing its
user-centric'ness (perhaps Henry mis-stated). I said openid lost is
user-centric orientation, becoming a fiefdom of Yahoo and Google and
Microsoft, (where the Microsoft service for openid federation in the Azure
cloud specifically excludes all the n,000 wordrpess UCI IDPs)


Now, someone asked on the webid list: so what website are clamoring for a
new web-centric authentication solution? It felt like someone having to
justify product management priorities.


I have two answers to that: one direct, and one indirect. They are
discussion points (therefore here, not there, where it's all formal). The
build in the topic of UCI.


1.       The world of foaf doesn't have a coherent access control model in
my mind; because it makes the same assumption that X.500 directories made -
that folks will want/allow public profiles. X500 failed as public
infrasrtucture because that premise was falst - corporate directories (and
now facebook) lock up folks profiles. So, since webid authentication is
about supporting authorization and then access control ultimately, we stand
a change of enabling foaf to take off as a profile document (once one adds
in the security layer).


2.       Openid's specific failure space is webid's first huge adoption
space. Commenting. Nobody actually uses openid to leave an authenticated
comment (mostly because its far too cumbersome a protocol, and too prone to
error particularly in the smaller IDP sites). Into that vaccum, fit webid,
which (i) doesn't require the browser-based redirect, and (ii) leverages the
cached SSL sessionid and browser-remembered client cert choice (with
effective pin-handling on smartcard class webid)


Don't see why the wordpress and joomla openid consumer plugins could not be
altered to do webid, pinging a well-run community sparql server to do the
cert pingback against UCI-centric foaf cards, remotely. Little or nothing to
fail in such a small scripting setup, in a small hosting shop, which =>
adoptability and viability.


Remember, in my mental model, if webid follows openid and ONLY gets adopted
by giants like Yahoo and Google, then this was all a waste of time. Might as
well stick with the self-signed cert in TLS land for servers and clients,
which currently keeps individuals free of centralization and dependency (if
they work at it, just a tad). If folks don't want it, by default they just
pay VeriSign, etc, for the total convenience, and the usual commercial
upsells of assurance/insurance etc.



From: public-xg-webid-request at w3.org [mailto:public-xg-webid-request at w3.org]
On Behalf Of Henry Story
Sent: Tuesday, March 01, 2011 3:47 AM
To: peter williams
Cc: 'Ryan Sleevi'; public-xg-webid at w3.org
Subject: Re: issue of initiating client auth for parallel SSL sessionids



On 28 Feb 2011, at 12:43, peter williams wrote:

[snip, stuff about webid loosing its user centric, and how WebID is
interested in RESTful web architecture solutions]


yes, Web Architecture is not an accidental aspect of the success of the web.

Here, with this initiative coming from the foaf project, folks prpobably
want to see "some" of the user-centric flavor be retained. I don't feel
folks are exactly on anti-corporate rants; but they are concerned about the
"politics of control." Should a lowly user 



thus create an RDF graph (in a hand-written foaf card) that cites lots of
https URIs including URIs of other foaf cards (quite typical!), what does it
mean for a machine to crawl the file's URI pointers - and thus de-reference
the URIs - all 100 of them say; on different domains, different ports,
different URI stems?


So if you connect to someone's social web server - let's say a friend of a
friend of yours - that server presumably already crawls the web of his
owners' friends, in order to keep up to date on what they are doing, where
they are, who their new friends are, etc... 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20110301/027f613b/attachment-0001.htm 

More information about the foaf-protocols mailing list