What problems does FOAF+SSL solve?

Despite having looked at the specification and material several times, I'm still not clear of the benefits of FOAF+SSL.

Henry Story has a blog post that tries to do this here:

http://blogs.sun.com/bblfish/entry/what_does_foaf_ssl_give

But the majority, if not all of these arguments come from a technical perspective, are easily avoided or not really an issue for end-users.

Can someone give me a good overview of what problems FOAF+SSL solves for me as a web user that aren't already addressed by OpenID or other single sign-on systems?

For this answer I'll assume that you already know what a WebID (formerly FOAF+SSL) is, and all the benefits which are entailed by giving each person a unique personal URI, which deferences to machine readable (linked) data using the standards, the benefits of a linked data based decentralized social web and all related. These all have end user benefits which I know you already know hence not included.

More End User benefits to you: FOAF+SSL natively requires that all communications whilst identified occur over HTTP+TLS, this means that all personally identifiable information is always sent encrypted across the wire (protecting you against sniffing, deep packet inspection, man in the middle attacks, and related). It ensures that all connections whilst identified are between two identified parties, and this is further restricted (by HTTP+TLS) to being a direct connection between the two parties that can't be tunnelled or passed on over more than one hop. Further still it ensures that the vital identifying 'secret' usually a password, but in this case a private key, is never ever transferred over the wire and doesn't leave your user agent.

Technical benefits to the web as a whole (and thus to end users) From a web architecture point of view, FOAF+SSL is a stateless authentication mechanism; one of the biggest problems on the web is that HTTP is a stateless protocol which 99.9% of people use as a stateful protocol, using sessions, keeping you 'logged in' and such like; this brings huge performance, caching and security issues to the web - FOAF+SSL negates all of these by being a stateless RESTful authentication and identification protocol, so inbuilt it's good for the web, for performance (security as mentioned) and moreover, it encourages good practise when developing web applications and makes the web entirely more RESTful.

These are points you can play down, but they are the root of the majority of the problems on the web today, big fat important issues which impact almost everybody on the web in countless ways - these alone are more than reason to adopt FOAF+SSL.

Daily End User benefits As mentioned there are all the Linked Data, Semantic Web and Decentralized Social Web benefits to boot (which are huge themselves) - then there are the simple things which make a big difference on a day to day basis - no 'logging in', you are either authorised or not, no having to remember passwords, no complicated sign up procedures, all profile information in a single place so no having to refill in all the same details over and over (and update them when something changes), no dependency on all consuming corporations that monitor your every (social) move (which they do via controlling your logins so you are always routed through them via openid, 'share this', 'like' etc), no NASCAR problem (list goes on)..

Hope that helps a little

Edit: re: 'I get many, if not all, of these benefits from having an OpenID, e.g. data about me can be accessed via profile exchange. OpenID can also be done over SSL. So what is it that FOAF+SSL/WebID actually adds?'

  • OpenID doesn't require the use of TLS, FOAF+SSL does
  • OpenID requires transferring account authentication details across the wire (and 'logging in')
  • OpenID natively encourages a stateful anti-pattern in the web which gives performance, caching and security risks.
  • OpenID is open to phishing.
  • OpenID is driven by the big players, and it's their tool to 'lock you in' to their networks, see janrain as the perfect example (also showing the NASCAR problem).
  • Public facing profiles are anemic, and although there is a semi supported attribute exchange it is extremely limited when contrasted with full RDF/Linked Data and RDFa profiles with unlimited scope.
  • ... many many more points.

What does FOAF+SSL give?

Simply, FOAF+SSL wraps up all the good things on the web in to one package and requires the use of them all, it requires the use of HTTP+TLS when identified, it requires using Public/Private keys via an X509 certificate, it requires the use of Linked Data, it requires the use of Standards, it requires that each person has a Personal URI / WebID, it requires that personal URI to be dereferencable, it requires cutting out the third parties and middle men. In built is a decentralized and federated secure social network which can easily be supported on all devices that support https. It puts the clientside part of authentication in to the APP which controls HTTP, in other words the browser, thus removing the need for convoluted 'login' systems to be included in applications.

FOAF+SSL allows (and is imho the key enabler in) the read/write web of linked data, it enables a paradigm shift where applications run on the client and data is stored on the web; it brings another level of universality to the web, it..

I'd ask, what's the reason not to use FOAF+SSL?

Edit 2 RE: 'What's the end user benefit over OpenID?'

  • All information you send or receive whilst identified is always encrypted
  • You don't need to 'login' or remember passwords and usernames any more
  • Your profile is ultimately extensible, machine readable and unlimited.
  • You are't faced with multi-step login processes which are plastered in logo's
  • You use an authentication protocol which enables a new generation of web applications gained via a web revolution and huge paradigm shift. (which other protocols don't support because they require server side web applications and stateful authentication)
  • Can be used for more than just humans, any Agent or Application or Device can have a WebID in this manner
  • Not limited to the Browser/User Agent, WebIDs are generic to the web and HTTP(+TLS)

all the other benefits already come from having a personal URI, a FOAF profile, being part of the web of linked data and similar :)

Here's a naive outsider's attempt to summarize what I've heard and can pick up from the documents.

For an end user who is trying to make information available (e.g. photos) then it has the advantages:

  • can specify new types of access restriction (e.g. visible to friends of friends, though subject to reliability of each link in that chain)
  • can guarantee that all accesses to information is over a secure channel

For an end user who is trying to access information then it has the advantages:

  • can access information by virtue of being a friend (or indirect friend) without have to sign up to each social networking service
  • arguable convenience of authentication process (replaces browser-indep/site-dep choosing OpenID provider and sign on if nec. by browser-dep/site-indep unlock of certificate store and selection of certificate - YMMV on the convenience trade-off)

For a developer:

  • ease of client implementation
  • usable for non-browser applications (this could turn into an end user benefit as such applications are developed)
  • opens up a range of new distributed application scenarios
  • cool technology stack

My personal take home from this is that the benefits are stronger for the developer right now. In a world with a few dominant social networking providers and openID providers the benefits of WebID for an "average" end user are maybe not that clear. Like any network-effect technology it is going to need some exciting end user applications to drive enough usage to start the snowball.

Disclosure: Having spent years having to use X509 certificates for access to corporate services I'm allergic to browser keystores and PKI in general, I'm trying to suppress this irrational reaction but some bias may have leaked through.

Apropos the comments above by Nathan. In a nutshell:

  1. Unambiguous Names for Agents (Person, Organization, of Software)
  2. Verifiable Names for Agents based on existing SSL/TLS protocol + URL de-referencing tweak applied to Structured Profile Document (e.g. FOAF based Profile)
  3. Foundation for real ACL based on control over shared resources on HTTP Networks
  4. Foundation for sophisticated Data Access Policies that built atop verifiable identity.

See complete WebID + OpenID demonstrations (screencast style) at:

  1. http://www.youtube.com/watch?v=eXoxUo7Py4M -- Safari
  2. http://www.youtube.com/watch?v=mjgXsjd8PDE -- Firefox

BTW - I used OpenID to get into this data space without entering a username or password combo :-)

Kingsley

FOAF+SSL is RESTful and easy to implement at the client end (assuming you have access to an SSL stack of course).

I can request a FOAF+SSL-secured resource with curl or wget. I can't do that with OpenID.

Lots of good answers here.

Furthermore, if I understand correctly, FOAF+SSL means you can publish a FOAF file without making it world-readable, adding an extra layer of privacy.

OpenID will not help at all in identifying your trusted network.