- From: Henry Story <henry.story@bblfish.net>
- Date: Tue, 27 Jul 2021 09:58:59 +0200
- To: Kingsley Idehen <kidehen@openlinksw.com>
- Cc: Read-Write-Web <public-rww@w3.org>
- Message-Id: <3CDC485D-7DDB-478A-852F-3EECC6B1F114@bblfish.net>
> 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/ 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/ 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. > > >> 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
Received on Tuesday, 27 July 2021 07:59:16 UTC