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

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

Keys *can* have URLs as per the cert ontology.  They can be blank nodes
too, which I think is currently more common.  I use a URL.


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

Since TPAC 2012 we have decided to decouple WebID into Identity and
Authentication specs.


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

Currently the cert ontology is able to related a key to a foaf : Agent via
the "key" predicate.  It cannot (yet) do accounts, though I requested it
last month, but coming to consensus on how to name things can sometimes be
a challenge :)

Do you need the agent -> key relationship or the account -> key
relationship, or both?


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

It seems both efforts have evolved in the last couple of years.  And sounds
like there's a lot in common still, maybe it's still possible to iron out
the differences ... so that each can reuse from the other.


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