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

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

There has been discussion for many years about whether to use PEM or the
modulus/exponent.  See for example this thread from 2010:

http://lists.foaf-project.org/pipermail/foaf-protocols/2010-September/003603.html

However modulus/exponent is RSA oriented.  Meaning DSA and particularly
ECDSA keys which have proven so popular in payments are largely
incompatible.  Could a DSA key work with WebID + TLS, for example?  I think
the answer is no.

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