Re: WebID+TLS Spec was (Re: Signed WebID documents and trust wrt GPG Web of Trust)

On 29 May 2013 17:31, Henry Story <henry.story@bblfish.net> wrote:

>
> On 29 May 2013, at 16:16, "Andreas Kuckartz" <A.Kuckartz@ping.de> wrote:
>
> > Henry Story:
> >> In any case Manu did not participate in any of the work for the past 3
> years or so, and
> >> has publically been critical of WebID.
> >
> > That he has publically been critical of WebID should be *irrelevant*
> > regarding the question if he should be mentioned as a (former) editor in
> > the document.
>
> Indeed if that were the only reason for him not being listed as an
> author that would not be enough of a reason. Which is why I put
> forward the fact that he has not participated in either the authorship
> or editorial work of the Incubotor group or community group, and that
> his contributions were over only a very short period of time.
>

IMHO Manu's comments were reasonable.  He simply explained why he was
unable to use WebID for payments.  While not everything is correct asof
today, I think he gave some fair and valid feedback.  He also emphasised
the good parts of WebID.

I would actually say the reverse is true, that conversation broke off where
Henry was critical of Manu's work, tho admitted he had not taken the time
to read it.

Text repeated beneath for convenience...

[[
The good parts of WebID that also exist in Web Keys:

1. Decentralized design.
2. Uses URLs to identify things.
3. Uses Linked Data to express information.
4. Access Control Lists via public/private crypto.

The bad parts of WebID:

1. No explanation of how to do digitally signed messages.
2. No explanation of how to encrypt messages, deferring to TLS
   instead (which may not always be available).
3. No URLs for keys, making it non-trivial to figure out which key
   signed a message.
4. Expression of modulus and exponent in raw form, making it difficult
   for developers to feed those values to common encryption libraries.
5. Key registration is not covered in the specification.
6. Unnecessarily coupled with TLS client-cert protocol.
7. Bad UX using client certs with browser makers not committed to making
   the experience better.

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
6. Key generation and registration is covered in the specification.
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).
8. Keys are expressed using PEM-encoded form, making them easy to
   drop into most common cryptography libraries.

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


>
> Henry
>
>
> > Cheers,
> > Andreas
> >
>
> Social Web Architect
> http://bblfish.net/
>
>