Re: Proof of Concept: Identity Credentials Login

On 6/16/14 11:50 AM, Dave Longley wrote:
> On 06/16/2014 09:47 AM, Kingsley Idehen wrote:
>> >As I keep on saying, we have two browsers that have the problem:
>> >
>> >1. Chrome -- it interacts with the keystore via OS provided APIs but
>> >doesn't emulate Safar or IE re. TLS session handling (they can fix that,
>> >and they will fix it)
>> >
>> >2. Firefox and Opera -- both of these use their own keystore rather than
>> >providing an option to work with the native OS keystore via existing
>> >APIs provided by respective operating systems.
> If that's the only problem, how long do you predict it will take for
> WebID+TLS to be widely adopted (by the general Internet public) once
> it's fixed?

I can't predict that for sure. What I can predict is that the confluence 
of Identity and Privacy issues will bump up the priority levels 
associated with TLS related bugs in browsers, especially in regards to 
UI and UX.

As I've stated, Apple and Microsoft don't have these issues across 
Windows, Windows Mobile, Mac OS X, and iOS.

> You also indicated before that you think Chrome (Google)
> will feel pressure to fix this problem. When do you predict it will be
> fixed?

As the "opportunity costs" become more and more palpable. Google can't 
afford to ignore this matter, especially when it reeks of competitive 
disadvantage re., Chrome as a user agent offering etc..

Ironically, the fix for Chrome is quite simple: emulate Safari in 
regards to how it interacts with Keychain. Note, Chrome is already using 
Keychain (on Mac OS X) and Keystore (on Windows) APIs to interact with 
the OS keystore, its just failing to hand TLS session management the 
right way.
>
>> >
>>> >>
>>> >>Again, this is a subjective statement, but we're saying it because we're
>>> >>not willing to bet our company on the current WebID+TLS login flow
>>> >>(because we think it's too "techy" for the masses and because we don't
>>> >>think browser companies are that interested in fixing the UX for the
>>> >>purposes of WebID+TLS).:)
>> >
>> >This isn't about "betting a company" on anything though, its supposed to
>> >be about constructing a spec where all the key components are loosely
>> >coupled and based on open standards, without prejudice:-)
> A system that does everything WebID+TLS does*and*  doesn't require
> browser implementations (to become a popular success) is more loosely
> coupled and has less prejudice, IMO.

That's in place. Browsers (e.g., Chrome and Opera) are simply skewing 
existing OS reality via their current implementations.

> That's the system we're supporting
> as an alternative to WebID+TLS. Concepts from WebID (not WebID+TLS) are
> included in this alternative, because they don't suffer from the same
> issues (tight-coupling w/browser UIs) that WebID+TLS does.

WebID-TLS isn't bound to Browsers. If it was it would be called 
WebID-Browser-TLS. Basically, Its a tweak to TLS.

It just so happens that you have the Browser and OS APIs sitting between 
users and TLS when interacting over HTTPS with servers.

-- 

Regards,

Kingsley Idehen 
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen