W3C home > Mailing lists > Public > public-webid@w3.org > April 2013

Re: Webkeys, OpenID, WebID, OAuth etc..

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Sun, 21 Apr 2013 23:04:02 -0400
Message-ID: <5174A8A2.1050600@digitalbazaar.com>
To: Henry Story <henry.story@bblfish.net>
CC: Melvin Carvalho <melvincarvalho@gmail.com>, Read-Write-Web <public-rww@w3.org>, Web Payments CG <public-webpayments@w3.org>, public-webid Group <public-webid@w3.org>
On 04/21/2013 06:33 PM, Henry Story wrote:
>>> The good parts of WebID that also exist in Web Keys: 1.
>>> Decentralized design.
>> 
>> (I doubt you really have that, which is the problem I always had 
>> with your protocol. You can't have decentralised design as long as 
>> javascript cryptography is not in the browser and done correctly,
>> and there is a lot of pushback to doing it correctly. As a result I
>> would bet that your system like BrowserID _seems_ decentralised but
>> is not really.)

Wait... what's not decentralized about BrowserID? Are you talking about
the current implementation not being decentralized, or the final
protocol? There is a big difference there and you're making it seem as
if they're one and the same. Please be specific instead of throwing
claims like this out there.

Henry Story wrote:
>> (I doubt you really have that, which is the problem I always had 
>> with your protocol. You can't have decentralised design as long 
>> javascript cryptography is not in the browser and done correctly,
>> and there is a lot of pushback to doing it correctly.
>> 
> Melvin wrote:
>> Could you expand on why you dont think it's decentralized?
> 
> I'd need to know more about the protocol to be precise.

Please stop doing this. Don't say you doubt a design is decentralized
and then state that you don't know enough about the design to state
whether or not it is decentralized.

Instead of reading the material on Web Keys, it seems like you have
assumed that it is based on the JavaScript-based WebID over TLS
implementation that we did two years ago.

The JavaScript-based WebID over TLS implementation that we did two years
ago has almost nothing to do with Web Keys. Web Keys has nothing to do
with client-side certificates, nothing to do with local storage, nothing
to do with Flash, nothing to do with Web Sockets, and nothing to do with
browser-based website login.

> But at an architectural level if you don't use the keystore in the 
> browser, then you must store the private key somehwere. Where? If you
> do it in the local browser store, then apart from it being insecure
> you have a problem with the same origin policty, that would allow 
> only javascript from your home server to access the key material. So
> if you go to another server it would not be able to know what your
> key material is or that you even have any. So how would it know what
> your server is in order to be able to interact with it? The only way
> would be for you to type that in somwhere - so at that point you have
> a UI that is already more complex that WebID-TLS since you have to
> type, and not just click.  Web Servers therfore as with BrowserID
> need to point their login code to some generic server - which is
> where the centralised piece comes in.

It doesn't sound like you understand Web Keys (you are assuming that you
do instead of reading the specs or the Mozilla Hacks tutorial) and you
probably don't understand Browser ID (based on this and other erroneous
statements you've made about the protocol).

> But the solution there is to petition the JS Cryptography group so
> that they can use X509 key material for signing.... But then you may
> as well also ask for UI improvements....

You have been saying this for the past two years. We said that
petitioning the browser vendors for UI improvements to the client-based
certificate UI was a non-starter for the browser vendors. The browser
vendors have done almost nothing to improve that experience in the past
two years, which we predicted would happen. It's not the state that we
would like, but the browser vendors are more likely to adopt something
like Persona at this point than improve their client-side certificate UI.

Persona currently supports single sign-on for hundreds of millions of
e-mail addresses. I don't think WebID penetration is anywhere even close
to that.

That's the state of affairs right now and Web Keys is aligned for a
future where Persona, or something Persona-like, ends up taking hold of
the market. It's going to happen because the Persona folks put the UX
first and built the technology out from there, not the other way around.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Meritora - Web payments commercial launch
http://blog.meritora.com/launch/
Received on Monday, 22 April 2013 03:04:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:54:43 UTC