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

Re: the openid para

From: Dan Brickley <danbri@danbri.org>
Date: Thu, 28 Apr 2011 10:34:38 +0200
Message-ID: <BANLkTi=wJN-uPyZz07U6AeSjBS_5xjofag@mail.gmail.com>
To: peter williams <home_pw@msn.com>
Cc: public-xg-webid@w3.org
On 28 April 2011 04:50, peter williams <home_pw@msn.com> wrote:
>
> "OpenID reduces the account multiplication issue by allowing users to login
> to every site using the same global identifier. This provides a base from
> which WebId can be deployed, procuring the following extra advantages:
> Protocol simplicity: the WebID protocol is a lot simpler, requiring only one
> more connection over and above the connection to the requested resource,
> where the result is cacheable. OpenID requires seven TLS connections,
> significantly more than WebID. These additional steps create opportunities
> for denial of service attacks, making it more difficult to secure and to
> debug."
>
> I think we are still learning to make effective pitches. The above, for
> example, now submitted, sounds somewhat catty. If my sales team used that
> tone about our competition, Id consider him jaded and time for retirement.

I have to agree. I have nothing but admiration for the technical
progress of this work, but I do find the messaging re OpenID over the
years has been needlessly (and perhaps unintentionally)
confrontational. Last thing we need is a retread of the unfortunate
tribalism that was 'microformats versus Upper Case Semantic Web'.
WebID stands on its strengths. And in some cases, being able to fall
back to OpenID (eg. from the certless cybercafe PC scenario) is more
appealing than messing around using a password to install (and then
remove) a transient WebID cert on an uknown PC.

[...]

> Now, that's too wordy. But, look at the difference in tone. One carps about
> the competitions most negative points. If I was an openid author, Id be
> showing no love for webid, at this point (simply because of the tone,
> taken). The other notes the differences in design schools, arguing our case
> for eliminating certain openid flows. In doing so, we happen to also
> indicate the limits of webid, so it's harder to portray our work as
> something that simply has done insufficient analysis of the requirements.

Yes. A lot of people are enthusiastic about the general ideas behind
OpenID, but pretty agnostic about the technical details. Others are
frustrated by the slow adoption progress, and usability problems.
Showing some fresh sympathetic ideas fits well with this situation;
I'm not sure 'our stuff is better' works so well.

> I think we have to learn to go for a multi-protocol world, that ADMITS
> websso, now. I note how the long fought multi-scheme URI made it
> successfully into the description. Good! Several more religion points to
> eliminate further, yet - simply so that the conditions for mass-adoption are
> encountered.

>From the point of view of the more descriptively-oriented FOAF work,
multi-protocol is not just unavoidable, but essential. Protocols are
the papertrail that let us move from RDF triples to RDF quads, to keep
track of who-said-what and to then be able to query them usefully in
SPARQL or even reason about them. There is a level of abstraction
where we should care to record the exact transaction details
associated with some package of RDF claims; and there's a
protocol-agnostic level where we'll instead associate those claims
directly with their human/social source - a person, group or
organization. While WebID and digital signature (PGP or otherwise) are
key tools there, so are custom REST APIs, XMPP, and other older, more
domesticated protocols like IMAP and POP. The important idea to
establish is that we have this soup of source-attributed claims, and
that different applications are free to make sense of them in quite
different ways. The way I'd deal with checking or exploiting the kinds
of factual claims that appear in http://dbpedia.org/page/Jackie_Chan
is quite different to how I'd handle claims about write access to a
Facebook group, or a db of detailed scientific claims; yet the semweb
infrastructure provides some level of useful common abstraction and
tooling.

Another example: Google's Social Graph API looks at the logic of pairs
of Web pages saying, reciprocally (in XFN and FOAF), "this [over
there] is [from/by] me too". The strategy works pretty well, for
upgrading and folding together claims found in the scruffy Web. If my
Twitter and YouTube pages both have rel=me pointing at the other, it
is less risky to treat claims found from each account as having common
origins. While this isn't OpenID, nor WebID, ... it can be integrated
into our narrative if we focus on the basic idea of a Web of documents
and parties making structured claims about the world.

Regarding multi-protocol, perhaps the most effective thing that could
be done in the WebID community would be to create or patch
opensource/free software tools to be protocol agnostic, and which
would allow Web developers to implement 'login with openid or webid or
facebook or twitter or ...' rather than face each hurdle separately.

The culture around W3C --- a standards organization, after all ---
tends unconsciously towards answering all "what should we do?"
questions with answers that are variations on "make or improve a
standard!". With WebID we can afford to think more broadly, ... and if
software-oriented activities have a better chance of getting us where
we want to go, to put some time into that(*). Updating the various
wordpress, drupal, mediawiki etc etc openid addons to handle WebID too
would be a big boost. But then so would having a not-for-geeks "login
with your Web identity" narrative that would subsume technology
differences between OpenID and WebID.

cheers,

Dan

(*) saying this, I'm painfully aware that I've not had time to put
much time into any of this lately, so maybe I shouldn't be cavalier in
making suggestions for how others assign their time.
Received on Thursday, 28 April 2011 08:35:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:06:24 UTC