WebID vs BrowserId on stack exchange

I spent some time answering a WebID vs BrowserId question on Stack exchange. 

http://security.stackexchange.com/questions/5406/what-are-the-main-advantages-and-disadvantages-of-webid-compared-to-browserid/5424

This is better than the previous question on stack exchange that was badly phrased against BrowserId asking for what was wrong with it. I answered it, and put the text below. Let me know where I went wrong, so I can fix that. It was a lot of work writing it up, so please take that into consideration when criticising me for the inevitable errors.

--------------------------------------------------------------------------------------

note: A lot of these questions on the WebID side are answered in the Foaf+ssl FAQ

BrowserID versus WebID: is the distinction real?

BrowserId is an experiment at Mozilla labs, is very new, not fully defined (exactly how the e-mail servers public key should be found is not specified for example) and not completely implemented (it requires browser support to be really distributed). WebId is a specification going through a W3C incubator process, and so is evolving.

Furthermore both projects are not clearly incompatible - or rather it is a question of semantics only if they are. We can divide how they differ by looking at two dimension - identity verification: certificate signature verification (BrowserId) or public key of user verification (WebId/foaf+ssl) - certificate format: JSON (BrowserId) or X509 (foaf+ssl) formats for certificates

Currently BrowserId has been defined by the pair (certificate signature verification, JSON certificate) and WebID/foaf+ssl by the pair (user public key verification, X509 cert)

But there is no logical reason why one could not have also have the other two combinations: - (certificate signature verification, X509 cert) - ie a BrowserId auth done with TLS - (user public key verifiction, JSON cert) - ie WebID auth done with JSON.

Or one could also have both strategies for each certificate type. That is one could verify the certificate signature first and then if needed also verify the WebID. This could be useful to get more information about the user (a RESTful attribute exchange) and it could also be useful to check that the key had not been revoked.

So the question should really be what are the advantages and disadvantages of the "pure" BrowserId authentication versus a "pure" WebID - known also as foaf+ssl - authentication. Please keep that in mind for the rest of this answer.

Comparing Pure BrowserId and WebId/foaf+ssl

Answer stating the way things are in July 2011.

Hows are compromised keys invalidated?

In WebID they are removed from the Profile page. A good user interface would make this a one click affair. The user would go to his social network and remove a key, which he could remember by name, by the computer he had it on, when he generated it, or other human friendly ways of remembering things.

BrowserId currently uses a JSON certificate with a time stamp, which the protocol currently desires to restrict to being very short term. The reason the |(JSON) certificate needs to be very short lived is because the only way a certificate is validated by the relying party in the current BrowserID spec is by checking its signature with the public key of the e-mail provider. But if BrowserId were to be combined with WebID (that is the JSON certificate could contain an http(s) Subject Name too) then then longer lasting keys could be used, and compromised keys could be checked by verifying the key published on the public profile.

How does multi device browser support work?

Both WebID and BrowserId can have multiple public keys.

In WebID each of them gets published in the profile page. You can see this in action in "WebId creation and use in 4 minutes" video. So each device can have a certificate create by the device.

BrowserId will save the key in the browser/OS keychain when that part is integrated in the browser. Since verification only requires the Relying Party to check the signature of the certificate it was sent with the public key of the e-mail provider there is no problem if different devices have different certificates.

If those result in multiple public keys, how are they linked?

In BrowserId the public key of the user's certificate is only used to verify that the client has the corresponding private key in the authentication process. There is no linking going on.

With WebID the different public keys can be published on the Profile page and can this be linked there. Some of those keys could be described as long lasting and so also used for signing and decryption.

Is the linking required to be done for every consumer?

In WebID - if WebID does not also offer a BrowserId like feature - then yes. Every profile published the public key. The profile may be nothing more than the publication of that key.

How is support in current browsers?

All desktop browsers support X509 certificate selection. Cell phones are more patchy. So they all support WebID since 1998 or so. (with a few exceptions like early versions of Chrome)

For BrowserId to work in a decentralised way it needs browser support. This is currently missing from all browsers.

Is the user interface easy enough to be understood by average users (including creation, selection, revocation from the current computer, and global revocation of an identity)?

Creation: In both this is a one click affair. With WebID X509 certificates can be generated using the html5 keygen element, and an IE ActiveX workaround. The user just needs to click a big button - see the WebID & Browsers video or the above "webId creation and use" one. User Interfaces could be improved of course with better web designers.
Selection:
WebId: Selection is excellent on Chrome, Safari, Opera and IE but ugly - though not impossible to use in Firefox. Why they don't bother to fix that is a mystery. Please vote up bug 396441 - Improve SSL client-authentication UI. There is a lot that can be done to improve the UI, but imperfect browsers has never stopped creative web people from using it creatively.
BrowerId: selection can be designed by the web site, though this may create more security risks, and will not provide a consistent authentication UI across sites (hence a possible physching risk)
Revocation from current computer
WebID: removing of X509 certificates from the current computer is something that should be avoided, and certainly the UI for that should be improved.
BrowserId: revocation from the current computer is not defined yet as it has not been implemented.
Global revocation of identity
WebID: this just requires the Profile Page to return one of the HTTP error codes if the identity needs to be completely removed, or an HTTP redirect if the profile moves, or a semantic identity relation between the old and the new identity, or just the removal of one of the public keys from the profile if a certificate has been stolen.
BrowserId protects itself with short lived (JSON based) certificates
Is there a centralized organisations which can track users?

WebID: it can be completely decentralised. You could place your WebId on your FreedomBox and so could all your friends. You could also place it on some anonymous server if you trusted that service.
BrowserId: when the JSON certificate store is integrated with the browser - and one no longer needs to use browserid.org then each e-mail provider could participate. Since Freedom Boxes can also be e-mail providers they can also be authorities.
Are there decentralized organisations which can track users?

Examples of what that would look like?

How detailed can the tracking be?

With BrowserId the Relying Party fetches the public key of the e-mail provider. All that provider should know is that some server made a GET request. This is something that may be worth integrating into WebID. On the other hand the Relying Party ends up with an e-mail address that could be misused for spamming.

With WebID - a request by the Relying party is made on the Profile Page. This request could be done anonymously, via a proxy or even an ip-proxy.

How easy is it for a consumer to get the implementation right?

WebID over TLS requires more to set up for the relying party, including an SSL server. That server should not do the usual authentication of client side certificates. On the other hand it is more secure, since it forces TLS. There are a lot of TLS tools that have been tested over time, and that keep being tested.

BrowserId does not require TLS on the Relying Party so it is easier to setup. On the other hand there are man in the middle attacks possible if TLS is not set up.

( But at this point one should notice that there is no deep reason why BrowserID and WebID cannot both use the new proposed JSON certificate format and combine their strengths. It is quite possible to do the BrowserId )

How does it work on Internet terminals on which you don't have permissions to install software on (assuming you accept the risk of it being compromised)?

Internet terminals are always dangerous. Only crypto keys could make those safe, by completely placing the key in hardware. see WebId and the Crypto Stick. Of course very short lived keys are the solution if either WebID or BrowserId has to be used. Both can have short term keys. Perhaps OpenId is better here combined with one time passwords passed by a cell phone.