Re: Browser ID

Hi Ben,

	thanks for the feedback...

On 15 Jul 2011, at 18:46, Ben Adida wrote:

>> Thus, please take this
>> opportunity to lay down vital integration hooks re. WebID.
> 
> I'm going to be blunt here: integration with WebID is not a use case. If integration with WebID helps our use cases, we'll happily consider it, of course. So, what would it get us? What would we lose? Help me understand those points.

The interesting thing is to see if there are synergies between our two projects. We are both doing identification using public keys and URIs: in your case you use e-mail URIs, in our case mostly http(s) ones, but other schemes such as accnt: ftp: etc... would work as well. We both would like better browser integration - I think you need to build that in, we would like better certificate management. WebID over TLS has a great security story to tell - which is getting more and more important. BrowserId can work without which makes deployment easier.

So let me walk through this step by step using http://lloyd.io/how-browserid-works as my guide.

1. Certificate provisioning
---------------------------

 I am not sure why you need to use the javascript API to create the key. Why not use keygen? It seems that in the end the certificate is going to go into the keystore anyway. 

 Google could then place the e-mail into the certificate the way  WebID does, in the Subject Alternative Name field. 

Side note:
In fact it is not clear to me at this point yet, why you need an e-mail URL in your certificate. The certificate is opaque. But it does not matter: you can put an e-mail in the san field.


2. Assertion generation
-----------------------

 [ • During the process of logging into a website, the user clicks on a "sign in" button on the RP's site, causing the RP to invokenavigator.id.getVerifiedEmail().]

Ok, why not just use a javascript to start the certificate selection box? Why make a distinction between certificate selection and verified e-mail selection? ( I am assuming that if this is deployed then the UI for all this would end up being massively improved, including taking up some features described by Aza Raskins a while ago http://www.azarask.in/blog/post/identity-in-the-browser-firefox/ )

 [ • The user selects an email address that they would like to use to log in from a list rendered by the browser.]

 An e-mail address is good. But in the certificate selection box you can get the same effect if you improve it a little bit. Chrome, Safari and Firefox show a very nice dialog showing just the Distinguished Name. If an e-mail makes most sense as a Distinguished Name, then all the better. Here are some certificate selection boxes:

 http://www.w3.org/wiki/Foaf%2Bssl/Clients/CertSelection

  You will notice that the problem is not the protocol, but Firefox horrible UI. Everyone else has a reasonable one.

 [ • The browser combines the domain requesting the identity (the audience), a validity period, and the certificate associated with the identity in to a bundle (the certificate includes a public key, and the email address being shared). ]

  Ok, that makes sense, since you don't want to send the X509 certificate. 

 [ • That bundle is signed using the private key associated with the identity, encoded into a JWT, and returned to the web page. ]

  Yep fine. So here you essentially have a self signed certificate.  Notice that you could easily extend this to put a
number of URIs in there, including a http/https URI.


3. Assertion Verification
-------------------------

  Here I think you could simplify your protocol and make it a lot more webby, and in fact tie it in completely with WebID.
So instead of sending the signed blob to the server, you could just have the server do the verification. This amount of cyrptography is not that difficult. We have managed to do crypto for X509 certs in every programming language out there, and you have essentially gotten rid of the ugliest part of that: X509. So you have made things simpler.

  If you do that, then the following happens: The signed blob you send to the "Relying Party" can simply be thought of as a Certificate with a neater syntax. At that point then then WebID falls back into place. Namely, here is a small protocol change which would make your BrowserId fall straight in line with WebID, and then you would gain a lot of new support.

  -once the relying party has verified the signature is correct, it can do
    * an http GET on the WebID if that is a http url
    * an webfinger lookup if it is an accnt url
    * ...
   take http, which is the simplest to understand:
   all that needs to return is a representation - JSON will do, (and in fact WebID is compatible with JSON formats as WebId is specified semantically see http://webid.info/spec/ )

  - if that representation contains an assertion to the effect that the user has the same public key corresponding to the private key he used to sign the blog, then you have authentication.

  That representation could or not, return an e-mail address to btw. So that the advantage is that you don't need to tell everyone about your e-mail address. Also because you are just doing a GET, nobody can tell what the purpose of the GET is: is it authentication, is it just a crawler, is it something else? Who knows. This gives your users more anonymity.

  So in essence by coming towards webid you don't use user friendliness, but you gain more anonymity - and you don't need to reveal an e-mail address to the Relying Party if the user does not want to.

  
  I hope that helps. Please let me know if I have missed the point. If the WebId part is not clear please look carefull at
the video on http://webid.info/ and the paper we presented at the Browser Workshop goes over the details in an easy language.

 http://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_22/webid.html

 Just remember that we can replace step 1-3 in the diagram there with http connections as you prefer, and we can replace step 3 with a json signed blob.


    Henry Story


Social Web Architect
http://bblfish.net/

Received on Friday, 15 July 2011 17:35:38 UTC