Open cloud mesh. 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 meshes and federation. So, it's not about what computers do
when they talk about it, 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 Cloud mesh 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.
I want to collaborate. 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 Cloud mesh 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 with in their file system,
in their file server, and they say, yeah, share it with user at host, and then it's federated.
Something I guess, right? You type here, because there's 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'll be a dialogue in this case. The next cloud server says, hey,
do you want to add the remote share by blaf 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 cloud mesh, right?
Because that is the actual implementation.
And, they can test, you know, that, like, is it working?
And, a lot of it is manual testing. Oh, yeah, it's working now, new version, et cetera.
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 science-mash project, this year, it's funded by NGI and LNet.
That's, and then you hear a lot of it's first time.
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 cloud mesh.
And, I'm going to talk through them.
The first one is, Share with.
So, that is the one we saw earlier.
Marie says, yeah, Share with us document with Einstein and types in the name there.
She knows Einstein's open cloud mesh address.
And, then, Einstein gets notified and clips accept accept.
And, what happens after that is no longer part of the open cloud mesh protocol.
But, probably, Einstein will get a link saying, oh, here you can find this file,
but it's actually a remote.
And, then, and he servers, 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 cloud mesh is just about establishing this context in a trustworthy way.
The second one is, 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 link, and then a link is copied.
And, then, you can give this link to other people for, I don't 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 the next cloud server.
And, it says, here, add to your next cloud institute.
I actually say, add to any server, add to your server.
And, then, you type in your own open cloud mesh 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 cloud mesh, 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 user 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, 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's server.
And, I know it's not, it's probably not an evil user,
or, well, maybe this person is mistaken, and click the fishing 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 cloud machine fights work.
Because, when this user clicks accept,
then there's a back end call between the servers,
where they establish trust between the servers.
So, that's how you do it, 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 invite,
just a button, 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 the non-technical part.
So, I just want to talk through how all of this looks in a,
the swim lane diagram, I think.
So, suppose that Bob wants to add Alice as 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.
And the invites help the service trust each other.
So, then Alice's server makes a backhand call,
post-invite accepts a 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 request signatures on HTTP calls,
use a key pair of public and private key to sign
to add a header to a SQL to sign it.
So, that you know that HTTP comes from a certain,
they come from an HTTP client,
but that it's running at the, it's part of a certain server
So, that's how these server can, oh yeah,
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 request signatures,
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 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,
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 norms that's 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 a wall of 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 party 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,
Hive and Provider,
and we renamed it slash dot well-known slash OCM.
There's still the fallback to the old path,
but this is just a little bit,
a little bit,
a place,
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,
that's the discovery you start from a domain name,
and then you look up the well-known,
and then you just got some JSON with the information.
After that,
you do the actual OCM share call,
the share creation notification.
So,
here,
this server does a signed post to slash OCM slash share,
to that server.
And then the new thing,
if there was an invite flow,
which is optional,
but if there was one,
then you can check the invite like,
hey,
is this person who is sending something to my user,
is that actually a contact
that was established through an actual OCM invite?
After that,
this server will do a lookup to get the public key
with which to check the signature.
And then if those checks pass,
then the share is created,
meaning that the receiving server says,
yeah,
thank you for sharing the resource,
and I will notify my user.
After that,
and this is a step that we invented,
but that nobody implemented yet.
We put it in the internet draft,
as the new way to go,
because we like the short-lived tokens better than
the secrets that last forever.
So,
the code from this first post call
is exchanged with a signed request for a baritone.
So, even if you would 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 safety check there.
And after that,
you do Fritzord's a web draft
to go access the resource.
Yes,
so that's another new thing we want to add.
That's what it will look like if all these things are added.
We have a test suite
that is testing,
next cloud,
on cloud 10,
certain box,
oasis,
and c-file for these different flows,
the share with flow, the public link flow,
and the invite flow,
Madi Bachbani is maintaining that.
He's doing very good work.
I hope he's watching this stream.
And with that test suite,
we can check that different implementations
of other cloud maps are compatible with each other.
And also, that's easier for vendors.
Like if you have a 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 exists.
And we're now convincing the vendors to include this test suite
in their own continuous integration.
So, 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 our cloud mesh,
but also with the three or four elements.
That's it.
Thank you.
We have eight minutes for questions.
I'm not wearing any questions.
Yeah.
Now.
Here.
There.
Here.
Another call.
菸菸.
Um hmm.
What?
Hmm.
There.
Mason.
There.
Yes.
Oh.
All right.
Yeah, so the question is...
Yeah, the question is, what is the difference between open cloud mesh and open id connect?
I don't know, they're probably some parts that you know that I don't know about that actually
detail, 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, that is, for instance, what's the same with federated sample, like id you gain.
A lot of universities use that, like if you want to log in to certain, you can log in with your identity from the University of Helsing.
As far as I know, open id connect does not have a mechanism to then also copy a resource to this other server.
So, you said that, that's also nothing but that.
If a cloud mesh is certain, why are you talking about the cloud mesh exchange user id connect?
Yeah, so in open cloud, sorry, the question was, you said that there's only also this exchange.
So, in open cloud mesh there are two users involved.
So, 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, a sort of an access control lesson,
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 that had a contact in the chat,
and you can do that.
And yeah,
and then you could follow the link there, you can do it,
so yeah, the question is, so you have to share the file email.
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 a resource in your own server.
And the idea of a cloud message is 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 OpenID connect,
and now also a cloud message 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 a cloud message as something that also fits into the our 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 just a file or a folder, access via web dev.
But you can also use it.
And I think next slide talk does this 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.
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?
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 Sweden.
So you want to make sure that if you share resource with another server,
that 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 can 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 last question.
Nope.
Thank you very much.
Thank you.