WEBVTT 00:00.000 --> 00:13.000 Open CloudMash. 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 measures and Federation. So, it's not about what computers do 00:27.000 --> 00:32.000 when they talk about each other, 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 CloudMash 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:34.000 I'm such a say, hey, I'm not nice to meet you. But also, at some point, 01:34.000 --> 01:39.000 you want to talk about the users that use each of those servers. 01:39.000 --> 01:44.000 Because you want to start sharing, these users want to share documents with each other. 01:44.000 --> 01:50.000 So, you have to say, oh, yeah, I'm looking for that user on your server. 01:50.000 --> 02:00.000 And you need to refer to resources that they then share to establish the sharing of those resources. 02:00.000 --> 02:07.000 So, the sharing between the users who want to collaborate with each other, 02:07.000 --> 02:12.000 requires that you establish trust between the computers. 02:12.000 --> 02:17.000 Usually we think of Open CloudMash as a way to just ping a user, 02:17.000 --> 02:22.000 but recently we've been working on it a lot and evolving the protocol. 02:22.000 --> 02:26.000 And we see it now more and more as a way to establish the trust. 02:26.000 --> 02:33.000 Because, yeah, it looks so simple. One user clicks share share with in their file system, 02:33.000 --> 02:40.000 in their cloud server. And they say, yeah, share this with user at host, 02:40.000 --> 02:44.000 and then it's federated. Something I guess, right? You type here. 02:44.000 --> 02:48.000 This is an uncloud server. You type here. I want to share this with Einstein 02:48.000 --> 02:53.000 at the next cloud one. Docker. This is for my test environment. 02:53.000 --> 02:58.000 And, yeah, you want to share this file with somebody at another server. 02:58.000 --> 03:04.000 And the user who is the recipient gets notified. 03:04.000 --> 03:07.000 And there will be a dialogue in this case. 03:07.000 --> 03:12.000 Next cloud server says, hey, do you want to add the remote share library from this person 03:12.000 --> 03:19.000 at this cloud server? 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 CloudMash, 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 is working. 03:36.000 --> 03:40.000 And a lot of it is manual testing. Oh, yeah, it's working now, new version, etc. 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:51.000 then by the ScienceMash project. 03:51.000 --> 03:54.000 This year it's funded by NGI and LNet. 03:54.000 --> 03:57.000 That's the name you hear a lot at host them. 03:57.000 --> 04:01.000 And we're hoping that maybe EOSK will fund it going forward. 04:01.000 --> 04:05.000 Yeah, take a picture of that. Thank you. 04:05.000 --> 04:12.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:22.000 And we tried to make it written in such a way that it's strict and clear what it means. 04:22.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:33.000 And there are a number of ways you can do Open CloudMash. 04:33.000 --> 04:35.000 And I'm going to talk through them. 04:35.000 --> 04:38.000 The first one is share with. 04:38.000 --> 04:39.000 I always got to share with. 04:39.000 --> 04:42.000 So that is the one we saw earlier. 04:42.000 --> 04:48.000 Marie says, yeah, share this document with Einstein and types in the name there. 04:48.000 --> 04:51.000 She knows Einstein's Open CloudMash address. 04:51.000 --> 04:57.000 And then Einstein gets notified and keeps accept accept. 04:57.000 --> 05:01.000 And what happens after that is no longer part of the Open CloudMash protocol. 05:01.000 --> 05:07.000 But probably Einstein will get a link saying, oh, here you can find this file, which is actually remote. 05:07.000 --> 05:11.000 And then the service, 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:17.000 It could be your invited to a video call and then a video call as established. 05:17.000 --> 05:24.000 It's Open CloudMash is just about establishing this context in a trustworthy way. 05:24.000 --> 05:32.000 The second one is this, and this is not strictly described by the protocol, but it's used pattern that you see in practice. 05:32.000 --> 05:41.000 When somebody creates a link, you can, from several EFSS systems, you can create a link like this. 05:42.000 --> 05:51.000 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. 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 a next cloud server. 06:00.000 --> 06:08.000 And it says here, add to your next cloud, it should actually say add to any server, add to your server. 06:08.000 --> 06:15.000 And then you type in your own Open CloudMash address here, and then it got saved to your next cloud, you log in. 06:15.000 --> 06:18.000 Then you see, oh, yeah, I saved this to myself. 06:18.000 --> 06:25.000 So that's a nice way of doing Open CloudMash, but there the recipient actually types in their own name. 06:25.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:43.000 And that's about a way in which we can make this scary internet, less scary for the computers, who want to establish contact. 06:43.000 --> 06:52.000 So for these two computers, these two flowers to find each other, the key is that these computers have users. 06:52.000 --> 06:59.000 And these users, these users are trusts this computer, and that user trusts that computer. 06:59.000 --> 07:09.000 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. 07:09.000 --> 07:17.000 So this user can send an invite to the other user via email or WhatsApp or signal or whatever. 07:17.000 --> 07:33.000 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. 07:33.000 --> 07:35.000 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:49.000 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. 07:49.000 --> 07:56.000 And I know it's probably not an evil user, or well, maybe this person is mistaken and click the phishing link. 07:56.000 --> 08:03.000 But as long as the relationship between the humans is trustworthy, then the servers can trust each other through the human link. 08:03.000 --> 08:19.000 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. 08:19.000 --> 08:29.000 So that's how you do that's how you establish trust between the computers 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:41.000 First, the first user generates an in-fot, just about in-generate invitation. 08:41.000 --> 08:51.000 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. 08:51.000 --> 08:59.000 To get the invite, to accept the invite, the basic way is to paste it, to type it here. 08:59.000 --> 09:04.000 But there are two parts of it, you know, you have a token and a provider that's a bit tricky. 09:04.000 --> 09:09.000 You would like to have a better, like, a where are you from page 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 an untechnical part. 09:23.000 --> 09:33.000 So I just want to talk through how all of this looks in a, the swimming diagram, I think. 09:33.000 --> 09:40.000 So suppose that Bob wants to add, Alice has a contact. 09:40.000 --> 09:44.000 And sends an invite token all the way to Alice. 09:44.000 --> 09:50.000 Now this is out of bounds. This might be, might even just be talking, saying, write this down, etc. 09:50.000 --> 09:53.000 There might be talking on the phone to each other. 09:53.000 --> 10:01.000 And then Alice says, yeah, I want to talk to Bob, and that's how the initial trust is established. 10:01.000 --> 10:04.000 The invites help the service trust each other. 10:04.000 --> 10:13.000 Then Alice's server makes a backhand call post invite accepts with the token to Bob's server. 10:13.000 --> 10:18.000 And Bob's server checks the token and says, oh, yeah, this is something that Bob sent. 10:18.000 --> 10:25.000 So now I know that this server is trusted by a human who's trusted by one of my users. 10:25.000 --> 10:33.000 And this server then gets a response with some data about Bob saying, yeah, actually this is my identifier for Bob. 10:33.000 --> 10:36.000 And this is his first and last name for instance. 10:36.000 --> 10:39.000 And then Alice and Bob can have each other in their address book. 10:39.000 --> 10:46.000 And that's nice for the service, but also for Alice and Bob themselves. 10:46.000 --> 10:51.000 So invites are important for security. That's what we sort of found out. 10:51.000 --> 10:58.000 Another thing that's really nice is request signatures, which is being added. 10:58.000 --> 11:12.000 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. 11:12.000 --> 11:18.000 So that you know that a speakhold comes from a certain. 11:18.000 --> 11:24.000 They come from an HTTP client, but that it's running at the part of this a certain server demanding. 11:24.000 --> 11:28.000 So that's how these server can, oh, yeah, you are. 11:28.000 --> 11:34.000 You can see which IP does it come from, and you don't know what it's linked with a real actual server. 11:34.000 --> 11:39.000 And what that service domain name is, but through the request signatures, you can make that link. 11:39.000 --> 11:53.000 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. 11:53.000 --> 11:58.000 And then when Max Hans said, hey, let's do requesting. 11:58.000 --> 12:09.000 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. 12:09.000 --> 12:11.000 And that suddenly made it much simpler. 12:11.000 --> 12:15.000 So then we specify the authorization code flow. 12:15.000 --> 12:18.000 It's in the internet draft. Nobody implemented yet. 12:18.000 --> 12:23.000 I'm hoping a certain is implementing it soon. 12:23.000 --> 12:34.000 Because there you can use a signature to obtain a token 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:43.000 Most actually, the way it's used now is in the invite. 12:43.000 --> 12:47.000 There's a secret included, and that becomes the access token. 12:47.000 --> 12:53.000 Which is, you know, it's safe, but it's not up to modern standards. 12:53.000 --> 12:59.000 So that's why we think that in the invite, there can be, first of all, that needs to be assigned request. 12:59.000 --> 13:05.000 And second of all, the, the nonsense in there should just be a code that needs to be exchanged. 13:05.000 --> 13:11.000 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. 13:12.000 --> 13:18.000 So they have a second check there. And then you give out tokens, which can be short lived and refreshable. 13:18.000 --> 13:27.000 So that's sort of basic 101, without that, we're not even talking about security for, like, aloft people, et cetera. 13:27.000 --> 13:32.000 So that's why we want to add these features to, 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:45.000 So, which, this is the part I already showed. 13:45.000 --> 13:50.000 After that, there is a capability discovery. 13:50.000 --> 13:54.000 There might be different capabilities for different servers. 13:54.000 --> 13:59.000 So we added a, it used to be called slash OCM, high from provider. 13:59.000 --> 14:03.000 And we renamed it slash dot well known slash OCM. 14:03.000 --> 14:08.000 And there's still the fallback to the old path, but this is just a little bit, uh, neater placed. 14:08.000 --> 14:11.000 And there you can discover the API endpoints. 14:11.000 --> 14:15.000 Also, the capabilities of that server, like which features does it implement. 14:15.000 --> 14:18.000 And it's public key, which you will need for the request signing. 14:18.000 --> 14:23.000 So, um, that's the discovery you start from a domain name. 14:23.000 --> 14:29.000 And then, um, you look up the well known, uh, and then you just got some JSON with the information. 14:29.000 --> 14:37.000 Um, after that, you do the actual OCM share call, uh, the share creation notification. 14:37.000 --> 14:46.000 So, um, here, this server does a signed post to slash OCM slash share, uh, to that server. 14:46.000 --> 14:54.000 And then the new thing, if there was an invite flow, um, which is optional, but if there was one, 14:54.000 --> 15:00.000 then you can check the invite like, hey, is this person who is sending, um, something to my user, 15:00.000 --> 15:05.000 is that actually a contact that was established through an actual OCM invite. 15:05.000 --> 15:13.000 Um, after that, you, this server will do a look up to get the public key with which to check the signature. 15:13.000 --> 15:22.000 And then if those checks pass, then the share is created, uh, meaning that the receiving server says, yeah, 15:22.000 --> 15:31.000 uh, thank you for, um, uh, sharing the resource, and, uh, I will notify my user. 15:31.000 --> 15:38.000 After that, and this is a step, that we, um, invented, but that nobody implement yet. 15:38.000 --> 15:48.000 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, 15:48.000 --> 16:00.000 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. 16:00.000 --> 16:09.000 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. 16:09.000 --> 16:14.000 So that's another, um, safety check there. 16:14.000 --> 16:20.000 Uh, and after that, you do frizzards, a web that I've profined to go access to resource. 16:20.000 --> 16:24.000 Um, yes, 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:38.000 Um, we have a, um, test suite that is testing, testing next cloud, uh, on cloud 10, uh, 16:38.000 --> 16:45.000 certain box, uh, osis, and c file for these different flows, the share with flow, the public link flow. 16:45.000 --> 16:50.000 And the invite flow, uh, Madi Bapani is, um, maintaining that. 16:50.000 --> 16:53.000 He's doing very good work. I hope he's watching this stream. 16:53.000 --> 16:58.000 And, um, with that test suite, we can check that different implementations of all the cloud, 16:58.000 --> 17:02.000 are compatible with each other. And also that's easier for vendors. 17:02.000 --> 17:07.000 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, 17:07.000 --> 17:13.000 versions of everybody else's software. And that's why the test suite, uh, exists. 17:13.000 --> 17:19.000 And we're now, uh, convincing the vendors to include this test suite in their own, 17:19.000 --> 17:25.000 continuous integration. So that already if you're changing your open cloud mesh code, 17:25.000 --> 17:29.000 you can see like, oh, did I break anything like compatible compatibility, 17:29.000 --> 17:35.000 not only with my own implementation of a cloud mesh, but also with the, uh, three or four other ones. 17:36.000 --> 17:38.000 That's it. Thank you. 17:45.000 --> 17:49.000 Thank you. We have eight minutes for questions. 17:49.000 --> 17:51.000 Any questions? 17:52.000 --> 17:54.000 Yeah. 17:58.000 --> 17:59.000 Yeah. 18:21.000 --> 18:43.000 Yeah. So the question is, 18:44.000 --> 18:57.000 what is the difference between open cloud mesh and open ID connect? 18:57.000 --> 19:06.000 Um, the way I don't know, um, they're probably some parts that you know that I don't know about that, 19:06.000 --> 19:15.000 actually, 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:26.000 So, um, 19:26.000 --> 19:29.000 that is, for instance, what, uh, 19:30.000 --> 19:34.000 what's the same with, like, federated sample, like adugane, a lot of, uh, 19:34.000 --> 19:40.000 universities use that, like if you want to log in to certain, you can log in with your identity from the University of Helsinki. 19:40.000 --> 19:51.000 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. 19:51.000 --> 19:53.000 So, um, 19:54.000 --> 20:12.000 yeah. So in open cloud, sorry, the, um, yeah, the, the question was, you said that there's only also, um, this exchange. 20:12.000 --> 20:17.000 So the, um, uh, in open cloud mesh, there are two users involved. 20:17.000 --> 20:26.000 So, um, 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 as sort of an access control lesson, 20:37.000 --> 20:42.000 and Bob can come to my server to access it and authenticate with his own IDP, 20:42.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:02.000 But you also showed that there is unique to somehow exchange with had the content in the chat. 21:02.000 --> 21:04.000 Yeah. 21:04.000 --> 21:06.000 And yeah. 21:06.000 --> 21:10.000 And then you can order a link there. 21:10.000 --> 21:12.000 We don't make connections. 21:12.000 --> 21:13.000 Sure. 21:13.000 --> 21:17.000 So, yeah, the question is so you, you have to share the file, you know. 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:35.000 Right? 21:35.000 --> 21:36.000 And maybe that's not what you want to do. 21:36.000 --> 21:43.000 So maybe you want to have it, you have a resource in your own server. 21:43.000 --> 21:49.000 And the idea of open cloud messages 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 open ID connect, 22:03.000 --> 22:06.000 and now also open cloud messages with these new features, 22:06.000 --> 22:10.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 open cloud messages as something that also fits into the old framework, 22:21.000 --> 22:22.000 in a way. 22:24.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:56.000 Well, there is a one thing is the type of resource and the access protocol. 22:56.000 --> 23:00.000 So the default one is folder access via web dev. 23:00.000 --> 23:08.000 But you can also use it and I think next time talk to us is to establish a video call for instance. 23:08.000 --> 23:10.000 And you could have any type of resource. 23:10.000 --> 23:19.000 You could say, yeah, I invite you to my Jupyter notebook or something very application specific. 23:19.000 --> 23:25.000 And those are the resource type and the protocols. 23:26.000 --> 23:32.000 And the way we use the capabilities here in the discovery is more about, 23:32.000 --> 23:35.000 does it support the signatures? 23:35.000 --> 23:43.000 It's basically, does it support the token exchange? 23:43.000 --> 23:50.000 Does it scan it and force a multi-factor authentication restriction? 23:50.000 --> 23:54.000 That's quite an advanced one that they use in soon at and suede. 23:54.000 --> 23:58.000 So you want to make sure that if you share resource with another server, 23:58.000 --> 24:02.000 that server has the same security policy for instance. 24:02.000 --> 24:07.000 If you say this has to be, this resource can only be viewed using multi-factor authentication. 24:07.000 --> 24:11.000 And then somebody is multi-factor authentication, but shares it with another person. 24:11.000 --> 24:14.000 And there, that user is not required to log in with the second factor. 24:14.000 --> 24:16.000 Then you have reached that policy. 24:16.000 --> 24:19.000 So that's another capability. 24:19.000 --> 24:22.000 If both servers have the capability to enforce it, 24:22.000 --> 24:25.000 and they trust each other to do that, 24:25.000 --> 24:29.000 then you can, yeah, you 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:36.000 I think there are three or four now in this pack. 24:36.000 --> 24:37.000 Thank you. 24:37.000 --> 24:39.000 Thank you. 24:39.000 --> 24:44.000 One less question. 24:44.000 --> 24:46.000 No, thank you very much. 24:46.000 --> 24:47.000 Thank you. 24:47.000 --> 24:50.000 Thank you.