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

> 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. 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. 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. It required not just replacing a binary format
with a linked data one, but also building new keystores, developing ontologies,
and a lot more…

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.

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