Re: Browser ID

On 7/15/11 10:34 AM, Henry Story wrote:
> WebID over TLS has a great security story to tell - which is getting
> more and more important.

Even if this were improved across the board (and that's a big IF), this 
requires web applications to tap into the network layer. That crosses 
protocol abstraction barriers in ways that have similarly made Digest 
Auth very difficult to implement by web developers. Often, they just 
don't have access to that part of the stack.

> 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.

For the reason mentioned above, mostly.

> 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.

Because that's the value we're delivering to the relying party: you get 
an email address. We've noticed that that's what web sites want.

> 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?

Again, because most web developers don't want to understand the general 
crypto stack, and we're trying to provide a very finely tuned feature.

  ( 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/
> )

Exactly.

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

I disagree. The server-side component can be quite gnarly. Have you 
investigated how this works if you use an SSL accelerator? If you use 
Amazon EC2's SSL load balancer? My sense is the abstraction layers get 
very gnarly.

Plus, what do you do for short-lived certs? We don't want to deal with 
revocation. Can you trigger cert re-generation automatically and 
silently? I don't think so.

> [ • 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.

No, not self-signed. That description is faulty, I think. Thanks for 
catching the bug :)

> Notice that you could easily extend this to put a number of URIs in
> there, including a http/https URI.

Yes, but I'm not sure we want to. Again, the key that we must have is 
email address. Additional attributes, we're not sure yet how we want to 
send them along.

We want a certified email address. Not a self-certified one, one 
certified by the email provider. Self-certification is good in the key 
continuity sense, but how would it help a site trust that the email 
address you claim to have is indeed yours?

> 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.

Oh of course. That is the long-term plan. There's no point in the crypto 
otherwise. The reason we have this verifier service is because (a) it 
actually is too much crypto for folks to start using it quickly, and (b) 
we plan on changing the data formats and certification details, and 
don't want folks building their own verifiers just yet.

> 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.

I don't understand this. My assertions must contain email addresses. 
They must also be short-lived. I'm pretty sure I don't want to mix 
protocol layers (SSL + app logic). I get the sense these are fundamental 
differences that can't easily be resolved, unless we're willing to 
accept weakening those requirements. But that would do away with the 
whole point of the effort, which is to keep the login process very, very 
simple for users and developers.

> -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/ )

Which would mean a publicly accessible resource, including email address 
for every user. That's not a good solution, privacy-wise.

> 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.

That's not an advantage from our point of view. We've noticed that every 
web site wants an email address so they can contact you. So, in the end, 
not providing relying parties with an email address means they'll just 
ask the user right away afterwards, or not use that auth system in the 
first place.

I don't see us budging on that property.

(And if you want pseudonymity, we know how to do that with email aliases 
pretty easily, we can even do it on the user's behalf if they ask.)

> 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.

I don't buy that :) It's pretty clear what that GET means, even with a 
good bit of chaff.

> 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.

Yep, I was there, I saw the video. I'm pretty sure I understand it, 
although if you think my points above indicate otherwise, let me know.

-Ben

Received on Saturday, 16 July 2011 05:09:54 UTC