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 Tue, 27 Jul 2021 at 09:59, Henry Story <henry.story@bblfish.net> 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/
>
> 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.
>

I'm hearing that you dont have time/resources to take WebID any further

So, would you step down as chair of the the WebID community group at let
others, perhaps a community effort, to modernize it

If not, we should I guess, mark it as abandonded


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