- From: Dave Longley <dlongley@digitalbazaar.com>
- Date: Mon, 16 Jun 2014 11:50:13 -0400
- 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