Foaf+ssl/FAQ

From W3C Wiki

Below is a list of Frequently Asked Questions, that tend to be more end-user oriented. For more developer-oriented questions see the HOWTO.

General

What is FOAF+SSL

FOAF+SSL (aka secure WebID) is a set of technologies for solving the global authentication problem, and enable the Social Web.

The most widespread method for login is the username/password pair,

  • is tedious for users:
    • they have to invent new username passwords on each site
    • fill in their details again and again
    • keep their data up to date on each service
    • reconnect with friends each time
  • which is a huge security hole:
    • as people tend to re-use the same passwords from one service to the other,
    • come up with easy to remember or easy to crack passwords
    • or these get passed over the wire without encryption, and so can be discovered by any listener on the public internet


Both of those points complement each other. Being tedious to recreate accounts people drop the security vigilance.

What is missing in this technology is cross organizational identity. In a world where people only talk to each other in a closed environment username/password is great. But we have not lived in such a world for a long time. Just consider the issue of dealing with customers.

FOAF+SSL allows users to create their own global identifiers which they can control, and log in and link together with any other agent world wide in a secure manner. It does this while linking up the user into a global web of metadata, reducing furthermore the need to ever re-enter any data.

Why SSL?

The main reason that SSL is used for authentication is that is an extremely well tested and widely supported technique for password-less login. It is embedded in every serious web browser, and it is what drives web commerce. It may not be perfect - see Dan Kaminsky's excellent critiques - but it is central to billions of dollars of transactions, and so problems will be fixed.

SSL login is used widely, for technologies such as SSH and email too.

How does Secure Authentication Work with FOAF+SSL?

The FOAF+SSL front page shows the 7 step sequence diagram of how the protocol functions. But this may still leave someone puzzled... Here is a more philosophical view of what is going on.

X.509 certificates allows you to publish a public key in a certificate, as illustrated by the padlock in the diagram below. The user keeps hold of the private key, usually saved securely in a keychain. You can think of this private key as being able to unlock the padlock ("public key") During the https connection the server verifies that the user can indeed unlock the padlock.

The certificate also makes a claim about the user being the referent of the WebID (i.e., that http://bblfish.net/#hjs in the diagram below is his name) . Since the meaning of the WebID is to be found by dereferencing the URL ( http://bblfish.net/ ), the server that is authenticating the user can GET its meaning. If the meaning of the WebID is that it refers to the person who can unlock the public key/padlock, then since the authenticating server knows the agent at the end of the SSL connection unlocked it, the server knows it is communicating with the user identified by the WebID.

( Note that this sense and reference distinction is fundamental to the philosophy of Language since the work of Frege at the end of the 19th century. See among others Frege's contribution to the Philosophy of Language )

The strength of this verification then depends essentially on

  • the trust one has in public key cryptography
  • the trust one has that one did indeed get an uncorrupted meaning for the Web ID.

If the WebID is an https URL, and the server's certificate was itself signed by a trusted CA, then this is the security that is accepted for reasonably sized business transactions. With DNSSEC being rolled out now, this part will be even more trustworthy. (see RFC4398: Storing Certificates in the Domain Name System and RFC4255: Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints). There is also the new Keyassure IETF working group (now called Dane) looking into this for DNSSEC.

This is not that different from the usual e-mail verification mechanism. With e-mail verification the proof is done by the sending of a message to the e-mail address - the equivalent of an HTTP GET - and the receiving of a response - in e-mail this is usually delayed - in such a way that the response can be tied to the initial e-mail request. The e-mail address here is an indirect identifier of the person, and the send-an-email-click-on-a-link protocol is the verification of the relationship between and agent and an e-mail referent.

Could I not simply copy your FOAF profile onto my server and pretend I am you?

There are two problems hidden in this question: one about how one gets the initial trust going for a Profile, and the other if having established trust for an initial WebID one cannot undermine that trust by just copying the profile.

So starting with the issue of general trust, we can look at this from a Web1.0 perspective, and see how things are dealt with there. Anyone can write anything on web servers they own, or have access to. One can already put up fake sites for President Obama, the Wells Fargo Bank or the W3C. The way issues of trusts are solved there is partly to do with the network of links from which one gets to those sites, partly advertising, and partly legal. WebID can in fact help solve this type of problem too, as explained in the presentation WebID and e-commerce, by allowing a user to select an institutional web of trust to guide him.

If we narrow down the problem to one where trust in a WebID is already established, the we can answer the question technically. Assume that Alice received my WebID because I gave it to her on a card at a party. So Alice can trust that WebID is mine. Now assume Chuck then copies my WebID Profile to his server. There are two ways of doing this, none of which will enable Chuck to pretend to Alice that he is me:

  • Isomorphic copy of the graph: If Chuck copies the graph over isomorphically, so that the web page he has states exactly the same things as my WebID Profile triple by triple ( with the exception perhaps of the public keys which Chuck changes to one whose private key he controls), then this document is not a WebID profile, because what in the original document was a WebID is not a WebID in the new one: that is the main url is not defined in that document. As a result anyone dereferencing the WebID will go to my document, which is the one that still contains my public keys.
  • copy of the relative graph: If Chuck copies the graph having first relativised that to having my profile document as base, and he pastes that document to his server, then he will have a document with a new WebID. But Alice will not trust as being mine, since I never gave her that WebID.

How does this improve over X.509 or GPG Certificates?

X.509 hierarchical trust requires trusting root Certificate Authority (CA). These sign other certificates, which end up signing end-user certificates, as shown in the following diagram.

But very few CAs are known globally to authenticate client certificates, and the information they would authenticate would both be very minimal and frozen - certificates cannot be changed once they are signed. New ones need to be re-issues. And since issuing one costs money, this is an expensive process. Furthermore X.509 certificates have no way of encoding relationships of trust between people. They are hierarchical trust systems.


PGP/GPG certificates do remove the hierarchical trust piece and favor a web of trust. Each person can specify that he trusts someone else by signing that person's certificate, as shown in this diagram

Here we have a way to encode a social web, but it remains just as difficult to add or remove information from signed certificates. Indeed if you wanted to change your certificate with PGP whilst retaining the signature of all members of your social network you would have to ask them all to sign your certificate again, a very tedious process. As a result social networks get encoded into unchanging certificates, mistakes are difficult to undo, and your social network is frozen in public servers.

By tying a WebID to a certificate, the referential role of the identifier can be used to its full. The data that changes (your blog, telephone number, address, current location, friends) can be placed outside the certificate at the profile document associated with the Web ID, where the content can change, be access controlled, etc... So you can change your friends, without changing certificates.

How does trust work? You could write anything in your profile!

You can indeed write anything in your profile, just as you can write anything into any of the forms available on the web. So after authentication all the server knows is that you are identified by that WebID. All the rest could easily be false.

On Facebook too people can write anything they like about themselves, or pretend they are somebody else. Those that do pretend to be someone else, will either have to write very little, and so be trusted less, or soon be discovered as impostors, as the actions of the fake person will soon diverge with the actions of the real one. The social network and the fact that people give and retrieve access to resources given the position someone holds in that network is the guarantor of trust.

Why FOAF?

FOAF/RDF is a framework used to describe machine readable statements. It is designed to be extensible and to be clear whilst being extensible. This is needed as we wish to be as flexible as logically possible.

The Social aspect of FOAF is key to understanding the deeper implications of distributed identity.

Why not leave identity to the big players: States, Banks, Social Network Providers,... ?

FOAF+SSL uses the same technology - but in a decentralized and much more flexible way - than what the states would have to use. Many states in Europe are in fact starting to deploy identity schemes using public key cryptography. There is nothing wrong of course with having banks, states, and others being identity providers (neither with FB being a provider too for that matter). But don't expect the state to vouch for your current (boy/girl)friend, micro-blogging account, preferred color, the latest book you read, or your political views... A government issues certificate may at most say that you are a citizen of a country, and a few other very carefully selected facts. Same with banks. It's up to you to build your reputation and speak with YOUR voice on things that matter to you.

To do this it will clearly be helpful if you can link accounts across the web, link statements you make, and speak with the voice appropriate to the situation. A State ID may not be the right identity if you want to go to a masked party, if you are role playing, speaking to your family, having a casual conversation or publishing an academic paper.

Will this not lead to a massively inconsistent user interfaces ? The MySpace problem to the nth degree?

Indeed everyone will be able to have their very own personal profile page styled to suit their character, and the message they wish to convey. This can lead to wide variations in page layout, and so make the web representation unique for each person/organization. Good layout will be key in the selection of personal profile software. The same is true for blogs, and people don't have that much problem with those.

But beyond that an even more interesting solution will emerge, allowing users to have completely coherent view over the whole social network space. Since the data behind any such presentation will be machine readable, any other linked data browser will be able to process it, and present it to the user in a manner consistent for the particular task the software is designed for. One prototype of such a browser is the Hyper Address Book, which specializes in presenting a number of FOAF related ontologies. Many more will be developed, just as a large number of clients have been developed for Twitter.

OpenID or WebID?

Yes, but not Xor. They can work well together. The OpenId page can be your WebID profile. All that needs to happen is to link them together. The relations needed are the following written out in N3 (Turtle)

@prefix foaf: <http://xmlns.com/foaf/0.1/>.
@prefix : <#> .

<> a foaf:PublicProfile; 
    foaf:primaryTopic :me .
 
:me a foaf:Person;
   foaf:openid <>;
   foaf:name "Joe";
   foaf:knows </people/jack>;

So the above can be written out in RDFa (or other formats) on the OpenId page, and the correct OpenID link relation be added to the OpenID service endpoint. Then one can tie OpenId back into the web of linked data, and use it as just an authentication mechanism, ie. without needing to rely on the attribute exchange part of OpenId.

WebID or BrowserId?

Long article on StackExchange looks at the differences and similarities between the two protocols: What are the main advantages and disadvantages of WebID compared to BrowserID?

Practical

Why have most sites preferred to use passwords over client certificates?

When used in the traditional way, Client Certificates get verified by checking the signature on the certificate against the public key of the signing Certificate Authority (CA). This puts a lot of weight on the Certification Authoritty, which has the following two problems:

  • The current well known CAs - those whose Certificates are available in all volume browsers - are very far from being practical organisation for certifing individual users. It would be both expensive and cumbersome for companies to have to coordinate their work with such companies.
  • Individual Companies could certify their users, but most of them suffer from the problem of not being widely known, meaning that the certificates they issue would be only known to themselves and a few others. As a result certificates they generate have tended to only be useable to their own users when those users access their own site.

Only large companies (such as armies or multinational corporations) will be widely enough known and have enough distributed porperties spanning the globe under many names, that their internal problem is large enough for client certificates to make sense. For such large organisations creating a client certificate allows the user to authenticate across many distinct properties that would otherwise require that user to know any number of username/password combinations in a very insecure setup. It would be difficult to make sure that employees of said company did not use the same password across subsidiaries - some of which may be in very fierce competition - or across external providers. Here the public/private key cryptography comes to be tremendously useful.

But any web site that does not have such issues will find it difficult to justify as currently things stand having their users create a certificate that only works for their web site - since creating this certificate across devices itself requires username passwords.

With WebID based certificates the same certificate can be used across all secure web sites, meaning that the benefits of Certificate based authentication comes immediately to the fore, and eclipses the quite low cost of creating such a certificate as shown in the short video Creating a WebID across browsers in under 4 minutes across browsers.

Is it difficult to create a certificate? Does it cost much?

Because of the way FOAF+SSL uses certificates, these can be self-signed. They can be signed by anybody in fact, it does not matter. So as a result the cost of producing one is insignificant, close to the cost of downloading a random web page. Making one is very easy for the desktop browsers such as Safari, Firefox, and Opera. These browsers support the KEYGEN element, which allows the browser to create a public/private key pair. So the private key never leaves the browser. The KEYGEN element is now defined in HTML5. For more see the section in the Clients section of the wiki

How is anyone going to remember their WebID?!

You don't need to remember it! It is locked away inside the user's certificate. All the user needs to do is point and click in their browser's Client Certificate Pop Up.

If you want to give someone an ID at your party then there are a number of solutions:

  • Give them a card with all the information written on it
  • If you don't have a card
    • write down your home page URL. If that is simple it should be easy to remember. Your home page can be your OpenID too. Have your home page link or be your WebId Profile Document
    • write down your e-mail address on a paper. If the service provider supports WebFinger then if this points to your home page, then automated software should be able to go from an email address to a home page, from whence one should find your WebID. (see WebFinger FingerPoint and other protocols)

Is SSL not really expensive server side to Process? To expensive for Google ?

No longer according to a Google engineer who wrote Overclocking SSL

In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production front-end machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that.

If you stop reading now you only need to remember one thing: SSL/TLS is not computationally expensive any more.

With the release of of Firesheep, the Firefox plugin that makes it easy to sniff passwords and cookies on public networks, security is no longer an option. "If you don't scale securely you are not scaling", as someone put on the web.

As of January 2011 Read Write Web reported that Zuckerberg's Page Hacked, Now Facebook To Offer "Always On" HTTPS .

SSL makes cheap hosting impossible

Cheap Hosting generally relied on vhosts - where one runs many sites off a single IP address. SSL made cheap hosting difficult, because it required a unique IP address for every site. So a web service provider could not host 1000 of different secure web servers at DNS names such as https://joe.name, https://jack.name, and so on from a single IP address - but instead had to assign each side its own IP address. This has a significant organizational and technical overhead. TLS 1.1 helps overcome that limitation with what is known as Server Name Indication (SNI). This again allows a single IP address to run as many virtual hosts as one wants. An easy to understand explanation of the problem and the solution can be found in TLS Server Name Indication on Paul's Journal. Though note that this post is from 2005, things have moved on; most browsers support SNI these days - and it has been shipped with most operating systems and servers for a few years now. As of January 2011 one issues is support in Android's default browser as reported by bug 12908.

It is complex to copy certificates from one browser to another

Yes, and indeed that is why FOAF+SSL (WebID) would not be a reasonable solution if this were the only way to do things. Luckily a user can be identified by any number of public/private key pairs, i.e., by any number of certificates. So the easiest solution is just to have one certificate per keychain - which often means one certificate per browser, as many browsers come bundled with their own keychain. (but this need not be so, as demonstrated by Safari and Chrome on OSX which use the same keychain)

OpenID failed, do people really want distributed identity?

It is not clear that OpenId failed. But it does have a lot of comparative disadvantages

  1. User Interface issues:
    • OpenID still requires the user to type a username ( URL ) - WebID does not. The user need not remember it, not type it. WebID authentication is point and click.
    • WebID removes the NASCAR problem (the ever growing number of authentication buttons on a site): authentication is in the browser. (Fallback options to OpenID, FaceBook via NASCAR is of course possible)
  2. Protocol Issues
    • OpenID is open to phishing. The Relying Party could send the user to a similar looking site getting the user to enter his password there
    • OpenID attribute exchange is very poor
      • limited to the length of a URL (1024characters).
      • attributes pass over the wire via the URL, and so makes them visible on the network.
      • attributes creation is open to name clash, and so limited. WebID attributes are fully extensible
    • OpenID (tends to) rely on a 3rd service, the identity provider
    • OpenID is not RESTful
      • attribute exchange places information in URLs which should be opaque.
      • therefore it does not play that well with linked data
      • one cannot link to someone's attributes, since they are not at the OpenId page URI
      • it is not possible to build a distributed social network with the attribute exchange protocol
    • OpenID requires 7 https connections - which are costly to establish - to be secure (see the openid sequence diagram) whereas the WebID Protocol requires only one more than the connection, and being RESTful that representation can be cached. So the WebID Protocol is close to as efficient as one can be, which is very important for distributed data applications such as Social Web apps that need to connect to many different servers.
    • OpenID Identity Providers always end up knowing where you logged in, as they have to tell the Relying Party your identity, in a protocol that requires them to know who that party is (they have to redirect there). WebID just requires the Relying Party to make a simple HTTP GET on the WebID, which it can do through anonymizing proxies.
    • WebID sets the basis for good security practice: encryption everywhere
    • WebID is extensible beyond human authentication. It can be used for Web Services, robots, and automated login
    • WebID comes with built failover support: a certificate can contain a number of Subject Alternative Names: if one of them is down, the other can take over
    • WebID does not require DNS. WebIds could use IP addresses (IPV4 or IPV6)


Most importantly of the above is that because OpenId does not fit into the RESTful architecture of the Web, it is not able it cannot be the foundation to build distributed social networks.

OpenId is very helpful stepping stone towards WebID (FOAF+SSL) though, and both can play very well together.

  • OpenId can be very useful for browsers with no X.509 support
  • It can make FOAF+SSL immediately useful, as it is easy to tie OpenId into FOAF+SSL. For example on

http://webid.myxwiki.org you get an OpenId automatically on creating a cert. This uses the http://openid4.me/ service

How does FOAF+SSL work with public terminals ?

The first thing to emphasize is that there is no security on public terminals that does not already require one to trust the Operating System and the terminal owners. With passwords this problem is very bad since the owners can just sniff the password. The only partly satisfactory solution would be to use a cryptokey on such a terminal. Everything else can just bee seen as improvements over password problems.

There are a few ways FOAF+SSL could be made to work with public terminals:

Using short term certificates:

  1. The user needs to be able to login to the server securely. There are a number of ways of doing that:
    • have the server send a one time password via SMS
    • use a Yubikey to create one time very secure passwords using a one button USB stick that acts as a keyboard
    • there are many other ways to create one time password - such as writing out a series on a piece of paper
  2. FOAF+SSL certificate services could allow one to create temporary certificates with very limited time duration (minutes or hours) (as demonstrated by the webid.myxwiki.org service - though a much better UI experience is of course imaginable) Once the certificate time limit expired, they become unusable - by the definition of the TLS protocol.
  3. furthermore FOAF+SSL services could make it easy for users to disable certificates either via a web interface, or for example by sending a reply to the one-time password key. The server need just remove the public key information for that certificate from the FOAF file. This would cover the case of a user leaving the public terminal much too early due to an emergency, then remembering that his certificate was still valid. A very user friendly service could allow him to do such a thing over the telephone for example.

Or for even higher security using specialized Token cards such as the German Privacy foundations' Open Source Crypto Stick or Safenet's Cert based e-token. On these devices the private keys are placed in memory that is inaccessible to all but the certificate negotiation module on the key. When the key is removed the SSL session is closed. see the Client Section.

Otherwise for convenience a WebID provider could easily also be an OpenId provider and so one's OpenId could be one's OpenID profile page, tying both protocols together to give the user choice. If the OpenId provider is password based then it the security whole is there.

How does one login to one's Web ID server if one looses one's certificate?

WebID servers such as http://webid.myxwiki.org allow one to login with a username/password, not just with FOAF+SSL. This is perhaps the only service that should conceivably still have password authentication enabled. It could send a one time password - to be more secure - via SMS.


Is one tied to using only one browser per WebId ?

No. Try http://webid.myxwiki.org/ and get yourself a public key for each browser on as many computers as you wish.

You could also take a certificate and move it between browsers. But why bother, if is is easier to create a new one?

What happens if I lose my private key? Am I locked out permanently?

No you should have another access mechanism for your WebId server. This may be the only service where you still need a password. Though that can be a one time only password sent to your cell phone, and valid only for a short period of time. If you keep your server in your basement then you could allow privileged access when connected physically to the machine.

Once you have access to your machine you can then revoke your previous certificate by just removing the public key from the Profile page. ( So revocation is also decentralized and simpler than with older standards in this area such as Online Certificate Status Protocol )

http://webid.myxwiki.org/ allows you to login with a username/password for example. You can then use this to delete the association between you and the public key.

If companies require users to regularly rotate their private key will this destroy the whole system?

No, Certificates have expiration dates, and it is easy to also invalidate a key by removing it from a FOAF file

I thought FOAF+SSL required self-signed certificates, but service X is signing the certificate for its users

Yes, FOAF+SSL can work even with self-signed certificates. But it does not need to, it can work just as well with certificates signed by some unknown CA, or even with certificates signed by a known CA. FOAF+SSL does not need to trust the CA. (A service could get a bit more information out of a certificate (though not that much) if it knew the signing CA and trusted it too)

Since browsers make it easy to create public/private keys in one click using the keygen element it is often easier to not create self-signed certificates. When the browser has created the key pair, it sends the public key to the server, which then has to sign it. As it never sees the matching private key, it cannot create a self-signed certificate. Hence it create a certificate signed by the default CA.

As a user how do i add information to my public profile - assuming that i don't know how to write RDF?

Usually information should be added to a profile using the best Web 2.0 practices, which in the end boils down to filling in forms, collecting interaction data, drag and drop (HTML 5 allows that in a much bigger way), etc.... The user should never be writing out any RDF in any format whatsoever - unless it's an RDF Integrated Development Environment of course.

Which developer tools support WebId?

TLS/SSL was developed in 1997 and is now part of every standard library. If you are programming you should have no trouble finding complete libraries for your language. In any case it is usually available in every tool if one looks around.

Here are some well known tools

  • Curl, a basic unix command line tool to fetch information from the net
 $ curl -E/--cert  <certificate[:password]> https://webid.net/web/
  • rapper, rasqual
 $ rapper -fwwwCertFilename=/path/to/cert/file -fwwwCertPassphrase=passphrase https://example.org/path
  • python rdflib
 todo
  • cwm
 todo

Privacy

Could one have throwaway WebIDs ?

"To the extent that "WebID" makes it impossible for sites like bugmenot.com or mailinator.com to exist and function well, it will be destructive of privacy". Those sites could easily create a form to create such temporary or minimal information WebIDs. The advantage would be it would just require one click to make an ID there.

Can one be Anonymous with WebIDs ?

Browsers should make it clear to users what identity they have used to log in to a site and tie all cookies to that identity, so that when logging out from the browser, the users cookies don't get used. Given more work from the browsers developers on this feature then given that one can also have throwaway WebIDs one can get a very smooth space of complete anonymity to stronger and stronger identity depending on the strength of one's social network. Remember that the social network need never reveal the web of relationships to outsiders.

FOAF files are public! who wants all their social network to be published to everyone?

HTTP has many methods of access control. Not everyone on LinkedIn or Facebook can see everyone's profile for example. Once one has authentication, one can control access to parts of the graph. For example:

  • you could allow your friends to see your current address and location, but not some unknown person.
  • you could allow your colleagues access to the business plan but not show that to your friends
  • you could allow friends of your friends to help organize a party
  • the photo of the new baby could only be made available to your wider family

People like to keep different parts of their life separate, is this not going to be restrictive?

You can have any number of WebIds. For example, Henry Story has

These don't need to be linked.

How does one revoke a certificate if its private key has been compromised?

You remove the public key from your Profile document file. That should be no more than clicking on a form of certificates to delete the one that was lost. Of course one could also do this using an editor such as vi and by editing an html file.

How can this work with Company https proxies?

First one has to understand how https proxies work.

Essentially TLS proxies work by the company placing root certificates they own the private key of in the browsers of all their workers. The firewall then intercepts all outgoing https connections and pretends it is the remote site. The browser will not of course be able to return an EV Certificate, the one that shows a green icon in the URL bar, as it has not been signed by the correct certificate authority, but this can be good enough.

The problem for WebID is that if the server requests a client certificate, the firewall will be the one receiving that requests. It can create the same request for their employee, and their employee will then ask her to choose a certificate as normal, which the firewall will again be able to intercept. But if the client does not know the private key of the client certificate, then it won't be able to pass the request along.

The solution is simply that in such circumstances the employee should use a company WebID. Then the firewall can create a certificate for that user and publish the public key in the company controlled user profile, along with the user generated public key.

see Issue-28 of the WebID Incubator Group.