WEBVTT

00:00.000 --> 00:13.000
Open cloud mesh. It's not a software project. It is a dating protocol for computers.

00:13.000 --> 00:19.000
So, you know, computers need to meet each other as well. If we want the world to be federated,

00:19.000 --> 00:27.000
then we need to establish these meshes and federation. So, it's not about what computers do

00:27.000 --> 00:32.000
when they talk about it, it's how computers meet. How they start the context.

00:32.000 --> 00:39.000
And the hard part, so the easy part for computers to meet is, yeah, you just use the domain names, right?

00:39.000 --> 00:43.000
You know the domain name, you know that computer's there. You know how to reach it.

00:43.000 --> 00:47.000
And especially if you use HTPS, then you know you're talking to the right computer.

00:47.000 --> 00:53.000
Now, the hard part is to know which computer to talk to in an evil internet.

00:53.000 --> 00:58.000
So, how do you know how does the blue flower who wants to know,

00:58.000 --> 01:03.000
once they talk to computers on the internet, but it's very scared and small in an evil world,

01:03.000 --> 01:09.000
but still wants to talk to the pink flower. How do they find each other?

01:09.000 --> 01:18.000
So, I'll answer that later. The other thing that Open Cloud mesh does,

01:18.000 --> 01:24.000
the part from establishing the first contact, is to exchange user enterprise.

01:24.000 --> 01:30.000
So, it's not just the identifiers of the servers to say, hey, I'm hello.

01:30.000 --> 01:32.000
I'm such a say, hey, I'm not nice to meet you.

01:32.000 --> 01:38.000
But also, at some point, you want to talk about the users that use each of those servers,

01:38.000 --> 01:43.000
because you want to start sharing, these users want to share documents with each other.

01:43.000 --> 01:49.000
I want to collaborate. So, you have to say, oh, yeah, I'm looking for that user on your server.

01:49.000 --> 01:59.000
And you need to refer to resources that they then share to establish the sharing of those resources.

01:59.000 --> 02:07.000
So, the sharing between the users who want to collaborate with each other,

02:07.000 --> 02:11.000
requires that you establish trust between the computers.

02:11.000 --> 02:16.000
Usually, we think of Open Cloud mesh as a way to just ping a user,

02:16.000 --> 02:21.000
but recently, we've been working on it a lot and evolving the protocol,

02:21.000 --> 02:25.000
and we see it now more and more as a way to establish the trust.

02:25.000 --> 02:33.000
Because, yeah, it looks so simple. One user clicks share with in their file system,

02:33.000 --> 02:41.000
in their file server, and they say, yeah, share it with user at host, and then it's federated.

02:41.000 --> 02:45.000
Something I guess, right? You type here, because there's an uncloud server,

02:45.000 --> 02:50.000
you type here. I want to share this with Einstein at the next cloud one. Docker.

02:50.000 --> 02:58.000
This is for my test environment. And, yeah, you want to share this file with somebody at another server.

02:58.000 --> 03:03.000
And, the user who is the recipient gets notified.

03:03.000 --> 03:08.000
And, there'll be a dialogue in this case. The next cloud server says, hey,

03:08.000 --> 03:14.000
do you want to add the remote share by blaf from this person at this cloud server?

03:14.000 --> 03:19.000
Now, there are a lot of vendors who implement this.

03:19.000 --> 03:23.000
I hope I got all the logos, right?

03:23.000 --> 03:28.000
And, they are doing the main work of open cloud mesh, right?

03:28.000 --> 03:31.000
Because that is the actual implementation.

03:31.000 --> 03:36.000
And, they can test, you know, that, like, is it working?

03:36.000 --> 03:40.000
And, a lot of it is manual testing. Oh, yeah, it's working now, new version, et cetera.

03:40.000 --> 03:45.000
But, we're also doing some work on the documentation and the protocol and the test suite,

03:45.000 --> 03:48.000
which has been funded originally by J.R.

03:48.000 --> 03:54.000
Then, by the science-mash project, this year, it's funded by NGI and LNet.

03:54.000 --> 03:56.000
That's, and then you hear a lot of it's first time.

03:56.000 --> 04:01.000
And, we're hoping that maybe EOSK will fund it going forward.

04:01.000 --> 04:04.000
Yeah, take a picture of that. Thank you.

04:04.000 --> 04:11.000
So, one of the things we're doing this year is we wrote down the spec as an internet draft.

04:12.000 --> 04:21.000
And, we tried to make it written in such a way that it's strict and clear what it means.

04:21.000 --> 04:29.000
So, not necessarily easy to read, but when you do read it, then it should not be confusing.

04:29.000 --> 04:32.000
And, there are a number of ways you can do open cloud mesh.

04:32.000 --> 04:34.000
And, I'm going to talk through them.

04:34.000 --> 04:37.000
The first one is, Share with.

04:38.000 --> 04:42.000
So, that is the one we saw earlier.

04:42.000 --> 04:47.000
Marie says, yeah, Share with us document with Einstein and types in the name there.

04:47.000 --> 04:51.000
She knows Einstein's open cloud mesh address.

04:51.000 --> 04:57.000
And, then, Einstein gets notified and clips accept accept.

04:57.000 --> 05:01.000
And, what happens after that is no longer part of the open cloud mesh protocol.

05:01.000 --> 05:06.000
But, probably, Einstein will get a link saying, oh, here you can find this file,

05:06.000 --> 05:08.000
but it's actually a remote.

05:08.000 --> 05:11.000
And, then, and he servers, for instance, talk to each other with WebDav.

05:11.000 --> 05:14.000
It could also be any other kind of resource, right?

05:14.000 --> 05:18.000
It could be your invited to a video call and then a video call as established.

05:18.000 --> 05:24.000
It's open cloud mesh is just about establishing this context in a trustworthy way.

05:24.000 --> 05:30.000
The second one is, and this is not strictly described by the protocol,

05:30.000 --> 05:33.000
but it's used pattern that you see in practice.

05:33.000 --> 05:38.000
When somebody creates a link, you can, from several EFSS systems,

05:38.000 --> 05:41.000
you can create a link like this.

05:41.000 --> 05:44.000
You say, Share link, and then a link is copied.

05:44.000 --> 05:51.000
And, then, you can give this link to other people for, I don't know, any transport.

05:51.000 --> 05:55.000
And, then, this other person can click Save, and that's a really nice feature.

05:55.000 --> 06:00.000
So, you're viewing, in this case, you're viewing a file that's on the next cloud server.

06:00.000 --> 06:04.000
And, it says, here, add to your next cloud institute.

06:04.000 --> 06:08.000
I actually say, add to any server, add to your server.

06:08.000 --> 06:12.000
And, then, you type in your own open cloud mesh address here.

06:12.000 --> 06:16.000
And, then, it got saved to your next cloud, you log in.

06:16.000 --> 06:18.000
Then, you see, oh, yeah, I saved this to myself.

06:18.000 --> 06:21.000
So, that's a nice way of doing open cloud mesh, but there,

06:21.000 --> 06:25.000
the recipient actually types in their own name.

06:26.000 --> 06:32.000
So, and the next thing I want to talk about is something that was sort of developed in the size mesh project.

06:32.000 --> 06:38.000
And, that's about a way in which we can make this scary internet,

06:38.000 --> 06:43.000
less scary for the computers, who want to establish contact.

06:43.000 --> 06:48.000
So, for these two computers, these two flowers to find each other,

06:48.000 --> 06:52.000
the key is that these computers have users.

06:52.000 --> 06:57.000
And, these users, these user trusts this computer,

06:57.000 --> 06:59.000
and that user trusts that computer.

06:59.000 --> 07:00.000
So, that's information.

07:00.000 --> 07:03.000
And, that's information we can bootstrap from.

07:03.000 --> 07:05.000
Because, actually, what we're trying to do,

07:05.000 --> 07:09.000
the users are trying to collaborate.

07:09.000 --> 07:13.000
So, this user can send an invite to the other user,

07:13.000 --> 07:17.000
via email or WhatsApp or signal or whatever.

07:17.000 --> 07:26.000
And, and that way, the servers know which servers are trustworthy,

07:26.000 --> 07:32.000
or at least they know, like, one of my users knows one of the other users

07:32.000 --> 07:35.000
who trusts that computer, and they want to collaborate.

07:35.000 --> 07:40.000
So, this user's asking me, hey, can I collaborate with the computer of this other person?

07:40.000 --> 07:43.000
So, that's the servers I'm now giving to this user.

07:43.000 --> 07:48.000
And, so, that's why I'm trusting through my user through the other user,

07:48.000 --> 07:49.000
that's server.

07:49.000 --> 07:52.000
And, I know it's not, it's probably not an evil user,

07:52.000 --> 07:56.000
or, well, maybe this person is mistaken, and click the fishing link.

07:56.000 --> 08:00.000
But, as long as the relationship between the humans is trustworthy,

08:00.000 --> 08:03.000
then the servers can trust each other through the human link.

08:03.000 --> 08:06.000
And, that's how I'll put cloud machine fights work.

08:06.000 --> 08:10.000
Because, when this user clicks accept,

08:10.000 --> 08:14.000
then there's a back end call between the servers,

08:14.000 --> 08:19.000
where they establish trust between the servers.

08:19.000 --> 08:24.000
So, that's how you do it, that's how you establish trust between the computers,

08:24.000 --> 08:29.000
using the trust that exists between the people.

08:29.000 --> 08:34.000
This is what it looked like in, I think, this isosis.

08:34.000 --> 08:38.000
First, the first user generates an invite,

08:39.000 --> 08:41.000
just a button, generate invitation.

08:41.000 --> 08:44.000
Then there's a little stamp that's a little bit hard,

08:44.000 --> 08:51.000
and that's also why we need something like EOS probably to help there.

08:51.000 --> 08:55.000
To get the invite, to accept the invite,

08:55.000 --> 08:59.000
the basic way is to paste it, to type it here.

08:59.000 --> 09:00.000
But, there are two parts of it.

09:00.000 --> 09:04.000
You know, you have a token and a provider that's a bit tricky.

09:04.000 --> 09:07.000
You would like to have a better, like, a where are you from page,

09:07.000 --> 09:09.000
that makes this easier.

09:09.000 --> 09:12.000
But, we're still working on that, making that easier.

09:12.000 --> 09:20.000
So, I'd like to talk through the, to get technical.

09:20.000 --> 09:23.000
This was the non-technical part.

09:23.000 --> 09:29.000
So, I just want to talk through how all of this looks in a,

09:29.000 --> 09:32.000
the swim lane diagram, I think.

09:33.000 --> 09:40.000
So, suppose that Bob wants to add Alice as a contact,

09:40.000 --> 09:44.000
and sends an invite token all the way to Alice.

09:44.000 --> 09:45.000
Now, this is out of bounds.

09:45.000 --> 09:48.000
This might be, might even just be talking, saying,

09:48.000 --> 09:50.000
write this down, etc.

09:50.000 --> 09:53.000
There might be talking on the phone to each other.

09:53.000 --> 09:56.000
And then Alice says, yeah, I want to talk to Bob,

09:56.000 --> 10:01.000
and that's how the initial trust is established.

10:01.000 --> 10:04.000
And the invites help the service trust each other.

10:04.000 --> 10:09.000
So, then Alice's server makes a backhand call,

10:09.000 --> 10:13.000
post-invite accepts a with the token to Bob's server.

10:13.000 --> 10:16.000
And Bob's server checks the token and says,

10:16.000 --> 10:18.000
oh, yeah, this is something that Bob sent.

10:18.000 --> 10:23.000
So, now I know that this server is trusted by a human

10:23.000 --> 10:25.000
who's trusted by one of my users.

10:25.000 --> 10:30.000
And this server then gets a response with some data about

10:30.000 --> 10:34.000
Bob, saying, yeah, actually this is my identifier for Bob,

10:34.000 --> 10:37.000
and this is his first and last name for instance.

10:37.000 --> 10:40.000
And then Alice and Bob can have each other in their address book,

10:40.000 --> 10:42.000
and that's nice for the service,

10:42.000 --> 10:45.000
but also for Alice and Bob themselves.

10:45.000 --> 10:49.000
So, invites are important for security.

10:49.000 --> 10:51.000
That's what we sort of found out.

10:51.000 --> 10:56.000
Another thing that's really nice is request signatures,

10:56.000 --> 10:59.000
which is being added.

10:59.000 --> 11:05.000
And in request signatures on HTTP calls,

11:05.000 --> 11:09.000
use a key pair of public and private key to sign

11:09.000 --> 11:12.000
to add a header to a SQL to sign it.

11:12.000 --> 11:17.000
So, that you know that HTTP comes from a certain,

11:17.000 --> 11:20.000
they come from an HTTP client,

11:20.000 --> 11:24.000
but that it's running at the, it's part of a certain server

11:25.000 --> 11:27.000
So, that's how these server can, oh yeah,

11:27.000 --> 11:30.000
you can see which IP does it come from,

11:30.000 --> 11:34.000
and you don't know what it's linked with a real actual server,

11:34.000 --> 11:36.000
and what that service domain name is,

11:36.000 --> 11:39.000
but through the request signatures, you can make that link.

11:39.000 --> 11:45.000
And I tried, look, I had very complex ideas about

11:45.000 --> 11:49.000
how we could make open cloud mesh,

11:49.000 --> 11:53.000
be more like aloft and more secure in that sense,

11:53.000 --> 11:56.000
and then when Max Hans said,

11:56.000 --> 11:58.000
hey, let's do request signatures,

11:58.000 --> 12:01.000
then I thought, oh wait, if we do request signatures,

12:01.000 --> 12:04.000
then all we actually have to add after that,

12:04.000 --> 12:07.000
is something like the authorization code flow

12:07.000 --> 12:09.000
that aloft already uses,

12:09.000 --> 12:11.000
and that suddenly made it much simpler.

12:11.000 --> 12:14.000
So, then we specify the authorization code flow,

12:14.000 --> 12:16.000
it's in the internet draft,

12:16.000 --> 12:18.000
nobody implemented yet.

12:18.000 --> 12:22.000
I'm hoping a certain is implementing it soon.

12:23.000 --> 12:29.000
Because you can use a signature to obtain a token

12:29.000 --> 12:34.000
to then do the resource access.

12:34.000 --> 12:38.000
That's better than how open cloud mesh works now,

12:38.000 --> 12:40.000
most actually.

12:40.000 --> 12:43.000
The way it's used now is in the invite,

12:43.000 --> 12:45.000
there's a secret included,

12:45.000 --> 12:48.000
and that becomes the access token,

12:48.000 --> 12:51.000
which is, you know, it's safe,

12:51.000 --> 12:53.000
it's not up to modern standards.

12:53.000 --> 12:56.000
So, that's why we think that in the invite,

12:56.000 --> 12:58.000
there can be, first of all,

12:58.000 --> 13:00.000
that needs to be assigned request,

13:00.000 --> 13:02.000
and second of all, the,

13:02.000 --> 13:04.000
the norms that's in there should just be a code

13:04.000 --> 13:06.000
that needs to be exchanged,

13:06.000 --> 13:08.000
and then you can see that the party that's exchanging a code

13:08.000 --> 13:11.000
is actually the recipient who you wanted to send the access to.

13:11.000 --> 13:13.000
So, they have a second check there,

13:13.000 --> 13:15.000
and then you give out tokens,

13:15.000 --> 13:18.000
which can be short-lived and refreshable.

13:18.000 --> 13:22.000
So, that's sort of basic 101,

13:22.000 --> 13:23.000
without that,

13:23.000 --> 13:26.000
we're not even talking about security for,

13:26.000 --> 13:28.000
like a wall of people, et cetera.

13:28.000 --> 13:31.000
So, that's why we want to add these features to,

13:31.000 --> 13:32.000
of a cloud mesh,

13:32.000 --> 13:38.000
and we hope we can get those into all the implementations.

13:38.000 --> 13:39.000
So,

13:41.000 --> 13:45.000
which, this is the party I already showed.

13:45.000 --> 13:46.000
After that,

13:46.000 --> 13:49.000
there is a capability discovery.

13:49.000 --> 13:53.000
There might be different capabilities for different servers.

13:53.000 --> 13:55.000
So, we added a,

13:55.000 --> 13:57.000
it used to be called slash OCM,

13:57.000 --> 13:59.000
Hive and Provider,

13:59.000 --> 14:02.000
and we renamed it slash dot well-known slash OCM.

14:02.000 --> 14:04.000
There's still the fallback to the old path,

14:04.000 --> 14:06.000
but this is just a little bit,

14:06.000 --> 14:07.000
a little bit,

14:07.000 --> 14:08.000
a place,

14:08.000 --> 14:11.000
and there you can discover the API endpoints,

14:11.000 --> 14:13.000
also the capabilities of that server,

14:13.000 --> 14:15.000
like which features does it implement,

14:15.000 --> 14:16.000
and it's public key,

14:16.000 --> 14:18.000
which you will need for the request signing.

14:18.000 --> 14:20.000
So,

14:20.000 --> 14:22.000
that's the discovery you start from a domain name,

14:22.000 --> 14:26.000
and then you look up the well-known,

14:26.000 --> 14:29.000
and then you just got some JSON with the information.

14:29.000 --> 14:32.000
After that,

14:32.000 --> 14:35.000
you do the actual OCM share call,

14:35.000 --> 14:37.000
the share creation notification.

14:37.000 --> 14:39.000
So,

14:39.000 --> 14:40.000
here,

14:40.000 --> 14:44.000
this server does a signed post to slash OCM slash share,

14:44.000 --> 14:46.000
to that server.

14:46.000 --> 14:48.000
And then the new thing,

14:48.000 --> 14:51.000
if there was an invite flow,

14:51.000 --> 14:53.000
which is optional,

14:53.000 --> 14:54.000
but if there was one,

14:54.000 --> 14:55.000
then you can check the invite like,

14:55.000 --> 14:56.000
hey,

14:56.000 --> 15:00.000
is this person who is sending something to my user,

15:00.000 --> 15:02.000
is that actually a contact

15:02.000 --> 15:05.000
that was established through an actual OCM invite?

15:05.000 --> 15:07.000
After that,

15:07.000 --> 15:10.000
this server will do a lookup to get the public key

15:10.000 --> 15:13.000
with which to check the signature.

15:13.000 --> 15:16.000
And then if those checks pass,

15:16.000 --> 15:18.000
then the share is created,

15:18.000 --> 15:21.000
meaning that the receiving server says,

15:21.000 --> 15:22.000
yeah,

15:22.000 --> 15:26.000
thank you for sharing the resource,

15:26.000 --> 15:30.000
and I will notify my user.

15:30.000 --> 15:32.000
After that,

15:32.000 --> 15:36.000
and this is a step that we invented,

15:36.000 --> 15:38.000
but that nobody implemented yet.

15:38.000 --> 15:40.000
We put it in the internet draft,

15:40.000 --> 15:43.000
as the new way to go,

15:43.000 --> 15:48.000
because we like the short-lived tokens better than

15:48.000 --> 15:50.000
the secrets that last forever.

15:50.000 --> 15:51.000
So,

15:51.000 --> 15:56.000
the code from this first post call

15:56.000 --> 16:00.000
is exchanged with a signed request for a baritone.

16:00.000 --> 16:04.000
So, even if you would somehow make this post call

16:04.000 --> 16:06.000
to the wrong server,

16:06.000 --> 16:08.000
and they would try to exchange it,

16:08.000 --> 16:10.000
then their signature wouldn't match.

16:10.000 --> 16:14.000
So, that's another safety check there.

16:14.000 --> 16:15.000
And after that,

16:15.000 --> 16:17.000
you do Fritzord's a web draft

16:17.000 --> 16:20.000
to go access the resource.

16:20.000 --> 16:21.000
Yes,

16:21.000 --> 16:24.000
so that's another new thing we want to add.

16:24.000 --> 16:28.000
That's what it will look like if all these things are added.

16:28.000 --> 16:32.000
We have a test suite

16:32.000 --> 16:34.000
that is testing,

16:34.000 --> 16:36.000
next cloud,

16:36.000 --> 16:38.000
on cloud 10,

16:38.000 --> 16:40.000
certain box,

16:40.000 --> 16:41.000
oasis,

16:41.000 --> 16:43.000
and c-file for these different flows,

16:43.000 --> 16:45.000
the share with flow, the public link flow,

16:45.000 --> 16:47.000
and the invite flow,

16:47.000 --> 16:50.000
Madi Bachbani is maintaining that.

16:50.000 --> 16:51.000
He's doing very good work.

16:51.000 --> 16:53.000
I hope he's watching this stream.

16:53.000 --> 16:55.000
And with that test suite,

16:55.000 --> 16:57.000
we can check that different implementations

16:57.000 --> 16:59.000
of other cloud maps are compatible with each other.

16:59.000 --> 17:02.000
And also, that's easier for vendors.

17:02.000 --> 17:05.000
Like if you have a new version of your own software,

17:05.000 --> 17:09.000
you want to check whether it's still compatible with all the versions of everybody else's software.

17:09.000 --> 17:13.000
And that's why the test suite exists.

17:13.000 --> 17:19.000
And we're now convincing the vendors to include this test suite

17:19.000 --> 17:22.000
in their own continuous integration.

17:22.000 --> 17:25.000
So, already if you're changing your open cloud mesh code,

17:25.000 --> 17:26.000
you can see like,

17:26.000 --> 17:28.000
oh, did I break anything?

17:28.000 --> 17:30.000
Like compatible compatibility,

17:30.000 --> 17:32.000
not only with my own implementation of our cloud mesh,

17:32.000 --> 17:36.000
but also with the three or four elements.

17:36.000 --> 17:37.000
That's it.

17:37.000 --> 17:38.000
Thank you.

17:39.000 --> 17:41.000
Thank you.

17:41.000 --> 17:46.000
We have eight minutes for questions.

17:46.000 --> 17:50.000
I'm not wearing any questions.

17:50.000 --> 17:51.000
Yeah.

17:51.000 --> 17:52.000
Now.

17:52.000 --> 17:54.000
Here.

17:54.000 --> 17:55.000
Here.

17:55.000 --> 17:56.000
Here.

17:56.000 --> 17:57.000
Here.

17:57.000 --> 17:58.000
Here.

17:58.000 --> 17:59.000
Here.

17:59.000 --> 18:00.000
Here.

18:00.000 --> 18:01.000
Here.

18:01.000 --> 18:02.000
Here.

18:02.000 --> 18:03.000
Here.

18:03.000 --> 18:04.000
Here.

18:04.000 --> 18:05.000
Here.

18:05.000 --> 18:06.000
There.

18:06.000 --> 18:07.000
There.

18:07.000 --> 18:08.000
Here.

18:08.000 --> 18:09.000
Here.

18:09.000 --> 18:10.000
Another call.

18:10.000 --> 18:11.000
菸菸.

18:11.000 --> 18:12.000
Um hmm.

18:12.000 --> 18:13.000
What?

18:17.000 --> 18:18.000
Hmm.

18:18.000 --> 18:24.000
There.

18:24.000 --> 18:28.000
There.

18:28.000 --> 18:29.000
Mason.

18:29.000 --> 18:30.000
There.

18:30.000 --> 18:31.000
Yes.

18:31.000 --> 18:32.000
Oh.

18:32.000 --> 18:33.000
All right.

18:33.000 --> 18:43.000
Yeah, so the question is...

18:43.000 --> 18:59.000
Yeah, the question is, what is the difference between open cloud mesh and open id connect?

18:59.000 --> 19:07.000
I don't know, they're probably some parts that you know that I don't know about that actually

19:07.000 --> 19:15.000
detail, but in general, when you say I'm going to federate authentication with open id connect,

19:15.000 --> 19:23.000
that means that you allow other identity providers to provide users to access resources on your server.

19:23.000 --> 19:32.000
So, that is, for instance, what's the same with federated sample, like id you gain.

19:32.000 --> 19:39.000
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.

19:39.000 --> 19:51.000
As far as I know, open id connect does not have a mechanism to then also copy a resource to this other server.

19:51.000 --> 19:56.000
So, you said that, that's also nothing but that.

19:56.000 --> 20:03.000
If a cloud mesh is certain, why are you talking about the cloud mesh exchange user id connect?

20:03.000 --> 20:13.000
Yeah, so in open cloud, sorry, the question was, you said that there's only also this exchange.

20:13.000 --> 20:17.000
So, in open cloud mesh there are two users involved.

20:17.000 --> 20:26.000
So, Alice can say, I want to share this with Bob and then Bob gets a notification in his own server.

20:26.000 --> 20:30.000
That's not something I want to see can do, as far as I know.

20:30.000 --> 20:37.000
So, Bob could, Alice could say, I want to give Bob access to it, a sort of an access control lesson,

20:37.000 --> 20:41.000
Bob can come to my server to access it and authenticate with his own idp,

20:41.000 --> 20:46.000
but that's different from sending a notification to his server,

20:46.000 --> 20:50.000
where in his server he will get a pop-up saying, hi, something to be shared with you,

20:50.000 --> 20:52.000
and that is actually a server to server access.

20:52.000 --> 21:01.000
But you also showed that there is unique to somehow exchange that had a contact in the chat,

21:01.000 --> 21:04.000
and you can do that.

21:04.000 --> 21:07.000
And yeah,

21:07.000 --> 21:12.000
and then you could follow the link there, you can do it,

21:12.000 --> 21:17.000
so yeah, the question is, so you have to share the file email.

21:17.000 --> 21:19.000
It's true that if I want to share a file with you,

21:19.000 --> 21:24.000
and I'm going to send you a link via email, then this might as well be a link on my server,

21:24.000 --> 21:28.000
and then you can log in with your idp.

21:28.000 --> 21:34.000
But that still means that you need to visit my server with your browser,

21:34.000 --> 21:36.000
right, and maybe that's not what you want to do.

21:36.000 --> 21:43.000
So, maybe you want to have a resource in your own server.

21:43.000 --> 21:49.000
And the idea of a cloud message is that everybody looks at their own home environment,

21:49.000 --> 21:52.000
and that these home environments talk to each other.

21:52.000 --> 21:55.000
So that's where the architect is slightly different.

21:55.000 --> 21:58.000
But you're right, they're very similar,

21:58.000 --> 22:03.000
and the important part of this is I think that both OpenID connect,

22:03.000 --> 22:06.000
and now also a cloud message with these new features,

22:06.000 --> 22:11.000
used the same ideas of like exchanging that come from our,

22:11.000 --> 22:15.000
so that's why that's what we do get from that,

22:15.000 --> 22:21.000
saying we think of a cloud message as something that also fits into the our framework,

22:21.000 --> 22:23.000
in a way.

22:23.000 --> 22:25.000
Thank you.

22:25.000 --> 22:26.000
Maybe one.

22:26.000 --> 22:28.000
There was one question here.

22:28.000 --> 22:41.000
Yeah.

22:41.000 --> 22:47.000
The question is, are there any examples of capabilities?

22:47.000 --> 22:50.000
Well, there is a,

22:50.000 --> 22:56.000
one thing is the type of resource and the access protocol.

22:56.000 --> 23:00.000
So the default one is just a file or a folder, access via web dev.

23:00.000 --> 23:02.000
But you can also use it.

23:02.000 --> 23:08.000
And I think next slide talk does this to establish a video call for instance.

23:08.000 --> 23:11.000
And you could have any type of resource.

23:11.000 --> 23:16.000
You could say, yeah, I invite you to my Jupyter notebook,

23:16.000 --> 23:21.000
or something very application specific.

23:22.000 --> 23:27.000
Those are the resource type and the protocols.

23:27.000 --> 23:33.000
And the way we use the capabilities here in the discovery is more about,

23:33.000 --> 23:37.000
does it support the signatures?

23:37.000 --> 23:44.000
Does it support the token exchange?

23:45.000 --> 23:51.000
Does it scan it and force a multi-factor authentication restriction?

23:51.000 --> 23:55.000
That's quite an advanced one that they use in soon at and Sweden.

23:55.000 --> 23:59.000
So you want to make sure that if you share resource with another server,

23:59.000 --> 24:03.000
that that server has the same security policy for instance,

24:03.000 --> 24:08.000
if you say this has to be, this resource can only be viewed using multi-factor authentication.

24:08.000 --> 24:12.000
And then somebody is multi-factor authentication, but shares it with another person.

24:12.000 --> 24:15.000
And there that user is not required to log in with the second factor,

24:15.000 --> 24:17.000
then you have reached that policy.

24:17.000 --> 24:20.000
So that's another capability.

24:20.000 --> 24:23.000
If both servers have the capability to enforce it,

24:23.000 --> 24:26.000
and they trust each other to do that,

24:26.000 --> 24:29.000
then you can, yeah, you can have the MFA capability.

24:29.000 --> 24:32.000
But you can read the internet draft and there's full list.

24:32.000 --> 24:37.000
I think there are three or four now in this pack.

24:37.000 --> 24:38.000
Thank you.

24:38.000 --> 24:40.000
Thank you.

24:40.000 --> 24:45.000
One last question.

24:45.000 --> 24:46.000
Nope.

24:46.000 --> 24:47.000
Thank you very much.

24:47.000 --> 24:48.000
Thank you.

24:48.000 --> 24:55.000
Thank you.