WEBVTT

1
00:00:03.290 --> 00:00:14.300
IT 31/2-028: Okay, so let's start this workshop. Thanks to everyone for for connecting hopefully, we get a few more people in the coming minutes as a

2
00:00:14.620 --> 00:00:23.479
IT 31/2-028: as we go. So these are really short introduction. Just to get a bit bit context. And here the idea really would be to have a

3
00:00:23.820 --> 00:00:29.830
IT 31/2-028: taking a focused worship for A for us to have a monitor inflection

4
00:00:30.000 --> 00:00:38.309
IT 31/2-028: in particular. Given that there's been a lot of work, a lot of discussions around around us again in the last months.

5
00:00:38.370 --> 00:00:43.085
IT 31/2-028: and so we thought, it's a good moment to to have a have this reflection now

6
00:00:44.290 --> 00:00:55.741
IT 31/2-028: also given, that then the main events of the community is really the conference within March. And actually, the registration has just opened. We got that from the

7
00:00:56.160 --> 00:01:06.110
IT 31/2-028: from the organization committee. Now, I'm also the principal. So there will be for sure assembly of this workshop at the 3 event.

8
00:01:06.200 --> 00:01:07.390
IT 31/2-028: and

9
00:01:07.480 --> 00:01:17.690
IT 31/2-028: possibly some other document. We'll try and do something, maybe with a similar format like the last time, or different, we- we'll see how- how this will will work out.

10
00:01:17.840 --> 00:01:26.439
IT 31/2-028: But okay, this today is more like getting a little bit deeper into the technical aspects. And all this kind of discussion.

11
00:01:27.010 --> 00:01:34.810
IT 31/2-028: So the agenda is essentially in 2 parts, but the timing is very rough. We go as- as

12
00:01:34.930 --> 00:01:38.179
IT 31/2-028: as as we see things. And it's not really.

13
00:01:38.810 --> 00:01:42.180
IT 31/2-028: It's already super super strict. Let's say so

14
00:01:42.240 --> 00:01:45.820
IT 31/2-028: it should be. It should be fine. We are the 1st

15
00:01:45.840 --> 00:01:49.989
IT 31/2-028: a quick status report by the different implementers.

16
00:01:50.180 --> 00:01:55.370
IT 31/2-028: and they got confirmation From- from Jonathan that should connect with me soon.

17
00:01:55.540 --> 00:02:10.049
IT 31/2-028: for C. 5. I did not get a confirmation from Cloud. Then I got a confirmation from Excel here and now we give myself a staff support about sandbox.

18
00:02:10.310 --> 00:02:14.719
IT 31/2-028: So those are, let's say, the 4 major implementations that we know about. So

19
00:02:15.910 --> 00:02:23.338
IT 31/2-028: whether there is anything else that any anyone else that knows about other implementations. And maybe somebody was shocked.

20
00:02:24.060 --> 00:02:36.269
IT 31/2-028: and then the second part will dive a little bit more into what has happened in those months, especially this funded project that was led by Mihil.

21
00:02:38.150 --> 00:02:42.460
IT 31/2-028: So this is more like going into

22
00:02:44.140 --> 00:02:50.609
IT 31/2-028: yeah, into essentially the work that has happened in the last in the last couple of months.

23
00:02:53.360 --> 00:03:02.660
IT 31/2-028: in particular. Well, okay, one thing showing it now, kind of breaking news reports is that we we talked.

24
00:03:02.980 --> 00:03:12.250
IT 31/2-028: and another new version of of the same standard, which is again to 1.0.

25
00:03:13.040 --> 00:03:14.430
IT 31/2-028: The

26
00:03:14.450 --> 00:03:35.050
IT 31/2-028: I would say, the biggest. Here is the fact that there have been a significant effort to transform the format of the specification in such a way that it is now in the format that is the typical format of the for the task force maintenance. Essentially

27
00:03:35.090 --> 00:03:41.307
IT 31/2-028: so. This has been submitted, and this is this is the link. The link is also in the in the record, anyway.

28
00:03:41.620 --> 00:03:46.870
IT 31/2-028: and this is the usual spec rendering a

29
00:03:46.940 --> 00:03:50.211
IT 31/2-028: of the of the specification as this today.

30
00:03:52.230 --> 00:03:55.399
IT 31/2-028: This is a little extractor of this

31
00:03:55.450 --> 00:03:59.290
IT 31/2-028: of the of the dust, let's say, of the Rfc.

32
00:03:59.860 --> 00:04:10.850
IT 31/2-028: Which is now indeed open for comments, except in the in the traditional ways of- of our right. This is effectively.

33
00:04:10.870 --> 00:04:12.870
IT 31/2-028: effectively.

34
00:04:13.410 --> 00:04:20.709
IT 31/2-028: yeah, the process actually, at this point. Well, okay, I guess we here actually hold on. See me here. Now, we'll give more details about

35
00:04:20.790 --> 00:04:25.920
IT 31/2-028: the process there. So what- what's going to happen next? I understand we have to kind of

36
00:04:26.320 --> 00:04:36.539
IT 31/2-028: sponsor this a little bit so that it's taken into account. It goes into some kind of approval, and then it gets into into consideration. Otherwise it sits there without so much

37
00:04:36.610 --> 00:04:41.411
IT 31/2-028: much movement. Sorry. Okay, we'll see.

38
00:04:42.160 --> 00:04:51.200
IT 31/2-028: We'll see as we go on. And okay, I I look forward to hear from from him about about this.

39
00:04:52.150 --> 00:04:57.080
IT 31/2-028: So with that said at this point so, and

40
00:04:57.160 --> 00:05:00.149
IT 31/2-028: I still don't see Jonathan, despite the

41
00:05:00.450 --> 00:05:10.280
IT 31/2-028: the reminder that sent. So the list of so just to go back to the agenda, the list is deliberately in order.

42
00:05:10.460 --> 00:05:13.639
IT 31/2-028: The thing is that these are sort of

43
00:05:13.830 --> 00:05:23.690
IT 31/2-028: cover a little bit the time zones, because is is in Asia, whereas maximum is 2 h behind one or 2 h behind us.

44
00:05:23.840 --> 00:05:31.990
IT 31/2-028: So we thought to make it a little bit, you know, in- in a more convenient focus.

45
00:05:32.590 --> 00:05:34.820
IT 31/2-028: we should get the time for people to connect.

46
00:05:37.030 --> 00:05:42.520
IT 31/2-028: Okay? So when we could also do

47
00:05:43.140 --> 00:05:52.766
IT 31/2-028: something else like we skip Si-fi, and as soon as we connect we see, because then we have, as I mentioned at the beginning, people were not connected

48
00:05:53.575 --> 00:06:00.179
IT 31/2-028: have a confirmation from this cloud. I don't have a confirmation from our cloud, so I can actually report what I know about the cloud. But this is.

49
00:06:00.250 --> 00:06:08.750
IT 31/2-028: this is 3 min. So what I know there is that particular office is the new version of a cloud.

50
00:06:08.960 --> 00:06:15.369
IT 31/2-028: Do you done the necessary reporting in such a way that

51
00:06:15.390 --> 00:06:19.510
IT 31/2-028: because- because this is part of of this European

52
00:06:20.030 --> 00:06:23.740
IT 31/2-028: pender, say, say, or a cold.

53
00:06:23.870 --> 00:06:34.810
IT 31/2-028: and so they made it such that for the European open source cloud. They just works with Ocm 1.1.

54
00:06:35.290 --> 00:06:43.619
IT 31/2-028: And I've got this information from class and class. And it told me, this is a public information. This you can share. There's actually not all of

55
00:06:43.960 --> 00:06:49.589
IT 31/2-028: then the problems they have are correlated with the relations with this is also well known that they've been

56
00:06:49.900 --> 00:06:51.997
IT 31/2-028: on cloud has been bought by catwalks, and

57
00:06:52.400 --> 00:06:58.290
IT 31/2-028: the evolution in the coming months is not clear possible to anyone, so I cannot say much.

58
00:06:58.660 --> 00:07:01.780
IT 31/2-028: and probably nobody knows actually what is going to happen.

59
00:07:01.890 --> 00:07:06.500
IT 31/2-028: Yes, on Cloud will be joining the worship in Munich.

60
00:07:06.810 --> 00:07:11.260
IT 31/2-028: and I guess next month as well. That should this time we are so close to you guys that

61
00:07:11.270 --> 00:07:20.160
IT 31/2-028: you should come in in mass. Right? So there, I expect we expect to have some more information from them.

62
00:07:20.590 --> 00:07:27.570
IT 31/2-028: This could be, let's say, let's see what- what- what they will announce. What will happen.

63
00:07:27.830 --> 00:07:29.520
IT 31/2-028: 2055.

64
00:07:32.820 --> 00:07:36.019
IT 31/2-028: Any comments so far from anyone. Just to

65
00:07:40.890 --> 00:07:46.070
IT 31/2-028: so, if not, this was a different

66
00:07:46.570 --> 00:07:56.379
IT 31/2-028: or something. I will applaud. The slides, anyway, is is totally fine.

67
00:07:59.100 --> 00:08:04.890
Micke Nordin | Sunet: Maybe we can move your presentation of cernbox until now and then.

68
00:08:04.970 --> 00:08:07.840
Micke Nordin | Sunet: So Moxanse has a chance to.

69
00:08:08.749 --> 00:08:30.460
IT 31/2-028: Because I don't think we connect because he knows that we'll connect later and also behind. So yes, I can go ahead with the with, Yeah, let's- let's do that so that we don't lose too much time. And then hopefully, we get Jonathan. Meanwhile, I'm watching the list of participants in case.

70
00:08:31.100 --> 00:08:35.189
IT 31/2-028: Okay? So then let's go into into the sandbox password.

71
00:08:36.919 --> 00:08:44.506
IT 31/2-028: So current status of the standalone. Let's say

72
00:08:45.940 --> 00:08:54.700
IT 31/2-028: I should remind people that Riva is an open source project where also cloud continues. But the fact of today. And already, since last conference.

73
00:08:54.830 --> 00:08:58.480
IT 31/2-028: we have a 2 forks in River 1 4 is

74
00:08:58.800 --> 00:09:10.560
IT 31/2-028: the is what all cloud has incorporated into- into office. The let's say the main form, master form, is what we run standalone

75
00:09:10.800 --> 00:09:13.299
IT 31/2-028: for the back end of sandbox.

76
00:09:13.540 --> 00:09:24.080
IT 31/2-028: So sandbox is based on Reba Cluster Branch, and it's a it's essentially a fault. I mean, the fork has happened already so long time ago that

77
00:09:24.560 --> 00:09:29.430
IT 31/2-028: it's a number of things have diverged from the presentation that is embedded into into office.

78
00:09:30.170 --> 00:09:38.849
IT 31/2-028: And what we did is that when we're seeing 1.1 implementation, this is. This was exactly like it was already in the in the

79
00:09:39.527 --> 00:09:49.289
IT 31/2-028: well. We had the conference. This is the Conference back in March, and so this is a short time. So we have this workflow that was actually prototype in the Sales Mesh project.

80
00:09:49.520 --> 00:09:53.619
IT 31/2-028: We have the support for web update that that protocols

81
00:09:54.740 --> 00:10:09.109
IT 31/2-028: to be said that the web app and this was actually proven. And we even used in production model. The data process was proven in a kind of proof of concept was never really delivered to any user. So it's a very early stage of development.

82
00:10:09.910 --> 00:10:20.900
IT 31/2-028: And okay, because of science based the way that this workflow works is connected to our Directory kind of a loud list of Whitelist. Let's call it a loud list.

83
00:10:20.990 --> 00:10:23.769
IT 31/2-028: We don't call it in the standard.

84
00:10:23.940 --> 00:10:27.597
IT 31/2-028: for who can send you invites right.

85
00:10:28.200 --> 00:10:32.059
IT 31/2-028: But the-, the code, the implementation is also.

86
00:10:32.110 --> 00:10:33.780
IT 31/2-028: This was open to

87
00:10:34.040 --> 00:10:42.680
IT 31/2-028: allow any level of part, so this would be the pure way of work. Basically, you can. You can invite anyone just by sending them

88
00:10:42.870 --> 00:10:53.860
IT 31/2-028: something, and then they would. They would be able to connect it. And you will still be able to to share with anyone excepting- except in the core.

89
00:10:53.890 --> 00:11:02.310
IT 31/2-028: total console, sharing completely open-open sharing. So this depends on the configuration now, in terms of usage.

90
00:11:02.440 --> 00:11:06.090
IT 31/2-028: This was done. This was tested as part of sandpress.

91
00:11:06.690 --> 00:11:11.140
IT 31/2-028: It was not deployed in production in the production service, and this was a

92
00:11:11.240 --> 00:11:16.410
IT 31/2-028: mostly because we never got to the point of really having a

93
00:11:16.600 --> 00:11:20.300
IT 31/2-028: a large size base that moved after

94
00:11:20.380 --> 00:11:22.970
IT 31/2-028: the people of the actual stage. Let's say so.

95
00:11:23.380 --> 00:11:29.080
IT 31/2-028: So then I think nobody really put this in place

96
00:11:29.180 --> 00:11:42.750
IT 31/2-028: except in the all cloud, because the implementation that also is now featured just mentioned before, and talk to him more afterwards is actually based on this implementation. So they posted it to to their

97
00:11:42.940 --> 00:11:53.540
IT 31/2-028: ring, a fork, and so also the same implementation, and with the same concept of having a directory of of trusted sites.

98
00:11:55.290 --> 00:12:04.109
IT 31/2-028: There's also one aspect here that it really connects with the with the status of sound, the way that works is that all of the collaborators eventually get us an account.

99
00:12:04.320 --> 00:12:09.334
IT 31/2-028: So the scope for Sierra is a little bit smaller. It's not so

100
00:12:09.800 --> 00:12:12.929
IT 31/2-028: not so required. But if people are able to share

101
00:12:13.390 --> 00:12:18.409
IT 31/2-028: essentially to anyone, just because the people under colleagues, anyway, have a sub account.

102
00:12:18.460 --> 00:12:26.839
IT 31/2-028: or nowadays, they can also get affiliated account through the same identity provider identity system. So why this

103
00:12:27.020 --> 00:12:31.533
IT 31/2-028: you already collect the server that we have so? Because of that.

104
00:12:32.340 --> 00:12:35.890
IT 31/2-028: indeed, the scope for is a little bit smaller.

105
00:12:36.150 --> 00:12:37.520
IT 31/2-028: No place.

106
00:12:37.630 --> 00:12:42.876
IT 31/2-028: Something happened this year, despite the effort available, was really really very thin.

107
00:12:43.500 --> 00:12:51.384
IT 31/2-028: and this we mentioned it already back there, and I could see on my on my shoulders. Of this meant because

108
00:12:51.840 --> 00:12:58.149
IT 31/2-028: effectively, the team has shrunk a lot. So we were. We had just had enough to- to- to cover the normal questions.

109
00:12:58.300 --> 00:13:11.420
IT 31/2-028: So what happened just went yesterday through the pull request. Everything that was more or less looking. Those pull requests.

110
00:13:11.530 --> 00:13:18.200
IT 31/2-028: Actually, one of them belongs to to the other branch, but but it actually applies also. This was

111
00:13:18.240 --> 00:13:23.139
IT 31/2-028: so. The form of the angle where I should apply it to the to the master folder.

112
00:13:23.220 --> 00:13:28.819
IT 31/2-028: You even see different contributors. Thanks, Mandy, for actually contributing this this one.

113
00:13:30.180 --> 00:13:48.110
IT 31/2-028: and probably the most interesting bit here is that we already took in one of the features of the new standard, which is the fact of not exposing the secret as part of the which was a kind of shortcut that we took during the moment. But okay, it's

114
00:13:48.210 --> 00:13:56.590
IT 31/2-028: acknowledged. It has been discussed a lot that if you put secrets in A and the Us. Get logged anywhere, and it goes through proxies. It goes through

115
00:13:56.610 --> 00:14:03.350
IT 31/2-028: whatever. So you don't want secrets, food totally visible there. So you want those.

116
00:14:03.350 --> 00:14:05.250
Michiel de Jong: Question about this Giuseppe.

117
00:14:05.570 --> 00:14:06.300
IT 31/2-028: Yeah.

118
00:14:07.199 --> 00:14:20.230
Michiel de Jong: So the bear you put the bear token in the authorization header. That's different from what other 1.0 implementations do they use basic off right.

119
00:14:21.002 --> 00:14:23.359
IT 31/2-028: Correct. Yes, so this is a

120
00:14:23.460 --> 00:14:30.770
IT 31/2-028: and, in fact, what that is there is. So remember, I think that

121
00:14:30.830 --> 00:14:36.370
IT 31/2-028: I'm able to contact a 1.0 server by using basic accounts.

122
00:14:36.380 --> 00:14:43.340
IT 31/2-028: but I pretended that whatsoever to contact me only with with authentication very topic

123
00:14:43.560 --> 00:14:55.649
IT 31/2-028: this is that the only header, I think, is a better-, a better header, not a basic header. The same way it's the same header. So I expect an authorization better secret and not authorization basic

124
00:14:55.660 --> 00:15:06.870
IT 31/2-028: with the secret as the username, which also is not very secure and identity password, which was the 1.0 access method. So it's kind of.

125
00:15:07.040 --> 00:15:12.200
Michiel de Jong: You also implemented the basic of both for sending and for receiving.

126
00:15:13.160 --> 00:15:18.950
IT 31/2-028: It's for accessing the remote, but not for receiving remote calls. So it's asymmetric.

127
00:15:19.560 --> 00:15:27.060
Michiel de Jong: So you cannot share to other servers, then you cannot share to a 1.0 from cernbox to a 1.0 server.

128
00:15:28.613 --> 00:15:34.000
IT 31/2-028: They can share with me, but they cannot share with them, because they won't be able to access me.

129
00:15:34.920 --> 00:15:38.859
Michiel de Jong: And is that still enough? Is that still something you plan to implement.

130
00:15:40.206 --> 00:15:51.263
IT 31/2-028: That is, that is, actually, I tried to do that. But there is a problem there. That is the way, let's say, start to work around a little bit. In fact.

131
00:15:51.640 --> 00:15:55.340
IT 31/2-028: the way I instructed the header because it's the same header

132
00:15:55.880 --> 00:16:10.569
IT 31/2-028: is like, I can either put the Oh, wait a second. No, it's actually sorry- sorry. So if I find the basic out, I use it. If I find the better out, I use it.

133
00:16:11.310 --> 00:16:21.099
IT 31/2-028: But then the other way around. What so which means that they can share to anyone and people can access external users can access sandbox. So it's exactly the positive.

134
00:16:21.120 --> 00:16:26.340
IT 31/2-028: Whereas if I if I get a share from 1.3 representation.

135
00:16:27.400 --> 00:16:29.129
IT 31/2-028: and they try to access it.

136
00:16:29.310 --> 00:16:37.199
IT 31/2-028: because at the moment I don't do the discovery, the proper way of doing the discovery, I try to access it with a better token. And this space.

137
00:16:37.490 --> 00:16:40.599
IT 31/2-028: Now this can be fixed by using the discovery.

138
00:16:40.610 --> 00:16:49.158
IT 31/2-028: So part of the plan. And this comes in next slide is implement what is missing in. So get to 1.2

139
00:16:49.620 --> 00:16:51.299
IT 31/2-028: and implement the problems for you.

140
00:16:51.460 --> 00:17:00.939
IT 31/2-028: So if I do the proper discovery at that point I can. I can send off when I access the remote server, anything basic out or better, out.

141
00:17:01.700 --> 00:17:02.330
Michiel de Jong: Yeah, even as.

142
00:17:02.330 --> 00:17:02.940
IT 31/2-028: And then.

143
00:17:03.140 --> 00:17:14.930
Michiel de Jong: Even as a quick fix. Without discovery you could do a fallback, you say? Well, if bearer or authorization bearer gives a 4 0, 3. Then you try authorization. Basic.

144
00:17:16.890 --> 00:17:17.270
Michiel de Jong: But yeah.

145
00:17:17.692 --> 00:17:29.509
IT 31/2-028: Can put that fixing. Yes, good point. That would be actually a rather simple request that doing the in the as of today, without even going from there.

146
00:17:29.510 --> 00:17:29.980
Michiel de Jong: Nice.

147
00:17:30.389 --> 00:17:30.799
Michiel de Jong: Nice.

148
00:17:30.800 --> 00:17:32.720
Michiel de Jong: Okay. Sorry for the interruption.

149
00:17:32.720 --> 00:17:42.549
Frank Karlitschek: Ask a question. So why exactly was this change done? I mean it creates complexity, it creates incompatibility, it creates unnecessarily work, and all the vendors.

150
00:17:42.720 --> 00:17:49.590
Frank Karlitschek: and we already don't have a ton of implementations of Ocm. Right? As we know, we have just a bunch of small players here.

151
00:17:49.710 --> 00:17:56.470
Frank Karlitschek: So why, why, why it was this done? But do we need to create this complexity and work.

152
00:17:57.360 --> 00:18:06.699
IT 31/2-028: Well the complexity there came from the fact that we wanted to move away and went from this basic out. Because basic out is also kind of deprecated as much as

153
00:18:06.820 --> 00:18:10.209
IT 31/2-028: sharing secrets, I mean, as far as understand.

154
00:18:10.270 --> 00:18:22.749
IT 31/2-028: because the secret at the moment is put as the username, not as the password. The username is not considered as sensitive information, so it can be. It can link anywhere in proxies, etcetera, exactly like, if you put the secret.

155
00:18:22.750 --> 00:18:25.119
Frank Karlitschek: It has dls encryption right?

156
00:18:26.080 --> 00:18:30.570
IT 31/2-028: Okay, sir. So then the idea was that we should convert into

157
00:18:30.820 --> 00:18:32.619
IT 31/2-028: the proper way would be forever

158
00:18:32.690 --> 00:18:35.869
IT 31/2-028: a secret that is passed as a parent token.

159
00:18:36.360 --> 00:18:51.587
IT 31/2-028: So it goes nowhere else than in the token, and then the that you choose will be with a with a different identity. Identifiers so would which can be anything. It can be the folder name. It can be a new.

160
00:18:52.160 --> 00:18:58.249
IT 31/2-028: whatever that one would be. And that's actually that is typically what the key that you put in the database

161
00:18:58.460 --> 00:19:00.650
IT 31/2-028: so that they know. Okay, somebody access.

162
00:19:00.650 --> 00:19:08.300
Frank Karlitschek: I just have to fear that this will. This will shrink our already tiny community here. And not grow it, which is the real goal.

163
00:19:08.550 --> 00:19:09.949
Frank Karlitschek: But maybe that's only me.

164
00:19:10.870 --> 00:19:23.650
IT 31/2-028: Well, eventually, by doing this, this phone back as exactly as mentioned this would be, would ease the transition. I mean, the transition is not that complicated to go from from basic to better optimization

165
00:19:24.020 --> 00:19:39.299
IT 31/2-028: and anything else that comes on top of this policy afterwards, it's actually capabilities. So it on a very, very basic level. Everything is compatible remains compatible. It's just that this basic out is in itself something that we should move away from.

166
00:19:40.090 --> 00:19:44.600
Frank Karlitschek: Okay, I'm looking forward to a pull request from you to implement this in the next cloud survey.

167
00:19:44.990 --> 00:19:47.289
Micke Nordin | Sunet: It's a already have one.

168
00:19:48.230 --> 00:19:48.550
IT 31/2-028: Yep.

169
00:19:48.970 --> 00:19:49.760
Frank Karlitschek: Okay.

170
00:19:49.760 --> 00:19:50.190
IT 31/2-028: It is.

171
00:19:50.190 --> 00:19:50.700
Micke Nordin | Sunet: So.

172
00:19:51.632 --> 00:20:00.020
IT 31/2-028: We'll probably share exactly this work that has happened.

173
00:20:00.330 --> 00:20:09.969
IT 31/2-028: Plus Microsoft was the one. Okay, now, but in this particular context it was the one even proposing to have a signed request.

174
00:20:10.100 --> 00:20:13.559
IT 31/2-028: Now, if you introduce Sunday requests.

175
00:20:13.600 --> 00:20:21.250
IT 31/2-028: this makes it even more complex, but if you do it in a backward, compatible way. Then you you would allow for both to coexist.

176
00:20:21.410 --> 00:20:24.470
IT 31/2-028: Of course we don't have anyone using sign the requests

177
00:20:24.530 --> 00:20:27.559
IT 31/2-028: like this. You would like to to have an upgrade path.

178
00:20:27.590 --> 00:20:34.149
IT 31/2-028: But ideally, this is where we want to go. So we want to make sure that that we can trust the remote party.

179
00:20:36.320 --> 00:20:54.310
IT 31/2-028: Okay, so this is what has happened in terms of the limit. So anyway, very limited, not really much. Then, in terms of testing so far, we managed to actually, so far until summer, we managed to run tests on top of about 4 vm. Which was there project.

180
00:20:54.490 --> 00:21:04.255
IT 31/2-028: This was important, because this is dead. We have to dismantle it and take out of the framework, etcetera.

181
00:21:04.950 --> 00:21:27.110
IT 31/2-028: Meanwhile we have this container based what we call this Mini desktop. That is all based on containers and scripts to run everything into containers in a very self contained way. I said a lot of that, but we learned that the sandbox implementation can stand alone. So with the local storage provider is actually

182
00:21:27.270 --> 00:21:31.849
IT 31/2-028: are broken, and this requires a little bit of

183
00:21:32.120 --> 00:21:41.179
IT 31/2-028: development. So here the let's say, my-by, divided at this point is like, shall I try and do

184
00:21:41.190 --> 00:21:52.289
IT 31/2-028: a mini containerization set up for sandbox videos which is guaranteed to work. And we know that we're gonna be using a container? Or should we invest a little bit of time

185
00:21:52.720 --> 00:21:56.592
IT 31/2-028: on this driver so that we can do a mini sandbox without use?

186
00:21:59.540 --> 00:22:03.830
IT 31/2-028: Busy this, but not entirely. I'm not entirely decided on that

187
00:22:04.260 --> 00:22:10.530
IT 31/2-028: now, what's next? So one thing one good thing is that within the sample

188
00:22:10.580 --> 00:22:22.129
IT 31/2-028: we already got a new person down last last month, and we're expecting more people next year, which means that we have a little bit of more margin to development.

189
00:22:22.350 --> 00:22:26.499
IT 31/2-028: and given the the kind of institution interested in having

190
00:22:26.720 --> 00:22:32.340
IT 31/2-028: keeping up with the same standard, and in particular the fact that we have the institutions that actually

191
00:22:32.520 --> 00:22:39.659
IT 31/2-028: want to learn channels. Now, smaller institutions are much more interesting, but they don't like the trick that 7 is using.

192
00:22:39.870 --> 00:22:41.940
IT 31/2-028: But then one gets his account.

193
00:22:42.560 --> 00:22:55.019
IT 31/2-028: So that's a that's where whereas it looks itself plays a place an interesting process, let's say.

194
00:22:55.040 --> 00:22:56.739
IT 31/2-028: makes it makes a difference.

195
00:22:58.620 --> 00:23:06.964
IT 31/2-028: So with that. So my my wish, and let's say at least, my commitment

196
00:23:07.620 --> 00:23:14.169
IT 31/2-028: for the team who did once you implement at this part of the capabilities when you started into into

197
00:23:15.880 --> 00:23:19.142
IT 31/2-028: yeah, into the work line of next year.

198
00:23:19.860 --> 00:23:28.000
IT 31/2-028: and in that respect also, testing something has to has to happen. So here I have a

199
00:23:28.080 --> 00:23:40.538
IT 31/2-028: like thank for following up the tests and doing all the things around there. He will present the test suite, and unfortunately, the sandbox. I've seen it already. It's not there because he did. We have. We are missing this

200
00:23:40.900 --> 00:23:52.380
IT 31/2-028: this bit. So my question, my kind of open question, is that for a long weekend for a longer, you still working on this we see also depends on the project itself. And the last time of the project.

201
00:23:54.660 --> 00:23:58.169
IT 31/2-028: Actually, we made this already. I don't know whether he already can commit.

202
00:23:58.290 --> 00:24:05.610
IT 31/2-028: how much time do we still have? Hopefully, we can do something ready before the end of the year. But we still have to to get

203
00:24:05.770 --> 00:24:08.780
IT 31/2-028: for a setup which you can embed into the

204
00:24:08.790 --> 00:24:14.389
IT 31/2-028: to the center suite, and so that then we can have a we can have it as part of the over ci, etcetera.

205
00:24:16.810 --> 00:24:19.389
IT 31/2-028: What would you say? Either be hit or buddy?

206
00:24:19.730 --> 00:24:27.029
IT 31/2-028: What is the time of the let's say you, the timeline of the funding of this.

207
00:24:27.030 --> 00:24:31.570
Michiel de Jong: Oh, the timeline of Marty's funding is until June.

208
00:24:32.500 --> 00:24:32.860
Mahdi Baghbani: Yeah.

209
00:24:32.860 --> 00:24:33.534
Michiel de Jong: And.

210
00:24:34.210 --> 00:24:35.520
IT 31/2-028: Oh, okay. Interesting.

211
00:24:35.520 --> 00:24:45.830
Michiel de Jong: Turn really wants to to be in the ocean test, which you can always contract, Marty, to work longer.

212
00:24:46.050 --> 00:24:51.229
Michiel de Jong: and you know we also hope that Eos will be funding some Ocm work.

213
00:24:51.860 --> 00:24:54.780
Michiel de Jong: but guaranteed for now net is until June.

214
00:24:55.550 --> 00:24:59.669
IT 31/2-028: Okay? Well, that already gives a little margin, because, indeed, I expected.

215
00:24:59.670 --> 00:25:01.900
Michiel de Jong: That's not an invitation, is it?

216
00:25:03.100 --> 00:25:06.850
Michiel de Jong: It's up to him too few weeks left you, said.

217
00:25:07.883 --> 00:25:26.249
IT 31/2-028: No, but at least I mean there is some good hope, because because 2025 is the time when the with the new people we are managing to do, to do more things there and again, I would expect actually to get at least the testing ongoing before the before in the next month.

218
00:25:27.010 --> 00:25:32.719
IT 31/2-028: So yeah, this is, well, this is good news, anyway, this is totally really good news.

219
00:25:34.066 --> 00:25:35.739
IT 31/2-028: Okay. So

220
00:25:35.900 --> 00:25:49.330
IT 31/2-028: situation now is, I think we still want to remain in so funny just because of the reference presentation, because it was the only one. Everything we did with. Also, we don't understand was by always putting

221
00:25:49.450 --> 00:25:54.872
IT 31/2-028: are even in front of the of the storage in front of the makes no difference.

222
00:25:55.470 --> 00:26:00.990
IT 31/2-028: So eventually this becomes now properly implemented, implemented by the vendors.

223
00:26:01.100 --> 00:26:08.080
IT 31/2-028: and I claim that because 1.2 includes the security where

224
00:26:08.230 --> 00:26:27.050
IT 31/2-028: features it's a nice package. This is easy to defend this year at least to defend with my management with the rest of the team, etcetera, like, you know. Look, we have this limitation. Let's bring it to a level of security, which then we can advertise more, and we are more confident about it.

225
00:26:27.450 --> 00:26:37.029
IT 31/2-028: It's all about this better tokens, making sure that secrets don't leak anywhere, possibly using also those signed requests.

226
00:26:37.040 --> 00:26:39.529
IT 31/2-028: Again, that comes from West Cloud.

227
00:26:39.600 --> 00:26:42.689
IT 31/2-028: So all of those things

228
00:26:44.070 --> 00:26:49.069
IT 31/2-028: actually are interesting. We made it make perfect sense. So I'm totally happy with that.

229
00:26:49.110 --> 00:27:04.169
IT 31/2-028: And so I hope that this comes, and well, just to thank you to especially to put that also connected here in particular for the work we have the last

230
00:27:04.430 --> 00:27:11.093
IT 31/2-028: the last few months. But in the last really last summer time end of spring summertime.

231
00:27:11.650 --> 00:27:23.429
IT 31/2-028: where the the evolution of the standard made a very good progress, and we are now in the position we have a. We have a nice standard that we hope vendors in a lot.

232
00:27:24.450 --> 00:27:27.259
IT 31/2-028: and this is all. I have

233
00:27:28.690 --> 00:27:37.739
IT 31/2-028: questions or comments, or more questions, and and looking at the people connected, in case Jonathan is coming up.

234
00:27:41.380 --> 00:27:43.900
Micke Nordin | Sunet: Since we had some.

235
00:27:44.620 --> 00:27:45.290
Micke Nordin | Sunet: Hmm!

236
00:27:49.600 --> 00:27:51.839
Micke Nordin | Sunet: Can you hear me? Is my mute.

237
00:27:51.840 --> 00:27:54.610
IT 31/2-028: Yes, we do. Yes, yes.

238
00:27:54.610 --> 00:28:05.110
Micke Nordin | Sunet: Okay? Good. Yeah. Since we had, we mentioned the pull request to next Cloud. So I can say a few words about that.

239
00:28:05.360 --> 00:28:09.540
Micke Nordin | Sunet: So we have a work in progress.

240
00:28:09.760 --> 00:28:17.229
Micke Nordin | Sunet: Pull request going on for next cloud, for mainly 1.1 features.

241
00:28:17.230 --> 00:28:19.209
IT 31/2-028: Okay, do you want to share your screen.

242
00:28:19.370 --> 00:28:23.880
Micke Nordin | Sunet: I know I don't have really have any slides about it. I just

243
00:28:24.630 --> 00:28:26.440
Micke Nordin | Sunet: mentioned it since it came up.

244
00:28:26.840 --> 00:28:28.680
IT 31/2-028: Yeah. Sure. Go ahead.

245
00:28:28.780 --> 00:28:45.379
Micke Nordin | Sunet: But so what we have mainly focused on there is adding optional, 1 point, one features like the invite flow. So I have implemented the invite accepted

246
00:28:45.390 --> 00:28:54.030
Micke Nordin | Sunet: endpoint, for instance, and Navid has implemented invitation.

247
00:28:55.140 --> 00:29:05.689
Micke Nordin | Sunet: it's similar to to the share, Gui, but for invitations, so you can keep track of Ocm. Invitations that you have gotten

248
00:29:08.080 --> 00:29:11.390
Micke Nordin | Sunet: and one. So

249
00:29:11.410 --> 00:29:23.930
Micke Nordin | Sunet: since Ocm. Is backward, compatible there, there's really no need to change a lot of things for 1.1 or 1.2. But one thing that we did was

250
00:29:23.990 --> 00:29:34.040
Micke Nordin | Sunet: added an Api, where you can from an app register capabilities for Ocm. So you can extend the next cloud

251
00:29:34.190 --> 00:29:45.390
Micke Nordin | Sunet: capabilities by adding apps. So apps can implement certain Ocm capabilities, and they will be additive. So you can

252
00:29:45.520 --> 00:29:51.729
Micke Nordin | Sunet: add more optional features from Ocm. By developing a standalone app.

253
00:29:52.190 --> 00:30:05.079
Micke Nordin | Sunet: which I think is nice. So, for instance, the Mfa. Capabilities or requirements that, we added, will be able to be implemented as a separate

254
00:30:05.190 --> 00:30:12.029
Micke Nordin | Sunet: app, and I will implement that in the Mfa. Zones app that I have written.

255
00:30:13.080 --> 00:30:19.200
Micke Nordin | Sunet: So really, the the main thing that we will

256
00:30:19.310 --> 00:30:23.309
Micke Nordin | Sunet: need to add, is the bearer token stuff, and we haven't

257
00:30:23.380 --> 00:30:38.149
Micke Nordin | Sunet: looked at that. So. But the idea is to do from the discovery, decide whether to use basic auth or bearer token and be able to accept

258
00:30:38.240 --> 00:30:41.260
Micke Nordin | Sunet: bearer, token shares.

259
00:30:42.710 --> 00:30:53.369
Michiel de Jong: So, and Max is also adding, has a Pr open to add request, signing to Ocm. Right? So that the the posts to share is signed.

260
00:30:54.380 --> 00:31:02.230
Micke Nordin | Sunet: I think it's merged right. So in one it's in 1.2. The signing so.

261
00:31:02.230 --> 00:31:03.600
Michiel de Jong: Next Cloud, Pierre.

262
00:31:06.340 --> 00:31:17.245
IT 31/2-028: Yeah, this was also, I mean, this is part of the standard. Now, what next? Cloud's work was to introduce, indeed, the signature?

263
00:31:19.290 --> 00:31:37.269
IT 31/2-028: Then we changed it. The agreement there was to not really go for signing every single request, including the access request, but to sign the invitation only at the beginning, and then, once this is done and it's signed.

264
00:31:37.780 --> 00:31:39.829
IT 31/2-028: then the rest of the person can go

265
00:31:40.160 --> 00:31:43.331
IT 31/2-028: to go. I mean the question there is more to like.

266
00:31:43.780 --> 00:31:48.519
IT 31/2-028: Make sure that you are talking to the tech party. That claims to be what it claims to be

267
00:31:48.690 --> 00:31:52.500
IT 31/2-028: right. Otherwise, as you need to respond to Frank. Why the extra complexity

268
00:31:52.690 --> 00:31:55.109
IT 31/2-028: today, with the server point 0,

269
00:31:55.400 --> 00:32:08.800
IT 31/2-028: you get a share from anyone. The sharing point is unauthenticated by construction. Because, of course, they cannot have any. It's by construction, anyone.

270
00:32:09.070 --> 00:32:15.950
IT 31/2-028: And how do you trust that this thing is real, that behind that there is a separate, that is, a that is a

271
00:32:17.170 --> 00:32:21.210
IT 31/2-028: a file system. Synchron share an Efs system

272
00:32:21.390 --> 00:32:27.820
IT 31/2-028: with the same capabilities, and that then you give access to the or you access them.

273
00:32:28.200 --> 00:32:39.240
IT 31/2-028: So you let your user access some remote entity. What is that remote entity is actually cheating, or, you know, trying to inject something, whatever.

274
00:32:39.240 --> 00:32:43.109
Michiel de Jong: Same accents just joined, so we can ask him directly.

275
00:32:43.110 --> 00:32:58.690
IT 31/2-028: So then we can ask, we can ask, that's that's good. But yes, that was a little bit the focus. And that's why I understand the-. The signatures were introduced in the workflows that at least you avoided this kind of attack scenario.

276
00:32:59.830 --> 00:33:02.647
IT 31/2-028: So I need. The waiter makes sense. And

277
00:33:04.440 --> 00:33:17.730
IT 31/2-028: we were actually discussing. So I presented already what is, what is the status of sandbox? And you can go ahead and present the status of next cloud. For

278
00:33:18.200 --> 00:33:19.310
IT 31/2-028: if you.

279
00:33:19.630 --> 00:33:28.660
IT 31/2-028: if you can share, share your screen, if you like, or or at least share your camera, and Mike cannot hear you or see you.

280
00:33:39.640 --> 00:33:40.050
Maxence: I don't.

281
00:33:41.066 --> 00:33:43.100
IT 31/2-028: Hello. Yes.

282
00:33:43.100 --> 00:33:44.509
Maxence: Hello! Everyone.

283
00:33:44.890 --> 00:33:45.315
IT 31/2-028: Hello!

284
00:33:46.270 --> 00:33:50.039
Maxence: Sorry for being late, but this is my time zone. So I.

285
00:33:50.040 --> 00:33:53.929
IT 31/2-028: Yeah. That's why we started later. This was expected.

286
00:33:53.930 --> 00:34:02.039
Maxence: Yeah. And when I saw the the planning I thought it was already on my time zone, so I didn't get it earlier than I expected. Anyway.

287
00:34:03.100 --> 00:34:04.779
IT 31/2-028: Do you have a camera yourself.

288
00:34:04.780 --> 00:34:05.750
Maxence: Excuse me.

289
00:34:06.140 --> 00:34:08.460
IT 31/2-028: Do you have a camera? You said, can you show.

290
00:34:08.469 --> 00:34:15.419
Maxence: No, I'm sorry. I was supposed. As I was saying, Giuseppe, yesterday I was supposed to to

291
00:34:15.509 --> 00:34:19.339
Maxence: to make some slide, but I was really out of time the last 2 weeks

292
00:34:20.205 --> 00:34:28.939
Maxence: also regarding some implementation of of the last feature of Ocm within for the next version of next cloud.

293
00:34:29.559 --> 00:34:41.009
Maxence: It took me so a while. So we we will be merging the the the last pull request for the identity

294
00:34:41.199 --> 00:34:49.939
Maxence: signature of the of the request, the one we discussed few months ago, and we implemented to the to the protocol for the 1.2. I think.

295
00:34:51.100 --> 00:34:58.220
IT 31/2-028: So right? That was exactly my question was more like, Do we have a camera to see you? Because we can hear you? But we cannot see you.

296
00:34:58.220 --> 00:35:00.730
Maxence: I don't have camera at home. I'm really sorry.

297
00:35:00.990 --> 00:35:17.610
IT 31/2-028: Okay, fine. Then let's go. Let's go by. So anyway, then it's fine. You can. Then at this point I would suggest, at least we share the screen for the for the was also commenting, is that there is this work. I'm going to have a

298
00:35:18.460 --> 00:35:20.650
IT 31/2-028: 1.1,

299
00:35:21.010 --> 00:35:25.810
IT 31/2-028: and even some extra features on top, because this interview is not part of what we want

300
00:35:25.890 --> 00:35:27.390
IT 31/2-028: as part of this cloud.

301
00:35:27.610 --> 00:35:32.229
IT 31/2-028: So then, I'm curious to see especially that I would already have a question

302
00:35:32.920 --> 00:35:39.494
IT 31/2-028: once you contributed to the stuff that meanwhile we digested, and we included it in a slightly different form

303
00:35:39.850 --> 00:35:41.419
IT 31/2-028: in the sense of

304
00:35:41.750 --> 00:35:48.339
IT 31/2-028: it's not like you sign every single request. You only sign the initial request, and then the traffic. The access

305
00:35:48.370 --> 00:35:51.170
IT 31/2-028: doesn't need to get signed. So

306
00:35:51.230 --> 00:35:53.879
IT 31/2-028: what is your implementation in this cloud.

307
00:35:56.650 --> 00:35:59.369
Maxence: So we're talking about the sign in request, right? About the

308
00:36:00.160 --> 00:36:05.630
Maxence: yeah. And I. I don't fully understand the the issue. So I'm signing every request.

309
00:36:07.010 --> 00:36:10.410
Maxence: but sorry I didn't get the the question.

310
00:36:10.760 --> 00:36:21.100
IT 31/2-028: The question is, is, as you introducing this signatures in every single request that takes place with the, with a remote party

311
00:36:21.250 --> 00:36:30.089
IT 31/2-028: or not, or which part which which request are you? In which request you are putting the signature? This should be signature, workflow.

312
00:36:30.380 --> 00:36:39.100
Maxence: Yeah, right now, it's it's only gonna sign the request based on the Ocm itself.

313
00:36:40.730 --> 00:36:41.380
Maxence: If this.

314
00:36:42.210 --> 00:36:42.970
Michiel de Jong: Shares.

315
00:36:43.660 --> 00:36:45.200
IT 31/2-028: Yeah. So the shared question.

316
00:36:45.200 --> 00:37:03.809
Maxence: Yeah. Yeah, the the one we are managing right now. We made it as an Api, and we are only signing the the request made by Ocm. Regarding shares, it is true, but the way it is done it's it's done in a way that you can sign any request

317
00:37:06.390 --> 00:37:18.140
Maxence: it even include it. Even include the editors to send a request using when you're using the the library, the Api to generate the request. I mean.

318
00:37:18.220 --> 00:37:23.730
Maxence: it's it, it can be embed to the iclient Api from next cloud.

319
00:37:23.740 --> 00:37:30.549
IT 31/2-028: So when you create a request, you just need to call one function and then check the

320
00:37:30.550 --> 00:37:31.560
IT 31/2-028: that would be right.

321
00:37:31.560 --> 00:37:36.870
Maxence: And then yourself. You compare the payload with the identity of the

322
00:37:37.670 --> 00:37:44.889
Maxence: of the remote instance. I I cannot make something too more generic, but this is generic enough from my point of view.

323
00:37:45.730 --> 00:37:47.189
Maxence: and your own request.

324
00:37:47.770 --> 00:37:48.240
IT 31/2-028: Yeah.

325
00:37:48.240 --> 00:37:52.390
Michiel de Jong: This is, and next cloud merged into the main branch of nextcloud.

326
00:37:52.650 --> 00:37:53.730
Maxence: Excuse me.

327
00:37:54.630 --> 00:37:57.409
Michiel de Jong: Is this already merged in the next cloud? Next cloud.

328
00:37:57.410 --> 00:38:07.399
Maxence: It will be merged this week. We we had some long discussion. The the current pull request is effective. It's working.

329
00:38:07.460 --> 00:38:16.399
Maxence: We had some. We had some discussion earlier this week on, if we merge it like this, or we put some modification to it

330
00:38:16.470 --> 00:38:21.229
Maxence: to make it the code more readable for everyone, because there are some.

331
00:38:21.260 --> 00:38:27.560
Maxence: some complexization in provision of some feature in the future.

332
00:38:27.790 --> 00:38:34.330
Maxence: and we decide that it was too much. And we're gonna keep it simple. So few lines gonna disappear and it's gonna be merged.

333
00:38:34.440 --> 00:38:39.279
Maxence: It was supposed to be yesterday. It's gonna be tomorrow or Friday.

334
00:38:39.790 --> 00:38:44.010
Michiel de Jong: Is it also signing the notifications when it sends a notification.

335
00:38:44.010 --> 00:39:01.580
Maxence: Yes, it. It signed the the creation of the share, the notification about the share, the reshare, everything ready to share, in fact, not the new, the next and new feature. But, as I was saying, if event talk will be able to sign its own request, using the Api.

336
00:39:02.420 --> 00:39:06.920
Michiel de Jong: And is it also announcing its public key in Ocm. Provider, or in.

337
00:39:07.370 --> 00:39:13.959
Maxence: Does. Yes, using the the Ocm discovery endpoint right now. It's the Ocm. Dash Provider, it's true.

338
00:39:14.090 --> 00:39:27.539
Maxence: But as I was supposed to explain. During my my my presentation today, we gonna we're gonna put some more work in the in the in the new scm protocol

339
00:39:28.190 --> 00:39:35.090
Maxence: and meaning, we're gonna also implement the the new, well-known Ocm discovery endpoint.

340
00:39:36.200 --> 00:39:46.029
Maxence: It's not included in the current protocol request. But this will be done to to fully and better support the the new, the next and new version, the new version, and the next version of the the Ocm Protocol.

341
00:39:46.420 --> 00:39:55.100
Micke Nordin | Sunet: Max, did you see the the work in progress? Pr. That me and Navid is working on for 1.1.

342
00:39:57.220 --> 00:40:00.810
Micke Nordin | Sunet: Do you have a link. Please. Sorry.

343
00:40:00.810 --> 00:40:03.439
Micke Nordin | Sunet: Send it to you later. I don't have it right.

344
00:40:03.980 --> 00:40:05.060
Maxence: Where did.

345
00:40:06.093 --> 00:40:08.160
IT 31/2-028: Been discussing.

346
00:40:08.160 --> 00:40:09.680
Micke Nordin | Sunet: Maybe okay, yeah, maybe.

347
00:40:09.680 --> 00:40:12.770
IT 31/2-028: Is there in the Github itself.

348
00:40:13.810 --> 00:40:14.350
Micke Nordin | Sunet: Yeah.

349
00:40:15.660 --> 00:40:20.399
Micke Nordin | Sunet: But so it's mainly related to

350
00:40:20.590 --> 00:40:29.910
Micke Nordin | Sunet: invite flow currently. But I was thinking also, if we should implement the dot well known. I think there is a

351
00:40:30.270 --> 00:40:37.770
Micke Nordin | Sunet: an Api in next cloud for adding a well-known address. So maybe.

352
00:40:37.810 --> 00:40:44.630
Micke Nordin | Sunet: But I don't know if it's if if it's a good idea to add it in that pr. Or if it should be

353
00:40:44.780 --> 00:40:45.990
Micke Nordin | Sunet: separate.

354
00:40:46.620 --> 00:40:57.789
Maxence: Yeah, I think it should be separate because it just that it doesn't really affect any other work. I I have no link to to check your work right now.

355
00:41:00.950 --> 00:41:20.539
Maxence: But yeah, it. The the well known endpoint is just I don't. It's a optional modification. It doesn't need to to be force push right now, right now we are using the Ocm Provider, but we can just switch to to the well known one in some other

356
00:41:20.710 --> 00:41:21.389
Maxence: put a request.

357
00:41:21.390 --> 00:41:31.300
Michiel de Jong: And so are you also implementing a a check? And how do you? If somebody sends a wrong signature or no signature at all, how do you classify this.

358
00:41:32.270 --> 00:41:44.829
Maxence: Okay. So nextloud, the the next version of next loud will will by default, will sign outgoing request when I'm making a request. If I don't have the the public key myself. I'm gonna generate it.

359
00:41:45.240 --> 00:41:53.290
Maxence: and this one will be used for any other request. So I generate my keeper and I store it, and I signed outgoing request.

360
00:41:53.930 --> 00:42:04.039
Maxence: If you send, if a next loud, when the the request will be merged, if the next loud receive a request which is sign it.

361
00:42:04.580 --> 00:42:18.880
Maxence: It will be checked, of course, but it's not enforced by default. We, of course, we would like to keep compatibility with any other instance of next law that does not yet have the possibility and the doability to

362
00:42:19.010 --> 00:42:21.469
Maxence: to sign the its request.

363
00:42:22.070 --> 00:42:33.489
Maxence: If you, if you, your next cloud that is supposedly support the the signing receive a non, a not signing request from a remote instance.

364
00:42:33.850 --> 00:42:53.829
Maxence: Next slide we'll check, based on the identity of the of the of the request that is extracted from the payload itself, because we have no real way to to check other way right now before the merge. Anyway, if I receive a not sign a request, I will check the supposed origin of the request.

365
00:42:54.600 --> 00:43:02.349
Maxence: and if that remote instance does not sign a request, if there is no public key in the discovery of the Ocm.

366
00:43:03.294 --> 00:43:05.110
Maxence: This Korean pond! Sorry

367
00:43:05.170 --> 00:43:16.710
Maxence: it will refuse the request if you're supposed to sign it, and I receive a request from your instance. That is supposedly from your instance. It's not signed. I will in your it.

368
00:43:16.950 --> 00:43:21.739
Maxence: I mean. Now we'll return an error. And just just a 400.

369
00:43:21.800 --> 00:43:27.469
IT 31/2-028: Okay. So you not like you find the request you can just send back to whatever is Pdf, file.

370
00:43:27.822 --> 00:43:33.109
Maxence: Think it's 403 I need to check. I don't have the- the.

371
00:43:33.110 --> 00:43:35.420
IT 31/2-028: Whatever. Yeah, yeah, if.

372
00:43:36.570 --> 00:43:51.880
Maxence: But yeah, I keep compatibility with a previous version of text loud, and if your own instance is supposed to sign, and I receive a spoofy request from another instance that say that it's coming from yours, and you're signing the request. I'm going to inure it.

373
00:43:56.030 --> 00:43:56.970
IT 31/2-028: Okay, so yeah, this is.

374
00:43:56.970 --> 00:43:58.870
Michiel de Jong: We should write that into the spec.

375
00:43:58.940 --> 00:44:01.650
Maxence: This is currently sorry. Excuse me.

376
00:44:01.870 --> 00:44:08.540
Michiel de Jong: I think it's a very smart thing to do, and we should recommend that to everybody to do it that way. If you receive

377
00:44:08.650 --> 00:44:14.270
Michiel de Jong: a wrongly signed request rejected if you receive an unsigned request.

378
00:44:14.430 --> 00:44:23.120
Michiel de Jong: but you look up the origin. If the origin doesn't announce a public key, you accept it right? Or maybe show the user like, it's unsigned.

379
00:44:23.260 --> 00:44:24.060
Michiel de Jong: Yeah.

380
00:44:24.060 --> 00:44:25.580
Maxence: It's the only other way.

381
00:44:25.580 --> 00:44:32.549
Michiel de Jong: And it has a public key. Then you have to distrust any unsigned request that claim to come from it.

382
00:44:33.820 --> 00:44:45.349
IT 31/2-028: That's a very good point, because at that point really looks like somebody. I mean, if I'm exposing a key, I would expect that they would use it

383
00:44:45.480 --> 00:44:48.107
IT 31/2-028: in the 1st place. So yes, that- that makes

384
00:44:48.660 --> 00:44:57.849
IT 31/2-028: perfect sense, and we are still on time to amend the text, and this is more like the recommendation on how to use the spec the way it is for it.

385
00:44:59.040 --> 00:45:07.329
IT 31/2-028: Okay? So myself, anything else you want to share on the on this, on what is going on.

386
00:45:07.600 --> 00:45:16.930
Maxence: What is going. Yeah, I have another thing to share about what is going on, what has been done. I think it's it's clear about how it should work.

387
00:45:16.990 --> 00:45:30.610
Maxence: We're gonna try regarding next cloud. And on Ocm, we're gonna try to. We're gonna try. We're gonna work on a better integration with the with the already listing of trusted server we have in the admin part of next cloud.

388
00:45:30.990 --> 00:45:40.019
Maxence: We're gonna we're gonna try to. We're gonna sorry we're gonna put some some command or so to help refresh the

389
00:45:40.270 --> 00:45:43.997
Maxence: the key in case of of some

390
00:45:45.460 --> 00:45:49.029
Maxence: reset a server. Right now, if the the instance.

391
00:45:49.500 --> 00:45:56.040
Maxence: the pull requests the current status of the pull request. If you remove a remote instance, you reinstall the remote instance.

392
00:45:56.100 --> 00:46:05.380
Maxence: you have no real way, but looking in the database to remove, to remove the previous key of that remote instance.

393
00:46:05.750 --> 00:46:10.350
Maxence: If I'm instance A and instance B is need to

394
00:46:10.700 --> 00:46:16.520
Maxence: restart instance meaning we set everything we need to add some functionality to A

395
00:46:16.580 --> 00:46:19.620
Maxence: to help rethink the the keys.

396
00:46:22.530 --> 00:46:43.430
Maxence: and also because now we can identify origin, we can also identify the the interface that is used by the remote instance. So if you have an internal network and external network in case of, I would say, trusted server or global scale, which is the technology used by next cloud to

397
00:46:45.130 --> 00:46:53.580
Maxence: have a list of internal instance that can interoperate together with less, with more trust, I would say.

398
00:46:54.000 --> 00:47:00.700
Maxence: but the idea would be to limit the video that share only to this instance

399
00:47:01.090 --> 00:47:07.160
Maxence: and let it and close it for remote instance, because there is some setup where you want to have the

400
00:47:07.180 --> 00:47:10.086
Maxence: fit in with that chair only within

401
00:47:14.144 --> 00:47:24.660
IT 31/2-028: A small kind of group of instances that are passing each other, and you don't want to open

402
00:47:24.880 --> 00:47:30.929
IT 31/2-028: to the rest of the world. So it's a like a closed group of of federated, federated.

403
00:47:30.930 --> 00:47:37.990
Maxence: Yeah. The the the fact that we add identity check on the on the request is, is really helpful for.

404
00:47:38.880 --> 00:47:39.410
IT 31/2-028: Thank you.

405
00:47:39.410 --> 00:47:40.100
Maxence: Yeah, yeah.

406
00:47:40.100 --> 00:47:41.680
IT 31/2-028: Yeah, absolutely. Absolutely.

407
00:47:41.730 --> 00:47:59.089
Micke Nordin | Sunet: I mean, there are several places in the spec where we talk about trust, but not how to establish it. We say that it's outside the scope of the spec to how the trust is established. But I think it's a really good mechanism that next cloud has to

408
00:47:59.200 --> 00:48:04.879
Micke Nordin | Sunet: keep track of the trusted servers, and we can use it in in many of the places where

409
00:48:05.030 --> 00:48:13.699
Micke Nordin | Sunet: we talk about trust. So, for instance, for the Mfa. Requirement, I think it only makes sense to

410
00:48:13.960 --> 00:48:19.009
Micke Nordin | Sunet: to share that with someone who is in the trusted list of servers. For instance.

411
00:48:19.010 --> 00:48:19.880
Maxence: Yeah, I think.

412
00:48:19.880 --> 00:48:20.940
Michiel de Jong: It's all right.

413
00:48:21.180 --> 00:48:22.010
Michiel de Jong: Go ahead!

414
00:48:23.140 --> 00:48:24.640
Maxence: Please please go.

415
00:48:24.980 --> 00:48:32.555
Michiel de Jong: Oh, yeah, sorry I was when we talk about the trust. And how do you come to trust the server? I

416
00:48:32.970 --> 00:48:38.980
Michiel de Jong: I think invites are a very good thing here, and I hadn't realized this

417
00:48:39.060 --> 00:49:01.609
Michiel de Jong: a few years ago when science mesh was using invites. I thought, well, that's just the way to meet right. But then I, when I started thinking about the trust between servers if Alice tells Bob out of band that they want to connect. Then one thing it makes it easy to find each other. You know. QR. Code, how do I meet? But the other thing is that now

418
00:49:01.610 --> 00:49:10.560
Michiel de Jong: Alice's when the invite is accepted. Then Alice's server knows that Bob's server is a

419
00:49:11.112 --> 00:49:40.589
Michiel de Jong: trusted server through Alice and through Bob, or that Alice trust Bob, who trusts bob.com. Also Bob Server knows that alice.com is a server that's trusted by Alice, who is a person who's trusted by Bob, who is a person who's trusted by bob.com. So you have a chain of trust through the 2 people. If you use invites, it's impossible for a rogue server to enter the Ocm. Network. If it's all invites, because if you have no users.

420
00:49:40.590 --> 00:49:46.440
Michiel de Jong: then nobody's gonna accept invites from any existing Ocm. Users.

421
00:49:46.670 --> 00:50:00.970
Michiel de Jong: You're never going to enter the network as a server. If nobody wants you to enter network as a human that goes both for the sending server and for the receiving server. So I'm very excited about invites now as excited as I am about signed requests

422
00:50:01.336 --> 00:50:18.839
Michiel de Jong: and about the code flow. But that's let's talk about that later. So yeah, my question for next cloud is, How do you see? Invites? And do do you see this as a a thing that can improve the security in that sense that I just said, like a server, trust a human trust, a human trust, a server.

423
00:50:20.707 --> 00:50:29.280
Maxence: We? We we didn't. We discuss about all, all of this but from

424
00:50:31.290 --> 00:50:34.350
Maxence: the only notice I have right now is.

425
00:50:34.440 --> 00:50:37.530
Maxence: I don't trust 2 people trusting each other in fights.

426
00:50:39.720 --> 00:50:47.160
Maxence: That's that's just. I don't know how we should well wish better. We could implement this, but

427
00:50:50.050 --> 00:50:54.821
Maxence: From my point of view. When I was saying twisting server, it was more like

428
00:50:55.530 --> 00:51:12.170
Maxence: being able to, in your only share confirmation from one instance, saying that when you share. To instance B, you don't need to have the notification you can. You don't need to to have the operation to click that I'm allowing the share

429
00:51:12.645 --> 00:51:30.060
Maxence: from that other instance. You don't need that operation from a user when you share. When you share a file to instance B, it will be instantly available in the file system of the user you're sharing to an instant. B, that that was more like the way I will. I was saying about trusted server.

430
00:51:30.820 --> 00:51:51.229
Michiel de Jong: I think I'd like to challenge that. So if it's if a share comes from alice.com to bob.com, then we all agree it's good. If alice.com signs the request, but then the next step is, why would bob.com refuse this share, or or trust it a little bit less. That's maybe because this server doesn't want to present it to Bob.

431
00:51:51.230 --> 00:52:09.720
Michiel de Jong: You know the document by itself doesn't do any harm to sitting on the server. It it could be harmful if Bob starts using it. So bob.com telling Bob like, Hey, here's the thing that came into your inbox. I think you can trust it. That is the question for the server, and if the server can

432
00:52:09.720 --> 00:52:23.349
Michiel de Jong: mathematically know that it comes from a person, Alice, who Bob had some out of band invite a connection with and Bob

433
00:52:23.530 --> 00:52:44.509
Michiel de Jong: told his server like, Okay, I got this invite from somebody I met in person, or through a android decrypted chat, app, or or something, I trust, anything coming from Alice as a person I want to see it. Don't hide it for me, because I trust Alice. Then

434
00:52:45.166 --> 00:52:56.959
Michiel de Jong: if bob.com knows that. Okay, there's a signed request coming in and we know that the invite was between Alice and Bob.

435
00:52:57.100 --> 00:53:09.630
Michiel de Jong: Then actually, I think it's it's safer based on the invite to show this incoming share than it would be based on just domain names. And and why allow lists and and deny list.

436
00:53:13.562 --> 00:53:14.670
Maxence: yeah, that

437
00:53:15.070 --> 00:53:32.450
Maxence: that this is trust between 2 users. I keep thinking. This is trust between the user and it should not bypass the the any security we can implement between between instances of this user. And and when I was talking about trusted server, it's it's

438
00:53:32.950 --> 00:53:42.019
Maxence: it's as I was saying, it's more like you are. You are exchanging a lot of file between the server, and you want it to be flawless. You don't want to

439
00:53:42.260 --> 00:54:00.659
Maxence: to. I will take example of the global scale thing, which is, you have multiple instance, and your user are distributed to the word instance. But you want it to be really as much invisible to your user as possible, meaning that

440
00:54:00.660 --> 00:54:19.980
Maxence: when you share a file from instance A to instance B, it have to be the same way. You're sharing a file from instance A to instance A itself between 2 different user. And you want it to be for it. It's it's a. It's a request we have from some customer, which is that they would like to be to be the.

441
00:54:20.130 --> 00:54:24.210
Maxence: The. The communication between 2 different instance should be

442
00:54:24.547 --> 00:54:33.149
Maxence: less invasive for the for the user, because they really trust the they are. They are coming from the same company. The instance are coming from the same.

443
00:54:33.320 --> 00:54:40.804
IT 31/2-028: But this doesn't contradict what was saying, because the story there is that if you show recent state that there is a user.

444
00:54:42.210 --> 00:54:53.610
IT 31/2-028: how do you know that this is this is possible? Let's say that that knows about user. So here, I guess there is also a difference. Wait, just- just understand.

445
00:54:53.610 --> 00:54:53.960
Maxence: Please.

446
00:54:54.231 --> 00:54:59.660
IT 31/2-028: Understand that we have the cases where you deploy multiple instances, but they all go to the same identity provider

447
00:55:00.300 --> 00:55:03.600
IT 31/2-028: which is cheating. If I could say.

448
00:55:03.600 --> 00:55:12.770
Micke Nordin | Sunet: So I can say a few things as well, because in sooner drive we have 54 instances.

449
00:55:12.950 --> 00:55:17.010
Micke Nordin | Sunet: and we use Eduain for logging in. So

450
00:55:17.850 --> 00:55:27.970
Micke Nordin | Sunet: basically, we trust anyone who is in our identity Federation. So I think it's like 6 or 8,000 idps or something.

451
00:55:28.510 --> 00:55:34.929
Micke Nordin | Sunet: We map the idps to a separate instance. So if you belong to one of

452
00:55:34.970 --> 00:55:45.790
Micke Nordin | Sunet: 53 Swedish universities, then you will get logged into your own instance, and if you belong to any of the other

453
00:55:45.890 --> 00:56:02.659
Micke Nordin | Sunet: 8,000 idps, you will be logged into our external node, which is used for external collaborators, so they get an account in sooner drive on our external node. So we don't want them to use any kind of

454
00:56:02.730 --> 00:56:22.590
Micke Nordin | Sunet: random next cloud or on cloud server out there to interact with our users, we want them to use the one that we set up and that we can control. So for us, I think it makes perfect sense to have a list of 54 trusted servers that trust each other, and we we can control

455
00:56:22.820 --> 00:56:24.769
Micke Nordin | Sunet: a lot of things about it.

456
00:56:25.010 --> 00:56:35.050
Micke Nordin | Sunet: So I do. I do. I wouldn't want anyone to override my trust list and start adding other trusted servers just because they know someone.

457
00:56:35.350 --> 00:56:41.659
Micke Nordin | Sunet: But I think what Mhil is saying makes a lot of sense

458
00:56:41.940 --> 00:56:53.839
Micke Nordin | Sunet: for someone who is not already in a Federation. So if you're not in a group of well trusted servers that you want to lock down. But instead, you're just

459
00:56:54.030 --> 00:56:58.029
Micke Nordin | Sunet: your own server on the Internet.

460
00:56:58.130 --> 00:57:01.599
Micke Nordin | Sunet: Then I think it makes sense to be able to look down.

461
00:57:01.770 --> 00:57:08.360
Micke Nordin | Sunet: Trust to only those that your users have interacted with and know and trust

462
00:57:08.630 --> 00:57:20.810
Micke Nordin | Sunet: right? So I mean, it would be a step up from accepting any kind of share from anywhere in the world to just the ones that your users have interacted with and trust.

463
00:57:20.960 --> 00:57:26.209
Micke Nordin | Sunet: So I think it's like a 3 level grade of

464
00:57:26.430 --> 00:57:31.909
Micke Nordin | Sunet: what you accept. So one is being very promiscuous. You accept anything.

465
00:57:31.940 --> 00:57:40.229
Micke Nordin | Sunet: One is trusting only users, and one is lockdown mode where you only trust the Admins list of trusted servers.

466
00:57:41.240 --> 00:58:01.852
Michiel de Jong: Yeah, no, I think that's a very good explanation and I wanna. And I also understand what makes sense said and I wanna emphasize. Maybe we can call it like firewall considerations. You don't want to open up rate limiting for a server that happens to have a user that happens to, you know. Be a friend of somebody.

467
00:58:02.190 --> 00:58:14.270
Michiel de Jong: So that's firewall, and spam filter is the other one. So I want my server to spam filter my incoming Ocm requests. But when I have accepted an invite.

468
00:58:14.330 --> 00:58:26.910
Michiel de Jong: I want that always to go through the spam filter, and that would help me to see? Like, okay, this is somebody who works at a Swedish university. But you've never interacted with them right?

469
00:58:30.650 --> 00:58:47.120
Maxence: Yeah. Yeah. As as I think, we, we all agree on on all this point, it just what I wasn't to say and make it. Say, better better it just that we don't have the same definition of trusted server. That's that's the only thing we need to. We need to define exactly.

470
00:58:47.450 --> 00:58:53.220
Maxence: We need to find some wording and phrasing for this and really define. But

471
00:58:53.700 --> 00:59:00.729
Maxence: we all agree on the features, but not on the the wording, on the on some elements of the feature. But yeah.

472
00:59:00.890 --> 00:59:01.959
Michiel de Jong: No, this is also.

473
00:59:02.770 --> 00:59:17.339
IT 31/2-028: This is also about the ui. Of course the mean eventually. What they see here is more like whenever you look for my contacts, if they want to share something I would have, then I would have to have some kind of a visual queue about

474
00:59:17.490 --> 00:59:34.620
IT 31/2-028: when the user is part of a trusted server in your sense, your meaning, Mickey and Maxon's like, it is already a user that is trusted because I trusted that person through an invite.

475
00:59:34.760 --> 00:59:41.750
IT 31/2-028: So it's a human trusted because I know them very well versus completely unknown.

476
00:59:42.570 --> 00:59:43.320
IT 31/2-028: It's fun.

477
00:59:43.670 --> 00:59:55.839
IT 31/2-028: possible, spam or possible even possible. If I if I'm sharing to an unknown person, then that person may refuse it because it comes from a completely unknown source, and it can be ignored, can be filtered whatever

478
00:59:55.850 --> 01:00:07.010
IT 31/2-028: you see- you see. So it's really different categories. See? So it's really more a matter of what you how you tweak the ui to show the difference between the users.

479
01:00:07.270 --> 01:00:23.300
Micke Nordin | Sunet: And I mean so the the spec definitely has a concept of trusted servers. But it doesn't say anything about how something becomes trusted. But you could easily imagine adding a checkbox to the next Cloud security tab.

480
01:00:23.320 --> 01:00:32.050
Micke Nordin | Sunet: where you say automatically, trust servers with accepted invites, signed, accepted, invites, or anything like something like that.

481
01:00:32.160 --> 01:00:38.079
Micke Nordin | Sunet: So that's a feature that could be added to nextcloud, for instance, to utilize the

482
01:00:38.120 --> 01:00:41.599
Micke Nordin | Sunet: already pre-existing notion of trusted server.

483
01:00:42.225 --> 01:00:46.950
Micke Nordin | Sunet: But anyone is, is free to come up with

484
01:00:46.990 --> 01:01:01.000
Micke Nordin | Sunet: schemes for how you trust servers in your implementation. I think it's a good idea to be able to to limit it to to something that an administrator has said is definitely trusted.

485
01:01:01.640 --> 01:01:08.770
IT 31/2-028: Yeah, and eventually did, because somebody open, they can definitely see different

486
01:01:08.810 --> 01:01:18.782
IT 31/2-028: ways of so policies, essentially ways of working. Because we would have that for sale we have a single license, so it would not be in a mode like what I just want to start, Peter.

487
01:01:19.190 --> 01:01:32.960
IT 31/2-028: I can trust anyone as long as people actually are kind of delegate to users to do the trust. So it's more like this one feature mode that he was mentioned, and not a predefined list of trusted us

488
01:01:33.859 --> 01:01:34.580
IT 31/2-028: from

489
01:01:34.740 --> 01:01:45.269
IT 31/2-028: from the administrators. So all those modes came to exist, and they actually already persist at the start of the way, it's so that we could even clarify a little bit more about those

490
01:01:45.730 --> 01:01:52.159
IT 31/2-028: kind of something is about to expose these these kind of differences.

491
01:01:52.890 --> 01:01:55.880
IT 31/2-028: Okay, thanks. Yeah.

492
01:01:55.880 --> 01:02:15.249
Michiel de Jong: Well, I have one more detailed question about this. So Nika and Navid are working on implementing. Invite flow in the core of next cloud, you know, adding a database table that is invites and a way to accept an invite and a way to generate an invite.

493
01:02:15.370 --> 01:02:17.389
Michiel de Jong: So oh.

494
01:02:17.390 --> 01:02:25.959
Micke Nordin | Sunet: The next slide already has invites. Right? So sending invites via email and all of that is already implemented, it's

495
01:02:26.010 --> 01:02:33.969
Micke Nordin | Sunet: for accept right invites and sending also adding the endpoint for shares accepted.

496
01:02:34.220 --> 01:02:35.170
Micke Nordin | Sunet: So yeah.

497
01:02:35.170 --> 01:02:37.920
Michiel de Jong: You can get notified. Yeah.

498
01:02:37.920 --> 01:02:43.209
Maxence: Yes, it's in my, it's in the roadmap, the the roadmap of the implementation of the Cm. It's to

499
01:02:43.710 --> 01:02:46.540
Maxence: to have a look to to the work from from Mickey.

500
01:02:47.817 --> 01:02:55.250
Maxence: It's on my roadmap, and and finalize that that feature that we already talked about a few months ago.

501
01:02:55.623 --> 01:02:58.759
Maxence: Do you have any more question on it? Because I.

502
01:02:58.760 --> 01:03:01.050
Michiel de Jong: No, that was my question. That was my question. Thank you.

503
01:03:01.050 --> 01:03:02.799
Maxence: Okay, yeah. So so this.

504
01:03:03.935 --> 01:03:05.070
IT 31/2-028: Yes.

505
01:03:05.220 --> 01:03:07.410
Maxence: This is not forget, and don't worry.

506
01:03:09.030 --> 01:03:09.390
IT 31/2-028: Okay.

507
01:03:09.390 --> 01:03:10.050
Maxence: So.

508
01:03:10.706 --> 01:03:29.750
IT 31/2-028: Something which includes the invitation workflow, which is essentially the work by weekend, plus the signatures. And these extra features that are actually 1.2 1.2.

509
01:03:29.930 --> 01:03:36.529
Maxence: The the senior tier will be in the next version of next loud. Yes, but we not. I don't think this is will be back ported

510
01:03:36.900 --> 01:03:40.060
Maxence: because it's it's a huge. It's a huge project.

511
01:03:40.060 --> 01:03:41.270
IT 31/2-028: There's also like a new.

512
01:03:41.270 --> 01:03:47.410
Maxence: Feature. Then it's a 1 new feature. I'm just a simple fix.

513
01:03:47.410 --> 01:03:59.059
IT 31/2-028: I'm not suggesting to would like to see a convergence also with the work, especially that if you follow the standard and you have only signatures without.

514
01:03:59.550 --> 01:04:15.960
IT 31/2-028: But let's say at least, the very, very minimum would be that value the product. And then the well known endpoints and the discover, so that the discovery you expose the fact that you implement signatures. You do not have it yet until you spend the invites

515
01:04:16.060 --> 01:04:22.500
IT 31/2-028: and you implement whatever is there. I mean that. Just look at. And of course you're responsible.

516
01:04:22.740 --> 01:04:29.180
IT 31/2-028: and that will be the when the top and all the endpoint effectively to say exactly

517
01:04:29.470 --> 01:04:33.723
IT 31/2-028: what capabilities you are actually implementing in your, in your instance.

518
01:04:34.220 --> 01:04:37.469
IT 31/2-028: which at that point you can say 1.2, we

519
01:04:37.490 --> 01:04:40.620
IT 31/2-028: for those things. It is totally totally fine.

520
01:04:42.040 --> 01:04:54.007
Maxence: Yeah, and the the invites. We're gonna be implemented also for 31, the invite invite for workflow. But we're gonna see if it's interesting and easy to back port to

521
01:04:54.810 --> 01:05:02.389
Maxence: previous majorities of of next ad. I don't know down to which one, but we're gonna try to do something about the invite workflow.

522
01:05:02.730 --> 01:05:03.480
Maxence: Just.

523
01:05:04.146 --> 01:05:17.469
IT 31/2-028: A new release, and it would be kind of the package comes with a new version of next month, right.

524
01:05:18.100 --> 01:05:20.760
Maxence: Okay, let's work.

525
01:05:21.960 --> 01:05:22.250
Micke Nordin | Sunet: Yeah.

526
01:05:25.730 --> 01:05:26.730
Maxence: Last, points.

527
01:05:26.940 --> 01:05:29.710
IT 31/2-028: Regarding Nextloud and Osm

528
01:05:30.608 --> 01:05:40.319
IT 31/2-028: we we have. We have an app which is circles, which is teams. Now, since fuel release it have been renamed to teams.

529
01:05:40.330 --> 01:05:47.910
Maxence: And it allowed in in some setup like, I was talking about global scale, it allowed the generation of groups over the Federation.

530
01:05:48.320 --> 01:05:51.260
Maxence: meaning that you

531
01:05:51.360 --> 01:05:56.740
Maxence: you you can set a group. Let's call it a circle. We can set the circle as federated

532
01:05:57.350 --> 01:06:18.270
Maxence: and based on your your local setup. You it can be joined by user from multiple instance. And you can also invite people. You can assign a permission to manage the member list. You can add, moderator that will only be able to invite new member. You can add admin that got more possibility like changing the settings

533
01:06:19.510 --> 01:06:26.360
Maxence: when it's federated, every action is related to A. When you're managing the circle and you add a member, remove a member.

534
01:06:26.430 --> 01:06:47.770
Maxence: Those action, even if it's initiated from instance B, but the circles was generated on Circle A, are to be confirmed by the instance that owns the account of the current owner of the circle. So there is some kind of communication between the instances regarding that kind of group

535
01:06:48.360 --> 01:06:59.999
Maxence: that is unfortunately an internal communication protocol. It's really private to circles, and as we already discussed about it few months ago

536
01:07:00.320 --> 01:07:02.610
Maxence: on our the Ocm group.

537
01:07:03.340 --> 01:07:10.100
Maxence: The idea will be to work on a protocol within Ocm

538
01:07:10.510 --> 01:07:18.399
Maxence: to do this work. So in the continuity of the invite thing. It will be the

539
01:07:18.720 --> 01:07:24.380
Maxence: ability ability to a to generate a group of members

540
01:07:25.223 --> 01:07:35.529
Maxence: above multiple instance of of next cloud. But it's not. The idea is to not limit this to next cloud, but to the, to to deploy it to every

541
01:07:36.200 --> 01:07:44.579
Maxence: project that is using Ocm. And supporting Ocm. So the idea will be to write the protocol to

542
01:07:44.760 --> 01:07:48.780
Maxence: manage this kind of groups above Federation.

543
01:07:50.080 --> 01:07:58.359
Micke Nordin | Sunet: So like group invite. So you can invite somebody to become a member of a federated group.

544
01:07:59.200 --> 01:08:12.329
Maxence: Yeah, some kind of bigger entity. And when you share a file to that entity, from instance, a every user remote user that are within that either entity

545
01:08:12.991 --> 01:08:15.499
Maxence: will receive the the file.

546
01:08:18.460 --> 01:08:28.950
IT 31/2-028: Is this feature already in? As well? I remember the-, the discussion about discussion of sequels is there? I remember Frank presenting it last time at this 3 workshop.

547
01:08:29.069 --> 01:08:33.770
IT 31/2-028: But did you already implement this part of this one? The fund.

548
01:08:33.770 --> 01:08:34.120
Maxence: Yes.

549
01:08:34.120 --> 01:08:34.640
IT 31/2-028: Yes, sir.

550
01:08:34.649 --> 01:08:35.259
Maxence: SE.

551
01:08:36.060 --> 01:08:36.470
Maxence: Sorry.

552
01:08:36.470 --> 01:08:38.930
IT 31/2-028: It goes via to all of the users.

553
01:08:38.930 --> 01:08:46.239
Maxence: No, no, it's it does not use it. It only use the the fenerated sharing itself

554
01:08:46.430 --> 01:08:52.120
Maxence: to manage the share. But the the exchange, regrouping, creating a new share

555
01:08:52.708 --> 01:08:59.189
Maxence: adding a new member to your group. This kind of communication between instances.

556
01:08:59.340 --> 01:09:04.819
Maxence: It's not done using. Ocm, it's use its own communication protocol. And that's the problem.

557
01:09:04.950 --> 01:09:10.139
Maxence: The idea would be to write a new protocol on Ocm

558
01:09:10.630 --> 01:09:21.199
Maxence: that will allow that kind of operation, the one that is currently done by the by the circle app. So right now the feature is working. The proof of concept is is efficient

559
01:09:21.229 --> 01:09:25.019
Maxence: in if you are using the global scale feature. From next cloud

560
01:09:25.080 --> 01:09:32.399
Maxence: you can. You can generate a circles that contain number of multiple instance.

561
01:09:32.870 --> 01:09:44.449
Maxence: and they are managed like a circle. On your own instance, you can have admin moderator member, and the the role permission is is set up even

562
01:09:44.770 --> 01:09:46.969
Maxence: on multiple and different instance.

563
01:09:47.080 --> 01:09:51.120
Maxence: But the idea would be to have it, using.

564
01:09:52.010 --> 01:09:54.430
Maxence: finding the protocol within the Ocm.

565
01:09:54.490 --> 01:10:05.879
Maxence: And then having the circle, using that protocol to to do the same thing, but more openly, meaning that any other projects that is supporting Ocm.

566
01:10:05.980 --> 01:10:13.690
Maxence: Will be able to generate and and manage grouping over Federation or over the Cm. In fact.

567
01:10:13.830 --> 01:10:14.860
Micke Nordin | Sunet: So in, in.

568
01:10:14.860 --> 01:10:15.560
Michiel de Jong: Second.

569
01:10:15.750 --> 01:10:26.840
Micke Nordin | Sunet: In Ocm, we have a shared type, right? User group and federation is possible. And I think next cloud has only implemented user

570
01:10:26.940 --> 01:10:28.950
Micke Nordin | Sunet: share type for Ocm shares.

571
01:10:28.950 --> 01:10:30.040
Micke Nordin | Sunet: I agree that right.

572
01:10:30.040 --> 01:10:31.130
Maxence: We have group.

573
01:10:32.450 --> 01:10:33.999
Micke Nordin | Sunet: You have group now is, okay.

574
01:10:34.000 --> 01:10:46.240
Maxence: It's not like you have a part of a group on one instance and the other part of the same group on some other instance, the group right now, the group in Ocm. It's more like you share to a full group

575
01:10:46.310 --> 01:10:48.109
Maxence: on some of our instance.

576
01:10:48.320 --> 01:10:54.420
Michiel de Jong: So the Federation Share type was implemented for next cloud by Sandro

577
01:10:55.008 --> 01:11:00.089
Michiel de Jong: for Helmholtz, who wanted this but Helmholtz use an AI

578
01:11:00.290 --> 01:11:09.120
Michiel de Jong: which makes it a little bit different authorization, authentication infrastructure. So to this central group, database

579
01:11:10.286 --> 01:11:18.380
Michiel de Jong: groups database. And I implemented the same thing for surf on own cloud. 10.

580
01:11:18.890 --> 01:11:31.850
Michiel de Jong: And or I say, I it was actually with Madi and Navid, and yashar. And I think we were like 8 people working on that in the end. And it's a little bit tricky.

581
01:11:32.040 --> 01:11:58.999
Michiel de Jong: because 1st of all, you need to know who is in the group. When when you share something, then you need to. Look at okay, which servers are they at? And then each server that has at least one user from that group needs to receive the share they need to understand who on their server is part of the group. Those that information has to be in sync. And

582
01:11:59.390 --> 01:12:04.209
Michiel de Jong: then if one of the share requests fails, then

583
01:12:04.270 --> 01:12:25.400
Michiel de Jong: it's unclear, like, okay, I wanted to share this with 20 people. There are 7 different servers I was able to reach. Well, my own server and 6 others I was able to reach 4, and 2 of them were unreachable, so now I sort of created this share, and 17 out of 20 people see it. But the other 3 don't see it. I'm gonna retry, but

584
01:12:25.630 --> 01:12:27.332
Michiel de Jong: it gets complex

585
01:12:28.292 --> 01:12:41.320
Michiel de Jong: but we implemented it and so it's being tested by serve now on on Cloud 10, which they're moving away from. So it's that's I don't know. Actually, we Anton, should talk about.

586
01:12:41.320 --> 01:12:42.020
Micke Nordin | Sunet: Yeah, it was.

587
01:12:42.343 --> 01:12:43.960
Michiel de Jong: He has the latest information.

588
01:12:43.960 --> 01:12:44.729
IT 31/2-028: Sorry about that.

589
01:12:44.960 --> 01:12:45.840
Michiel de Jong: But of course, yeah.

590
01:12:46.370 --> 01:12:46.760
IT 31/2-028: Indeed.

591
01:12:46.940 --> 01:12:51.790
Antoon Prins: I'm not involved in this. Actually, that's told. Okay.

592
01:12:51.790 --> 01:12:52.120
Michiel de Jong: Okay.

593
01:12:52.120 --> 01:13:00.769
Antoon Prins: I have another question for Max. If he's saying he's going to implement invites. Does that mean?

594
01:13:01.010 --> 01:13:04.130
Antoon Prins: Are we talking about the invitation workflow

595
01:13:05.380 --> 01:13:07.130
Antoon Prins: as we know it from science. Mesh!

596
01:13:07.290 --> 01:13:08.400
IT 31/2-028: Yes, yes.

597
01:13:08.400 --> 01:13:09.490
Antoon Prins: Yeah, okay.

598
01:13:10.720 --> 01:13:11.940
IT 31/2-028: I mean this, we.

599
01:13:11.940 --> 01:13:14.090
Maxence: Already discussed about this. Yes, yes.

600
01:13:14.460 --> 01:13:19.820
Micke Nordin | Sunet: So, yeah, but so invites, except in next cloud and in the specification.

601
01:13:20.434 --> 01:13:26.640
Micke Nordin | Sunet: We do do not specify how an invitation is made so.

602
01:13:26.640 --> 01:13:30.779
Antoon Prins: Or are we talking about the Ocm. Endpoint invite, accepted.

603
01:13:30.780 --> 01:13:31.570
Micke Nordin | Sunet: Yes, so.

604
01:13:31.846 --> 01:13:33.779
Antoon Prins: Okay, so not the not the process.

605
01:13:33.780 --> 01:13:44.980
Micke Nordin | Sunet: Missing from next cloud, and also a way of keeping track of shares that you have received, invites, you mean, invites.

606
01:13:44.980 --> 01:13:46.509
Antoon Prins: So the management part.

607
01:13:46.510 --> 01:13:47.940
Micke Nordin | Sunet: Yeah, management. Part of invite.

608
01:13:47.940 --> 01:13:49.200
Antoon Prins: That's separate from.

609
01:13:49.480 --> 01:13:54.489
Antoon Prins: Yeah, that's I could actually, the most work goes into that

610
01:13:55.660 --> 01:13:57.590
Antoon Prins: endpoint is not very difficult. Of course.

611
01:13:57.590 --> 01:14:10.779
Micke Nordin | Sunet: Yeah. So on the sending an invite side, I think we may. We need to amend the current email thing with some more information. But it will be essentially the same.

612
01:14:11.060 --> 01:14:22.610
Micke Nordin | Sunet: and then the other part is the accepted. Invite endpoint and keeping track of invites and re-removing invites.

613
01:14:22.610 --> 01:14:22.940
Antoon Prins: Yeah.

614
01:14:22.940 --> 01:14:23.739
Micke Nordin | Sunet: Sort of thing.

615
01:14:23.920 --> 01:14:28.660
Antoon Prins: Yeah. So as you may or may not know, we implemented this invitation workflow

616
01:14:28.920 --> 01:14:36.430
Antoon Prins: as an app for our own cloud. In that app we also implemented all Cloud 10. In that

617
01:14:36.960 --> 01:14:42.290
Antoon Prins: app. We have also implemented the the invite accepted Ocm. Endpoint

618
01:14:42.580 --> 01:14:46.630
Antoon Prins: because that wasn't there. And now we're in the process of

619
01:14:47.576 --> 01:14:51.740
Antoon Prins: creating a similar app for next cloud.

620
01:14:55.384 --> 01:14:58.145
Antoon Prins: We already discussed this with mix science.

621
01:15:00.080 --> 01:15:08.459
Antoon Prins: so yeah, I just need to know how far next cloud will, we'll be implementing

622
01:15:08.610 --> 01:15:10.460
Antoon Prins: this. So is it only the

623
01:15:11.070 --> 01:15:19.000
Antoon Prins: the Ocm Endpoint invite, accepted? Or is it also going to be the management of of invites.

624
01:15:19.250 --> 01:15:25.200
Micke Nordin | Sunet: Yeah. So that's that's what Navid has been working on the management of invites.

625
01:15:25.840 --> 01:15:36.200
Micke Nordin | Sunet: So it's in. It will be in the Pr, it's a. It's in a separate branch on the fork that we have of next cloud where we're working on the

626
01:15:36.270 --> 01:15:47.670
Micke Nordin | Sunet: will request. So I haven't had a chance to to look at it yet and try it out, and the it's the Pr. Is still pretty rough.

627
01:15:47.790 --> 01:15:54.040
Micke Nordin | Sunet: So that's why it's a work in progress, and it's not ready to be merged, but it's an ongoing effort at least.

628
01:15:55.523 --> 01:16:05.470
IT 31/2-028: Especially that, to my view, having the invite accepted endpoint at the back end without the-. The management of the invitations

629
01:16:05.540 --> 01:16:10.690
IT 31/2-028: at the front end level is kind of it's useless.

630
01:16:10.690 --> 01:16:14.029
IT 31/2-028: Yeah, yeah, yeah, they're good together, after all.

631
01:16:14.030 --> 01:16:15.979
Antoon Prins: Exactly exactly, and most work goes.

632
01:16:16.473 --> 01:16:25.359
IT 31/2-028: Would all of you to convince me to work with the same on the same for the same.

633
01:16:25.360 --> 01:16:25.910
IT 31/2-028: Yeah, yeah, that's.

634
01:16:27.180 --> 01:16:41.759
Micke Nordin | Sunet: That that's what Navid has been doing. So he, Navid, has a branch in the fork, and the Navid's branches will be merged into the main branch, which the is what the pull request is against. So it's just that

635
01:16:41.800 --> 01:16:45.100
Micke Nordin | Sunet: we haven't had time to to finalize that yet.

636
01:16:45.760 --> 01:16:51.089
Micke Nordin | Sunet: So, but we definitely should set up a meeting between at least Navid and Anton.

637
01:16:51.770 --> 01:16:52.260
Micke Nordin | Sunet: Yeah, sure.

638
01:16:52.612 --> 01:16:54.019
Michiel de Jong: Talk about the code

639
01:16:54.900 --> 01:17:01.130
Michiel de Jong: and compare you know, I compare actual Php code and see how to merge the efforts.

640
01:17:02.610 --> 01:17:09.389
Frank Karlitschek: Maybe there's another thing. I can share what's happening on the next cloud side. That might be interesting for this group

641
01:17:09.907 --> 01:17:19.509
Frank Karlitschek: mentioned before, but maybe with an update here. So in the Ocm spec, we have this resource type field, right?

642
01:17:19.520 --> 01:17:25.889
Frank Karlitschek: Which is for like mostly everybody here cares about files, I guess, mostly.

643
01:17:26.100 --> 01:17:30.120
Frank Karlitschek: But the ideas, of course, was uses for other resource types.

644
01:17:30.160 --> 01:17:39.850
Frank Karlitschek: And we implemented it in the version 29 like early this year already for invitations for federated chats.

645
01:17:40.210 --> 01:18:00.590
Frank Karlitschek: So in in next cloud, we have next talk, which is for chatting, video, conferencing. And we implemented Federated chatting. So you can actually have a chat room with people on different servers, or you can also have people from all different instances in the same chat conversation. And we use Ocm for that of course.

646
01:18:00.610 --> 01:18:03.470
Frank Karlitschek: using this resource type.

647
01:18:03.490 --> 01:18:12.340
Frank Karlitschek: And in the last version, the version 30 that we released like a few weeks ago, we expanded this to video calls to.

648
01:18:12.620 --> 01:18:21.179
Frank Karlitschek: So you can have now, video calls between different people like as we do here on this proprietary evil software. Soon you should switch to something nicer.

649
01:18:22.034 --> 01:18:29.940
Frank Karlitschek: And we can have like a call like that. But actually, everybody is in a different instance. And we also have to with the Ocm

650
01:18:30.090 --> 01:18:33.320
Frank Karlitschek: invitation system.

651
01:18:33.480 --> 01:18:44.710
Frank Karlitschek: And you can also then just call people on different servers, you know, you can. Just it's not only for this arranged video calls, group conversations, meetings like here, you can actually call people.

652
01:18:44.720 --> 01:18:49.940
Frank Karlitschek: And then the the phone rings. If the phone is connected to the server

653
01:18:50.443 --> 01:18:54.979
Frank Karlitschek: with the VoIP calling interface, just as normal phone call.

654
01:18:55.406 --> 01:18:59.469
Frank Karlitschek: actually, in, people are on different instances or using Ocm.

655
01:18:59.570 --> 01:19:04.429
Frank Karlitschek: And this all, of course, means that the whole concept of invitations.

656
01:19:04.490 --> 01:19:07.950
Frank Karlitschek: We have a bit of more advanced requirements here.

657
01:19:08.140 --> 01:19:15.020
Frank Karlitschek: because this is not about just sending showing something in the list or sending an invitation email or something. This all has to be instant.

658
01:19:15.090 --> 01:19:18.830
Frank Karlitschek: Alright. So if someone basically calls someone. It's an Ocm call

659
01:19:18.860 --> 01:19:22.819
Frank Karlitschek: invitation. But this, then, needs to be sent out as a push notification

660
01:19:23.226 --> 01:19:33.340
Frank Karlitschek: to the different devices of the people that I can with just one click, then accept it. And then, being a video audio call with the people on different instance fully federated.

661
01:19:33.680 --> 01:19:48.039
Frank Karlitschek: So yeah, it's probably a topic, probably a topic that most of you are not super interested in. But we are expanding the use of Ocm into all kinds of collaboration features, way beyond file, sharing.

662
01:19:48.570 --> 01:19:52.990
Micke Nordin | Sunet: Oh, contrary, we're very interested. So I think this is great. And we actually, we.

663
01:19:52.990 --> 01:19:58.610
IT 31/2-028: Yeah, we modeled 1.2, yeah, on one.

664
01:19:58.610 --> 01:20:13.290
Micke Nordin | Sunet: You did for talk so 1.2 is, should be compliant with what you are doing for talk there, and you should be able to use the invite accepted endpoint to accept any kind of invitation

665
01:20:13.470 --> 01:20:16.040
Micke Nordin | Sunet: there. So yeah, let's.

666
01:20:16.260 --> 01:20:39.409
IT 31/2-028: Slightly different if you can say because there is a I mean the difference with the invitation so far was that we want to discover the other end in this case, for what Frank says is a instant, but already knowing, what is that? The server so? And then it's just inviting the user to connect to the, to the talk, but not to discovering the user. So clearly, the scope is different.

667
01:20:39.510 --> 01:21:03.779
IT 31/2-028: But yes, it's an interesting solution. But I really want to make clear to myself the story of those circles, and what can be done, and what cannot be done yet, or what will be done after. So right? And

668
01:21:04.360 --> 01:21:17.589
IT 31/2-028: you can create those groups, and you can invite people. And this at the moment goes into a dedicated next cloud protocol, which eventually would be nice part of the protocol. Fine. But

669
01:21:17.610 --> 01:21:44.970
IT 31/2-028: after you have the circle, can you share resources? Files, whatever with the circle or not? Or is that the part that is not yet implemented. And it's what we consider to do, using what actually, I mean, this was a bit. And so this will be sharing to a group of Federation group that spans multiple instances.

670
01:21:45.030 --> 01:21:50.580
IT 31/2-028: So is that what we have next? Or do you already something integrated in this cloud.

671
01:21:51.420 --> 01:21:58.440
Maxence: We. We already have this working in next start, I was, I was saying, you can share files above multiple instance

672
01:21:58.510 --> 01:22:08.229
Maxence: through a circle. When you share a file to a circle that owns members or account. From other instances the file is shared to everyone.

673
01:22:08.690 --> 01:22:09.250
Maxence: to other.

674
01:22:09.250 --> 01:22:09.790
IT 31/2-028: For instance.

675
01:22:09.790 --> 01:22:15.620
Maxence: And to everyone within the circuit. That's the that's the how it works right now as of today. And already

676
01:22:16.030 --> 01:22:23.350
Maxence: version, the idea is to migrate the exchange protocol to Ocm. To integrate.

677
01:22:23.350 --> 01:22:33.579
IT 31/2-028: So this works completely with desktop specific protocols and ideas to manage to move this entire workflow into being compliant.

678
01:22:33.580 --> 01:22:34.200
Maxence: Exactly.

679
01:22:34.200 --> 01:22:42.205
IT 31/2-028: You also sharing for groups which would be already there. But it's your specialness cloud sharing for federations.

680
01:22:43.690 --> 01:22:44.500
Micke Nordin | Sunet: Yeah.

681
01:22:44.500 --> 01:22:56.580
Micke Nordin | Sunet: I I wanna ask you. So if I understand this correctly. So the share share type in the spec it's user group and Federation user is a single person.

682
01:22:57.270 --> 01:23:02.910
Micke Nordin | Sunet: either on the local node or the remote. So I guess in the context of.

683
01:23:02.910 --> 01:23:03.330
Michiel de Jong: The target.

684
01:23:03.701 --> 01:23:06.298
Micke Nordin | Sunet: It's on, it's on the remote node

685
01:23:06.690 --> 01:23:18.149
Micke Nordin | Sunet: and group is also the on a remote node federation is that like on a federated group. So a group spanning multiple servers. So

686
01:23:18.150 --> 01:23:20.400
Micke Nordin | Sunet: that would be the same as a circle. Then.

687
01:23:20.810 --> 01:23:28.670
Michiel de Jong: So don't get confused between federated sharing, which is just Ocm. All Ocm is federated sharing

688
01:23:29.177 --> 01:23:36.470
Michiel de Jong: and it's federated sharing as opposed to local sharing. Right? 2 people are on one server. You don't have to do anything search.

689
01:23:36.620 --> 01:23:41.209
Michiel de Jong: So then, yeah, user to user

690
01:23:41.510 --> 01:23:47.770
Michiel de Jong: a user to group to remote group and then

691
01:23:48.040 --> 01:23:56.090
Michiel de Jong: a Federation share type is an Ocm request that is, part of a set of Ocm. Requests that together

692
01:23:56.150 --> 01:24:05.259
Michiel de Jong: make up share with the Federated with a virtual organization or a what else can you call it? A circle, or a team, or.

693
01:24:05.820 --> 01:24:06.390
Maxence: Entity.

694
01:24:08.050 --> 01:24:08.800
Micke Nordin | Sunet: And.

695
01:24:09.804 --> 01:24:31.899
Michiel de Jong: what? What also is worth mentioning is that what Sandro and our team built last year, and that we called the Ocm. Request in there, of which you will make a few right, because some of the people in the group will be in different service for each server that has at least one group member. You're gonna make a Federation type. Ocm request.

696
01:24:31.900 --> 01:24:32.480
Micke Nordin | Sunet: Hmm.

697
01:24:32.480 --> 01:24:37.399
Michiel de Jong: But that's just a notification about the share being created for

698
01:24:37.930 --> 01:24:47.920
Michiel de Jong: people in different places. And what we built was all based on AI. So the setup where all these servers that are involved

699
01:24:48.509 --> 01:24:54.229
Michiel de Jong: share a database somehow share a state of who is in the group

700
01:24:54.430 --> 01:24:58.959
Michiel de Jong: and in for surf. We implemented that with a

701
01:24:59.700 --> 01:25:03.480
Michiel de Jong: Tom Vesopel implemented a proxy which

702
01:25:03.530 --> 01:25:12.740
Michiel de Jong: receives skim requests from the surf resource access management system, and then

703
01:25:12.760 --> 01:25:30.670
Michiel de Jong: forwards that to all nest cloud servers. And so that is a pretty complex setup. But it's also, but it's still more centralized than what Max Hans is describing where you just have only Efs servers that talk to each other without a central group server.

704
01:25:30.710 --> 01:25:38.429
Michiel de Jong: So I think it really it's a complex challenge to keep these groups in sync.

705
01:25:38.910 --> 01:25:41.970
Michiel de Jong: But I'm so I'm very interested in

706
01:25:42.615 --> 01:25:50.439
Michiel de Jong: the Max census proposal to bring this to the Ocm group and to make it a spec. I think that's very exciting

707
01:25:50.968 --> 01:25:56.210
Michiel de Jong: cause. It's even more advanced than what any of us have been doing so far.

708
01:25:57.510 --> 01:26:17.129
Maxence: And just just for security reason as we are talking about it. And I don't think it's really the subject of the of the call. But yeah, so circles over. Ocm we also I also already implemented. So this will be implemented to Ocm, it's like a trust. Sorry it's like a trust level between instances.

709
01:26:17.520 --> 01:26:27.450
Maxence: meaning that if you fully trust an instance, you're gonna have access to the to the full member list within the the group

710
01:26:28.140 --> 01:26:42.459
Maxence: on a remote instance, and if you don't trust the instance, there is different level, but from 0 to 5 I would say so. 5 you fully trust, and you have access to the member list and detailed, and if you don't trust it, you are part of the group, but you don't know

711
01:26:42.800 --> 01:27:00.759
Maxence: the member. That's on some other instance for the same group. Okay, let's call it circles, because it's going to be easier. We're going to find a new name for the Ocm protocol. But if I'm on instance A and I don't trust instance B, when I share a file to a circles that contain members from both instance.

712
01:27:00.830 --> 01:27:10.719
Maxence: they all receive the file. That's okay. But I don't know. I don't have the name of the list of member within the circle, for instance, B, because.

713
01:27:11.400 --> 01:27:13.950
Maxence: The intent. B doesn't doesn't trust me.

714
01:27:13.970 --> 01:27:19.990
Maxence: So I don't have access to detail about the user. This is just a level, different level of trust that will

715
01:27:20.060 --> 01:27:27.490
Maxence: do. You have access to the member list? Do we have access to the detail about this number? Do we have access to everything about these numbers that kind of thing.

716
01:27:28.410 --> 01:27:35.599
Maxence: This will be integrated to the, to the protocol also. When it would be for ocm.

717
01:27:35.970 --> 01:27:40.430
IT 31/2-028: So this is more like really sharing the like. The business card of the user for me.

718
01:27:41.120 --> 01:27:42.300
Maxence: Sorry. Excuse me.

719
01:27:42.520 --> 01:27:47.512
IT 31/2-028: It looks like that. It's like sharing the business card of the usage. So all the details that.

720
01:27:47.790 --> 01:27:48.200
Maxence: Yes.

721
01:27:48.510 --> 01:28:04.080
IT 31/2-028: Which actually is a bit what? What the it is, exactly what this invitation workflow eventually does on the payload, like the payload of the invitation of the invite accepted, and the response is exactly like the exchange of a business card.

722
01:28:04.270 --> 01:28:08.500
IT 31/2-028: All possibilities that that you may want to know.

723
01:28:08.560 --> 01:28:12.562
IT 31/2-028: On the on the other party. So they both know each other completely.

724
01:28:13.316 --> 01:28:18.969
IT 31/2-028: So. But indeed it's a it's a nice. It's a nice direction, all of this.

725
01:28:20.580 --> 01:28:35.379
IT 31/2-028: okay, I let you speak. Given that the topic is interesting. It was a nice exchange also, because I see, anyway, that so we took over his lot.

726
01:28:35.470 --> 01:28:43.080
IT 31/2-028: But at this point I would still go for closing this path, which was the start of the prop. Let's say, of all the implementations.

727
01:28:43.320 --> 01:28:45.180
IT 31/2-028: even though we've spoken

728
01:28:45.320 --> 01:28:50.231
IT 31/2-028: mostly about only 7 or 6 cloud, a little bit of a cloud. Nothing but C. 5.

729
01:28:50.640 --> 01:29:01.872
IT 31/2-028: I'm sure we can say something about C. 5 in a moment well, in the next part, because of the money will present, because he also tested C. 5.

730
01:29:02.330 --> 01:29:08.110
IT 31/2-028: So, and despite that we propose to take a little break. I also have to

731
01:29:08.220 --> 01:29:20.380
IT 31/2-028: something here, but so let's stick to the agenda so that we frame we frame it properly. So we have a little break until so 7 min from now until 1110.

732
01:29:20.430 --> 01:29:44.530
IT 31/2-028: Just grab a coffee something, and we see again here, and the next part will be more in the evolution of the standard which okay, we follow a little bit already discussed. But then, on what has been done in the in this project. So the test suite. And what's next?

733
01:29:46.230 --> 01:29:52.473
IT 31/2-028: So okay, see you, I'll stay connected. But I see you in yeah, 5 min.

734
01:29:52.890 --> 01:29:53.620
Micke Nordin | Sunet: Okay.

735
01:29:53.620 --> 01:29:55.050
IT 31/2-028: Thanks. Thanks so far.

736
01:30:29.470 --> 01:30:40.029
IT 31/2-028: Okay, so I guess we can restart. As you see, people like to come back. But I see at least once you back

737
01:30:40.700 --> 01:30:41.826
IT 31/2-028: and the

738
01:30:43.750 --> 01:31:00.159
IT 31/2-028: well. With this I would even say, maybe, and we hear about who presents what. So I leave you.

739
01:31:01.360 --> 01:31:03.259
IT 31/2-028: I leave you the floor. Let's say.

740
01:31:03.260 --> 01:31:12.469
Micke Nordin | Sunet: Yeah, I think the idea is that Mardi and Mihil will present some slides and things about the annual

741
01:31:12.760 --> 01:31:23.480
Micke Nordin | Sunet: and that funded work. And then we have an open discussion after that, and I will try to to moderate that a bit low, so similar

742
01:31:23.500 --> 01:31:31.719
Micke Nordin | Sunet: like what we no but bit more structured. Maybe so. I leave the floor to you, Madi and Mihil.

743
01:31:33.700 --> 01:31:35.490
Mahdi Baghbani: Thanks!

744
01:31:35.750 --> 01:31:39.019
Mahdi Baghbani: Oh, oh! Oh, I'll go first.st

745
01:31:45.790 --> 01:31:48.572
IT 31/2-028: But if you think you have limited bandwidth.

746
01:31:48.960 --> 01:31:54.699
IT 31/2-028: it's okay also not to share the screen and sorry not to share the camera.

747
01:32:05.400 --> 01:32:08.000
Mahdi Baghbani: That's true.

748
01:32:08.150 --> 01:32:10.779
Mahdi Baghbani: Good with is, is.

749
01:32:12.941 --> 01:32:16.690
IT 31/2-028: Now, the how this really cut, yeah.

750
01:32:19.220 --> 01:32:21.610
Mahdi Baghbani: My screen.

751
01:32:24.630 --> 01:32:27.329
IT 31/2-028: The audio is really bad, the screen.

752
01:32:27.550 --> 01:32:31.469
IT 31/2-028: the screen sharing, but also not also cut.

753
01:32:33.700 --> 01:32:38.049
Micke Nordin | Sunet: I don't know if you maybe can send your slides to Michel or something, and.

754
01:32:39.320 --> 01:32:42.979
IT 31/2-028: Can talk exactly them in the in the workflow page.

755
01:32:43.120 --> 01:32:44.570
IT 31/2-028: Then we share them.

756
01:32:45.180 --> 01:32:47.489
Mahdi Baghbani: Yeah. Do you hear me now? Is it better.

757
01:32:47.490 --> 01:32:48.250
Micke Nordin | Sunet: So it's.

758
01:32:48.470 --> 01:32:48.900
IT 31/2-028: The dogs.

759
01:32:48.900 --> 01:32:50.860
Micke Nordin | Sunet: Screen and and camera. It works.

760
01:32:51.400 --> 01:32:51.650
IT 31/2-028: Alright!

761
01:32:51.650 --> 01:32:56.980
Mahdi Baghbani: Okay, so let me share it again and see if it didn't work. I will send it to Miguel

762
01:32:57.250 --> 01:32:58.300
Mahdi Baghbani: hopefully.

763
01:33:01.310 --> 01:33:04.190
IT 31/2-028: Or just upload the okay, that works.

764
01:33:04.530 --> 01:33:06.599
IT 31/2-028: Well, let's see. Maybe.

765
01:33:06.600 --> 01:33:17.240
Mahdi Baghbani: Okay, so it works so we have started working on the New test suite over a year ago, after the Science Mission, when we had to do all the tests manually

766
01:33:17.420 --> 01:33:18.760
Mahdi Baghbani: and

767
01:33:19.353 --> 01:33:29.626
Mahdi Baghbani: so. But this time we wanted to do everything by an end to end testing with Cyprus. So

768
01:33:30.420 --> 01:33:35.080
Mahdi Baghbani: I'm going to just give you an overview of what we have done.

769
01:33:35.120 --> 01:33:39.219
Mahdi Baghbani: And what is the so?

770
01:33:40.200 --> 01:33:54.279
Mahdi Baghbani: we have to test the interoperability between different Efs platforms like next cloud oncloud and osis they might test their own apps, but they wouldn't test with the other platforms.

771
01:33:54.290 --> 01:34:05.459
Mahdi Baghbani: and that was the cause of problem. Because, if you remember, when we had this big test with different universities some of them use on cloud, and then, some other use next cloud.

772
01:34:05.510 --> 01:34:20.849
Mahdi Baghbani: And we also have sandbox on top of that. So when people test their software within them so they couldn't be sure that it's going to work on another university like Psnc. Or some other universities.

773
01:34:21.160 --> 01:34:33.790
Mahdi Baghbani: And also we found that that the standards are not following correctly, there was a test between Joseph and I which we discovered that next cloud is not doing.

774
01:34:35.360 --> 01:34:47.210
Mahdi Baghbani: you know, the exact thing that the Ocm. Api has in this way. So we reported it, and I think Maxen has solved it.

775
01:34:48.565 --> 01:34:49.530
Mahdi Baghbani: I.

776
01:34:52.220 --> 01:34:56.569
Mahdi Baghbani: And the other thing is that we also need to do everything automated

777
01:34:57.199 --> 01:35:07.689
Mahdi Baghbani: so I haven't done that yet, like I mean, I have to still go and select the exact next slide release still by hand.

778
01:35:07.980 --> 01:35:10.858
Mahdi Baghbani: and next slide is really fast, like,

779
01:35:11.420 --> 01:35:13.980
Mahdi Baghbani: they just released 29 and 30.

780
01:35:14.240 --> 01:35:20.340
Mahdi Baghbani: I'm already on 28. So I need to. You know, implement 28 and 30

781
01:35:20.650 --> 01:35:35.929
Mahdi Baghbani: by hand. So what we do is that we do the cross platform validation to ensure that platforms can share to each other. And then, we are going to test file, sharing invitation and the share link.

782
01:35:36.040 --> 01:35:52.649
Mahdi Baghbani: So when you create a public link, the ability to add that link to your own storage. This is the feature that makes a lot of cloud. They have it, but I think Osis doesn't have it as far as I tested it, and sandbox also doesn't have it.

783
01:35:52.990 --> 01:35:58.620
Mahdi Baghbani: C. File also doesn't have it. But it's a good feature. So we are going to keep the test

784
01:35:58.970 --> 01:36:10.990
Mahdi Baghbani: and we have the login test. Login tests are just, you know, login test that we can. You know, validate that we can bring up the instance, correctly and log in into it.

785
01:36:11.130 --> 01:36:18.569
Mahdi Baghbani: and see if everything works. But the realtors are like share links and invite links and share with.

786
01:36:19.730 --> 01:36:36.639
Mahdi Baghbani: So how the test suite works. We have a darker environment, and we don't use the official dockers of next cloud and on cloud, because next cloud is like an all in one docker installation

787
01:36:36.700 --> 01:36:48.849
Mahdi Baghbani: that installs everything and every app. It is very good for self hosting. I use it on raspberry pi. Great experience before. But for testing, that's a bit too much

788
01:36:49.290 --> 01:36:53.190
Mahdi Baghbani: so we create our own docker images for that

789
01:36:53.460 --> 01:37:02.060
Mahdi Baghbani: and for C file, we use the you know official ones, and also like that and sandbox. We use a bundle, a provider from sandbox

790
01:37:02.557 --> 01:37:09.120
Mahdi Baghbani: so we also use cypress, which is an end to end platform testing.

791
01:37:09.530 --> 01:37:25.230
Mahdi Baghbani: And we use the Github action. So we create an action, a Github job for every test we want to have. For example, in the left side you can see the Ocm test invite link between an Excel out version 27 to an excel out version 28,

792
01:37:25.300 --> 01:37:32.759
Mahdi Baghbani: and also the Login test for Ocs, and also we have created an Ocm stuff. We just test the Ocm compatibility.

793
01:37:32.830 --> 01:37:40.219
Mahdi Baghbani: We also do the tests like that. And on the right side. You can see some result of that. Say, test.

794
01:37:42.420 --> 01:37:50.119
Mahdi Baghbani: So there is also, the Ocm compatibility result in the form of a group table

795
01:37:50.230 --> 01:38:00.619
Mahdi Baghbani: that shows the results of these tests. Like, we have to share link test that initial out 27 can share a link to a public link

796
01:38:00.840 --> 01:38:15.710
Mahdi Baghbani: and a user that has an account on another instance. With Nexla, 27 can open the public link and then add it to its own account on next lot 27. But it doesn't work for Nexella. 28.

797
01:38:17.201 --> 01:38:22.829
Mahdi Baghbani: you know, sharing from 27 to 28 doesn't work, but sharing from 27 to own cloud works.

798
01:38:22.960 --> 01:38:37.249
Mahdi Baghbani: Also, next lot. This is actually the interesting one that I found like updating a minor version next slide 28, next lot 28 0 point 6. It was green, but now it's fading. I don't know why.

799
01:38:37.650 --> 01:38:43.259
Mahdi Baghbani: Next lot 28 can share to next lot 27, but cannot share to itself.

800
01:38:43.580 --> 01:38:52.349
Mahdi Baghbani: but also can share. To own cloud version 10. I think something on the receiver side of next 2 and 8 is broken.

801
01:38:52.730 --> 01:38:59.890
Mahdi Baghbani: But I didn't, you know, divide that we can see the result for other test cases like that.

802
01:39:00.680 --> 01:39:04.760
Mahdi Baghbani: We don't have the invite link just for next lot for any

803
01:39:04.820 --> 01:39:15.360
Mahdi Baghbani: 8, and up because now it is working on that. So the invite link is not complete for them. So if I included it with science, Mister, it works with the Plugin.

804
01:39:15.460 --> 01:39:21.309
Mahdi Baghbani: But when they are done implementing that feature, we can add the test in the test rate.

805
01:39:21.720 --> 01:39:27.940
Mahdi Baghbani: There is also video of invite polluters from posts to next club.

806
01:39:28.546 --> 01:39:34.320
Mahdi Baghbani: The video is rather fast, because this not failing.

807
01:39:34.470 --> 01:39:36.259
Mahdi Baghbani: So you might not see it.

808
01:39:36.290 --> 01:39:43.440
Mahdi Baghbani: Little bit of details, but when a test fails you can see what happened. And why did it fail?

809
01:39:43.760 --> 01:39:47.700
Mahdi Baghbani: So I'm just showing this.

810
01:39:50.810 --> 01:39:58.150
Mahdi Baghbani: There is just an invite link below that creates an invite, accept an invite, goes to osis again and

811
01:39:58.639 --> 01:40:05.210
Mahdi Baghbani: creates a file. Then yeah, save the file and share it to the contact.

812
01:40:05.920 --> 01:40:14.110
Mahdi Baghbani: And then when the share was added successfully, it goes back to the receiver side and

813
01:40:14.770 --> 01:40:20.919
Mahdi Baghbani: accept the show and see the share, is there.

814
01:40:22.120 --> 01:40:24.929
Mahdi Baghbani: Yeah, that was, that quote was too fast.

815
01:40:25.610 --> 01:40:37.329
Mahdi Baghbani: But anyway, so we have another test for next, and there is a 1 for C. 5. I think I'm running out of time, so I'm not going to show that.

816
01:40:38.200 --> 01:40:38.840
Michiel de Jong: Oh!

817
01:40:39.127 --> 01:40:39.990
IT 31/2-028: Has to be.

818
01:40:39.990 --> 01:40:40.620
Michiel de Jong: Take care!

819
01:40:41.190 --> 01:40:47.275
IT 31/2-028: But just to be sure, when you share, when you do, the event flow between the office and this cloud

820
01:40:47.650 --> 01:40:57.560
IT 31/2-028: is that, like the size mesh population with? Or are you using the pull? Request that and the.

821
01:41:00.290 --> 01:41:09.829
Mahdi Baghbani: No, their app isn't complete, and that it's using with science. Mesh, I you know.

822
01:41:10.740 --> 01:41:13.329
Mahdi Baghbani: let me go back to this slide.

823
01:41:13.900 --> 01:41:18.949
Mahdi Baghbani: So it is the slide, as you can see in the inviting test.

824
01:41:22.404 --> 01:41:29.630
IT 31/2-028: So that, yes, okay, very good.

825
01:41:29.820 --> 01:41:30.790
IT 31/2-028: Yeah.

826
01:41:31.300 --> 01:41:33.659
Mahdi Baghbani: And that's just with that.

827
01:41:34.056 --> 01:41:42.859
Mahdi Baghbani: But when they are done implementing, I can add the new invite link test with, updated next slide versions to the queue.

828
01:41:42.860 --> 01:41:43.870
IT 31/2-028: Of course.

829
01:41:45.250 --> 01:42:11.440
Mahdi Baghbani: And there is also developers, guides like a mini developers. Guide. I tried to document what I have done and how you can run the test yourself. So it's like pretty easy. It's just one single command. Well, you need to use it on dev site. But we are planning to migrate the Ocm test suite from Devast to its own repository. So you're not going to see a lot of different

830
01:42:11.888 --> 01:42:23.109
Mahdi Baghbani: unrelated scripts in there. But comment itself is like easy you just type of test suite and then provided a test scenario

831
01:42:23.170 --> 01:42:38.089
Mahdi Baghbani: which we have login share with invite link or share. Link, and then you're going to pass the name of the 1st platform. Next to that, we have discern box into your lips yet, but I didn't include it because.

832
01:42:39.570 --> 01:42:42.020
Mahdi Baghbani: is had that problem juice had mentioned.

833
01:42:42.210 --> 01:42:58.449
Mahdi Baghbani: And then you provide the version of the platform one, and then you're going to provide the run mode run mode is a Ci and dev like David, while you're trying to develop the test and go inside the Gui environment of the surface. And

834
01:42:58.794 --> 01:43:24.270
Mahdi Baghbani: you know, they will have to test the new test, or, you know, modify the other test, and the Ci. One is a headless, and it doesn't open a query. It just shows you the test result. And then, the Cyprus runner, Cyprus gives you ability to run the test in different browsers. But it's just not in the scope of the posting test suite. We don't care about broader compatibility.

835
01:43:24.380 --> 01:43:26.900
Mahdi Baghbani: so we can just select election

836
01:43:27.290 --> 01:43:37.179
Mahdi Baghbani: and go ahead. Then, for login test. You don't need to, you know, provide the second platform for. But for all the other tests you need to also provide a second platform.

837
01:43:37.200 --> 01:43:41.889
Mahdi Baghbani: which has the similar arguments like the platform name and its version.

838
01:43:42.540 --> 01:43:51.414
Mahdi Baghbani: So if someone wants to test it on their own machine, they just need to prove the images. The images are also

839
01:43:52.188 --> 01:43:57.570
Mahdi Baghbani: I said, we have mostly official images, but some of them are counter source images.

840
01:43:57.640 --> 01:44:00.269
Mahdi Baghbani: so you can even build them yourself.

841
01:44:00.690 --> 01:44:11.900
Mahdi Baghbani: And I also benefits of hosting test suite.

842
01:44:12.424 --> 01:44:21.270
Mahdi Baghbani: You're not ensuring interoperability, as you know it. But what I'm really interested in is real time validation, which is not done yet.

843
01:44:21.733 --> 01:44:38.069
Mahdi Baghbani: Next slide has this pre-release things they just pre release it before the actual release. So if we can somehow create some hooks that you know, automatically, as new versions to Ocm test suite.

844
01:44:38.130 --> 01:44:46.360
Mahdi Baghbani: we can even test the releases before they are, you know, made into the production and

845
01:44:46.950 --> 01:44:54.970
Mahdi Baghbani: compliance. Facility is not really how you do it on, you know, end to end tests.

846
01:44:55.080 --> 01:44:57.490
Mahdi Baghbani: because on end to end test. You just

847
01:44:57.710 --> 01:45:08.349
Mahdi Baghbani: try to see how the end user would interact with your application. And if they can just share the file and access the file on the other surface, or what?

848
01:45:08.370 --> 01:45:33.999
Mahdi Baghbani: But maybe we can do other than end to end testing like with Ocm stuff that Michael provided, and also Mika created an app to interact with the Ocm on next cloud. We might have opportunity to create a better test like not the Gui test. But the test that interacts actually with the Api

849
01:45:34.000 --> 01:45:53.159
Mahdi Baghbani: and validates the the other stuff like is your Json correct? If you have some you know, things in your Ocm. Provider that is not in the aspect. Or if you're doing the sign correctly, and other sort of stuff

850
01:45:53.692 --> 01:46:04.110
Mahdi Baghbani: that are really makes it to to different application, to be compliant with the Ocm. For example, C file implemented Ocm.

851
01:46:04.130 --> 01:46:05.180
Mahdi Baghbani: Endpoint.

852
01:46:05.420 --> 01:46:21.879
Mahdi Baghbani: and they were wondering why they cannot share to nextlab, and it turns out that they weren't following the Ocm. Spec. And they were just putting some different stuff in the Ocm. Provider. That next lab didn't even understand

853
01:46:22.140 --> 01:46:23.689
Mahdi Baghbani: and couldn't make sense of.

854
01:46:23.790 --> 01:46:28.430
Mahdi Baghbani: So I think I'm done.

855
01:46:29.220 --> 01:46:32.770
Mahdi Baghbani: Yeah, I think this part is for Maker.

856
01:46:33.707 --> 01:46:39.579
Mahdi Baghbani: so I'm pretty much done. Thank you for listening to.

857
01:46:42.890 --> 01:46:47.110
Micke Nordin | Sunet: Thank you, mil, to add something or.

858
01:46:49.807 --> 01:46:52.650
Michiel de Jong: well, about the call to action.

859
01:46:53.270 --> 01:47:01.200
Michiel de Jong: I think it would be great if implementers would include the Ocm test suite in their Ci.

860
01:47:03.090 --> 01:47:07.250
Michiel de Jong: so yeah. Asking mainly next cloud and cernbox.

861
01:47:09.320 --> 01:47:11.289
Michiel de Jong: What are your thoughts on that.

862
01:47:15.547 --> 01:47:24.002
IT 31/2-028: Who goes first.st Actually, I would have a technical question there, very willing to include this in the but technically can

863
01:47:24.500 --> 01:47:33.556
IT 31/2-028: kind of. So should I kind of import the repo and or- or How would you see?

864
01:47:34.510 --> 01:47:46.390
IT 31/2-028: maybe one thing that you could do? I'm just thinking loud is provide an example of A, of an of an action that I would import into my record, which actually goes and calls

865
01:47:46.670 --> 01:47:56.140
IT 31/2-028: this this because I would imagine that check out the suite and execute the thing from my own. Ci.

866
01:47:57.304 --> 01:48:07.419
IT 31/2-028: The action that runs with the CIO at different level, so how can I adopt.

867
01:48:07.420 --> 01:48:07.760
Michiel de Jong: If.

868
01:48:07.760 --> 01:48:08.310
IT 31/2-028: Right.

869
01:48:09.030 --> 01:48:17.950
Michiel de Jong: If you're already thinking about the details of how to Bootstrap the Github action. That's a good place. That means you're dedicated to actually including it.

870
01:48:18.726 --> 01:48:21.669
Michiel de Jong: So in the past.

871
01:48:22.090 --> 01:48:26.889
Michiel de Jong: I think, like 4 years ago, I wrote a version of the Ocm test suite

872
01:48:27.020 --> 01:48:49.450
Michiel de Jong: using puppeteer, and that was really scrappy, and it's you know it fell over. It was incomplete. And now I'm really impressed by this cypress based one, and the work that Marty has done on this, and I think it's really ready for for implementations to add the

873
01:48:50.654 --> 01:48:56.950
Michiel de Jong: to their Ci the thing you would have to insert, then is

874
01:48:57.425 --> 01:49:02.649
Michiel de Jong: of course it doesn't help if you run the whole thing

875
01:49:03.240 --> 01:49:08.310
Michiel de Jong: on a pull request, because you want to code from the pull request to be tested.

876
01:49:08.390 --> 01:49:15.769
Michiel de Jong: So you need to somehow look at which images for your own server, and then inject your current branch

877
01:49:15.870 --> 01:49:27.479
Michiel de Jong: in there. Somehow we're maybe a docker volume or mount and then, etcetera. But of course we can. We are more than willing to help with that.

878
01:49:29.440 --> 01:49:39.810
Michiel de Jong: So, yeah, should we create a pull request to next cloud to to add this to the test suites that you have in place.

879
01:49:46.073 --> 01:50:08.160
IT 31/2-028: Because it's gonna be exactly what we just mentioned. Like being able to generate a docket image on the fly from the from the pull request at end, and make sure that this is the one that gets into the to the test.

880
01:50:08.620 --> 01:50:11.374
Micke Nordin | Sunet: Frank. It looks like you were about to answer.

881
01:50:12.380 --> 01:50:19.289
Frank Karlitschek: No, I'm wondering. Maybe Max is not only here. I don't know. Yeah, but obviously it would be nice if we do request.

882
01:50:19.290 --> 01:50:31.149
Maxence: Yeah, I was supposed to say the same, but I was muted so no one here but I we agree with I agree with Frank. And it's logical. It's a good it first, st

883
01:50:31.190 --> 01:50:34.520
Maxence: it's a impressive work, Maddie. Thanks.

884
01:50:34.800 --> 01:50:41.454
Maxence: And yeah, please if you have some some workflow to implement within the github.

885
01:50:42.890 --> 01:50:50.479
Maxence: stuff there, I I guess it will. If it's if it's working fine, it would be merged. That's there is no doubt on it.

886
01:50:53.180 --> 01:51:16.349
Micke Nordin | Sunet: I don't know if you have seen what the web platform tests look like. So they have a really huge test suite, and then they have a lot of browsers who implement the web standards, and you can go and look at what the current status of each web engine is, and I think it would be really nice for us to have a similar web page that

887
01:51:16.380 --> 01:51:25.749
Micke Nordin | Sunet: maybe on each release of an implementation we'll get that and run it and test it and put it on a web

888
01:51:25.920 --> 01:51:27.460
Micke Nordin | Sunet: the page. So

889
01:51:27.900 --> 01:51:42.759
Micke Nordin | Sunet: at sunet we already do a lot of automated testing. Ricket might want to say a few things about that, but I think we could probably like sponsor Ocm. With

890
01:51:42.800 --> 01:51:48.190
Micke Nordin | Sunet: like a Central Yankin server or something like that, and where we could do

891
01:51:48.210 --> 01:51:52.300
Micke Nordin | Sunet: like run these automated tests for each

892
01:51:52.580 --> 01:52:01.340
Micke Nordin | Sunet: like for every supported version of an Ocm implementation, and put it on a web page where you can go and look at the current

893
01:52:01.440 --> 01:52:02.920
Micke Nordin | Sunet: state of everything.

894
01:52:03.779 --> 01:52:25.160
Richard Freitag (Sunet): Was just waiting for for asking questions. I'm really interested in this because we do a lot of regression testing and that like the sandbox testing. So having the sandbox testing from our side implemented, that's definitely something that I would like to do. And the question I would have is we do a lot of regression testing against production and test instances.

895
01:52:25.900 --> 01:52:36.820
Richard Freitag (Sunet): It's probably not a big effort to point the test suite to actual live instances of your own Efss. Right to do some regression testing.

896
01:52:38.808 --> 01:52:49.689
Mahdi Baghbani: No, we're just providing them like the IP, and you know the house name inside the docker network, so we can clearly point it to our side.

897
01:52:51.380 --> 01:53:16.150
Mahdi Baghbani: now, that's a very good idea. Like you can even host the publicly instance just updates with each version, and then we can just test it like you're I'm just speaking, you know, thinking loudly. You can. Host version one of your app in a subdomain, and then version 2 on another subdomain. And then just

898
01:53:16.533 --> 01:53:28.816
Mahdi Baghbani: you know. Whenever you create a new version, you just have to subcommit with the Mini public instance, that is, the and the platform thing that might make us say,

899
01:53:29.260 --> 01:53:36.059
Mahdi Baghbani: can you know, like grab it by some configuration file and run the test against auto

900
01:53:36.090 --> 01:53:45.079
Mahdi Baghbani: instances against other platforms, too, to see if it is you know, indeed compatible, and they can share to each other.

901
01:53:45.210 --> 01:53:51.480
Mahdi Baghbani: So yes, that can be done in July, instances, too, and not just about the ones.

902
01:53:53.340 --> 01:54:03.890
Mahdi Baghbani: and even it could be, you know, somehow implemented into the Github approval request. But your code needs to be deployed

903
01:54:04.304 --> 01:54:10.375
Mahdi Baghbani: on Linkedin, and you can use, you know, github pages, I think I don't know

904
01:54:10.800 --> 01:54:19.150
Mahdi Baghbani: I never hosted the next slide on Github pages, but there might be some kind of platform that gets the hook and builds your app, then deploy it

905
01:54:19.180 --> 01:54:21.002
Mahdi Baghbani: a short time

906
01:54:21.790 --> 01:54:29.790
Mahdi Baghbani: like heroco, or something like that, and then run the test and put the result back. So yeah, it can be done.

907
01:54:31.060 --> 01:54:37.159
Richard Freitag (Sunet): I. I will definitely contact you with a couple of more specific questions about this regarding our instances.

908
01:54:37.760 --> 01:54:49.889
IT 31/2-028: Maybe what they can see as an issue. But this is a matter of agreeing. Those things is to then provide to the testers. Let's say someone test account, because at the point, if this is a live instance, you still need to authenticate.

909
01:54:49.970 --> 01:54:57.100
IT 31/2-028: At the moment everything is done with, it's all self contained. So you have those special uses, time

910
01:54:57.625 --> 01:55:17.219
IT 31/2-028: company that log in and do the event themselves, and whatever. But in this, if this we used to do that also for for other projects, and being able to have a test account. For example, this is totally fine with me, for example.

911
01:55:18.940 --> 01:55:26.040
Richard Freitag (Sunet): What would be quite high on my wish list would also be, of course, compatibility. If if we talk about Eos open Science Cloud.

912
01:55:26.450 --> 01:55:48.500
Richard Freitag (Sunet): That, we can actually prove that our implementations are compatible with other Eos implementations using that test suite doing all the regression testing. Since, I mean, we. We also found dependencies on the underlying storage infrastructure. So every time you do a change, you just run the test suite and just prove your compliance.

913
01:55:49.730 --> 01:55:52.880
Michiel de Jong: Is there something from Eos we can test already.

914
01:55:53.890 --> 01:55:54.890
Richard Freitag (Sunet): Well.

915
01:55:55.748 --> 01:56:14.679
Richard Freitag (Sunet): good, good question. I I tried to log into Eos and we don't have any rights because we're not researchers. I try to convince our Idp people to add, at least my profile as a researcher. So right now, I'm just logging into an empty shell at Eos, and cannot even

916
01:56:14.680 --> 01:56:25.980
Richard Freitag (Sunet): go into their own cloud instance. So there is an old cloud instance, or osis that they have that could technically be tested.

917
01:56:26.465 --> 01:56:30.999
Richard Freitag (Sunet): But you would ask someone to get access to it.

918
01:56:31.310 --> 01:56:36.690
Micke Nordin | Sunet: Yeah, I think we should probably be able to ask Ps and C to give us a test account.

919
01:56:36.890 --> 01:56:37.720
Richard Freitag (Sunet): Yeah.

920
01:56:37.720 --> 01:56:38.280
Micke Nordin | Sunet: Hmm.

921
01:56:39.790 --> 01:56:50.400
Michiel de Jong: Yeah, it would be good to for that. Also that conversation about their you know our know how their money

922
01:56:51.057 --> 01:56:55.520
Michiel de Jong: combine that into prolonged open cloud. Mesh work

923
01:56:56.160 --> 01:57:03.129
Michiel de Jong: so if we just look at what they have testing, and then, you know, ask specific questions.

924
01:57:03.270 --> 01:57:07.510
Michiel de Jong: get a dialogue and get it on their mind that might be useful.

925
01:57:07.770 --> 01:57:32.629
Richard Freitag (Sunet): I I think a good initial candidate for regression testing would be B 2 drop they're based on next cloud, and I know that in Ireland, for instance, they're using B 2 drop as their Efss solution. That would. And then, of course, the new sibo based on next cloud. Then we would have at least 3 endpoints where we could prove ocm compliance.

926
01:57:32.810 --> 01:57:40.260
Richard Freitag (Sunet): and from there we could then go to own cloud osis. All the other instances, eos testing, and so on.

927
01:57:40.880 --> 01:57:44.720
Micke Nordin | Sunet: I think there's a like a a lot of

928
01:57:44.860 --> 01:57:53.809
Micke Nordin | Sunet: overlap between testing requirements. But there are also, like clearly different use cases. One is from

929
01:57:54.150 --> 01:58:01.370
Micke Nordin | Sunet: like, for instance, soon outside, as a user of next cloud, that we, we want to test things.

930
01:58:01.470 --> 01:58:11.090
Micke Nordin | Sunet: The other one is from, like the implementers wanting their implementations to be correct, maybe run a test

931
01:58:11.120 --> 01:58:22.409
Micke Nordin | Sunet: compliance tests on pull requests or or things like that for Ci. And then there's also the need for for us as a spec body to

932
01:58:23.156 --> 01:58:29.860
Micke Nordin | Sunet: have a like tooling to show how the

933
01:58:30.260 --> 01:58:33.610
Micke Nordin | Sunet: spec compliance is at the current stage.

934
01:58:34.050 --> 01:58:41.019
Micke Nordin | Sunet: like, so I think doing all of these things makes sense to me. But I think as

935
01:58:41.030 --> 01:58:44.710
Micke Nordin | Sunet: like the Ocm Spec group, our community group

936
01:58:44.980 --> 01:58:53.070
Micke Nordin | Sunet: should also have some infrastructure of its own, to run, test continuously and.

937
01:58:53.070 --> 01:58:55.220
Michiel de Jong: But we're running it on github actions right?

938
01:58:55.820 --> 01:59:09.200
Micke Nordin | Sunet: I mean, we could. Yeah, or we can have. If we need. I think we soon it could sponsor with the servers or something like that. If if Github actions isn't sufficient.

939
01:59:09.440 --> 01:59:32.870
Richard Freitag (Sunet): You were talking about the Ocm. Stop. So it would be interesting if in the beginning, for manual testing the operator of the next cloud, or any Ocm instance could just send, invites to the Oc. To to a generic Ocm. Stop to get feedback, if if it is compliant, that would be great as well.

940
01:59:34.990 --> 01:59:43.740
Micke Nordin | Sunet: So like host host, a Ocm. Stub server, which can except invitations and then

941
01:59:43.840 --> 01:59:46.910
Micke Nordin | Sunet: use that as a basis for testing.

942
01:59:46.910 --> 01:59:48.250
Richard Freitag (Sunet): Yes, that will be that.

943
01:59:48.250 --> 01:59:49.320
Michiel de Jong: That's a great idea.

944
01:59:49.680 --> 01:59:51.119
IT 31/2-028: That's very good idea.

945
01:59:51.120 --> 01:59:51.950
Michiel de Jong: Yeah, we should support.

946
01:59:51.950 --> 02:00:08.980
IT 31/2-028: So this is precisely what we were missing during the salesforce development, so that we could test against something otherwise you're always with your own. So yes, this- this is a totally work out.

947
02:00:08.980 --> 02:00:16.050
Micke Nordin | Sunet: So what you could do is send an invite to a share and then accept the share.

948
02:00:16.090 --> 02:00:28.779
Micke Nordin | Sunet: The Ocm. Stub would get the Directory and write the compliance file to that directory, and then the one who sent the invitation can see if they're compliant

949
02:00:29.260 --> 02:00:31.999
Micke Nordin | Sunet: or not like in a standardized format.

950
02:00:32.450 --> 02:00:38.500
Micke Nordin | Sunet: So any anyone implementing Ocm can just invite and then get the feedback on.

951
02:00:38.720 --> 02:00:42.340
Micke Nordin | Sunet: If the stub implementation thinks that it's compliant.

952
02:00:44.330 --> 02:00:48.200
Michiel de Jong: Oh, shall I? Slide into my presentation.

953
02:00:48.860 --> 02:00:49.450
Micke Nordin | Sunet: Yes.

954
02:00:51.130 --> 02:00:54.790
Michiel de Jong: Okay, run around, isn't it?

955
02:01:01.280 --> 02:01:03.290
Michiel de Jong: Can you see my screen.

956
02:01:03.900 --> 02:01:04.550
Micke Nordin | Sunet: Yes.

957
02:01:05.050 --> 02:01:29.500
Michiel de Jong: Okay. So the 1st slides are from I think it was in March we were at cf, 3 when we said, Yeah, whereas at Cern there was the Yang funding for open cloud mesh? Then the Science mesh project, which stopped. Then we got the Ngi funding, and then the question mark is where we hope that the Eos project will step in.

958
02:01:29.690 --> 02:01:33.187
Michiel de Jong: And we started, or I started

959
02:01:34.030 --> 02:01:59.600
Michiel de Jong: thinking of how can we review the open Cloud match protocol as an authorization flow. We have the share with flow where you have a you start from a document you have in your Efs, and then you pick a contact to share it with. Then you have the invite flow which was pioneered by science. Mash the public link where you

960
02:01:59.600 --> 02:02:09.319
Michiel de Jong: 1st put something on the public meeting. But then there's also a option to add something to your own Efss and and and like store a bookmark, as it were.

961
02:02:09.440 --> 02:02:11.350
Michiel de Jong: And and then

962
02:02:11.800 --> 02:02:18.999
Michiel de Jong: the comparison with Oauth, which is a, has been a very successful Internet standard for securing Apis

963
02:02:19.418 --> 02:02:25.869
Michiel de Jong: and also work that I've been doing for solid, for instance, which is a similar server to server

964
02:02:26.272 --> 02:02:30.859
Michiel de Jong: you know. Allow this app access to your storage, and then

965
02:02:32.550 --> 02:02:57.779
Michiel de Jong: My thought was, well, could we see open cloud bash as an oauth extension? So with that thought, I, started like reading more about Oauth, and I went to the Oauth Security workshop in Rome, and I talked to also a colleague at surf at length about like how this can work and and could work in a Federation in a federated environment.

966
02:02:57.880 --> 02:02:58.656
Michiel de Jong: And

967
02:03:00.810 --> 02:03:11.886
Michiel de Jong: came up with, I came up so O off is evolving, and it's going into user manage access and also gnap, which is generalized.

968
02:03:12.923 --> 02:03:21.320
Michiel de Jong: negoti negotiation of authorization protocol, I think, which will probably become our 3.0,

969
02:03:21.390 --> 02:03:39.220
Michiel de Jong: and then I got it all very complex in my head. And then Max sounds came along with his request, signing proposal. And then I thought, Yeah, well, actually, if you just use request signing that solves a lot of the problems, and then you only need a small step

970
02:03:39.320 --> 02:03:41.049
Michiel de Jong: on top of that

971
02:03:41.080 --> 02:03:53.479
Michiel de Jong: to get a better security, which I'll come back later. So my idea of how we can make open cloud mesh more. Oh, oh, off like

972
02:03:55.060 --> 02:04:04.639
Michiel de Jong: We had very good weekly discussions which led to an Internet draft which we're very proud of. So we rewrote the spec text.

973
02:04:05.323 --> 02:04:09.226
Michiel de Jong: From just basically a readme file to an actual

974
02:04:09.720 --> 02:04:14.879
Michiel de Jong: document with the concept definitions and then recommendations, etc.

975
02:04:15.070 --> 02:04:28.789
Michiel de Jong: And one of the things I like particularly is that while for the 1.1 version that we published there were some changes like, Oh, yeah, we we need to start doing

976
02:04:29.200 --> 02:04:44.400
Michiel de Jong: things this way, which is now amounts to the same, but it's slightly cleaner, etcetera. And then for the 1.2 version which was tagged this morning. It's actually fully backward, compatible with existing 1.0 implementations

977
02:04:44.950 --> 02:04:54.390
Michiel de Jong: as we use the the the capabilities as optional things, and we always say that you know the legacy behavior and the current

978
02:04:54.837 --> 02:05:02.500
Michiel de Jong: in the wild behavior is always a default that everybody should should support.

979
02:05:02.540 --> 02:05:11.330
Michiel de Jong: So we talked a lot about invites. And how invites help servers to trust each other.

980
02:05:11.420 --> 02:05:23.350
Michiel de Jong: And yeah, we had a good discussion earlier in in this workshop about the difference between a firewall and a spam filter, but especially the double spam filter, I think invites are very important

981
02:05:23.360 --> 02:05:46.779
Michiel de Jong: and and useful. So here's a little bit of a flow diagram. So on the right, Bob tells his enterprise file sync and share servers to add Alice as a contact, and it generates an invite. So Bob shares the invite out of badge to Alice, because this of a token and a fully qualified domain. Name for Bob's Ocm. Server.

982
02:05:47.210 --> 02:05:53.879
Michiel de Jong: Alice tells her if it says to add contact, Bob, and then there's an invite except post

983
02:05:54.318 --> 02:06:17.449
Michiel de Jong: and so now these 2 servers know that these 2 people know each other, and then after that Alice could share something with Bob or Bob should share something. With Alice. The next step after an invite has been so the invite preamble is optional, but we think it's useful

984
02:06:17.550 --> 02:06:24.733
Michiel de Jong: after that. There has to be capabilities. Discovery caps discount and

985
02:06:26.640 --> 02:06:51.619
Michiel de Jong: that looks like a right now it's ocm hyphen provider. And then this new spec, we say, well, yeah, not well known as Ocm. Is preferred, but we will still always, for the 10 years to come. Probably also always look at Ocm. Provider just for backwards compatibility, and from there you get endpoints. You get capabilities, and you get a public key

986
02:06:51.730 --> 02:06:53.600
Michiel de Jong: for request. Signing.

987
02:06:54.480 --> 02:07:07.420
Michiel de Jong: Then the next step in the flow is to actually share something. And we call that we used to call it a share creation, although that's a little bit confusing, because you're not

988
02:07:07.530 --> 02:07:12.760
Michiel de Jong: creating a remote share is more like you said you're notifying the remote server that

989
02:07:12.820 --> 02:07:18.159
Michiel de Jong: a share was created on the sending server. So we call it a share creation, notification.

990
02:07:19.265 --> 02:07:24.290
Michiel de Jong: Which is a long name, but slightly more correct. So Alice, share something with Bob.

991
02:07:24.990 --> 02:07:32.316
Michiel de Jong: First.st The discovery happens to find out endpoints, capabilities, and public key.

992
02:07:33.160 --> 02:07:47.439
Michiel de Jong: and then, as possibly signed, request is made, server to server. The receiving server might check the invite like is this from a a invited to contact.

993
02:07:47.530 --> 02:07:48.830
Michiel de Jong: and

994
02:07:48.850 --> 02:07:57.160
Michiel de Jong: if it was signed, then it will look up the public key from the sending server and check the Acp signature, and then the share is created.

995
02:07:59.440 --> 02:08:07.689
Michiel de Jong: And then one of the we did a unconference session

996
02:08:07.750 --> 02:08:12.600
Michiel de Jong: about open cloud mesh at the Oauth Security workshop.

997
02:08:13.049 --> 02:08:22.289
Michiel de Jong: There was like colleagues from the surface there, Peter, but also Justin. Richard was there, who's been a core of

998
02:08:22.820 --> 02:08:29.439
Michiel de Jong: contributor for a long time. Arab Parecky was there who invented Pix. He's also a core Oauth

999
02:08:29.950 --> 02:08:45.169
Michiel de Jong: people from financial grade services, like the group, like people who know their shit. They they were all in this unconference session. And I was presenting like, Yeah, and then we send the share secret which we never rotate.

1000
02:08:45.190 --> 02:08:48.079
Michiel de Jong: and that we use on every Api call.

1001
02:08:48.100 --> 02:08:51.980
Michiel de Jong: And they were like, Yeah, okay, so you're right.

1002
02:08:52.130 --> 02:08:59.120
Michiel de Jong: You're using Tls, so nothing could go wrong. But if you look at the last 10 years of best practices.

1003
02:08:59.230 --> 02:09:03.589
Michiel de Jong: a bank would never do this like no way. Don't even think about it.

1004
02:09:03.610 --> 02:09:24.360
Michiel de Jong: A bank would never use Ocm, the way it looks now. And a I don't know like slightly less. well, apparently, Enron do use Ocm. But if you look at other services that we deploy that have, for instance, client bound tokens

1005
02:09:26.030 --> 02:09:31.206
Michiel de Jong: and that have short lived tokens. They are

1006
02:09:32.100 --> 02:09:36.610
Michiel de Jong: like Ocm is secure. But you could have more layers of security.

1007
02:09:37.225 --> 02:09:41.910
Michiel de Jong: And so what I came up with was the code flow

1008
02:09:42.140 --> 02:09:47.589
Michiel de Jong: which builds a lot on Max census work of adding signatures. So

1009
02:09:47.860 --> 02:10:00.979
Michiel de Jong: instead of adding a shared secret in a share, you add a code which is exactly the same sort of code as with a Oauth authorization codes grant. Then the receiving server.

1010
02:10:00.980 --> 02:10:17.880
Michiel de Jong: does a backend call a back channel call which is signed, which requests a token, saying, Hey, I have this brand code. Can I exchange my code for tokens and a refresh token? And then the sending server gives a short lived bearer token.

1011
02:10:18.340 --> 02:10:21.939
Michiel de Jong: and then it the receiving server. Does the actual

1012
02:10:21.950 --> 02:10:30.950
Michiel de Jong: prop find, or whatever it does to access the share? So this is what that would look like.

1013
02:10:31.502 --> 02:10:33.100
Michiel de Jong: As a whole.

1014
02:10:35.190 --> 02:10:36.290
Michiel de Jong: And

1015
02:10:38.150 --> 02:10:53.479
Michiel de Jong: yeah, I could go through it again. But you know, from the top to bottom it's 1st the invite gets accepted. Then there's a discovery and there's a share posted. Check the invite check. The signature. Then there is a

1016
02:10:53.790 --> 02:10:57.749
Michiel de Jong: the code that was posted gets exchanged for a token.

1017
02:10:57.770 --> 02:11:12.419
Michiel de Jong: And then the token gets used to actually access the web data. And you could ask, like, Okay, yeah, do we need that? Well, you know, in theory, apparently, you know, we've been using with success

1018
02:11:12.420 --> 02:11:27.989
Michiel de Jong: for a long time, but I think if we want to move forward and get better. Then it would help to have more layers of security and to have short lived bearer token. So if somebody would were to intercept a web dev request

1019
02:11:28.342 --> 02:11:34.700
Michiel de Jong: they would only get access to the share for 20 min, and after that, because they don't have the refresh token.

1020
02:11:34.720 --> 02:11:36.853
Michiel de Jong: they wouldn't be able to

1021
02:11:39.021 --> 02:11:46.999
Michiel de Jong: to access it further also, the even if somebody would get the code, because

1022
02:11:47.210 --> 02:12:09.180
Michiel de Jong: exchanging the code for a bear token is a signed request. The code by itself is useless, like it's useless. Unless you can prove that you are the intended recipient of that code, then you can exchange it to the to the bear token. So the bearer token is stored list, but not client, bound like. If you have it, you can actually do Api requests

1023
02:12:09.180 --> 02:12:17.459
Michiel de Jong: until it expires, but refreshing. It is client bound, like you need to have received the share. You also need to

1024
02:12:17.710 --> 02:12:22.060
Michiel de Jong: sign your request and prove that you have the private keys.

1025
02:12:22.458 --> 02:12:43.419
Michiel de Jong: And then, you know, you would also revoke shares, as you would normally but this is just an extra layer of security where, because of the mostly because of the request signing of the back end server to server calls you make it harder like, even if you would.

1026
02:12:43.530 --> 02:12:54.180
Michiel de Jong: If a call would get intercepted, it would be harder for somebody to to break into an Ocm. Share. So to recap

1027
02:12:54.715 --> 02:13:04.839
Michiel de Jong: things. To add to an existing Ocm implementation would be, yeah. The Ocm Provider endpoint. Just copy it to double down slash. Ocm.

1028
02:13:06.110 --> 02:13:07.210
Michiel de Jong: then

1029
02:13:07.790 --> 02:13:28.950
Michiel de Jong: the protocol object in a when you create a share right now it has name, web app and then options. It has the web options. So, to make it more expandable, we, we change that to a keyed object where there's no name entry, and instead of options you call that entry web app. So

1030
02:13:29.070 --> 02:13:40.120
Michiel de Jong: web dev means the web dev options. But then, in the same call, you could have web dev plus data. Tx, right? So I have a file here. You can access this through web dev or through our sync

1031
02:13:40.550 --> 02:13:54.619
Michiel de Jong: as you choose. So you could have multiple protocols for one share, or you could, of course, have other things like a chat or a video call, etc. That would also then go to this

1032
02:13:55.452 --> 02:14:07.729
Michiel de Jong: keyed object, and web apps as pioneered. Where you say I share something with you. Here is a URL. You visit that in your browser. Then you'll be able to access it

1033
02:14:07.900 --> 02:14:21.339
Michiel de Jong: then invites very important for spam filtering, so that if a Ocm share comes from a somebody who was an invite, then you can all be almost certain that it's not spam

1034
02:14:21.610 --> 02:14:23.600
Michiel de Jong: because you added this person yourself.

1035
02:14:24.473 --> 02:14:27.926
Michiel de Jong: And I think

1036
02:14:29.240 --> 02:14:37.329
Michiel de Jong: actually, I don't know if cernbox supports group shares. I think this is what they message to Cernbox and also saying, Implement group shares and then.

1037
02:14:37.330 --> 02:14:37.769
IT 31/2-028: Talk to you.

1038
02:14:37.770 --> 02:14:45.429
Michiel de Jong: Federation. Yeah. Well, first, st you need groups before you can accept group shares. But you know, it's something that.

1039
02:14:45.430 --> 02:14:51.910
IT 31/2-028: Groups. Yes, but the local groups only. So this is actually interesting. Concept is that.

1040
02:14:52.510 --> 02:14:55.900
Michiel de Jong: And then Federation shares. Yeah, we are. We have.

1041
02:14:56.530 --> 02:15:08.689
Michiel de Jong: We had 2 ways of doing it. So yeah, the circles way is a 3rd way that's even more advanced. So we'll that's that's really, you know, in under construction and in progress.

1042
02:15:09.119 --> 02:15:23.300
Michiel de Jong: And then there's enforce Mfa. Which soon it has been pioneering. Where you ask, the remote server say, Okay, yeah. You could show this to your user. Please do make sure that their Mfa logged in before you show it to them.

1043
02:15:24.004 --> 02:15:41.410
Michiel de Jong: Htbc. Max, signing which we're message signing, which we're very happy about those added this year. And then, yeah, the code flow which I described, which I think is the way to go. If you know, if we want banks to use. Ocm.

1044
02:15:42.337 --> 02:15:49.239
Michiel de Jong: Then we need the code flow? Yeah, so we can, we could postpone a little bit. But if we want to become more serious

1045
02:15:49.716 --> 02:15:55.260
Michiel de Jong: to the point where banks and hospitals which use it. Then that is something I think. Really.

1046
02:15:55.924 --> 02:15:58.830
Michiel de Jong: That's the end of my presentation.

1047
02:15:59.340 --> 02:16:00.160
Michiel de Jong: Thank you.

1048
02:16:01.310 --> 02:16:09.208
Micke Nordin | Sunet: Thanks, Mehil if you if you want to show your slide your last slide again.

1049
02:16:09.810 --> 02:16:10.939
Micke Nordin | Sunet: I wanted to mention.

1050
02:16:10.940 --> 02:16:11.590
Michiel de Jong: S.

1051
02:16:13.730 --> 02:16:14.816
Micke Nordin | Sunet: I have

1052
02:16:16.050 --> 02:16:24.079
Micke Nordin | Sunet: So for next cloud, since we were talking about the implementers and implementations.

1053
02:16:24.802 --> 02:16:28.527
Micke Nordin | Sunet: What is in going on in the

1054
02:16:29.770 --> 02:16:36.490
Micke Nordin | Sunet: pull request work in progress. Pull request is, I think, the 1st 3 points there.

1055
02:16:37.090 --> 02:16:41.179
Michiel de Jong: Max sans has a Pr. For the Http.

1056
02:16:41.230 --> 02:16:52.199
Micke Nordin | Sunet: Sig and enforce Mfa. We are working on implementing in in the Mfa. Zones, app.

1057
02:16:53.709 --> 02:16:56.376
Micke Nordin | Sunet: But for the code flow.

1058
02:16:56.969 --> 02:17:06.650
Micke Nordin | Sunet: Something interesting is that I have written a generic next cloud app for openid connect.

1059
02:17:07.370 --> 02:17:09.840
Micke Nordin | Sunet: So you can.

1060
02:17:10.200 --> 02:17:13.040
Micke Nordin | Sunet: I will post a link to it.

1061
02:17:13.070 --> 02:17:18.430
Micke Nordin | Sunet: You can add any openid, connect provider

1062
02:17:18.709 --> 02:17:29.369
Micke Nordin | Sunet: so the Admin can go in and add, like an integration where they need some things like a client, id and and things like that which is part of openid connect.

1063
02:17:29.520 --> 02:17:31.660
Micke Nordin | Sunet: and all of the endpoints.

1064
02:17:31.889 --> 02:17:40.969
Micke Nordin | Sunet: And then for the user, the user can go into the user settings and click connect to this provider.

1065
02:17:41.160 --> 02:17:58.930
Micke Nordin | Sunet: And what happens then is that the user is taken to the provider and can click there and say, Yeah, okay, I will. Accept. I I will log in here with this provider, give their password and all of the things that they need, and then they will get the

1066
02:17:59.040 --> 02:18:23.209
Micke Nordin | Sunet: token and the refresh token access, token and refresh token. And what this app does is, it takes the refresh token and the access token, and then it uses the refresh token to refresh the access token when it is provided, so any other kind of next cloud app could use this integration

1067
02:18:23.270 --> 02:18:27.220
Micke Nordin | Sunet: to use the and act on behalf of the user.

1068
02:18:28.860 --> 02:18:39.230
Micke Nordin | Sunet: So I think a lot of this code could be used for the code flow in next cloud. So all of the parts where where you get the

1069
02:18:39.350 --> 02:18:42.030
Micke Nordin | Sunet: refresh token and need to

1070
02:18:42.500 --> 02:19:02.319
Micke Nordin | Sunet: get it back essentially, or refresh the access token. It's already implemented, and it's done with the scheduled jobs that looks at the expiry time and just does it. So I think for next cloud. A lot of those points that you

1071
02:19:02.330 --> 02:19:07.639
Micke Nordin | Sunet: have there is actually ongoing pretty much

1072
02:19:08.135 --> 02:19:10.900
Micke Nordin | Sunet: could be or or could be adopted.

1073
02:19:11.480 --> 02:19:19.950
Michiel de Jong: That's definitely useful, the refreshing logic. But I think it's about 20% of the work is about refreshing the tokens

1074
02:19:20.509 --> 02:19:25.459
Michiel de Jong: cause. That's just a client accessing the window, Api

1075
02:19:25.549 --> 02:19:31.670
Michiel de Jong: and saying, Okay, I have this. I have a code. Now I have a token, and I have a refresh token

1076
02:19:31.700 --> 02:19:37.007
Michiel de Jong: I'm gonna refresh, and I have a new one. And then

1077
02:19:37.940 --> 02:19:44.500
Michiel de Jong: This signing the request to exchange a code or a token is another part.

1078
02:19:46.000 --> 02:19:50.390
Michiel de Jong: I think a trivial way to implement it

1079
02:19:50.540 --> 02:19:54.570
Michiel de Jong: would be that when you create a share, you

1080
02:19:54.620 --> 02:20:01.360
Michiel de Jong: store the shared secret in the remote shares table and

1081
02:20:02.590 --> 02:20:10.450
Michiel de Jong: Then maybe you would. I you would also add a code or derive that

1082
02:20:11.220 --> 02:20:16.747
Michiel de Jong: and then not send the shared secret to the other party.

1083
02:20:17.320 --> 02:20:30.819
Michiel de Jong: And then you, as a sending server, you would need to implement this code endpoint. Where, when somebody tries to exchange a code, you look up the share that this code before. And you say, Okay, yeah, this checks out. The signature is correct. I'm going to give them the shared secret back.

1084
02:20:33.090 --> 02:20:38.250
Michiel de Jong: And so you could do it

1085
02:20:38.460 --> 02:20:42.009
Michiel de Jong: if you do the code float minus the refreshing

1086
02:20:44.090 --> 02:20:46.309
Michiel de Jong: that would be an intermediate step.

1087
02:20:48.150 --> 02:20:58.520
Michiel de Jong: And then, if we get that working so that we're no longer sending the shared secrets on every web request. But there's a it's decouples.

1088
02:20:58.900 --> 02:20:59.860
Michiel de Jong: Then.

1089
02:21:01.330 --> 02:21:04.559
Michiel de Jong: We can add the refreshing on top of that

1090
02:21:05.860 --> 02:21:15.310
Micke Nordin | Sunet: Shouldn't it just be a matter of using the access token as the bearer token? So if you have bear token authentication

1091
02:21:15.958 --> 02:21:21.120
Micke Nordin | Sunet: every time the share needs to be accessed. You just use the access token.

1092
02:21:21.120 --> 02:21:26.899
Michiel de Jong: Access token as the bear token. Yes, that's what you do. But the question is, where do you get the bear where you get this access token from

1093
02:21:27.170 --> 02:21:30.700
Michiel de Jong: so right now you get it right in the share as a shared secret.

1094
02:21:31.660 --> 02:21:34.219
Michiel de Jong: But there, we need to insert an extra step.

1095
02:21:34.860 --> 02:21:38.580
Micke Nordin | Sunet: Yeah, exactly. So using the code flow.

1096
02:21:39.020 --> 02:21:48.959
Micke Nordin | Sunet: Yeah, so. But I think once we have the bearer token part, then it will be

1097
02:21:49.160 --> 02:21:56.850
Micke Nordin | Sunet: quite easy to add the refreshing and using the access token for the bearer as the bearer token.

1098
02:21:57.220 --> 02:21:57.870
Micke Nordin | Sunet: Oh.

1099
02:21:57.870 --> 02:22:08.460
IT 31/2-028: And for the signatures. This is already ready, like you can sign anything. So in particular, the request to to get the fresh token out of the code

1100
02:22:08.510 --> 02:22:25.319
IT 31/2-028: is to be signed, and this can be done. So yeah, it looks like you. You will be the first, st I mean. I hope you'll be the 1st to have all of this in place, and I'm also taking note for myself in terms of things to add, in terms of implementation

1101
02:22:25.730 --> 02:22:30.621
IT 31/2-028: the trickiest call to be written, but everything you can be done, of course, but

1102
02:22:30.930 --> 02:22:37.627
IT 31/2-028: we would have to do all of that also. If you want to support this code flow. And

1103
02:22:38.490 --> 02:22:48.150
IT 31/2-028: yeah, there is this kind of intended state that you do it without refreshing. But I can really see the advantage there is to really go for the full package

1104
02:22:48.260 --> 02:23:06.260
IT 31/2-028: like this code should really be that you use it only within a site request otherwise. And the security really comes from the fact that the code must come from the code. Exchange gets only to side requests.

1105
02:23:06.350 --> 02:23:09.790
IT 31/2-028: and the birth token in the profile is shortly

1106
02:23:10.090 --> 02:23:16.900
IT 31/2-028: the combination of those 2 makes such that whatever unique they don't lose much.

1107
02:23:17.680 --> 02:23:21.700
IT 31/2-028: So yeah, I take note of that for for myself.

1108
02:23:22.720 --> 02:23:30.099
Michiel de Jong: Yeah, so I already implemented the code flow in. Ocm stub, so I invite everybody to

1109
02:23:30.750 --> 02:23:33.819
Michiel de Jong: implement the code flow on their Fss.

1110
02:23:33.890 --> 02:23:35.970
Michiel de Jong: and then we can test the guns for each other.

1111
02:23:39.370 --> 02:23:40.160
Micke Nordin | Sunet: Cool.

1112
02:23:40.160 --> 02:23:41.751
IT 31/2-028: That's that's interesting. Yes.

1113
02:23:45.260 --> 02:23:46.010
IT 31/2-028: oops.

1114
02:23:49.930 --> 02:23:57.750
Micke Nordin | Sunet: Is there anything else we want to discuss about the like? The we have a

1115
02:23:57.970 --> 02:24:01.680
Micke Nordin | Sunet: talked a bit about Ocm. 1 point

1116
02:24:01.790 --> 02:24:06.010
Micke Nordin | Sunet: 2, and the new features that we have added the test, suite

1117
02:24:06.240 --> 02:24:18.250
Micke Nordin | Sunet: testing of compliance between different Ocm providers and things like that is that something else that we

1118
02:24:18.390 --> 02:24:21.019
Micke Nordin | Sunet: want to discuss or add to this

1119
02:24:21.350 --> 02:24:23.939
Micke Nordin | Sunet: or any questions, anything at all, that we

1120
02:24:23.970 --> 02:24:26.760
Micke Nordin | Sunet: should race. Now, when we're all together.

1121
02:24:29.293 --> 02:24:44.899
IT 31/2-028: As part of this work on the specifications. But there was also this idea of adding requirements which we were all discussing, all that, but I would consider that also another interesting addition. This would also

1122
02:24:44.990 --> 02:24:46.440
IT 31/2-028: go towards

1123
02:24:46.590 --> 02:24:54.199
IT 31/2-028: Frank's observation about how we're making things more complicated. But then, so far, we did things different in a different way, etc.

1124
02:24:54.930 --> 02:25:14.710
IT 31/2-028: So eventually the idea would be, and especially for maximum. Think about your idea of putting the signatures. So, of course, everything is optional, because you have to be backward, compatible, and at some point you may do in such a way that whatever you share you require. Again, optional capability, for example, the signature

1125
02:25:15.390 --> 02:25:22.625
IT 31/2-028: and the code flow to actually be used, meaning that the other parties, the other part, is not able to actually do that

1126
02:25:23.090 --> 02:25:25.869
IT 31/2-028: the share won't take place. It's refused.

1127
02:25:26.310 --> 02:25:47.749
IT 31/2-028: So that would be the extra way to actually ensure the transition, so that you could have a mixed system with- with the instances that are that are new and others that are older. So they don't have this feature in. So if you, if you have a user that can set this requirement, then those users will not be able to share to.

1128
02:25:47.750 --> 02:25:52.830
Maxence: Oh, sorry am I muted yet again.

1129
02:25:53.100 --> 02:25:53.680
IT 31/2-028: Yeah, yeah.

1130
02:25:53.680 --> 02:26:05.322
Maxence: Okay? Great. Yeah, it's there is a coffee. I think I understand your request at 95%. But just to confirm it is doable

1131
02:26:05.860 --> 02:26:21.500
Maxence: already. To enforce the signature of request you can. You can add a config to config flag to your instance, to say, I only accept shares that are signed.

1132
02:26:22.690 --> 02:26:44.559
IT 31/2-028: Okay. But what I mean is, this has to be as advertised as part of the payload through here. So if you configure that, I would ask you to also put. So you can look for these requirements in in the in the specifications document, and you see that you would have to add an extra payload in the share itself.

1133
02:26:44.710 --> 02:26:51.099
IT 31/2-028: because the idea is that then I receive a share with display mode that tells me, okay, I can actually share. Only if

1134
02:26:51.918 --> 02:26:53.229
IT 31/2-028: do the site request.

1135
02:26:53.450 --> 02:27:09.979
IT 31/2-028: And in that case I would like personally say, No, I cannot. This is part of the protocol. It's not just a matter of when you compute it yourself there and then the other remote end. It doesn't know anything, and then they try to have to access, and it's gonna be a failure.

1136
02:27:13.730 --> 02:27:28.360
IT 31/2-028: You can even put it 1 1 step forward, that is, imagine that we have your server. So let's put the usual Alice and Bob. So Alice wishes to share something to Bob, but the Alice server requires signatures.

1137
02:27:28.760 --> 02:27:32.239
IT 31/2-028: or one of those features, let's say signatures.

1138
02:27:32.510 --> 02:27:37.019
IT 31/2-028: Now, when I disclose. So when the answer goes to Bob.

1139
02:27:37.180 --> 02:27:43.449
IT 31/2-028: he can look at the bundle, capabilities, the caps discount that we mentioned.

1140
02:27:43.490 --> 02:27:49.019
IT 31/2-028: If in the bump capabilities there is no signature, no support for signatures

1141
02:27:49.360 --> 02:27:54.690
IT 31/2-028: already. The said they should show twice that they cannot share to pop.

1142
02:27:55.099 --> 02:28:09.139
IT 31/2-028: because the requirement is not fulfilled. You see what I mean you don't let it go, and then it fails afterwards, and then the users are completely lost. You- you stop it before before this goes out.

1143
02:28:10.040 --> 02:28:16.549
Maxence: Okay, it's yeah. It's a, it's a use case. I haven't thought about. Yeah to.

1144
02:28:16.580 --> 02:28:22.069
Maxence: yeah. I thought the other way around that you only accept sign and thing. But yeah, when you you might.

1145
02:28:22.070 --> 02:28:22.470
IT 31/2-028: Of course.

1146
02:28:22.470 --> 02:28:25.759
Maxence: One that you only sent

1147
02:28:26.220 --> 02:28:35.250
Maxence: you share, or any request or Cm request to to an instant that that provide a public key. Yeah, okay, we. It's something that can be done. Yes.

1148
02:28:35.380 --> 02:28:35.940
IT 31/2-028: You know.

1149
02:28:35.940 --> 02:28:46.200
Micke Nordin | Sunet: And also I mean to be a good Ocm. Citizen. It's very good to announce to to other servers that you will only accept signed

1150
02:28:46.470 --> 02:28:50.429
Micke Nordin | Sunet: requests not just reject them.

1151
02:28:51.110 --> 02:28:56.250
Maxence: We can add an unforeseen value in the in the discovery. It would be.

1152
02:28:56.600 --> 02:29:13.239
IT 31/2-028: You will see that it's already forese. So look at the specifications. You see that the discovery has been growing in that sense. There are now criteria. So then, that would be the accepted. So a server can expose the fact that a criteria for for accepting changes, that they are signing, for example.

1153
02:29:13.590 --> 02:29:13.920
Micke Nordin | Sunet: Okay.

1154
02:29:13.920 --> 02:29:22.692
IT 31/2-028: Or whatever go through the discovery part, which is quite, quite expanded, because there are all of those capabilities and requirements

1155
02:29:23.240 --> 02:29:24.800
IT 31/2-028: spelled out.

1156
02:29:29.620 --> 02:29:31.100
Michiel de Jong: So in the.

1157
02:29:31.740 --> 02:29:41.390
Michiel de Jong: in the discovery, we have capabilities, resource types, and protocols. So the capabilities are things that server says it can do

1158
02:29:42.116 --> 02:29:48.283
Michiel de Jong: resource types are file and folder, and maybe chat and

1159
02:29:49.100 --> 02:29:53.890
Michiel de Jong: a video call and other source of resources that

1160
02:29:54.340 --> 02:30:04.319
Michiel de Jong: related to protocols the server announces. So it's the per resource type, it says, which protocol it supports. So

1161
02:30:04.380 --> 02:30:14.840
Michiel de Jong: protocol could be web, dev or web, app or data transfer or sip, or whatever. And there's obviously a connection between the resource type and the protocol.

1162
02:30:15.293 --> 02:30:20.100
Michiel de Jong: Like web Dev makes the protocol web dev makes sense for the resource type

1163
02:30:20.210 --> 02:30:32.479
Michiel de Jong: file. And then, when you actually send the share there are the share has a resource type. The share has one or more protocols through which you can access it, for instance, web app

1164
02:30:33.145 --> 02:30:38.800
Michiel de Jong: and then the share also announces permissions and requirements.

1165
02:30:39.510 --> 02:30:41.780
Michiel de Jong: I'd actually yeah permissions.

1166
02:30:41.820 --> 02:30:56.970
Michiel de Jong: You could always announce some permission and then still block the request when it happens so it's more prediction of when you try to make a right request. I'll probably allow it.

1167
02:30:57.160 --> 02:31:02.469
Michiel de Jong: But the final decision is obviously when the request happens, and then but requirements

1168
02:31:02.994 --> 02:31:10.790
Michiel de Jong: you can only send a requirement if you know that the other server understands this requirement. Otherwise you get a big mess.

1169
02:31:10.850 --> 02:31:18.120
Michiel de Jong: So if the receiving server has the and force Mfa capability, then you can set the.

1170
02:31:18.580 --> 02:31:22.229
Michiel de Jong: And is it also called enforced Mfa. The the.

1171
02:31:22.230 --> 02:31:25.259
Micke Nordin | Sunet: Yeah, I think so. We we harmonized it. I think.

1172
02:31:25.260 --> 02:31:30.309
Michiel de Jong: It's the same name. Yeah, requirement on a share, and then trust that it will be.

1173
02:31:30.410 --> 02:31:37.099
Michiel de Jong: And 1st so probably, if you see a requirement that you don't understand.

1174
02:31:37.170 --> 02:31:43.933
Michiel de Jong: You should reject the share, do you say would say you're requiring something I don't understand so but

1175
02:31:47.180 --> 02:31:54.529
IT 31/2-028: So as a good designer, yeah, you should reject what you don't understand. So if you're not able to fulfill the requirements.

1176
02:31:54.640 --> 02:31:56.559
IT 31/2-028: Indeed, that's the.

1177
02:31:58.160 --> 02:32:04.699
Michiel de Jong: Yeah. So permissions you don't understand are fine. Oh, well, I can do something I don't know

1178
02:32:04.870 --> 02:32:09.259
Michiel de Jong: doesn't doesn't matter. But a requirement you don't understand is a reason to.

1179
02:32:15.680 --> 02:32:21.389
Micke Nordin | Sunet: But yeah, you shouldn't get them in the 1st place, because the sending so.

1180
02:32:21.390 --> 02:32:21.960
Michiel de Jong: Membership.

1181
02:32:21.960 --> 02:32:23.639
Micke Nordin | Sunet: At your capabilities and under.

1182
02:32:26.590 --> 02:32:29.620
Michiel de Jong: So that's an extra reason. Say, if you do get them, then just.

1183
02:32:29.620 --> 02:32:29.950
Micke Nordin | Sunet: Yeah, yeah.

1184
02:32:29.950 --> 02:32:31.179
Michiel de Jong: Definitely, something to win.

1185
02:32:31.360 --> 02:32:31.960
Micke Nordin | Sunet: Hmm.

1186
02:32:38.140 --> 02:32:39.469
Michiel de Jong: Any other topics?

1187
02:32:40.580 --> 02:32:41.160
Michiel de Jong: Oh, yeah.

1188
02:32:41.746 --> 02:32:51.450
IT 31/2-028: Was just sharing the agenda just to showed the wrong, the wrong.

1189
02:32:51.450 --> 02:32:52.750
Michiel de Jong: This is the wrong one.

1190
02:32:53.618 --> 02:32:56.070
IT 31/2-028: Because there is another opportunity that

1191
02:32:56.150 --> 02:32:59.409
IT 31/2-028: I have to look after the 2,

1192
02:32:59.990 --> 02:33:10.319
IT 31/2-028: and they all look, of course, very similar, because if we the zoom, because our our confidence management system.

1193
02:33:11.280 --> 02:33:21.500
IT 31/2-028: Well, I said this also to as a reminder for especially for Nikhil, and to upload your slides so that we keep track of what was

1194
02:33:21.590 --> 02:33:23.290
IT 31/2-028: what was shown.

1195
02:33:23.310 --> 02:33:38.659
IT 31/2-028: Also I took myself some notes. I see he took some notes, live on the on the chat which is so good I will take everything that Zoom gives me. That is the the meeting chat of Zoom itself.

1196
02:33:38.840 --> 02:33:41.890
IT 31/2-028: Possibly even the transcripts of the of the recording.

1197
02:33:42.190 --> 02:33:50.379
IT 31/2-028: So I try and make a some summary of all of this, but at least for what I can see and what they see on you may not.

1198
02:33:50.830 --> 02:33:57.189
IT 31/2-028: I think we got many nice ideas and the things to do to do. Going forward.

1199
02:33:57.540 --> 02:34:05.219
IT 31/2-028: I hope to see good work also into the implementations, and the further Max and Frank are here

1200
02:34:05.670 --> 02:34:11.129
IT 31/2-028: is promising for this point of view, and well, I hope that this applies also to

1201
02:34:11.920 --> 02:34:14.909
IT 31/2-028: you. Know, to the other, to the other vendors.

1202
02:34:15.090 --> 02:34:24.990
IT 31/2-028: So when I wouldn't add much else, thanks to everyone for for attending, and for this

1203
02:34:25.180 --> 02:34:35.610
IT 31/2-028: again for me, very fruitful exchange, technical exchange. Exactly what I was thinking when we had this idea of of bringing together the people

1204
02:34:35.680 --> 02:34:45.379
IT 31/2-028: about time where, so that we could discuss, not on the short time that we take every week or so on the on the Progress. This was a nice time to

1205
02:34:45.640 --> 02:34:47.940
IT 31/2-028: check a little bit all that has happened.

1206
02:34:48.470 --> 02:35:00.670
IT 31/2-028: People interested. We are meeting, anyway, every Thursday for about 30 min to the maximum 1 h. So this is to check the progress of all of those activities.

1207
02:35:00.920 --> 02:35:08.680
IT 31/2-028: And well, that's all from me. I hope to see many of you in Munich next year.

1208
02:35:10.340 --> 02:35:11.840
IT 31/2-028: And again, thanks.

1209
02:35:14.230 --> 02:35:17.739
Micke Nordin | Sunet: Yeah, thank you. Was very interesting.

1210
02:35:20.380 --> 02:35:23.470
IT 31/2-028: So we'll stop the recording. Now let's see.

1211
02:35:24.990 --> 02:35:26.720
Micke Nordin | Sunet: And yeah.