W3C home > Mailing lists > Public > public-webpayments@w3.org > April 2013

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

From: Dave Longley <dlongley@digitalbazaar.com>
Date: Sun, 21 Apr 2013 22:53:40 -0400
Message-ID: <5174A634.80307@digitalbazaar.com>
To: Henry Story <henry.story@bblfish.net>
CC: public-webpayments@w3.org
On 04/21/2013 05:26 PM, Henry Story wrote:
> On 21 Apr 2013, at 23:26, Dave Longley <dlongley@digitalbazaar.com> wrote:
>> On 04/21/2013 03:15 PM, Henry Story wrote:
>>> On 21 Apr 2013, at 20:17, Dave Longley <dlongley@digitalbazaar.com> wrote:
>>>> On 04/21/2013 09:18 AM, Henry Story wrote:
>>>>> ... your initial implementation was not a
>>>>> WebID over TLS implementation at all.
>>>> This is false and perhaps even inflammatory at this point. We've had this discussion many times; each time you were disinterested in understanding the implementation we did. However, your disinterest had nothing to do with the technical merits of the implementation or its adherence to how WebID over TLS was described at the time.
>>>> Our implementation was of a TLS client that used a TLS client-side certificate with an alternate name that was a URL that the authentication server accessed to obtain the same public key in the client-side certificate given during the TLS handshake.
>>> Ah I remeber. One part of it was WebID over TLS, with javascropt implementation of TLS. But not having access to the X509
>>> certificates you had to build a very complicated non decentralised protocol around it.
>> You still don't understand how it worked. Of course there was access to the X.509 certificates -- and they were managed by your WebID provider -- which, by the way, could have been any server you wanted, whatsoever. In other words, your false claim about a "very complicated non-decentralized protocol" is still rooted in your continued disinterest in understanding what we implemented.
> Can you find a mail where you publically explained how this worked?

Yes, I can find those and so can you. Search the foaf-protocols list, 
for instance. There are even some emails that may have been sent just to 

Here's the main disagreement I have with your approach and continue to 
have: I believe that replacement technologies (such as WebID) are rarely 
adopted wholesale. Usually, you need to have a smooth transition away 
from the way things currently are; a clean break just isn't likely to 
happen. You can talk all you want about how great things would be if 
everyone just used WebID, exactly as intended, today. But that's not how 
these things typically work; you have to provide a path for people to 
ease into using your new technology. That means accepting 
"imperfections" along the way... exactly because you are applying a 
gradient, moving from old technology to new. The WebID implementation we 
provided you with (open source) was one such path to helping getting 
WebID adopted -- it wasn't the end-game and was never intended to be.

>> Please remember that your disinterest was not due to a lack of us trying to explain it to you either. Rather, you saw no value in what we created because you were dismissive of the argument that an alternative was needed to, what we consider, a poor browser certificate management UX. I remain unconvinced that WebID is going anywhere without an improved browser certificate management UX or some kind of polyfill (we which happily implemented to help you) in the meantime. This, clearly, was a great point of frustration for us in trying to help the WebID work be successful.
>>> I am not sure where the crypto in
>>> the browser stuff is going, but that's the only hope for that type of approach. And since that was not finished, we did
>>> not make it our priority.
>>> Of course you have a different use case. But for that the certificate ontology could still be useful.
>> WebID will not be widely adopted with the current UX limitations it depends on. Feel free to continue to think differently at your own peril. That is my opinion. I honestly had hoped for its success and tried to be a part of getting around what I thought was its greatest roadblock.
>>>> -Dave
>>>> -- 
>>>> Dave Longley
>>>> CTO
>>>> Digital Bazaar, Inc.
>>> Social Web Architect
>>> http://bblfish.net/
>> -- 
>> Dave Longley
>> CTO
>> Digital Bazaar, Inc.
> Social Web Architect
> http://bblfish.net/

Dave Longley
Digital Bazaar, Inc.
Received on Monday, 22 April 2013 02:52:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:03:31 UTC