Re: Browser ID, WebID & URLs

On 7/17/11 9:37 PM, Henry Story wrote:
> 
> The goal of both is to have global and distributed authentication. As 
> far as that goes the goals are the same. 

Right, the difference is that we're trying to start with the simplest
layer, you're trying to build the distributed social network up front.

> Btw. for BrowserId to function in a distributed way it will require browser 
> support, right? Or can it already function that way?

To be *truly* distributed, it will require browser support. But it will
be pretty close to fully distributed with just browserid.org as a
passthrough domain for certificates.

> There is a problem with javascript being able to access only one site at a 
> time if I understand correctly.

Right, but with postMessage() and browserid.org doing coordination,
we're in good shape. Also, the relying parties will *not* have to change
their code to inherit browser support. The JS library turns itself off
once it detects that the browser natively supports the API.

> I am all for keeping things simple, btw. But this is a big browser change that
> it being put through, with security implications, and so I imagine that being
> able to enable one more use case may be a good thing for adoption.

Actually, it's exactly the opposite. Simple, targeted changes are *much*
easier to deploy than larger changes with bigger attack surfaces.

>> User profiles are great, but I don't think they should be required,
> 
> They are not required in WebId. 

Hmmm, don't you have to have a public URI? Isn't that what Kingsley was
saying?

> Services that don't control the e-mail, such a Social Web services - including
> Facebook, and others - won't find this very helpful then.

Ah, because you're thinking that we want Facebook to certify your
bblfish.net address. That's not really it. Facebook is already doing
email. You can claim your @facebook.com email address now. So we hope
that Facebook will eventually certify their users for @facebook.com,
over which they, of course, have authority.

> sending e-mail addresses out can be a spam problem.

Users are sharing email addresses with web sites *anyways*.

> A URL which verifies
> a public key and has a bit of optional metadata - name for example - allows
> protection from that type of spam.

Ah, so now we're back to a public profile?

> It is not a baseline to WebID either. It just enables it. 

Now I'm really confused. Is there a public URI or not?

> You seem to have made short lasting keys a necessary part of your protocol.
> Why is that? I am pointing out one can enable longer lasting ones too.

Because long-lasting keys require adding revocation to the protocol, and
we don't want to go there because it's gnarly.

> I don't think it says anywhere that BrowserId is not meant to have browser support.
> It just says that implementing security correctly is  a lot of work and that the TLS
> layer in the browser has been there for a while. So BrowserID support in the browser will
> have to be implemented very carefully.

Which is why we're keeping things extremely simple for now.

We don't think we can effectively reuse TLS while meeting our
requirement that relying parties should have a very easy job.

> I don't argue that JavaScript is insecure. But it is true that any
> extra layer adds complexity which creates potential holes.

Agreed, but if we (the browser vendors) take on the complexity, it's
much better than asking every RP to take it on. Compare the complexity
of BrowserID to WebID for relying parties, I think it's clear BrowserID
is simpler.

> Yes, I like the experiment. It's a very good idea, and in fact I have said so
> in a number of places. WebID can learn from your work. (I hope you don't mind?)

Of course I don't mind!

> By enabling your work in the TLS space we gain some other very interesting use 
> cases.

Yes, I can see that. So far, I don't see that approach as meeting our
requirements, but if what we're doing can help other use cases, that's
fantastic.

>> We have different requirements.
> 
> Not sure we do.

At the very least we have different sub-requirements. You want to
leverage TLS client-side certs. We specifically don't.

[...]

> Well WebId does not have any notion of longer or shorter lived keys.
> The certificate says how long they are valid for, full stop. They can 
> be longer or shorter.

Right. We want to specifically rule out longer-lived certs for our
application, because otherwise we have to build in revocation. Now, of
course our data formats don't rule it out. But our logic certainly will
for the time being.

> Well yes, that ok. But you do seem to empasize the non-collaboration all
> the time.

Because I'm hearing comments that sound like "obviously we should
collaborate." It's not obvious, and in fact it may hurt both efforts.
There are a dozen ways of slicing the authentication pie. We're trying
one way, and we want to see how far it goes before we complicate.

> Could it also be the other way around that we should perhaps also
> accept the conclusion that we might benefit from collaboration, were it to
> be justified?

Of course, but so far I'm seeing lots of conflicting approaches.

> What are the different sets of requirements?

We can start with the two very important ones:

(a) we think TLS is wrong for RPs, you think it should be leveraged.
(b) we think relying parties should always get an email address (or at
least we're not trying to address the use cases where they don't need
one), you think it's optional.

-Ben

Received on Tuesday, 19 July 2011 02:56:41 UTC