Re: Deployment, Deployment, Deployment! was: X509 and Verificable Creds: A Quick Note on WebID history - Re: All the Agents Challenge (ATAC) at ISWC 2021

On 7/27/21 3:58 AM, Henry Story wrote:
>
>> On 26. Jul 2021, at 16:18, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>>
>> On 7/25/21 5:22 PM, Henry Story wrote:
>>>> On 25. Jul 2021, at 21:37, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>>>>
>>>> On 7/24/21 3:44 PM, Henry Story wrote:
>>>>> A proof is that it took 10 years to get to the point where credentials
>>>>> could replace X509 certificates, and it is actually not quite there yet,
>>>>> as we need RDF canonicalization, which will take another 3 years.
>>>> Hi Henry,
>>>>
>>>> Why is X.509 Certificate replacement important? Personally, I've always
>>>> felt its ubiquity enables one solve Identity challenges by simply
>>>> hooking in the magical powers of resolvable URIs.
>>> Indeed the extremely wide deployment of X509 is its major advantage.
>>> That is why we used it with WebID-TLS. Every browser from around 1999
>>> had a built in keystore for X509 certificates tied to TLS that allowed
>>> client authentication.  The wide deployment of this technology with
>>> the hope it could potentially be improved, led me to be very enthusiastic
>>> about using it. WebID-TLS was a clever logical hack on that deployed foundation
>>> to allow us to create decentralised social networks.
>>>
>>> One problem of X509 was that it was built on ASN.1 which is pre-web binary
>>> format.
>>
>> So you have ubiquity and structured data representation format
>> preferences (or trends) colliding.
>>
>> Every modern computer operating systems knows what to do with an X.509
>> certificate. That kind of ubiquity should be sacrosanct.
> Kingsley: we agree here 100%. Deployment is worth millions if not billions
> of times more than a paper standard. And as far as deployment goes
> X509 wins hands down. Actually X509 is a testament to the value add
> of deployment over ”perfection”. Nobody would use X509 if they had
> to do it again now: they would use verifiable claims standard from the
> W3C I am sure.
>
> Anyway, deployment is why WebID built an authentication scheme
> on top of TLS. Deployment, deployment, deployment! :-)
> https://www.w3.org/2005/Incubator/webid/spec/tls/


Yep!


>
> A lot of people did not like it because it did not meet their
> ideal of perfection, and a lot of detractors of decentralised
> networks (and they have a lot of money) fed trolls by helping
> them highlight the imperfections, which always exist. So if you
> notice people making mountains out of molehills, be careful not
> to feed the trolls.
>
> That is why the IETF motto is not ”perfection” but ”rough consensus
> and working code”. And with WebID we have that by being very light.
> So thanks to OpenLink for the hard work with deployment and working on
> implementations and real deployments.
>
> Also WebID is what helped the emergence of the Solid project,
> which is where the (light-weigh) read-write-web action is taking
> place.
>
> https://solidproject.org/


Yep!


>
> I am getting funding from the EU to help research/build a server with
> attribute based access control, which is the next state we need
> after the simple but useful Access Control Lists. Luckily again
> we don’t need to start from scratch but can build on the Web
> ACL ontology and get most of the way there by a few adjustments.
>
> As I have mentioned I am also working on building a plan B for
> X509 Certs and the browser keychain, using just HTTP, and the
> emerging IETF HTTP WG standard ”Signing HTTP Messages”
> https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-05.html
>
> I have implemented of that spec in Scala, so it compiles to Java and JavaScript.
> I can put more work on tuning it to particular requirements if people
> either can help me financially put the time aside to do that, or if they
> are skilled enough to help out.
>
> The work I did on WebID was all out of my own pocket, and my
> saving have dried up quite a lot in the meantime, which is why
> I have to be very focused on what I do, and I can’t spend much
> time on the many discussion channels around the internet.
>
> Deployment, deployment, deployment. That’s the key.


Agreed!


Kingsley

>
>
>>
>>> It’s an EAV format where relations are named by numbers, with no
>>> semantics and only belatedly a central registrar for registering these numbers.
>>> https://www.alvestrand.no/objectid/
>>> The gap between that and both JSON-LD, Turtle or any other RDF tech is huge.
>>> Indeed the heated debates between RDF formats are just storms in some folks’ teacups,
>>> in comparison.
>>>
>>>
>>> An RDF based certificate format based on linked data is compared to ASN1 something
>>> like a 40 year technology jump forward.
>>
>> I don't see it that way.
>>
>> What I've always seen is the use of a resolvable IRI to create a pathway
>> to credentials that build on what's in an X.509 cert i.e., embrace and
>> extend by meshing structured data across two sources.
>>
>> You have an X.509 cross-referencing an RDF-based Profile document as the
>> underlying kernel of a protocol.
> Hey, we agree. That cross referencing is what I discovered (with a couple of others)
> in 2008 and wrote up in the Sun Blog Post
> "foaf+ssl: adding security to open distributed social networks"
> https://web.archive.org/web/20090304221910/http://blogs.sun.com/bblfish/entry/foaf_ssl_adding_security_to
>
> I am just saying that if one were to start from scratch *now* then Verfiable Credentials would
> win hands down, as it is built on RDF, is extensible, has a semantics, etc, etc…
>
> But you know: Deployments, Deployments, Deployments!
>
>>
>>> It’s a huge step. 12 years ago it was a
>>> 28 year step forward. As was predictable, replacing something like ASN.1 with
>>> a RDF tech was a huge undertaking.
>>
>> The replacement part is expense and unnecessary, IMHO.
> It was not expensive to me: I went and studying Category Theory,
> and when I came back the important standards I need
> were mostly written :-)
>
> But yes, the movement towards that clearly improved
> standard, partly eclipsed work that continued in
> other areas such as the growth of Solid. That is at it has to be:
> to create such large movements one has to make a lot
> of noise, and noisy crowds don’t like subtlety. They
> like simple messages.
>
> Our star the Sun is a massive star large enough to
> fit 1.3 million Earths, and it is a medium star among the
> 10 to the power of 24 stars in the Universe.
> So energy loss happens everywhere.
>
>
>>
>>> It required not just replacing a binary format
>>> with a linked data one, but also building new keystores, developing ontologies,
>>> and a lot more…
>>
>> Again, resolvable IRIs as the basis for WebID was never about replacing
>> ASN.1 based credentials. It was about using the power of de-reference to
>> augment various credential sources.
> We agree. I am not saying it MUST be replaced. I am just saying
> given that the work and energy on making good replacements has
> been done, well we can use them where it makes sense.
>
>>> Another problem with X509 and TLS is that TLS is at a layer below the HTTP stack,
>>> and even though some folks at Mozilla have been trying to link these together I think
>>> those have failed. Otherwise it would potentially be possible to use VCs as
>>> client side TLS replacements. But I think with HTTP Sig one can actually get a much
>>> simpler solution at the same layer as HTTP.
>>
>> I see this issue as more to do with browser implementation choices by
>> browser vendors.
>>
>> Delegation gets around this problem as we've demonstrated for many years.
>>
>> Ultimately, you need delegation (expressed using machine-readable
>> semantics) in order to not conflate the user of a browser and the
>> browser itself (a piece of software).
> Indeed, you can have delegation or have a browser plugin that stores
> your keys. Essentially with time I think we are going to see a move
> from the current keychains to VC keychains. They fulfill the same
> role. So essentially if VC’s succeed - which I hope they will - then
> WebID will just have switched to a different Certificate format, and
> with a slightly different protocol. But the logic remains exactly the
> same!
>
> The power of RDF and WebID is that we keep things so simple that they
> have close to mathematical simplicity. Maths is actually built on
> extremely simple blocks. Indeed Category Theory is built on arrows,
> just like RDF is. It’s all about connecting things.
>
> That is what the Yoneda Lemma teaches us, as explained by this excellent
> blog post
>  https://www.math3ma.com/blog/the-yoneda-perspective
>
> Henry Story
>
> PS. I really need to get back to work folks!
>
>>
>>> What may go a lot further would be the deployment of P2P extensions to HTTP.
>>> https://github.com/w3c/architecture/issues/14
>>>
>>> Henry Story
>>> https://twitter.com/bblfish
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>> --
>> Regards,
>>
>> Kingsley Idehen
>> Founder & CEO
>> OpenLink Software
>> Home Page: http://www.openlinksw.com
>> Community Support: https://community.openlinksw.com
>> Weblogs (Blogs):
>> Company Blog: https://medium.com/openlink-software-blog
>> Virtuoso Blog: https://medium.com/virtuoso-blog
>> Data Access Drivers Blog: https://medium.com/openlink-odbc-jdbc-ado-net-data-access-drivers
>>
>> Personal Weblogs (Blogs):
>> Medium Blog: https://medium.com/@kidehen
>> Legacy Blogs: http://www.openlinksw.com/blog/~kidehen/
>>              http://kidehen.blogspot.com
>>
>> Profile Pages:
>> Pinterest: https://www.pinterest.com/kidehen/
>> Quora: https://www.quora.com/profile/Kingsley-Uyi-Idehen
>> Twitter: https://twitter.com/kidehen
>> Google+: https://plus.google.com/+KingsleyIdehen/about
>> LinkedIn: http://www.linkedin.com/in/kidehen
>>
>> Web Identities (WebID):
>> Personal: http://kingsley.idehen.net/public_home/kidehen/profile.ttl#i
>>        : http://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl#this
> Henry Story
>
> https://co-operating.systems
> WhatsApp, Signal, Tel: +33 6 38 32 69 84‬
> Twitter: @bblfish
>

-- 
Regards,

Kingsley Idehen       
Founder & CEO 
OpenLink Software   
Home Page: http://www.openlinksw.com
Community Support: https://community.openlinksw.com
Weblogs (Blogs):
Company Blog: https://medium.com/openlink-software-blog
Virtuoso Blog: https://medium.com/virtuoso-blog
Data Access Drivers Blog: https://medium.com/openlink-odbc-jdbc-ado-net-data-access-drivers

Personal Weblogs (Blogs):
Medium Blog: https://medium.com/@kidehen
Legacy Blogs: http://www.openlinksw.com/blog/~kidehen/
              http://kidehen.blogspot.com

Profile Pages:
Pinterest: https://www.pinterest.com/kidehen/
Quora: https://www.quora.com/profile/Kingsley-Uyi-Idehen
Twitter: https://twitter.com/kidehen
Google+: https://plus.google.com/+KingsleyIdehen/about
LinkedIn: http://www.linkedin.com/in/kidehen

Web Identities (WebID):
Personal: http://kingsley.idehen.net/public_home/kidehen/profile.ttl#i
        : http://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl#this