All right, everybody, grab a seat. I would like to introduce Tim Hobson, Pamela and Sam from Trust
Chain. Trustworthy, decentralized public key infrastructure. We're going to do about 20
minute presentation. We're going to stay some time again for discussion. If you could
remember to repeat the question of somebody else who question I'd be on trying.
Awesome. Thank you very much and thanks for the organisers. This is fantastic. I'm going to
talk about Trust Chain, which is a project software project or about decentralized
public key infrastructure. I'm Tim. There's Pam and Sam are in the audience there, so if
you want to come and talk to us after you know, to look for. Okay, so I'm going to start
with the kind of design goals behind Trust Chain. So what we're trying to do is enable
anybody basically to build their own public key infrastructure without requiring any trusted
third parties. Of course, there are public key structures that exist already, but they
do require third parties, certificate authorities, for example. And so we want anyone
anyone to be able to set up their own public key infrastructure and I explain why you might
want to do that in a minute. Any user community to be able to just basically do it themselves
and that means really using decentralized infrastructure so you don't, it doesn't cost fortune.
And if we're going to work in a decentralized setting, then we really need the end user
to be able to verify everything, essentially. Otherwise, you need to trust a third party.
So end user verifiability is like a key goal. There are some really massive categories
of use cases. First is digital ID in a kind of decentralized and trustworthy user centric
context. That was how we started off this project was looking at digital ID, but then
we basically realized that if you can do public key infrastructure in a trustworthy way,
then you kind of get digital ID for free, obviously decentralized. But you also get a lot
of other cool things for free. You can verify your files and I'll explain how that works.
Before you visit a URL, you can verify that it really is the legitimate one. You can do
data provenance because if you know if you know the public keys of your counterparty or some
institution, then you can just, you know, they can sign data when they release it, like
a media company can release images, video or just articles or, and you can just, you know,
they sign that data and you can verify their signature on it because you've got their
public key from this infrastructure. And then generally secure communications between
counterparties in a kind of digital economy. So there's loads of massive use cases. And
yeah, just for a highlight, trustworthy digital ID is where we kind of came from this idea
came out of. And one of the motivations is the idea that instead of kind of lobbying or
trying to fight against, you know, centralized digital ID, which is widely, it's widely
recognized to be potentially really risky for society. Well, one approach is to just build
an open decentralized alternative, which hopefully is superior, and then people just use
that instead, and that's kind of worked in some other context. So, okay, so this is one
picture to try to get the idea across. It's just one possible scenario. It does not need
to be a kind of government, you know, centered or public sector, you know, structure of
this network. But the idea is we want to be able to access, just imagine a world basically
where you can access the public keys in a verified, in a trustworthy way, of all these
different institutions in society. And if you can do that, then, yeah, you can see at
the bottom, you've got credentials can then be issued by any of these legal entities,
and because you can access the public key, you know, you can verify the signature on the
credentials, and so everything just works. And, you know, when there's been lots of
talks about credentials, and, you know, it's kind of just assumed that there is some
public key infrastructure, but we want to be able to say, well, you know, just, you know,
how does that work? And, you know, wouldn't it be great if anyone could set up their own
because, for example, yeah, you could have, like, yeah, the route of this network could
be a private company, and with, you know, different regional offices, and they want credentials,
people be able to scan QR codes in order to sort of admit their employees as they move
around, or there's all sorts of possible, or it could be an online community, not physically
located in one place. So I'll come back to this example. So these key icons, they represent
public key certificates, which, for us, are going to be the ID documents. So the WBC
DID standard. So yes, I wanted kind of focus on the WBC standards for verifiable credentials
and the IDs, and this is taken, this diagram's taken from that standard, and the whole
thing, basically, revolves or works because of something that they refer to as a verifiable
data registry, which sounds great, but how do you actually create a data registry, where
you can somehow verify the veracity, the tripalness of the information that's on it,
but the point is that you really need the end user to be able to verify it, right? So
what, you know, it's called a verifiable data registry, well, what mechanisms do we have
for actually verifying data, right? So what types of information can we verify cryptographically?
So one, of course, is digital signatures, so their ubiquitous, and that's the whole point
of having a public key infrastructure is so that you can then verify digital signatures.
So that's super cool, and they're definitely going to be part of the solution, but they're
necessary, right? But they're not sufficient, because, well, there's a chicken and egg
problem, right? You can't, you can't only use digital signatures in order to set up a
public key infrastructure, because you always need another public key to verify the signature
in the first place, right? So alone they're not going to be sufficient, they transfer trust
rather than creating trust. The second one that's going to be useful as well is basically
cryptographic hash functions that produce a digest, an output of that function, and what
that gives you is basically you can then verify immutability of the data, right? So this
is how IPFS works, the implantary filing file system, so online distributed filing system.
So you put data into IPFS and the address for then retrieving that data is the hash of the
data set. So when anyone retrieves the data, they can simply just compute the hash again,
and they know that the data is exactly the same as when it was put on the registry.
So again, that's super useful, but it's also not going to be sufficient, because it's
all decentralized. Anybody could have put the data there. So how do you know it was legit
when it went on? How do you know it who it actually relates to in the decentralized setting
just being able to prove immutability is not sufficient? So this is sometimes referred to as
the Oracle problem, because you need a kind of an external Oracle to kind of like actually
create the trust, if you like. So there's one, there's a third one. I'm not going to
talk about zero knowledge stuff here, because I don't think it's useful for sharing public
key. So pretty much the only other one that I know about, I'd love anyone to correct me.
We can verify cryptographically, we can verify timestamps, and so trust chain is basically
going to see if we can leverage this ability to verify timestamps to to support a decentralized
public key infrastructure. So how do we actually do that? How do we, so this is kind of funky
right? Because you know how, how and if can I verify cryptographically? How can I verify
that an event took place on a certain date or a certain time in the past? That right,
we're jumping from the digital to the physical in a really funky way. Well, so I want
to kind of drill down, this is like the core verification mechanism used in trust chain.
So I'll just to some people, you know, this might be kind of obvious if you know about the
the pit pit networks that make this work, but if not, I want to just make sure everyone understands
that this really is a cryptographic verification that certain public keys were published on a certain
date in the past. And so we're using a system called Ion, the identity overlay network,
and that's a DID method for those who know what that is. It's essentially enabled you to take a
DID string of characters and then it returns DID documents and the DID documents are the things
that actually contain the public keys that you use to verify the signatures and those documents
also contain URL endpoints. That's how we do verifyable URLs as well because they're contained
in this DID document. So what does Ion do? When it publishes a DID, it takes that data and it publishes
it onto IPFS, this distributed filing system. And it uses these three different files at the top,
that's for scalability. So you end up being able to just fit more data into each transaction.
And then as I said, the address of a IPFS file is called a CID content identifier. That address
is just the hash of the file itself. So it takes that hash and it puts it in a Bitcoin transaction
and then publishes that on the chain. So what that does is it that anchors it in time and that's
exactly what we're going to leverage. So all we have to do, you have to pay for a Bitcoin
transaction but that's not high cost less than a dollar usually and you can embed up to
well several thousand DID operations with the single transaction because of this scaling the
guys who develop Ion took care of. So what do we do when we actually verify a timestamp on some
public keys in trust chain. We start the top of this diagram, we take the actual bytes. So we use Ion
to retrieve the information but we don't want to trust Ion, right? We don't want to trust any third
party. So Ion would be a trusted third party unless we verify it for ourselves. And so we want the
end user to be able to do the full verification which is what I'm going to describe now. So the trust
chain software will basically use Ion or some other, it doesn't really have to be Ion but
you retrieve this information from the IPFS and that you actually access the DID document,
you look at the public keys and you say, well, how can I trust these? You take those bytes and
you you check that they're contained in this first chunk file and then you compute a hash
that gives you the CID of that file and then you check that in the next file, you hash it,
you check that in the next file, you keep going until you get to the hash that's in the Bitcoin
and then that again you can continue the sequence of hashing and checking the hash is contained
in the next step and eventually you end up at the Bitcoin block header and that also contains a
Unix timestamp, right? That's when the Bitcoin block was mined and then you hash that and you get
this proof of work hash, right? This POW is proof of work hash and what makes all this work is
that basically the PIRT PIN network, the Bitcoin network is hashing and you know kind of crazy
rate of like around 800 x or hashes per second and that just keeps going up and up so it's just
infeasible to edit or change any of the information in this diagram right? Without performing even
more hashes than the Bitcoin network and there's no there's no authority on earth that has got
that amount of you know it does infeasible like computationally that's otherwise Bitcoin itself
wouldn't work, right? So I know there's been like yeah I'm definitely not a blockchain advocate
I think you've got to draw a big there's a world of difference between the Bitcoin network which is
doing proof of work and gives you verifiable timestamping and then all the other blockchain stuff which
I would agree with most some of the people here that you know very skeptical. Okay cool so yeah just
to sort of recap basically if anyone came back subsequently and edited any of the bytes any of the
information in the DID document then you would end up with a different hash which wouldn't match
the proof of work hash at the end of this the sequence and so each trust chain node just needs to
have a Bitcoin client built into it and it can be a light client which means that you only need
the sequence of Bitcoin block headers you don't need the full blockchain you just need the headers
and that is sufficient for the end user to then be able to say why is this proof of work hash
actually you know contained in the header the chain of headers if it is you you basically have
cryptographically verified that that that document was published on that particular date.
Okay so this is what it then looks like you know with with trust chain basically securing all of
these public keys so whoever's going to act as like the root entity on this network we're assuming
us of hierarchical network you know because well yeah these are very common but we don't want yeah
you know the the end the root entity doesn't want to have to you know provision all of the
infrastructure so it's all built on decentralized infrastructure but they are like you know some kind of
authority within the the social structure that you know wanting to share information so in this
case here we've got the central government is the root but that's just just an example what what
matters is that when that entity publishes brilliant when that entity publishes their root
DID right there's going to act as a kind of the root of of this network of trust what they then
do is they can they can wait for a month or two to make sure that the Bitcoin chain really isn't
going to get like attacked and then and then they just share the information they just have to
tell everyone else in the network you know what date they actually publish that that information
and then everyone is going to be able to verify that you know that there really is a DID published
on that date and any attacker is you know is not you know can't overpower the Bitcoin network
we're assuming and it would be observed if they did but yeah that's infeasable and they certainly
can't go back in time and and publish their own root DID to sort of you know to attack this system
so the root DID has a verifiable timestamp in fact they all do but that's the most important one
and then after that you can then create these chains of what we call downstream DIDs right so these
are DIDs that have an attestation they have a signature from the from the layer above
yeah so that you know assuming you you of course we we're not when I say no trusted
the parties and we don't we don't want the digital infrastructure to need to be trusted that should
just be verifiable but of course you know we expect to trust the legal entities in this network
that's the whole point right we we want to interact with these other institutions in society that we
that we recognize so we've we've proposed a small extension to the DID standard to enable
these chains of downstream DIDs to be you sort of realize within that standard in a way that is
we've got to work around which is fine at the moment but you know it could be it could be
need to so we're hoping to to get a slight change to the standard so how does this look on
so we're we're really focusing on the back end infrastructure side but in order to like demonstrate
the software we've we've forked an open source credential wallet and so this is this is the kind of
the result this you know yeah this is supposed to sort of describe what what's the user experience like
for a mobile user so basically the first time you you you you you run your you you install your wallet
and then the first time you run it it's going to basically push you to go to the settings page
and then you just need to enter the date just need to enter the date that you will have you'll have
seen you communicated to you buy this central entity if it were central government you'd expect
you know there'll be billboards and you know on the side of buses or in public buildings you
just have posted saying this is the date right you just need to know this date if you know
this date then it's you know it's a small amount of information and you know normies can type of
date into an app right to configure it and and that's about small and easy amount of information
you know as possible to to remember but it because it's verifiable the time stamps are verifiable
it also gives you this kind of end user verification and then there's a short confirmation code of
just a few characters and that that's just a fragment of the Bitcoin transaction that contains the
DID you hashed into it and and that enables the software to just identify exactly the right
transaction to look at so once you've done that quick configuration step you can then basically verify
all the DID chains on the network that I showed a moment ago you can verify URLs because
you know URLs can be you know inserted in DID documents as well so you get public keys as well
URLs as well as public keys and of course credentials as well because you know you've now got
a public key infrastructure and yeah so so it ends up looking like this and obviously if
if the you know if the the timestamp on the the you know the ID didn't match the one that you've
configured then it would just give you and you know like don't trust this chain basically
I'm not sure how if I've got 10 okay I was going to do a very quick sort of demo of the
the the back end so we haven't tried to sort of build any graphical light interface or anything
I'll just show you so this is the DID this is the same DID that is being verified here but
on the on a full this is like a full installation a full node we we can basically just use
this command line interface so it has commands for working with DIDs and credentials
issuing signing and verifying credentials and then a challenge response system for creating these
downstream DIDs so if I just I mean you can do things like so I say DID I want to verify
and then I put in my DID which I've got in a environment variable and then it basically does the
same thing but and you can do a lot more stuff obviously with the with the full the full installation
but it's essentially the same as on the the mobile quick word about like the text stack we're using
so we're building we've built the whole thing in in rust we're using the spruce ID libraries SSI
libraries which are fantastic we relied on them a lot and also rust Bitcoin to do the
interact with the Bitcoin client I on is the DID method that we're wrapping around so
first chain is a DID method but it's a thin wrapper around the ion method which uses IPFS and
Bitcoin under the hood and then the mobile app is written in Dart, Flutter and Dart and just to
yeah give give credit to spruce ID again because we we've fought their credible wallet I think
it's not it's just called wallet now but I'm not going to have time to talk about all the
different features but you basically this model you end up with some really cool features you can
sort of impose constraints from the upstream to the downstream entities and then in the mobile wallet
we implemented selected disclosure using reductable signatures which was going outside of the standard
hopefully you know this was before the BBS stuff I think was fully lined out so yeah at some point
we need to sort of update that to be more you know within within the standards but there are loads and
loads of nice features of this of this kind of this model just finally to just say look please come
and talk to us we're really interested in meeting open source devs who might want to get involved
or especially use a group so if you know any any institution or if you're part of any group that
might find this sort of thing useful and we can even do a live demo using some some mobile devices
that we've brought so come and come and chat to us and that'll take you to the doc site. Thanks.
Thank you. Thank you. I have about seven minutes if you have a question raise your hand
Tim is going to repeat the question for the folks in the live stream in the recording. Tim is also
a much better person than I am he's going to get me his deck so I can put into the
Boston website later. I should have known better that's one of the charitable person.
Anybody quite question right here. Hi. Hi. I'm from the system manager handle or
compromise credentials. Yeah so compromise credentials so I mean we're focusing on the
infrastructure the public key infrastructure so actual you know credentials is we're hoping that
you know there are solutions that you know are being worked on to be honest I mean my view is
that credentials probably should be quite short lived and so yeah replication of credentials we
don't we have a solution we do have a solution like the DAD standard for revoking
DIDs then there's a mechanism in fact having everything on chain and you know I
will find all of the all of the DID operations that have happened since the start of the you know
since the deployment initial deployment so that means the replication of DIDs and downstream
DIDs is very is really nice because you can you can be sure that you've got a full list of
revocations which in the web PKI is not always easy. Revocation of credentials I think the solution
to that personally is is just giving short lived credentials which you then reissue rather than
trying to sort of have revocation lists.
Yeah yeah so the question the question is if the date is used as the kind of route you know to
verify the trustworthiness what happens if someone just basically produce it publishes another
Bitcoin transaction with essentially the same hash in it but then it would have a later date.
Well I mean so that could that could be done I mean the the the premise is that the route
authority is going to be able to share the correct date so so you would just expect that to
have just been like just a waste of you know waste of Bitcoin someone's just published another
it doesn't it doesn't harm the system it's just an additional sort of irrelevant transaction
unless they can get other people to actually kind of look at it and think that that's the actual date
but the thing is because the hash hasn't changed that means none of the data have changed so actually
all they can do is just that's just another route to exactly the same information.
Yeah we're only trying to share the public keys ultimately not the date.
No I mean it would if if you've configured it to a given date then then you you have to find a
DID with that date but if someone else just comes along and publishes that same one like you
they can do it every day like you can do as many times as they want you're just going to ignore
of those because you're going to find your you know the actual valid one.
Okay so the question is about centralization and mining in the proof of work network so I mean this is
I mean theoretically that that kind of attack could harm the Bitcoin network.
I mean the the the way that that was designed that that Bitcoin's designed to be robust to that
because of economic incentives basically you know those miners would be harming themselves by by you know
so but you could have an attack like a nation state might decide to try to attack like that.
I mean I think you know more and more Bitcoin is being seen as a as a layer that really isn't isn't
you know that that 51% attack threat is actually you know becoming less and less of a risk I think
I mean obviously nothing's you know absolutely you know perfect but I I don't I don't really worry
about that I mean there have been times when mining concentration has increased but then usually
um actually it might look like it's very concentrated but actually it's usually mining pools and then
when those pools get too big then you know the individual miners can actually just migrate to
different pools because again it's in their own interest so I mean you know that that's a criticism
basically of the Bitcoin network and whether it actually works but it's it's kind of proved itself
at this point in my view.
Yeah so it's a good question yeah so yeah that's a great question so the question is about like
you know you say no trusted to the parties but actually you've got this root of trust and then
the other mem entities in the in the chains of trust they will you could think of them as trusted
so what I mean is I don't want the the digital infrastructure used to support the system