Re: Proof of Concept: Identity Credentials Login

On 6/18/14 10:19 AM, Anders Rundgren wrote:
> 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.

Again, it doesn't matter. WebID-U2F is just a bridge that brings WebIDs 
to this protocol. Many protocols isn't a problem. This isn't about 
winners and losers, its about infrastructure for effective computing, 
via the infrastructure provided by the Internet and Web.

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

Not to me. We don't need to conflate architecture and marketing :-)

I've seen this movie a zillion times, the outcome is always the same. 
Don't bet against open standards.

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


-- 

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