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

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.

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.

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/

Received on Wednesday, 17 April 2013 19:20:37 UTC