Re: Browser ID

On 7/16/11 6:20 AM, Ben Adida wrote:
>
> 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.

WebID does it in the network security and data layer. Where Linked Data 
== data layer. When a profile associates a public key with a WebID it is 
straddling two layers in an ultra powerful way courtesy of trust logics.
>
> 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.)

Translation: we are back to Application vs Data vs Network Layer. You 
are saying an Application Layer oriented solution matches a Data + 
Network layer hybrid. I utter disagree since the trust logics aren't 
backed into the Application Layer solution and the solution isn't 
implicitly flexible. Simple != Flexible. If this solution includes an 
option to leverage WebID this deficiency vaporizes.

Please understand, all I am seeking here is for the architecture of this 
solution to be "deceptively simple" i.e., developers can start simple 
but be pleasantly surprised as what they perceive as edge cases (e.g. 
Peter Parker or Spiderman) arise re. personas, identity, and privacy.

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

Try to see it :-)

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

But this won't be the case.

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

WebID is 100% AWWW. If BrowserID steps back from dropping Webfinger as 
an option for verification protocol you're basically set. Just give 
developers options, many are more capable that is typically assumed re. 
Web. Remember, the Web was built using existing technology developed by 
programmers/developers. Good architecture is about flexibility. Never 
compromise flexibility, there is no degree of simplicity that trumps 
implicit and inherent flexibility.


>
> -Ben
>
>


-- 

Regards,

Kingsley Idehen	
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen

Received on Saturday, 16 July 2011 16:29:36 UTC