Re: Browser ID

Ben Adida wrote:
> On 7/15/11 1:47 AM, Kingsley Idehen wrote:
>> Remember, WebID is URI rather than HTTP URI based. It too works fine
>> with mailto: scheme URIs.
> 
> Sure, but that doesn't solve the problem we're trying to solve.
> 
> We see web sites asking for email addresses. Even after you do OpenID, 
> they want an email address. We see users understanding quite well that 
> emails represent personas. They have their work email, and their home 
> email.
> 
> So, we want to build a protocol where web sites *always* get a valid 
> email address. Not a URI that could be an email address.

Makes sense, and upon seeing BrowserID it was my first thought. 
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.

>> I assume WebFinger is still part of the email verification protocol that
>> underlies BrowserID? I ask because this is the most important point of
>> integration between WebID and BrowerID.
> 
> In fact, we're about to phase it out. Not because we want a different 
> discovery mechanism (that would be silly), but because we want very 
> short-lived keys and we currently don't want to depend on revocation.
> 
> 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.

>>> and we're using JSON-based assertions and certs (JWS and JWT) to keep
>>> things very simple.
>>
>> Do you mean "simply simple" or "deceptively simple" ?
> 
> I'm not quite sure I understand the implications behind each term, so 
> I'd rather we spell them out lest we misunderstand each other.
> 
> "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?

>> For the record, "simply simple" doesn't scale,
>> never has, and won't break the mould now.
> 
> I would disagree with the above statement. Simple is the only thing that 
> has ever worked on a large scale.
> 
>> Thus, please take this
>> opportunity to lay down vital integration hooks re. WebID.
> 
> I'm going to be blunt here: integration with WebID is not a use case. If 
> integration with WebID helps our use cases, we'll happily consider it, 
> of course. So, what would it get us? What would we lose? Help me 
> understand those points.

The ability to work stateless, tls on the wire forced, and the benefits 
of open profiles with an easy extension mechanism, whilst perhaps not 
vital for the common use case, could add nice features and a good level 
of open and easy extensibility.

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.

Best,

Nathan

Received on Friday, 15 July 2011 23:05:55 UTC