Re: Browser ID

On 7/15/11 5:46 PM, 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.

Yes, and nothing I've said or implied re. URIs is contrary to what 
you've stated above, not a single thing.

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

Translation: you want to build a protocol that based mailto: scheme URIs 
since they are intuitive identifiers for personas.

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

But I don't see how you loose that via Webfinger+WebID. An IdP can 
produce long or short term X.509 certificates. You can even use 
relations in a profile graph to express additional semantics re. life 
time and validity of keys. Not of this needs to burden end-users since 
this would be IdP functionality. Most WebID based IdPs already possess 
this capability.

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

Your problem isn't out of scope re. WebID. Authentication isn't 
monolithic re. age of keys.

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

Yes, but it doesn't have to be simple at the expense of flexibility 
(future expansion). A "simply simple" solution is lightweight, specific, 
and inherently inflexible re. future use-case scenarios.

WebID is "deceptively simple" meaning: it is a powerful bridge (e.g., to 
what you are trying to build re. BrowserID) while also flexible enough 
to handle future scenarios where people ultimately construct more 
complex policies re. verifiable identities. For instance, how Peter 
Parker and Spiderman personas can exists, appear, and operate concurrently.

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

Yes, but you can do this without compromising the ability to deal with 
more complex scenarios as they arise. Leveraging AWWW which basically 
means bridging to WebID (which is 100% AWWW DNA) ensures that, and it 
does without you guys doing anything bar commitment to architecture that 
bridges to AWWW. Basically, base your effort on resolvable URIs (in this 
case mailto: scheme with Webfinger as resolution protocol).

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

The WWW is "deceptively simple" because its 100% AWWW. Its the most 
scalable, flexible, and successful system in the history of mankind, as 
far as I know :-)

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

I am going to be blunt back: what was the use case for the WWW?

> If integration with WebID helps our use cases, we'll happily consider 
> it, of course.

WebID 100% AWWW which means its 100% as potent as the WWW. Basically, it 
makes the WWW better, and without disruption since this is all about 
AWWW DNA.

> So, what would it get us? What would we lose? Help me understand those 
> points.

What you get is a system that solves your short term problem via mailto: 
scheme URIs. You also inherit the ability to deal with longer term 
issues and complexities as exemplified by the: Peter Parker and 
Spiderman personas scenario. All of this happens in distributed fashion.

To quote you: its hard to bootstrap distributed solutions. Thus, why not 
bootstrap in such a way that the centralized system is a natural conduit 
to a more sophisticated and distributed solution. Its just a game of 
architectural lego re. AWWW, no more, no less. We can pull this off!


>
>
> -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 15:12:45 UTC