Open CloudMash. It's not a software project. It is a dating protocol for computers.
So, you know, computers need to meet each other as well. If we want the world to be federated,
then we need to establish these measures and Federation. So, it's not about what computers do
when they talk about each other, it's how computers meet. How they start the context.
And the hard part. So, the easy part for computers to meet is, yeah, you just use the domain names, right?
You know the domain name, you know that computer's there. You know how to reach it.
And especially if you use HTPS, then you know you're talking to the right computer.
Now, the hard part is to know which computer to talk to in an evil internet.
So, how do you know how does the blue flower who wants to know,
once they talk to computers on the internet, but it's very scared and small in an evil world,
but still wants to talk to the pink flower. How do they find each other?
So, I'll answer that later. The other thing that Open CloudMash does,
the part from establishing the first contact, is to exchange user enterprise.
So, it's not just the identifiers of the servers to say, hey, I'm hello.
I'm such a say, hey, I'm not nice to meet you. But also, at some point,
you want to talk about the users that use each of those servers.
Because you want to start sharing, these users want to share documents with each other.
So, you have to say, oh, yeah, I'm looking for that user on your server.
And you need to refer to resources that they then share to establish the sharing of those resources.
So, the sharing between the users who want to collaborate with each other,
requires that you establish trust between the computers.
Usually we think of Open CloudMash as a way to just ping a user,
but recently we've been working on it a lot and evolving the protocol.
And we see it now more and more as a way to establish the trust.
Because, yeah, it looks so simple. One user clicks share share with in their file system,
in their cloud server. And they say, yeah, share this with user at host,
and then it's federated. Something I guess, right? You type here.
This is an uncloud server. You type here. I want to share this with Einstein
at the next cloud one. Docker. This is for my test environment.
And, yeah, you want to share this file with somebody at another server.
And the user who is the recipient gets notified.
And there will be a dialogue in this case.
Next cloud server says, hey, do you want to add the remote share library from this person
at this cloud server? Now, there are a lot of vendors who implement this.
I hope I got all the logos, right?
And they are doing the main work of Open CloudMash, right?
Because that is the actual implementation.
And they can test, you know, that is working.
And a lot of it is manual testing. Oh, yeah, it's working now, new version, etc.
But we're also doing some work on the documentation and the protocol and the test suite,
which has been funded originally by J.R.
then by the ScienceMash project.
This year it's funded by NGI and LNet.
That's the name you hear a lot at host them.
And we're hoping that maybe EOSK will fund it going forward.
Yeah, take a picture of that. Thank you.
So one of the things we're doing this year is we wrote down the spec as an internet draft.
And we tried to make it written in such a way that it's strict and clear what it means.
So not necessarily easy to read, but when you do read it, then it should not be confusing.
And there are a number of ways you can do Open CloudMash.
And I'm going to talk through them.
The first one is share with.
I always got to share with.
So that is the one we saw earlier.
Marie says, yeah, share this document with Einstein and types in the name there.
She knows Einstein's Open CloudMash address.
And then Einstein gets notified and keeps accept accept.
And what happens after that is no longer part of the Open CloudMash protocol.
But probably Einstein will get a link saying, oh, here you can find this file, which is actually remote.
And then the service, for instance, talk to each other with WebDav.
It could also be any other kind of resource, right?
It could be your invited to a video call and then a video call as established.
It's Open CloudMash is just about establishing this context in a trustworthy way.
The second one is this, and this is not strictly described by the protocol, but it's used pattern that you see in practice.
When somebody creates a link, you can, from several EFSS systems, you can create a link like this.
You say, share a link, and then a link is copied, and then you can give this link to other people for, you know, any transport.
And then this other person can click save, and that's a really nice feature.
So you're viewing, in this case, you're viewing a file that's on a next cloud server.
And it says here, add to your next cloud, it should actually say add to any server, add to your server.
And then you type in your own Open CloudMash address here, and then it got saved to your next cloud, you log in.
Then you see, oh, yeah, I saved this to myself.
So that's a nice way of doing Open CloudMash, but there the recipient actually types in their own name.
So, and the next thing I want to talk about is something that was sort of developed in the size mesh project.
And that's about a way in which we can make this scary internet, less scary for the computers, who want to establish contact.
So for these two computers, these two flowers to find each other, the key is that these computers have users.
And these users, these users are trusts this computer, and that user trusts that computer.
So that's information, and that's information we can bootstrap from, because actually what we're trying to do, the users are trying to collaborate.
So this user can send an invite to the other user via email or WhatsApp or signal or whatever.
And that way, the servers know which servers are trustworthy, or at least they know like one of my users knows one of the other users who trusts that computer.
And they want to collaborate.
So this user's asking me, hey, can I collaborate with the computer of this other person?
So that's the servers I'm now giving to this user, and so that's why I'm trusting through my user through the other user that server.
And I know it's probably not an evil user, or well, maybe this person is mistaken and click the phishing link.
But as long as the relationship between the humans is trustworthy, then the servers can trust each other through the human link.
And that's how I'll put my in-fots work, because when this user clicks accept, then there's a backhand call between the servers where they establish trust between the servers.
So that's how you do that's how you establish trust between the computers using the trust that exists between the people.
This is what it looked like in, I think this isosis.
First, the first user generates an in-fot, just about in-generate invitation.
Then there's a little stamp that's a little bit hard, and that's also why we need something like EOS probably to help there.
To get the invite, to accept the invite, the basic way is to paste it, to type it here.
But there are two parts of it, you know, you have a token and a provider that's a bit tricky.
You would like to have a better, like, a where are you from page that makes this easier.
But we're still working on that, making that easier.
So I'd like to talk through the, to get technical.
This was an untechnical part.
So I just want to talk through how all of this looks in a, the swimming diagram, I think.
So suppose that Bob wants to add, Alice has a contact.
And sends an invite token all the way to Alice.
Now this is out of bounds. This might be, might even just be talking, saying, write this down, etc.
There might be talking on the phone to each other.
And then Alice says, yeah, I want to talk to Bob, and that's how the initial trust is established.
The invites help the service trust each other.
Then Alice's server makes a backhand call post invite accepts with the token to Bob's server.
And Bob's server checks the token and says, oh, yeah, this is something that Bob sent.
So now I know that this server is trusted by a human who's trusted by one of my users.
And this server then gets a response with some data about Bob saying, yeah, actually this is my identifier for Bob.
And this is his first and last name for instance.
And then Alice and Bob can have each other in their address book.
And that's nice for the service, but also for Alice and Bob themselves.
So invites are important for security. That's what we sort of found out.
Another thing that's really nice is request signatures, which is being added.
And in requesting to use on HTTP calls, use a public and a key pair of public and private key to sign to add a header to a speakhold to sign it.
So that you know that a speakhold comes from a certain.
They come from an HTTP client, but that it's running at the part of this a certain server demanding.
So that's how these server can, oh, yeah, you are.
You can see which IP does it come from, and you don't know what it's linked with a real actual server.
And what that service domain name is, but through the request signatures, you can make that link.
And I tried, look, I had very complex ideas about how we could make open cloud mesh be more like aloft and more secure in that sense.
And then when Max Hans said, hey, let's do requesting.
Then I thought, oh, wait, if we do request signatures, then all we actually have to add after that is something like the authorization code flow that aloft already uses.
And that suddenly made it much simpler.
So then we specify the authorization code flow.
It's in the internet draft. Nobody implemented yet.
I'm hoping a certain is implementing it soon.
Because there you can use a signature to obtain a token to then do the resource access.
That's better than how open cloud mesh works now.
Most actually, the way it's used now is in the invite.
There's a secret included, and that becomes the access token.
Which is, you know, it's safe, but it's not up to modern standards.
So that's why we think that in the invite, there can be, first of all, that needs to be assigned request.
And second of all, the, the nonsense in there should just be a code that needs to be exchanged.
And then you can see that the party that's exchanging a code is actually the recipient who you wanted to send the access to.
So they have a second check there. And then you give out tokens, which can be short lived and refreshable.
So that's sort of basic 101, without that, we're not even talking about security for, like, aloft people, et cetera.
So that's why we want to add these features to, of a cloud mesh.
And we hope we can get those into all the implementations.
So, which, this is the part I already showed.
After that, there is a capability discovery.
There might be different capabilities for different servers.
So we added a, it used to be called slash OCM, high from provider.
And we renamed it slash dot well known slash OCM.
And there's still the fallback to the old path, but this is just a little bit, uh, neater placed.
And there you can discover the API endpoints.
Also, the capabilities of that server, like which features does it implement.
And it's public key, which you will need for the request signing.
So, um, that's the discovery you start from a domain name.
And then, um, you look up the well known, uh, and then you just got some JSON with the information.
Um, after that, you do the actual OCM share call, uh, the share creation notification.
So, um, here, this server does a signed post to slash OCM slash share, uh, to that server.
And then the new thing, if there was an invite flow, um, which is optional, but if there was one,
then you can check the invite like, hey, is this person who is sending, um, something to my user,
is that actually a contact that was established through an actual OCM invite.
Um, after that, you, this server will do a look up to get the public key with which to check the signature.
And then if those checks pass, then the share is created, uh, meaning that the receiving server says, yeah,
uh, thank you for, um, uh, sharing the resource, and, uh, I will notify my user.
After that, and this is a step, that we, um, invented, but that nobody implement yet.
We put it in the internet draft as, as the new, uh, way to go, because we, like the short lived, uh, tokens better than,
the secrets that last forever. Um, so they're, the code from this first, uh, post call is exchanged with a signed request for a baratode.
So even if you would, um, somehow make this post call to the wrong server, and they would try to exchange it, then their signature wouldn't match.
So that's another, um, safety check there.
Uh, and after that, you do frizzards, a web that I've profined to go access to resource.
Um, yes, so that's another new thing we want to add.
That's what it will look like if all these things are added.
Um, we have a, um, test suite that is testing, testing next cloud, uh, on cloud 10, uh,
certain box, uh, osis, and c file for these different flows, the share with flow, the public link flow.
And the invite flow, uh, Madi Bapani is, um, maintaining that.
He's doing very good work. I hope he's watching this stream.
And, um, with that test suite, we can check that different implementations of all the cloud,
are compatible with each other. And also that's easier for vendors.
Like if you have a new vendor at the new version of your own software, you want to check whether it's still compatible with all the,
versions of everybody else's software. And that's why the test suite, uh, exists.
And we're now, uh, convincing the vendors to include this test suite in their own,
continuous integration. So that already if you're changing your open cloud mesh code,
you can see like, oh, did I break anything like compatible compatibility,
not only with my own implementation of a cloud mesh, but also with the, uh, three or four other ones.
That's it. Thank you.
Thank you. We have eight minutes for questions.
Any questions?
Yeah.
Yeah. So the question is,
what is the difference between open cloud mesh and open ID connect?
Um, the way I don't know, um, they're probably some parts that you know that I don't know about that,
actually, but in general, when you say I'm going to federate authentication with open ID connect,
that means that you allow other identity providers to provide users to access resources on your server.
So, um,
that is, for instance, what, uh,
what's the same with, like, federated sample, like adugane, a lot of, uh,
universities use that, like if you want to log in to certain, you can log in with your identity from the University of Helsinki.
Um, the, um, as far as I know, uh, open ID connect does not have a mechanism to then also copy a resource to this other server.
So, um,
yeah. So in open cloud, sorry, the, um, yeah, the, the question was, you said that there's only also, um, this exchange.
So the, um, uh, in open cloud mesh, there are two users involved.
So, um, Alice can say I want to share this with Bob and then Bob gets a notification in his own server.
That's not something I want to see can do as far as I know.
So Bob could, Alice could say I want to give Bob access to it as sort of an access control lesson,
and Bob can come to my server to access it and authenticate with his own IDP,
but that's different from sending a notification to his server,
where in his server he will get a pop up saying hi, something to be shared with you,
and that is actually a server to server access.
But you also showed that there is unique to somehow exchange with had the content in the chat.
Yeah.
And yeah.
And then you can order a link there.
We don't make connections.
Sure.
So, yeah, the question is so you, you have to share the file, you know.
It's true that if I want to share a file with you,
and I'm going to send you a link via email, then this might as well be a link on my server,
and then you can log in with your IDP.
But that still means that you need to visit my server with your browser.
Right?
And maybe that's not what you want to do.
So maybe you want to have it, you have a resource in your own server.
And the idea of open cloud messages that everybody looks at their own home environment,
and that these home environments talk to each other.
So that's where the architect is slightly different.
But you're right, they're very similar.
And the important part of this is I think that both open ID connect,
and now also open cloud messages with these new features,
used the same ideas of like exchanging that come from our,
so that's why that's what we do get from that,
saying we think of open cloud messages as something that also fits into the old framework,
in a way.
Thank you.
Maybe one.
There was one question here.
Yeah.
The question is, are there any examples of capabilities?
Well, there is a one thing is the type of resource and the access protocol.
So the default one is folder access via web dev.
But you can also use it and I think next time talk to us is to establish a video call for instance.
And you could have any type of resource.
You could say, yeah, I invite you to my Jupyter notebook or something very application specific.
And those are the resource type and the protocols.
And the way we use the capabilities here in the discovery is more about,
does it support the signatures?
It's basically, does it support the token exchange?
Does it scan it and force a multi-factor authentication restriction?
That's quite an advanced one that they use in soon at and suede.
So you want to make sure that if you share resource with another server,
that server has the same security policy for instance.
If you say this has to be, this resource can only be viewed using multi-factor authentication.
And then somebody is multi-factor authentication, but shares it with another person.
And there, that user is not required to log in with the second factor.
Then you have reached that policy.
So that's another capability.
If both servers have the capability to enforce it,
and they trust each other to do that,
then you can, yeah, you have the MFA capability.
But you can read the internet draft and there's full list.
I think there are three or four now in this pack.
Thank you.
One less question.
No, thank you very much.
Thank you.