W3C home > Mailing lists > Public > public-webpayments@w3.org > June 2014

Re: Proof of Concept: Identity Credentials Login

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Thu, 19 Jun 2014 09:47:34 -0400
Message-ID: <53A2E9F6.4060007@openlinksw.com>
To: public-webpayments@w3.org
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.

> 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



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 Thursday, 19 June 2014 13:47:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:31 UTC