Okay, Jarma Makenbach, his next talk is K-OxEat, the refiner line, the identity of his cryptography.
Welcome, Jim.
All right.
Is this working?
Yeah.
All right, awesome.
Thank you all for coming.
So, yeah, I'm Jarma Makenbach, and I would like to give you a little non-technical introduction
to my project called K-OxEat, which is all about verifying online identity with cryptography.
And to start us off, I would actually like to review very quickly how traditional passwords
work.
So, yeah, you walk around with your little passport, and you give it to the person who
needs to verify it.
They will do their little verification with a computer, and then, of course, after that,
you can do whatever you came to do with your passport.
So what I would like to briefly touch on is this third step, where a passport needs to
be verified by contacting the government that issued it.
In and of itself, the passport doesn't do that much, it's just a piece of paper with
maybe a little picture to identify the person, but not that much more.
And in fact, even if you do verify with the government, you know, it checks the validity
of the document, is it still valid?
But it doesn't actually link it to the person, again, except for maybe the picture, but still.
So if we were...
So the online world, of course, is becoming more part of our lives.
So how would identity work on the internet online?
So for me, of course, I would like to have it secure.
And with that, I actually mean verifiable, so that, you know, I can present my online
passport and prove to people that it's me and that not someone else is trying to claim
that they're me or anything like that.
I would like it to be anonymous.
We don't actually need this online identity to be the same as our real, in real life identity.
In fact, I would go even further than that.
In fact, we can be multiple persons.
We can, you know, be a certain person that works in a certain domain.
We can be a person with a certain hobby.
And all these personas, they don't need to match, you know, a real identity.
And they should have their own identities that need to be maintained and be cared for
and be presented separately as identities.
I would like to be self-sovereign.
So people should be able to make their own passport.
They should be able to create it, update it, delete it, distribute it, or keep private
as much as, you know, as they would like to, as they see fit.
And of course, I would like to see it decentralized.
There shouldn't be any gatekeepers.
It shouldn't run through a single big instances.
It should just be, if you verify someone's identity, you need to be able to do it yourself
on the spot without having to trust another entity in the middle as much as possible,
because, you know.
And if you combine all this, I think it should represent what you do on the Internet, online,
and not just like the traditional passport where you were born, mostly.
So let's envision a little scenario.
Again, I said that this would be non-technical, so, you know.
So we start off with Alice, and, you know, if there's Alice, then, of course, there's
Bob.
And they've spoken to each other for years now with, let's say, Matrix, I don't know.
So they know who they are.
And again, they don't need to be this, these don't need to be like in real life identities.
They could be pseudonyms, so, but they know who they are.
And on a certain day, Alice gets a message from a certain Bob91 through a separate network.
And of course, Alice wants to know, you know, is this Bob?
Why are they using, and if it is, you know, why are they using a different username?
That's could have many reasons.
But again, is this the same actual person?
So luckily for Alice, in this case, she could ask Keoghseid.
And Keoghseid actually did a little check on both Bob on the Matrix networks and Bob
on 91 on the XYZ network, and it could actually verify that they were the same person.
So that's really a rough explanation.
So let's actually look at what happens to get to this point.
So what Bob did is he created a cryptographic key.
So cryptographic keys are represented by a fingerprint, a large string.
In this case, let's simplify it, we'll just call it key 42.
And he treats the cryptographic key as a sort of vault.
So he can put arbitrary data in there.
So in this case, he puts two links.
In this case, I use different accounts.
So maybe he refers to a Fediverse account, and he refers to a Liberapay account.
Again, these could be any number of services that he chooses to enter in the vault.
And then he uploads a public key version of this to a so-called key server.
So a public key in this context, we can view it as like a glass vault.
Everybody can look inside, but no one can actually modify the contents.
Only Bob can, and Bob secured it through cryptography.
But everyone can actually look at this vault and look at the links that are inside.
And on that fateful day that we just discussed, Alice, so she went to this key oxide page
and she entered the number 42 because she knows that that's Bob's cryptographic key identifier.
Again, they must have talked about this before or anything like that.
But so beforehand, she knew that this was Bob's key.
And so, well, a key oxide then goes and fetch this key from the key server, displays the
data.
But again, it's just displaying this as a list.
It doesn't know yet if it's actually verified because just claiming that you are someone,
a certain account on the internet, that's not sufficient.
So what the key oxide then continues to do is that it will actually fetch some basic data,
profiled data from this Fediverse account.
And inside this Fediverse account, it will actually find a link back to the key, in this
case the number 42.
And with this confirmation, it actually knows that it verifies the identity.
This really is the basis on how key oxide determines identity through bidirectional verification.
So the key links to a certain account on the internet, and the account on the internet
links back to the key.
It does the same verification for the Liberapay account.
It finds a link back to the key.
So it has to be the same person that both actions put the link to the account in the
key, and put the link to the key back in the account.
So that's how it looks in the stick figure mode.
This is an example of my account, for example.
And so this big string, that's actually what the 42 were presented in the stick figures.
And below are all my identities, all my accounts that I linked in my profile.
And that actually have been verified by this website.
So what this website does, kikosite.org, in the end is basically just like a little
automation layer.
You could verify it yourself.
You could go to each of these profiles.
You could go to each of these links.
And just look for the reference back to my key, which is written up there.
But yeah, that is kind of a tedious task.
So that's what kikosite is designed to automate for you.
But kikosite will always give you the option to verify for yourself.
So currently, we do have a kikosite mobile app.
It's available on fdroid for now only.
And it only does this profile verification mode functionality.
It doesn't do profile creation yet.
For now, it requires you to use the command line, the GBG command line tool.
So that's not for everyone.
But yeah, we're working on making sure that the app can just make it just like Keybase
used to do back in the day.
And of course, we would like to release it on different play stores so that it's more
widely available.
But you can already play around with it right now.
I would like to briefly touch on what is next for kikosite.
So we're trying to create this more easy kind of way to create profiles, not only using
OpenPGP.
Right now, everything's OpenPGP within kikosite.
But soon, you'll be able to use, like it says, a minisign keys or SSH keys or whatever
keys we can find.
As I said before, I would also like to have more apps that can actually help you and guide
you in creating profiles so that it's not just for the very technical people among us,
but also just more general that people can enjoy online identity verification.
Another thing is for each website that we support, it needs to be programmed manually.
We need to know the right APIs for every service.
So there's a lot of work that goes into finding out how to do that.
And of course, if a certain bird site decides to close their API, well, yeah, that is over
then for those certifications, but that is their problem.
So we need to, yeah, add support for more services and websites.
And yeah, we should also play around with creating new websites, creating more clients.
Clients can do a lot more things than just display a list of profiles.
And these are things that should be explored, like different ways of using identity online.
Actually, I did so myself.
I created my own competitor, in this case named Kiyoksal Blue.
And I just, yeah, like it says, I built this in an afternoon, and it's just that easy to
get started with this ID because in the end, it's just an automation layer.
And yeah, it was just a little quick test for myself to see how easy is it to create
a new client.
So if anyone feels like playing around with this, go ahead.
It's a little fun, I guess.
And the other thing that I quickly wanted to mention is to go further than just display
a nice list of profiles and of online identities would be, what else can we do with online identity?
And actually, a few hours ago, there was this presentation by Pablo, where he discussed
creating CVs for developers in the end for more people, which is, for now, like developers,
how can they share what they do online?
How can they share their free open and open source contributions on different platforms,
on different websites?
So that is something that maybe we could explore using Kiyoksal as a back end to know who has
done what and make a nice little CV of anyone's contributions to the open source world.
And with that, I would like to thank Victor and Berker and all the other people who have
contributed to the project so far, an illness for their funding.
And yeah, if you like the idea behind this, do reach out.
It's fun.
And yeah, we're always looking for more people to get this field further.
Thank you.
Yeah, thank you a lot for that presentation.
So we have now almost three minutes for questions.
And after that, you will ask them outside.
Anyone?
Questions?
So is this system dependent on a key server?
And no.
So the question was, is it dependent on key servers?
In the end, no.
So key servers are just one way of promoting, distributing keys.
But there's also like WKD, web key directory where you can put keys on your own server.
You could also share keys directly, of course, between people.
Brilliant.
OK.
So have you also included key signing so that you can create a web of trust?
No.
There have been talks about that, you know, because...
It will be good.
Yeah.
Yeah, of course, like the web of trust discussion, you know, that's, yeah, people like it.
People don't like it.
If you can make that socially easy for people, it's a big deal.
Yeah.
That is also something to explore, the social aspect between having identities and, yeah,
because in the end, that's just another verification.
Do people know each other?
And then that, yeah, generates trust.
Thanks.
There was a few questions there.
Yeah, there's a last question.
Because also in that direction, do you have support for blockchain names or something
like that, where the public key is on a chain?
It should probably be feasible.
We haven't looked that much into it yet.
For now, we're just focusing on the basic platforms where people are and where you can
just create an account and then, yeah, get some data back from an API.
It should probably be feasible as long as you can, and as long as you have an online entity
where you can put arbitrary data and you have a way of querying the data, everything's possible.
It's just a matter of, yeah, send us a PR or send us an issue and let's discuss and
we'll get it sorted.
Okay.
Thank you, Yarma.
Thank you for listening.
Thank you.