OpenId, WebID and BrowserID

I wrote up a note on how they fit together on Ars Technica https://bitly.com/pAycSw

Just for future reference I'll copy it here. This came in response to someone was complaining that there were too many identity protocols out there. (see one of the previous comments)

---------

The different technologies try to solve the same problem, each whilst trying to optimise for some use cases.

- OpenId wanted to give the user control of his identity - he could choose his IDP and move around over time - but wanted to reduce as much as possible the requirements on browsers and servers. So it is all done via attributes passed in the URL and simple HTTP redirects. This is not RESTful, but it requires no access control to the users profile page which would be required if you wanted to place attributed there in a machine readable format but not allow every person to see it. OpenId Attribute exchange is a substitute for that. It bought immediate deployability at the cost of emphasizing the IDP over the profile page, which could and should have been the center of web linkages which would then form the basis of a web of trust. As a result the IDPs are fighting each other over an necessarily ellusive trustworthiness of their claims.

- WebID is looking at a way of doing authentication by taking web architecture fully into account and using only existing standards: TLS, HTTP, Semweb. As far as the identificition process goes it gets to the same point as OpenId but in a very efficient manner, requiring only one more http connection over the initial user connection. But it emphasises the importance of that URL identifier, looking as it is towards building a global decentralised web of trust where links are between WebIDs, and those links provide the trust metrics for giving access control. (see the video on http://webid.info/). 
WebID though requires the server to have or rely on one that has a tweaked SSL layer. This makes it technically more difficult to get started than OpenId for many services. But it comes with full commercial grade security, and this will only improve with time as DNSsec and other things get rolled out. And in my view all the web should be behind tls if we really want to be serious about security. But it does slow down adoption.

- BrowserId uses encryption and could with a bit of tweaking (I need to look into this in more detail) use exactly the same certificates and profiles as WebID does. This would remove the need for the Relying Party (the server you want to log in to) to deploy a TLS endpoint which means it is a great way to get WebID off the ground, and get people to have more identifiers. 

So on this view BrowserID can complement WebID very nicely (modulo some changes in BrowserID and probably the development of a JSON format for WebID). OpenId also uses a URL to identify the user, as WebID does. The OpenId url and the WebID url can be put in a simple relation on to the other in fact. So OpenId is a protocol for browsers that don't have TLS or client certificate access.

If you look at those three protocols that way, then they are all fully compatible one with the other. It helps to think semantically for this to be apparent though.

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

Ok, so next we need to look if one could really build this WebID BrowserId combo.

Henry


Social Web Architect
http://bblfish.net/