Re: Proof of Concept: Identity Credentials Login

Kingsley,

Google have already decided that U2F is the way to go and their somewhat
"sheepish" followers including Microsoft, EMC/RSA, ARM, VISA, and PayPal,
have (in the absence of a better alternative), nothing else to do but
embracing it.

U2F also have links to WebCrypto which no other tech out there have.

I'm sorry to say but neither WebID-TLS nor Identity Credentials Login
look like viable schemes under these circumstances.

That I find U2F crippled and featuring a fake notion of privacy doesn't
matter, questioning Google's supremacy in web-tech is true heresy.

Anders

On 2014-06-18 15:44, Kingsley Idehen wrote:
> 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
>
>
>
>

Received on Wednesday, 18 June 2014 14:20:07 UTC