Foaf+ssl

From W3C Wiki
Revision as of 14:46, 24 October 2012 by Bblfish (Talk | contribs)

Jump to: navigation, search

Foaf+ssl$foaf keylock small.png

FOAF+SSL

FOAF+SSL is a secure authentication protocol that enables the building of distributed, open, and secure social networks: the Social Web. The protocol is being developed by the W3C WebID Incubator Group.

How does it work?

This is a summary of the WebID 1.0: Web Identification and Discovery unofficial draft.

FOAF+SSL is a very simple protocol. It authenticates a user in one connection; the same connection made whenever accessing a web site. This is done by making clever use of the SSL layer built into virtually every standard Web browser that implements HTTPS. The following sequence diagram illustrates this clearly:

Foaf ssl sequence.png

  1. In the first connection the user (Romeo) arrives on the home page of Juliet, after having received a note from her at a party. This page contains a login button or link.
  2. Romeo clicks the login link, an https URL. Perhaps https://juliet.example/login
  3. Juliet's server on receiving the HTTPS connection asks the client for his certificate. As a result a popup appears in Romeo's browser asking him to choose his WebId. (see the pictures of how different browsers present this). Romeo selects one of them, and this corresponding X.509 certificate is sent back to the server, which verifies that Romeo's browser has the private key associated with the public key published in it, using the standard https protocol.
  4. The certificate also contains a Web ID, which is a URL such as http://romeo.example/#me that was placed in the Subject Alternative Name field of the cert. Juliet's server finds this and does an HTTP GET on it.
  5. If the graph of the returned document contains the relations that http://romeo.example/#me has the public key specified in the certificate, the server knows that the person at the other end of the connection is <http://romeo.example/#me> .
  6. Juliet' server can then check in its database if <http://romeo.example/#me> is known by any of Juliet's friends, as specified in their foaf files published on their servers.
  7. Juliet's server authorized Romeo to see her file.

Note: The access control rule could be different, but this one is particularly telling, as it shows how each of Juliet's friends can contribute to helping her build a web of trust.

Trust is established recursively. Individuals add people they have had direct interactions with by exchanging WebIDs to their foaf file. Those people in turn do the same with their aquaintances. This can then be used by any user to build web's of trust.

FOAF+SSL uses Public Key (PKI) standards — usually thought of as hierarchical trust management tools — in a decentralized "web of trust" way. The web of trust is built using semantic web vocabularies (particularly FOAF) published in RESTful manner to form Linked Data.

Based on well known and widely deployed standards, FOAF+SSL and its implications are being discussed on the FOAF protocols mailing list (see its archive ). FOAF+SSL does not require the FOAF vocabulary, but this helps understand the social implications of the protocol.

For a very short description of the protocol, read the one-page FOAF+SSL: Adding Security to Open Distributed Social Networks. People working with client certificates may be surprised by this usage of this old technology. Reading The FOAF+SSL Paradigm Shift may help. For a much more detailed, technical explanation of the way we are thinking of trust, see FOAF+SSL: Creating a Web of Trust without Key Signing Parties.

Try it Out

To get an idea of what to expect with foaf+ssl watch this short screen cast. You can then try it out by creating a profile with one of the identity providers, and logging in to one of the Relying parties listed below.

  • FOAF+SSL Identity Providers will help you create a WebID, that is a foaf profile and a foaf+ssl certificate, without coding. ( If you prefer to hand write your foaf file see the HOWTO section ).
  • FOAF+SSL Relying Parties: A Relying Party is a service that authenticates a user with Foaf+SSL. Without Relying Parties a WebID is not much fun.

Some further pointers

Screencast Demos

Presentations

Papers & Blogs

Academic

Many more search results can be found on Google Scholar, by searching for "foaf+ssl" or WebID foaf

Ontologies

Wiki Layout

Some further wiki pages dedicated to check:

Use Cases

HowTos

Relations to Other Protocols

OpenID

SAML

Bruno Harbulot put a proof of concept together for delegated login using SAML.

XMPP

There is some work going on exploring how foaf+ssl could be used in this space. See the Rhizomatik foaf+ssl XMPP page, and some of the mailing list discussion. This still needs to be discussed further, so please post ideas and contributions to the mailing list.

Implementation Links

Articles

Libraries

For a comparison of features of these libraries see WebID Protocol Implementations

Services

Clients

SSL/TLS is a core part of the Web, and client certificates is very important for security conscious organisations. As such it is implemented in all high volume browsers. Before the development of FOAF+SSL though, client certificates were used in a very limited setting. Usually a client cert would be used only on the site that had released it and to a small extent on partner sites. As such the user interface for client certificates has not been very carefully worked on, especially the option of using one certificate across many sites.

For more details on the state of support of various browsers see the FOAF+SSL Clients page .

To Do

The most important thing now is to build tools that make it very easy for any member of the general public to get and use a WebID. This can be done most easily by retrofitting an existing application, mostly because all the user interface work will already have been done by the existing application developers.

Other Applications of FOAF+SSL

  • Fixing Email Spam -- Using WebIDs for DKIM Identity
  • replacing e-mail with WebID + Atom/restmail. This would in one go make e-mail secure, RESTful, webenabled and reduce spam, or at least severely restrict the damage, as the spammer would have to identify himself, and perhaps even host the spam.

Related

Reference Material

Icons

see the attachments section of this wiki page