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

On 22 Apr 2013, at 05:04, Manu Sporny <msporny@digitalbazaar.com> wrote:

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

Ok. So it's all differnt. Looks like you have missed the evolution 
in WebID which is close to where it was, but is now all the stronger
from the evolution of Linked Data Protocol and Turtle standardisation, 
and I have missed the evolution of your technology, which has nothing
to do with what it was 2 years ago.

Still I wonder why you attacked WebID if WebKeys has nothing to
do with browser based 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).

I did study BrowserID carefully
http://security.stackexchange.com/questions/5406/what-are-the-main-advantages-and-disadvantages-of-webid-compared-to-browserid

I did not study WebKeys carefully. I'll let the community do that,
and if it gets traction I'll look at it more carefully.

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

There is a working group that started 2 years ago which I urged you to join
http://www.w3.org/TR/WebCryptoAPI/

Seems like there is some movement there.

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

In the web of data the UI is of no concern. And WebID is going to be very
important in that non UI space. Having a protocol run by JS seems like the
road to hell to me. 

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

Social Web Architect
http://bblfish.net/