Re: [foaf-protocols] Standardising the foaf+ssl protocol to launch the Social Web

On 6 Jul 2010, at 10:30, Thomas Roessler wrote:

> Adding www-archive@w3.org; quotes snipped heavily.  The earlier parts of the thread are archived here:
> 	http://lists.foaf-project.org/pipermail/foaf-protocols/2010-July/002653.html
> 
> On 5 Jul 2010, at 19:07, Henry Story wrote:
> 
>> Many of our implementations can understand RDF/XML, Turtle, RDFa, and some
>> forms of  RDFised JSON even. The community finds these way more than enough 
>> to work on. 
> 
> Yet, interoperability requires an agreement on the vocabulary that you use (and a choice of format).

Oddly enough, choice of formats are no longer an issue once one has understood the semantic web. GRDDL for example allows any xml format to be mapped automatically to rdf. This is for many computer scientists a very odd result. It took me some time 
to believe it. It is very liberating when understood. :-)

> 
>> We proposed a paper at the W3C Workshop on Privacy Aware, Trusted Web APIs
>> 
>> http://esw.w3.org/PrivacyAwareWeb
>> 
>> We are still awaiting a decision as to whether we can present there. 
> 
> The paper was accepted by the program committee for participation, but not for presentation.  I thought that decision had been made clear.

Ah I understood there was still some flexibility in the presentations schedule

   http://www.w3.org/2010/api-privacy-ws/agenda.html

I would be surprised if there is not a 10 minute slot still available there, which is  the minimum we need to present - though 20 minutes would be a bit easier on the public. I can't see how WebID is not relevant to the privacy workshop. 

What is the procedure to change the current decision? 

I am currently in Germany, and would be travelling all the way to London for this workshop. It would be nice if we did not have to present our case to every single person individually there, but could get this done in one go, and so have more fruitful discussions. 

> 
>>> research institutions,
>> 
>>  There are at least 3 universities in the UK that have done research on 
>> this protocol, tying it in with work on SOAP, other security protocols (Manchester) and more. There are  reasearchers at MIT who have written 
>> papers on this too. The wiki has a lot of those links, but I keep  discovering new ones all the time. 
>> 
>> (note to the foaf-protocols mailing list: please send us pointers to your papers, so we can add them to the wiki, let's fill out that section clearly)
> 
> pointer to the link list, for those of us who don't live and breathe foaf+ssl?

Everything we know we try to put on the wiki. I just filled in the Academic
section more carefully, though I am sure there are still some missing papers:

 http://esw.w3.org/Foaf%2Bssl#Academic

> 
>>> In particular, if the community around OpenID could get together with the
>>> community around WebID, we'd have a great combination.
>> 
>> We have examples of foaf+ssl tying in with many other protocols:
>> 
>> - OpenID: the http://openid4.me/ service shows how using the openid
>>   protocol and the foaf:openid relation allows any WebID to function
>>   as an OpenId
> 
> It ties in with OpenID in the same way in which user names and passwords, SAML, Infocard, and really any other sign on system ties in with OpenID: There's an OpenID provider that recognizes its user by that user's identity in the other system.  Perhaps that OpenID provider forwards some information about the WebID that was used to the relying party.
> 
> To me, some of the interesting questions are:
> 
> - Where do the use cases for the two protocols overlap?

  Both do authentication.
  Both have a way to describe the identified user: using attribute exchange in the case of OpenId, using RESTfully published RDF (or anything) in the case of WebIDs

> - Where do the use cases *not* overlap?

   WebId being RESTful are more natural citizens in a Web of Trust, which is the basis for the Social Web. 

   The WebID is a URL. The representation returned by that URL described the entity named. It can be linked to clearly.

   In OpenId the description of the entity refereed to indirectly by the OpenId is placed in the OpenId server which can only return a description about it as attribute
values inside a URL. The OpenId descriptions cannot be linked to.

   So one can build a web of trust in the manner of foaf+ssl using openid, but a key component is broken, resulting in a ripple effect of complexity. 

  This has resulted in the growing importance of Identity Providers, whose business model is to guarantee attributes. But that goes against the whole promise of OpenId, which was hoping to create a decentralised distributed social web.
  

> - What are the benefits of using one over the other in the cases where they overlap?

  OpenID's design is not quite RESTful, ie, the architecture is not clean Web architecture. As a result it suffers in a number of ways. The ripple effect of bad design grows quickly in a web architecture which has to grow to a global scale.

  - Attributes/values in the attribute exchange are limited to the size of a URL, ie 1024 chars. In WebId they can be any reasonable length

  - Attribute/values need to be defined in a centralised process. This is a serious bottleneck. In WebId's anyone can grow their own vocabulary, and prove their use cases without risking a name clash with the other services.

  - It is not possible to express friendship relations between ones friends in the
attribute exchange spec. (one would have to place URIs inside a URL, which is clearly going to be very limited - no more than 10 friends?)

  - OpenId requires the user to type in his ID, WebID's only require the user to click a button. OpenId's main problems in security and usability stem from this. With WebIds you do not need to type anything! In a mobile environement this is a huge win
   http://esw.w3.org/Foaf%2Bssl/Clients/CertSelection#Mobile_environments

  - WebIds can be linked together in RDF, making it easy for a web of trust to develop. OpenIds could too, but the OpenId community is too tied to the Attribute Exchange model, to want to move. As a result OpenId has the trust problem: why trust what an Attribute Exchange server says about someone. By using WebIDs one can at least bet a relative answer: because I trust people who refer to him. This means that there is a lot less need for centralised naming services. The OpenID community
is being split apart by this dilemma now, as the original creators promised what
WebID enables, but they are unable to deliver.


> - Is it possible to bring the benefits of either protocol to the other, or are the use cases distinct enough that both need to exist next to each other?

  One could improve OpenId by making it use the Web ID protocol. I explain how to do this here: 
    http://markmail.org/message/oub3mhq4q4lpazwh

 But that would would require the WebID protocol to be defined separately.

> 
> Those questions sound like material for a useful discussion with some of the communities that aren't currently following WebID.

   And indeed these are conversations we have had and have documented. 

   Sincerely,


	Henry Story

Received on Tuesday, 6 July 2010 11:11:45 UTC