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

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.

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