So thank you very much, thank you all for being here, we're almost a closing time of
fussing but I'm glad you're still paying attention and not yet to worn out, yes, my
microphone's not working well enough, higher, maybe, one, two, three, better, okay, cool, all right,
yes, so from reverse Google from email to decentralization, titles have to be a bit interesting,
I tried to make this one interesting, but I could have of course taken others as well,
however, I think Google perfectly exemplifies what I am thinking about it here, just like this.
This was about when was it launched 2003, 2004, right, Gmail, so in fussing terms,
fussing plus three, plus four kind of likeish, and basically from today's perspective, I would
say that when you look at what happened back then, Gmail was a lost leader to capture the
identity market. They basically gave Gmail away for free so everybody would get the address,
right, it's enormous today, we all know that, and basically what they did then with the
Federation of Identity, so login with Google, is that they got visibility on every single
interaction that people are doing, right, whenever somebody uses the login with Google thing,
then they know who is signing on where, for what, you know, I mean they have the full visibility
on the interaction and then they monetize that, basically, right, because that allows them
to create better data profiles. So Gmail has been the lost leader to create this kind of mechanism,
but it goes deeper. I actually believe by now, it took me a while to come to this, and if you
see my first Asia talk, last year actually, you'll see that I've actually, I have a little bit more
story to this, but I'm not going to tell all of that today, I believe that the Federation
protocols for identity are part of the problem, they're not part of the solution, because in the
way that the web is set up, basically what happens here is that you have enormous economies of
scale, you have the cost benefit of running a larger platform, more centralized system, and
you have their ability to leverage identity into multiple markets that makes the life for every
single free software project much harder, and it's harder for us to build applications, they have
the identity platform to leverage into other domains. And that is actually part of the problem
is to some extent view to the fact how the web, how TLS, how certificate authorities, how all
these things work together to create a circle that actually works against us, it's like we are
working against gravity, there's an underlying principle that really makes our life much much harder.
That was at least my problem analysis, and this is basically why we started the rain,
the rain is short for sovereign, so the idea was to create applications on top of self-sauvered
identity that would help to change that dynamic in favor of free software in favor of open source.
That was the idea behind this, right? Because I mean the only answer otherwise we had was again
that's all self-hosted, but to me they're always sounded a lot like Marie Antoinette,
the whole thing like let them eat cake, but come on guys, like seriously we need to have
better answers than that, because most people do not want to self-host everything,
I prefer not to self-host everything. I mean I have good connectivity, I can self-host,
I really don't want to self-host everything, I really don't. So at the end of the day we need better
answers, and I believe a very important part of that answer is actually this idea of self-sauvered identity.
Now I do not want to do a full introduction of how this works, but I do want to talk about a few
things conceptually, how all of this comes together, because what we see today is that the idea of
self-sauvered identity is increasingly co-opted by the web-based federation technology community.
They actually now implement a lot of things on top of open ID, connect, and things like this,
and basically reintroduce similar patterns again when we actually want something else,
we want actual decentralization. So let me show you what I think and what a decentralized key
management system should look like, and this is one of them, right? So this is in fact the one
that I say is the most advanced and most well thought out and best implemented approach,
which is based on something called carry, the key event receipt infrastructure, and we start over
on the left. We have an autonomous identifier, right? So similar to a content identifier,
we have an autonomous identifier that identifies my key, right? It's derived from the inception key
that I'd create for my identity. My key represents this identity. I can't have one. I can have many.
I always generate them locally. They always remain on the device. Every device that ever interacts
has its own identifier. The identifiers, of course, evolve, they do things, right? So they even have
the possibility for key rotations, say, I want to keep my identity, but I think my key might have
been compromised. I want to rotate the key. So I have a pre rotation key that allows me to do that.
There's a couple of concepts here that are really, really powerful. I encourage everyone that's
interested at all in this kind of technology to have a look at that because it's really
quite interesting. What I can also do here is I can sign interactions. And I add all of this
basic to a hash list, right? It's a bit like a micro ledger, just like hash linked transaction
information. I share this information with a pool of so-called witnesses, which is nothing but a
very simple agent running anywhere that receives those receipts, the receipts or updates and
push-up spec receipts to your devices that have the AID and manage it to control us.
That they made to the key and provide a unified view these things that I've created those certificates,
that I have provided a new certificate for this topic, that I have signed a very file of credential,
all these kind of things. And I have my curl, the key event receipt look that is the aggregation of
all of this. And I can get that, of course, directly from my key management system, but I can also
then get it from my witnesses, right? So I can ask a witness, here's an AID, an identifier that
connected to me, do you know anything about them? What is their history? So I can link them back
to actually the root of truth, which to those of you who have looked at ledger systems,
blockchains and all these kind of things, it's basically taking some of those concepts from there
and making them locally consistent with an eventually consistent approach in terms of synchronization
across the interactions. And it's actually really, really powerful because it scales,
right, unless blockchains, which you all know have a enormous scalability problem, this thing scales,
because it's a decentralized set of micro ledgers, if you will. That is an actual full decentralized
system that allows you to then verify the state of every single device. And because it's lightweight
enough, you can actually deploy this, even in an IoT setting, you didn't deploy it anywhere.
That is the kind of system that I believe we would want because if we had something like this
that works, we could then, on top of this, use variable credentials, so machine readable
documents that are signed and linked to these AIDs, in order to attest to certain interactions
or certain statements about our identities that we can verify as much or as little all the way
to full anonymity as the context requires, right, there's different contexts in world.
If I need to buy a beer, it's different than if I want to open a bank account,
or if I just want to exchange an anonymous message, those things are completely different use cases.
This system allows us to say, I need this much or this little verification here.
That is the kind of system that I think we want to move towards. Now,
wanting to move towards a system and knowing that it is more secure than what we're doing
more scalable is one thing. The other thing is how do we actually get this into the real world?
And that is always kind of the hardest problem. I mean, all of us here are technologies,
so all of us know how to build technology, but getting the technology into the hands of actual
people is actually very often at scale. It's the harder problem. How do you get the actual adoption?
We have been doing a lot of work with GIAX and other European projects in this field and
through them managed to find health info net in Switzerland, health info net is a very specific
part of ours with a very specific property because they are a company, but they are owned
by the Swiss Doctors Association. So they do not have a profit motive, right? If they make a
profit, they distribute back to the Doctors Association. There's no other player that wins.
They have a service mission. They're driven by service. As long as they do not go bankrupt,
they're okay, but they want to provide a proper service. They're very old, like 30 years
old, and they started out in the 90s with email. Basically, back in the day, email was new,
right? They realized we cannot just send patient data on encrypted back and forth. So what do we do?
So at that time, had the answer S-mine, so basically now they're doing S-mine based domain encryption,
which is not fantastic, but I guess it's better than pen text. They are operating in every single
G-P's office and across all the hospitals and laboratories in Switzerland. And they realized
a few years ago that if they continued to do what they do without actually adapting,
they would go bankrupt. They would not exist. They would no longer be relevant at some point,
because the world has moved on. So they decided to invest into their own reinvention
on a platform basis, so moving to a modern cloud and open shift, and all these kind of things
on a process level, so DevOps, agile, all the modern things that you would want to do,
and also on a solution level, like, what is it that we should do 15 years from now?
Was the question that they asked? And for them, they realized,
basically in order to remain relevant, we need to look at how the health care sector is transforming.
Coming, we have more seats there. They just don't worry, sit down. They realized that they
do need in order to remain relevant, they do need to change the way they're doing this. And
my version of this would be that they are increasingly becoming the data space terminal
to the health care data space of Switzerland. On that journey, we got together through some
POCs. They're looking at things like science, which is an ETA's age-based network technology
for better secure networking and SSI, and something that they would want to be able to do.
We've been helping them in that transition. In fact, we already have one product in
production, which is sealed. I would be getting another talk, seal is a edge application based
on IPFS, by the way. So, content, addressing, delivering all the messages of Swiss doctors to
patients securely to the edge in the form of basically a cryptographic fragment swarm that comes
together, only at the edge and only at the crypt of their. The system is in production today
with around 800,000 messages every month. All of the Swiss doctors are using it.
But I'm not here for that. I'm here for the S-Mime Gateway's, because this is the next stage
of the transition, the S-Mime Gateway's very old technology. That is the next thing that really
squeaks very hard in terms of what they are doing today. So, we with them have come up with something
to replace S-Mime Gateway this year, all of them until the end of this year, which is really
interesting time, by the way. It's quite challenging, but you know, we'll manage. We'll actually
make it happen. But instead of just building a mayor gateway, because the hospital still needs
to be able to send mail. You cannot tell that mail is no longer there. It doesn't exist anymore.
That would never work. So, instead of just taking away the S-Mime Gateway, so what we did
is we came up with the idea of let's wrap this concept of decentralized key management,
organization, credential management, all of these things into a new kind of mesh node that basis
key management on autonomous identifiers, fully, fully based on the principles
from before, on that new generation, and then allow that to also generate x-fibre-nice certificates
that we wrap into an S-MTP in S-Mime Flow. So, we are legacy compatible, right? We can still exchange
messages with normal S-Mime Gateway, but new gateways, suddenly get the ability to verify
those organizational identities based on the new technology on very fibre credential,
organizational identity, multi-route trust systems, all of the things that you would actually want.
We have a scalable, truly peer-to-peer mesh network that allows you to exchange data.
We call this the sovereign data exchange that we're building around this, so it's a
store-in-forward engine with smart routing, and smart in this case means programmable. So,
rego-based policies stored in git, so you can actually version them, you can control them,
you can alter them the way that you need to, and suddenly this thing becomes able to,
a, of course, send mail, right? Wonderful, better, more secure. There's a wire guard tunnel
between all these mesh nodes, so no, no more metadata leakage at least, so that is good,
it's better than S-Mime was before, but what we've done by the end of this is we have rolled out
a new, more capable infrastructure. Because we're not stopping an email, right? That email
is necessary, but it's not the goal, it's not the end game of this. So what we have here now is a system
that is able to handle structure data in an intelligent way, because based on autonomous identifiers
and then using things like the overlay capture architecture, which is, it's basically content
address schema system, if you will, that allows you to determine the schema of data in a way that
is unique and clear, and both sites know they're using the same schema to interpret that kind of
data, right? And you can link it all together, you can sign it all. So you know, have you, you
exchange data that is signed, authentic, schema is clear, you know, even five years later,
which schema has been used. You no longer have the unclarity on the schema level either,
which is if you ever have looked at that sector, it's a big problem, because even to doctors
will note things differently in their systems, right? Same case, two different doctors,
they write it on different. And so you need to understand the semantics underneath,
and the only way to do this is with some kind of layer for allowing you express the semantics
of the specific data at the time it has been created. So this, I mean, we call it Stargate,
actually this whole system. I mean, somebody came up with the idea that stuck as stupid names
of the do, and basically now this whole thing is the ability of creating a mesh network of
nodes that is able to handle male, but also structure data based on this new kind of autonomous
approach of to identity and data. Just quickly, I don't want to go into the whole architecture
of the whole thing, but just so you know, I mean, we're not reinventing everything, right? We're
not idiots. We take whatever is proven in the free software world and combine it in a new way to
generate this result. So if you look at the architecture here, you will see something like the open policy
agent, right, which is for ego. You will see, you know, API gateway, because you need to somehow
connect this to legacy systems. You have a key cloak in order to connect your SSI decentralized key
management to open ID locally in a local environment, right? Because you need to somehow bring these
things to work them together. I mean, you cannot replace everything around you as impossible.
You have a post-pics, of course, for the male routing, because, well, you know, it is kind of
application to do that. So it's not really like we're reinventing everything. We're just
specifically building the components that are needed to make the new functionality possible.
And that is exactly what we're building. And one of the beautiful things of our partnership
with him is that they have committed to having us release everything, a hundred percent as
free software, all of it without exception. Everything will be free software under the
AGPL. So we have a complete stack that in a couple of years, I mean, this is now a work that is
ongoing, right? It's not going to be over this year. It's not going to be over in a month. It's
too much work. But that will be able to provide this capability to health systems anywhere
fully as for software. We have an actual answer that is data-friendly, privacy-friendly allows
us to give patients control over that data, because suddenly things like constant management
and so on become much, much easier. You can actually handle them and you can prove them because
your event logs are basically your audit trail for the interactions as well.
So you can map this entire space in this in a secure, robust, scalable decentralized way.
So yeah, and language is just in case you're you care, most of everything we do back and
there's always going, some rust is in there for like the crypto primitives and stuff like this.
And our front is usually reactivative. So technologies that pretty much most people know these days.
Why do I think, yes, I'm almost done. Almost there. Why do I think this is relevant,
specifically also here, and the decentralized communications room? You see, one of the
beauties is that this note, because it is the stack, if you want to call it that,
is actually capable of handling any type of data every time of interaction. And once you have
the ability to handle organizational, institutional, server-side identity in this way, and sign
verify the credentials to, to, to, um, e-mark data or local users or, or interaction requests,
you can connect systems without a central source of truth. You can trust in the local source of
truth, right? The local service provides you with all the signed evidence chain that you require.
And on the other side, you can verify this. You can say, this is really this system or
the stockter in this department in this hospital. And on the other side, you can verify that,
without needing to agree to a single point of failure or control, that tells you in both directions,
yes or no. You can now make this local decentralized, which I think actually offers us for the
first time something that solves the usability problem of key management. That's why I started
all of this, right? That's why I realized we needed something like this, because this is something
after between since the 1990s. I mean, I, I, I was part of everything of key management thing that
existed. Um, and that finally, we have an actual answer to this. So it solves this cross-domain trust
issue, right? The cross-sure, trust issue in an elegant, robust and scalable way. And so I would be
very happy if people were building on it. I mean, we are, um, with our partner together,
having a health innovation center now. So anyone working on health care IT, right? Anything in this
domain, interested in this, wanting to work together, please get in touch. We are not only
open, but we would like you to, to reach out to us. We actually want to work on this together, right?
We, this is, this is such a big thing. It doesn't just take, if you, if you, if you guys to do it,
it takes the community at the end of the day. And of course, since everything is going to be
free software, I would be very happy if others took this and applied it to other domains as well.
Right? If this might be something that could solve a problem for you, right? Reach out as well.
I mean, all of this is really like recent development. As in, the alpha test phase will begin
in March in a month from now. It's that much that at the forefront, right? It's really at the edge.
But by the end of this year, this thing is in production, across with someone. And I'm absolutely
certain that that will happen. So, that is what I wanted to share. Thank you very much. This is my view
card. So, without if you want, you have a point at detail. And if there's questions, maybe we still
have space for more. Yeah, I've put up some further questions that.
Yeah, thank you. Thank you. I'm very interested. The load of cells sober,
identify systems always come down to how do you manage your private piece that you mentioned
to be able to perform the device? The devices get lost all the way down. Yes.
How can you reach all the devices? So, the way that carry allows us to handle that case is
whenever you generate a new autonomous identifier, you have one key in private storage on the device,
right, ideally in a hardware, of some kind, some HSM, however that may look like. And you have a
second key that is your, your pre-commitment on the recovery key, right, but that key never gets used
until you need it. You store that key in a different system. You can either do a social recovery,
right, you can break it up and give it off to five people, you trust or whatever, right,
or you could give it to an escrow. I mean, depends on your use case, this is a usability decision
at the end of the day, right? So, you need to figure out what is my user base willing to accept,
but I can handle that key anyway I want, and when that device gets lost, I can use that key
to initialize a new device where again do the same thing, right, I have another private key in HSM,
but I use this key to sign that interaction to say yes, this is the new authoritative key for that identifier.
I would not tell her anything about keys, right? This is, no, I mean, this would be an application
design thing, right? Like she would have her, whatever you want to call her, her app, right? And
she would, you know, when the app initializes, right, it says, oh, you know, like either it's an
initialization process that someone is participating in, as in you do it for her and you manage
that or she gets it from a provider of some kind, like either her, her doctor or some other institution,
like somebody that is in a trusted relationship to her. And yes, I mean, there's suboptimal scenarios
obviously, right? But in the end of the day, I think a social recovery for these kind of scenarios,
for most of us at least, would work rather well.