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

On 22 Apr 2013, at 00:16, Melvin Carvalho <melvincarvalho@gmail.com> wrote:

> 
> 
> 
> On 21 April 2013 15:18, Henry Story <henry.story@bblfish.net> wrote:
> 
> On 17 Apr 2013, at 21:20, Manu Sporny <msporny@digitalbazaar.com> wrote:
> 
> > On 04/16/2013 02:41 PM, Melvin Carvalho wrote:
> >> I just read:
> >> https://hacks.mozilla.org/2013/04/web-payments-with-payswarm-identity-part-1-of-3/.
> >>
> >> Of the four points listed below, where does WebID+TLS fall short?
> >>
> >> 1. It must be decentralized. 2. It must support discoverability by
> >> using a resolvable address, like a URL or email address. 3. It must
> >> support, with authorization, arbitrary machine-readable information
> >> being attached to the identity by 3rd parties. 4. It must be able to
> >> provide both public and private data to external sites, based on who
> >> is accessing the resource. 5. It must provide a secure digital
> >> signature and encryption mechanism.
> >>
> >> I think it's perhaps (5)
> >>
> >> Also iirc (and I could be wrong on this) the UX for WebID + TLS
> >> using client certs was not considered optimal for users with limited
> >> technical knowledge ...
> >
> > Hi Kingsley, Jürgen, Melvin,
> >
> > You will notice that the Web Keys spec builds on a number of the good
> > parts of WebID while stripping out the bad parts of WebID.
> 
> Hi Manu, I don't think you have been following the evolution of WebID
> for a couple of years now, and your initial implementation was not a
> WebID over TLS implementation at all. We now have a couple of specs:
> 
> "WebID 1.0: Web Identity and Discovery"
> https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html
> 
> "WebID-TLS"
> https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/tls-respec.html
> 
> The Cert Ontology
> http://www.w3.org/ns/auth/cert
> 
> A wiki project for Web Access Control:
> http://www.w3.org/wiki/WebAccessControl
> 
> 
> >
> > 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.)
> 
> Could you expand on why you dont think it's decentralized?

I'd need to know more about the protocol to be precise. 

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.

So there seems to be security issues and centralisation issues. 

I understand that Manu who wants web payements really wants access to a public key to do signing.
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.... 


>  
> 
> > 2. Uses URLs to identify things.
> > 3. Uses Linked Data to express information.
> 
> 1,2,3 are part of WebID 1.0.
> You could use that.
> 
> > 4. Access Control Lists via public/private crypto.
> 
> That's part of WebAccessControl, and it's independent of authentication.
> 
> >
> > The bad parts of WebID:
> >
> > 1. No explanation of how to do digitally signed messages.
> 
> Well that was out of scope. If you want to start a working group on that,
> I don't think it would be incompatible with what we have produced.
> 
> > 2. No explanation of how to encrypt messages, deferring to TLS
> >   instead (which may not always be available).
> 
> That just something to add on top.
> 
> > 3. No URLs for keys, making it non-trivial to figure out which key
> >   signed a message.
> 
> Why do you think one cannot have URLs for keys?
> 
> > 4. Expression of modulus and exponent in raw form, making it difficult
> >   for developers to feed those values to common encryption libraries.
> 
> Something that would be easy to add. But I'll let you push for a Working Group.
> 
> > 5. Key registration is not covered in the specification.
> 
> That can be done by LDP.
> 
> > 6. Unnecessarily coupled with TLS client-cert protocol.
> 
> Not at all. The WebID 1.0 spec makes no mention of TLS. The WebID over
> TLS spec mentions TLS of course. But that should not be surprising.
> 
> > 7. Bad UX using client certs with browser makers not committed to making
> >   the experience better.
> 
> The UX is a lot better than you think.
> 
> Other ways of doing it tend to make it very easy to create phishing attacks.
> Security has to be in the Chrome.
> 
> >
> > The parts that don't exist in WebID, but do exist in Web Keys:
> >
> > 1. Creating digital signatures for JSON-LD-based messages is covered.
> > 2. Encrypting JSON-LD-based messages is covered.
> > 3. Using a Web Key to do digital signatures for HTTP requests is
> >   covered (HTTP Signatures), allowing you to do digitally signed
> >   GETs on resources.
> > 4. Keys can have URLs, and owners - for example:
> >   https://dev.payswarm.com/i/manu/keys/1 is owned by
> >   https://dev.payswarm.com/i/manu
> 
> Not sure why you think that can't be done with WebID.
> 
> > 6. Key generation and registration is covered in the specification.
> 
> Key generation in WebID is covered by HTML5.0. And we have a section in
> the spec on it:
> https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/tls-respec.html#the-certificate
> 
> 
> > 7. TLS is never required for Web Keys clients (but is required for Web
> >   Keys servers). No dependence on client-side certs (which are hard to
> >   install and manage for beginners).
> 
> They are in fact easy to manage and insert for beginners. We have a lot
> of demos of this.
> 
> > 8. Keys are expressed using PEM-encoded form, making them easy to
> >   drop into most common cryptography libraries.
> 
> Does not sound like a big deal to me. Could be easy to add, but would
> just make implementations more complicated.
> 
> >
> > We did try to build PaySwarm on top of WebID in the beginning. When it
> > became apparent that there were issues with the WebID protocol that made
> > it impossible to build a payment solution on top of it, we came back to
> > the community with several change requests that were eventually rejected.
> >
> > Since we needed a solid identity solution for the Web Payments work, we
> > decided to take the good parts of WebID and use it as a basis for what
> > eventually became Web Keys.
> >
> > The Mozilla Hacks post on identity only covered the requirements at a
> > high-level. The items above are really what we needed from an identity
> > solution for Web Payments. Hope that explains it in a bit more detail,
> > if you'd like me to elaborate on any of the points above, please let me
> > know and I'd be happy to do so.
> >
> > -- 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/
> 
> 

Social Web Architect
http://bblfish.net/