Re: Browser ID

Hi Nathan,

Thanks for your note.

> Generally speaking it seems at a non technical level, that BrowserID is
> a nice abstraction layer on top of WebID, that makes it more user friendly.

Right, at a non-technical level, but if you dig into the technical 
details, the big difference is that BrowserID delivers an assertion in 
the application layer, while WebID delivers it in the network security 
layer.

No doubt that WebID delivers a more hardened solution, but also one that 
is much harder for server-side developers to tap into. (Probably not so 
hard when you're doing development and you've got the whole stack just 
an API call away, but much harder when those layers start existing on 
different machines.)

As per my previous email, I sense that this will create difficulties 
much like Digest Auth.

>> We're trying to solve a very thin problem: login. I don't think we
>> need to build that on stable, long-term keys, as crypto tokens with
>> long validity periods create all sorts of problems when users lose
>> devices, etc.
>
> I agree, but if they could be added with next to no cost, preferably
> behind the interface, then it may be a good addition.

Do you mean assertions for stuff other than logging in? Maybe, as long 
as we're not reusing keys for different purposes. There *is* a risk to 
expanding the scope of a given key, or to enabling longer-lived certs 
for the same scope.

>> "Simple for the developer" is very important. Of course, there is a
>> lower bound if you want to be secure, but we want to get closer to
>> that simplicity lower bound than other technologies have done so far.
>
> Perhaps layers of abstraction, and different layers one can interface at?

I don't see it yet, because of the stack issue mentioned above.

> The ability to work stateless, tls on the wire forced,

Stateless... at the app layer you mean? Right, we're back to playing 
with different layers of the stack. The flipside of that coin is as 
above: harder for implementers.

> and the benefits of open profiles

Open in what sense? Access? Not good. Data model? Good. We're not there 
yet, though. We're only certifying the federated identifier.

> If BrowserID/WebID can be merged and become an single adequate and long
> term login/auth solution, then it would perhaps be better than yet more
> different and competing solutions - at the end of the day, it's users
> who will pay the price of having to manage multiple login mechanisms and
> auths.

I hear you, but if the merger weakens the model (by having long-lived 
certs that require revocation) or complicates developers' lives, then 
those are significant downsides that could scuttle the whole effort.

Right now, I'm still seeing some fundamental differences, where the same 
property is something WebID sees as an advantage, while BrowserID sees 
it as a problem.

-Ben

Received on Saturday, 16 July 2011 05:21:18 UTC