What are the main advantages and disadvantages of webid compared to browserid?

Question

What are the main advantages and disadvantages of webid compared to browserid?

This question is inspired by this answer which got a number of upvotes despite being very vague on the topic of that question.

Webid is basically a fancy name for SSL client side certificates with a profile url in it.

Some topics:

• Hows are compromised keys invalidated?
• How does multi device/browser support work? If those result in multiple public keys, how are they linked? Is the linking required to be done for every consumer?
• How is support in current 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)?
• Is there a centralized organisations which can track users? Are there decentralized organisations which can track users? How detailed can the tracking be?
• How easy is it for a consumer to get the implementation right? (Read how likely is it that a lazy implementation contains security issues?)
• 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)?

Answer 1

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 (detailed spec) 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). The WebId Protocol is being developed in a W3C Incubator Group, building on the protocol formerly known as foaf+ssl. So it is also evolving. Both of these protocols were presented at the W3C Identity in the Browser Workshop at Mozilla's office in California this May 2011

Furthermore it is not clear that both projects are incompatible - or rather it is only a question of semantics if they are. One can distinguish two dimensions in which they differ: an authentication and a serialisation one.

• identity verification: certificate signature verification (BrowserId) or subject public key 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) as described in this e-mail

But there is no logical reason why one could not 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 certificates.

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 that we are dealing with here is really: 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 after logging in - perhaps with a one time key sent to him via cell phone - and remove the compromised public key, which he could recognise by name, the computer he generated it on, or some other other way that makes things easy to remember.

BrowserId currently uses a JSON certificate with a validity period, 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 relying party in the current BrowserID spec can only verify the cert by checking its signature with the public key of the e-mail provider. The longer the certificate is valid for the more likely it is that something could have gone wrong in the meanting - for example the users computer could have been stolen.

But if BrowserId were to be combined with WebID (ie: the JSON certificate were to contain an http(s) Subject Name) then longer lasting keys could be used: Relying Parties could verify that keys had not been compromised by checking the user's public profile.

How does multi device browser support work?

Both WebID and BrowserId can have multiple public keys.

With WebID/foaf+ssl each public key gets published in the profile page, as can be seen in "WebId creation and use in 4 minutes" video. Each device/browser can have its own certificate for the same WebID. Authentication of the user is done by verifying that the public key in the certificate matches one of the public keys publised on the WebID profile page.

BrowserId will save the key in the browser/OS keychain once that part is integrated in the browser. The Relying Party verifies a certificate by checking that the Issuer really signed the certificate, not by a byte-by-byte comparison of certificates. So any certificate can be used, as long as the signature is authentic.

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 pure WebID every profile needs to publish every public key. The profile may be nothing more than the publication of that key.

BrowserID only requires the e-mail server to publish its public key.

How is support in current browsers?

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

For BrowserId to work in a decentralised way it needs browser support. This is currently missing, but it has a chance of being deployed as it has support at Mozilla labs.

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 the risk acceptable. By completely placing the key in hardware the risk that the private key be stolen is removed. see WebId and the Crypto Stick. Otherwise very short lived keys are a damage limitation solution if either WebID or BrowserId has to be used. Both protocols can work with short term keys.

Perhaps OpenId is better here combined with one time passwords passed by a cell phone.

Answer 2

Security, Privacy and Usability Requirements for Federated Identity by Michael Hackett and Kirstie Hawkey provides a comparison between WebID and Mozilla Persona, which at the time was still referred to as BrowserID.

The main differences that were noted (in Table 1) are:

• Persona keys are short lived, and should be protected with a password. WebID keys are long lived but can easily be disabled from a password protected profile.
• The current Persona implementation uses standard browser windows so it is difficult to spot spoofing (this may change once browsers get native Persona support). WebID uses the browsers native certificate selection UI so no chance of phishing.
• Both Persona and WebID identities can be compromised if control over the owners email/URI is lost.
• Persona IdPs have no knowledge of SPs that use an identity. WebID IdPs know every SP that uses an identity.
• If a Persona SP has a cache of the IdP's public key and the browser still has a valid certificate it should still be possible to verify identities. WebID profiles must be reachable otherwise identities will not be usable.
• Persona has good UX design, whereas WebID is the opposite.

I suggest reading the paper for more detail. It is freely available online, no digital library access needed.

Answer 3

Here's the conventional wisdom that I've always heard about client-side certs: Client-side certificates are not well-supported by current browsers. The UI is not readily comprehensible to ordinary users. Consequently, it's not really a viable option for the masses.