Re: Browser ID, WebID & URLs

On 18 Jul 2011, at 02:04, Ben Adida wrote:

> 
> Hi Henry,
> 
> I want to back up for a second: it may be that BrowserID and WebID
> simply have different goals.

The goal of both is to have global and distributed authentication. As 
far as that goes the goals are the same. 

> That's okay. We're not trying to be the
> authentication system to end all other authentication systems. We're
> pursuing an experiment to see if our hunch – that web sites just want
> an email address – is right. We believe additional layers can be built
> on top of this simple bootstrap, and importantly we don't yet see a
> reason to complicate the bootstrap.

Btw. for BrowserId to function in a distributed way it will require browser 
support, right? Or can it already function that way? If so how does that work? 
There is a problem with javascript being able to access only one site at a 
time if I understand correctly.

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.

> 
>>  - it gives the possibility of very rich "attribute exchange": rich semantically enhanced
>>     profiles.
> 
> User profiles are great, but I don't think they should be required,

They are not required in WebId. 

> and I still don't see a problem with using WebFinger to go from email
> to profile URL.

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

> Private exchange of an email address is privacy-
> protecting. Exposing a public profile is not. Thus, the public profile
> should be the optional component.

sending e-mail addresses out can be a spam problem. A URL which verifies
a public key and has a bit of optional metadata - name for example - allows
protection from that type of spam.

> 
>>  - linked data between friends - social networking at a global scale
> 
> Sure. But not as a baseline requirement for logging in. As an optional
> layer on top of login, yes.

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

> 
>>  - key revocation - allowing for longer lasting keys
> 
> I don't think this is an advantage. Crypto keys should be used for
> very specific purposes. Logging in does not require long-lasting keys.
> Encryption probably does, but of course you wouldn't want to reuse the
> same key for both activities. So on this we may simply disagree. We
> actively *don't* want long-lasting keys for this purpose.

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.

> 
>> Anyway, you may also want to consider my reply to this stackexchange questionhttp://bit.ly/pCNdUt
> 
> I have important disagreements with your points there, in particular
> they imply that BrowserID is not meant to have browser support,

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.

> or that JavaScript is inherently insecure.

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

> We are aiming for browser support, but we are starting with pure HTML because it's an
> experiment.

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?)
By enabling your work in the TLS space we gain some other very interesting use 
cases.

>> Together we can be a lot stronger than each on his own.
> 
> Not necessarily.

few things are necessarily true.

> We have different requirements.

Not sure we do.

> If we complicate both approaches because we want to work together, then the complexity might
> hurt us both.

I agree that it is a good idea to not try to do everything alone, and
to split things up. But also we should try to make it so that our work 
can complement each other. That requires taking time a bit to learn what
the other side is doing, and trying to make sure doors don't get closed
unnecessarily.

> For example, if you think long-lived keys are a good thing, and we
> think they're a bad thing, then it hurts us to enable them. Security
> and abstraction usually mix very poorly.

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.

> In other words, I think both groups need to be comfortable with the
> possible conclusion that there is no collaboration needed, and that's
> okay.

Well yes, that ok. But you do seem to empasize the non-collaboration all
the time. 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?

> I'm not closing the door on continued discussion, but I am
> saying that we should consider it a perfectly reasonable outcome that
> we might simply agree to go our separate ways for now. I wouldn't see
> this as a failure, rather I'd see two different experiments with
> different sets of requirements.

What are the different sets of requirements?

Henry

> 
> -Ben
> _______________________________________________
> dev-identity mailing list
> dev-identity@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-identity

Social Web Architect
http://bblfish.net/

Received on Monday, 18 July 2011 04:38:02 UTC