W3C home > Mailing lists > Public > public-xg-webid@w3.org > July 2011

BrowserId and Issuer Alternative Names

From: Henry Story <henry.story@bblfish.net>
Date: Sun, 17 Jul 2011 08:40:04 +0200
Message-Id: <9F4931BD-A0CC-4329-9045-A28298E6823C@bblfish.net>
To: Ben Adida <ben@adida.net>, WebID XG <public-xg-webid@w3.org>
Hi Ben,

Thanks for all your careful replies. I have re-read the documentation at http://lloyd.io/how-browserid-works and I think I now have a much better understanding of what BrowserId is doing. Let me summarise that first, then go into a little bit of details, then show how I think that fits in with WebID as we have it now - let me call that foaf+ssl, to make clear that WebID can evolve.

Summary
-------

Essentially browserId is a way for an e-mail provider to sign a certificate (JSON based) asserting that its primary subject  has a certain e-mail address. The e-mail provider's public key - with whose corresponding private key he signed the assertion given to the user - is to be found by using yet to be settled on well known url [1], perhaps http://coca-cola.com/.well-known/mail, or a lookup in DNSsec. If the signature is confirmed authentic, the claims in the JSON certificate sent by the user to the Relying Party are understood to have been claimed by the e-mail server. Since that agent is the one making naming decisions in that space his claims are final.
 
 If the user was able to sign the bundle sent to the Relying Party correctly with his private key, and of course if the Relying Party was then able to verify this, then he has proven himself to be the subject of the certificate.

Detailed interaction
--------------------

BrowserId works in that the Identity Provider (Google, Identi.ca, coca-cola.com, harvard.edu ) issues a signed json certificate to each of its users containing an e-mail address and the public key of the client (the private key remains in the users browser) The verification of the certificate by the Relying Party is done as follows:

 0 - the user selects a certificate signed by his IDP (gmail, identi.ca, browserid.com...) adds some token sent to it by the server, signs the whole with the private key and sends it to the Relying Party (RP)

 1 - The Relying Party (RP) verifies that the bundle it received was signed by the users public key.

 2 - The RP fetches the certificate of the Identity Provider by going to a well known location related to the domain of the e-mail holder.  ( perhaps by going to a http://gmail.com/.well-know /mail or by looking this up in DNS, or what not. This is not yet specified )

 3 - The Relying Party verifies that the public key from the IDP did in fact sign the JSON certificate sent to it by the client. If it did, the claim in the json certificate are verified as claims made by the IDP.

Since the e-mail claims made by an e-mail identity provider are necessarily true (they are naming decisions within his space of authority), the claim there can be trusted.


JSON/X509 Certificates
----------------------

BrowserId uses a JSON certificate format, which is very useful for deploying web apps and getting away from ASN.1. You want to do that because you don't want to rely on TLS to get the certificate, and you want it to be easier to parse for developers. Both are good reasons. Being with a browser vendor you have the ability to build such a certificate into the browser, which of course opens up new venues, and these were of course not ones we were going to explore by ourselves.

 But we should not loose sight of the fact that these are just syntactic differences here. What can be done expressed with JSON can be expressed with X509. And if it can be done with both in a way that makes sure the semantics is the same, then one gains by being able to work with a lot of legacy applications. 

So in short it is worth looking at how this maps over to X509 world.

The role of the issuer
----------------------

The role of the certificate issuer is something we discussed on the foaf+ssl mailing list and here, but never really developed as we were able to get far enough with what we had, and we could not find a good and convinced party with real implementation desire to defend something in that space. You are that party :-) so now we have something real to go on.

  So a WebID Relying Party could find in the certificate sent to it by the user, the domain of the issuer - perhaps this was placed in the Issuer Alternative Name field - and then use exactly the same process you will use to fetch the verifiably correct public key of the domain owner.

   With this the WebID Relying Party could believe all claims that were naming claims for which the domain owner was the final arbiter. So in particular if the Subject Alternative name contained either a mailto: (for real e-mail addresses) or an accnt: (for names that are not to be used as e-mail addresses) URL, then those could be used immediately without dereferencing those claims. 

   This could be thought to be very useful for large sites like Google, who have 100s of millions of users, as this would avoid the dereferencing of each of the subjects. It could also allow Relying Parties to be more discreet, since by downloading just the public key of Google, Google would not be able to tell which of their users had found an interest in  that particular service.

Conclusion
----------

  It looks like the BrowserId ideas can be taken up by the X509 version of WebId very well. I now realise that this could in fact improve anonymity of WebID and reduce the load perhaps on the Identity Providers.

  The WebID part can be also taken up by BrowserId - now or at a later time (just make sure the json is extensible and has clear semantics - see json-grddl perhaps) and this will give you some good ammunition to fight the criticism you have received (from reading the web). That is if you make sure the subject field is extensible enough to allow http and https URLs (or any URI for that matter) so that the user can have a link to his WebId or OpenId page there too, then you can respond to the following
 
   no attribute exchange! Wrong: the http(s) WebId allows you to have RESTful and linked data information about the user    
- as much or as little as he wishes to make available.
 
   no key deprovisioning! Wrong: by dereferencing an http webid you can verify that the public key the user was working with is still valid now.

  I hope we can work together on these parts. I for sure thing that BrowserID could help grow the number of WeBIds by giving services the ability to verifiy WebIDs without needing to implement TLS (at the cost of some security)

   Let me know if I am on the right track,

	Henry Story



[1] perhaps using http://www.mnot.net/blog/2010/04/07/well-known



Social Web Architect
http://bblfish.net/
Received on Sunday, 17 July 2011 06:40:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 17 July 2011 06:40:49 GMT