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

On 22 April 2013 00:22, Melvin Carvalho <melvincarvalho@gmail.com> wrote:

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

Typo: I *cant* 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/
>>
>>
>