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

On 22 April 2013 00:17, Henry Story <henry.story@bblfish.net> wrote:

>
> On 22 Apr 2013, at 00:07, Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
>
>
>
> 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.
>
>
> Why do you think the answer is no, Melvin? I think it is possible to have
> X509 certificates with DSA keys.
>
> And even if here were not it would not be a problem to add DSA keys to the
> ontology. I
> Indeed Dominik  Tomaszuk added it to the mercurial repository recently
>
> https://dvcs.w3.org/hg/WebID/file/26c457f1bdc0/ontologies/cert.n3#l139
>
> We're looking for feedback from people with crypto + rdf ontology
> background.
>
> Improving the cert ontology like this in a way that makes sense is
> perfectly fine.
> (we've just been careful not to add to much, because we don't have the
> manpower).
> IF we could get a Working Group things would be easier.
>

Yes I do think that adding DSA to the cert ontology is a great step.  As
you know, I helped to patch this last month.

But the more difficult part is that the sparql in the webid+tls would then
have to change too.  Which means all of the implementations as well.  While
it's doable in the long term, it's far from straightforward today, I can
think of an implementation that could do it.



>
>
>
>>
>>
>> >
>> > 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/
>>
>>
>
> Social Web Architect
> http://bblfish.net/
>
>