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

Re: Proof of Concept: Identity Credentials Login

From: Dave Longley <dlongley@digitalbazaar.com>
Date: Mon, 16 Jun 2014 11:50:13 -0400
Message-ID: <539F1235.5000506@digitalbazaar.com>
To: public-webpayments@w3.org
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? You also indicated before that you think Chrome (Google)
will feel pressure to fix this problem. When do you predict it will be
fixed?

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


-- 
Dave Longley
CTO
Digital Bazaar, Inc.
Received on Monday, 16 June 2014 15:50:36 UTC

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