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

On 22 April 2013 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.
>

+1 Henry, it would be good if you could read the links supplied, before
offering critical comment on the technical details or asking for explanation


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

Agree that the Persona UI is very good.  How does it fit in with.

"It must be designed to work with Web architecture like URLs, HTTP, and
other Web standards."

I thought Persona is currency email based.  I chatted to Tim Berners-Lee on
this topic at TPAC and he suggested trying to explain to the Persona team
that supporting HTTP URLs would facilitate additional work.

Currently, WebID as identity is simply using HTTP URLs to identify Agents
(as is popularly demonstrated by facebook).  So it seems WebID (identity)
is compatible with the payswarm specs.

The WebID+TLS spec (which you originally authored) is a separate work from
the Identity


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