WEBVTT 00:00.000 --> 00:17.280 Okay, my name is Oliz Johansson and I have to actually admit that I want to see coders. 00:17.280 --> 00:24.280 I've been coding C for 25 years, project like Asteriske and Al Camerillo, Camerillo 00:24.280 --> 00:26.880 is 25 years old. 00:26.880 --> 00:34.440 We've been having a make-fall system for a very long time and recently we tried to convert 00:34.440 --> 00:36.080 that into C-make. 00:36.080 --> 00:40.440 I wasn't part of that story, but during that transition we realized that no one understood 00:40.440 --> 00:43.400 the make-fall system either. 00:43.400 --> 00:51.360 It has lived its own life, but I quite often use Camerillo as an example of stuff that's 00:51.360 --> 00:57.640 really, really hard to automate making C-bombs of or S-bombs of. 00:57.640 --> 00:59.480 But I'm not here to talk about Camerillo. 00:59.480 --> 01:06.640 I can do that if anyone asks, how many here are active in S-PDX? 01:06.640 --> 01:10.840 Great, O wasp cycle in the X. 01:10.840 --> 01:14.400 Wow, or CVG. 01:14.400 --> 01:21.680 Let's see, that didn't raise hands, you belong to me. 01:21.680 --> 01:25.360 I need you, right? 01:25.360 --> 01:30.280 So I'm going to talk a little bit, I have too many slides, so don't worry about that. 01:30.280 --> 01:32.720 I'm going to skip a few because you already know. 01:32.720 --> 01:38.640 We had so many good speakers here, but we have a problem. 01:38.640 --> 01:46.120 That is, I was in a seminar a few years ago in Sweden, and in the old TV industry, and 01:46.120 --> 01:50.760 they described how they work with their supply chain and S-bombs, and I tried to figure 01:50.760 --> 01:54.960 out how did they get S-bombs. 01:54.960 --> 02:01.480 When I asked three times to say, well, we look into this portal, right-hand click, download, 02:01.480 --> 02:06.360 save, and then we go to our system, click, click, click upload. 02:06.360 --> 02:16.160 From all vendors, now we're getting an email, and we're getting, we can't have it that way. 02:16.160 --> 02:23.360 We need automation, especially with stuff like vex files, that for complex systems, we'll 02:23.360 --> 02:28.040 have to change almost every day. 02:28.040 --> 02:31.560 So I started looking if anyone was targeting this problem. 02:32.440 --> 02:38.440 I've been acting in IITF, I've been writing protocols, I worked with real-time communication. 02:38.440 --> 02:45.160 I know how to send data 50 packets a second, right? 02:45.160 --> 02:50.600 Super real-time communication, we send a lot of packets in real-time. 02:50.600 --> 02:55.400 And I didn't find anyone, and I spoke with Cyclone DX, and they said, well, look at the 02:55.480 --> 03:03.320 bomb exchange API, a very old and sleeping project, but they had a very cool logotype. 03:03.320 --> 03:07.120 The koala is nice. 03:07.120 --> 03:11.760 Supported koala got new life. 03:11.760 --> 03:13.160 Why a koala? 03:13.160 --> 03:17.840 Well, when they started this, they discussed, oh, we need a nice animal, very much like 03:17.840 --> 03:20.160 the Riley books. 03:20.160 --> 03:25.200 So that's why we are creating the transparency exchange API, 03:25.200 --> 03:29.680 which is called T, I never drink coffee, so I loved it. 03:29.680 --> 03:35.840 So that's koala drinking T, you always remember that. 03:35.840 --> 03:45.200 So the problem here is, as you understand, you're well aware that a customer has many vendors, 03:45.200 --> 03:50.440 and each vendor has many vendors upstream, and some of them are commercial, some of them 03:50.520 --> 03:55.520 are, yes, dependencies and open source, they're not even vendors. 03:55.520 --> 04:03.800 We need to automate the flow of software transparency documents in here. 04:03.800 --> 04:08.800 I found the CSS bomb sharing group, that's not where you've been involved with, right? 04:08.800 --> 04:10.720 That's another group. 04:10.720 --> 04:12.760 That's a different group. 04:12.760 --> 04:19.000 But they talk about sophistication levels, and we are really aiming for a very high 04:19.040 --> 04:27.960 sophistication level, because we can't afford having human beings doing all this work manually. 04:27.960 --> 04:34.120 And while the S-bomb is very fun to talk with, people talk about S-bomb. 04:34.120 --> 04:38.960 This is the S-bomb Devroom, but we talked about C-bomb's earlier in Vexfals. 04:38.960 --> 04:47.680 There are lots of different administrations, and since I'm in Sweden, which is part of the EU, 04:47.720 --> 05:00.640 certificates compliance with the CE-marking will be a document we will have to automate and over together with many other documents. 05:00.640 --> 05:11.680 Even though we're a cyclone DX project, the T-A-P-I doesn't matter, we don't bother with a format of the S-bomb. 05:11.680 --> 05:13.920 That's another problem. 05:13.920 --> 05:19.800 We just want to make sure that the files are transferred. 05:19.800 --> 05:23.600 So I'm not going to go through all the details here. 05:23.600 --> 05:30.040 But we start looking into something we call, I'm not allowed to cross the red line. 05:30.040 --> 05:33.600 It's really hard for me. 05:33.600 --> 05:43.760 We start looking to discovery how does a customer figure out the AI server location? 05:43.760 --> 05:51.600 And since I come from I-P-Tell for me, we use, in that case, we use DNS heavily for load balancing and failover. 05:51.600 --> 05:58.080 And I tried really hard, Victor can support me in that. 05:58.080 --> 06:02.000 But the HTTP world doesn't bother with that. 06:02.000 --> 06:07.040 They have their F-5 load balancer and someone else fixed the problem. 06:07.040 --> 06:10.240 So we can't operate in two data centers. I'm sorry. 06:10.240 --> 06:16.320 But we have a discovery called Transparency Exchange Identifier. 06:16.320 --> 06:18.560 It's a unique identifier. 06:18.560 --> 06:22.080 But we're not trying to create news identifiers. 06:22.080 --> 06:26.720 We're building upon others and I'll show you soon how we do that. 06:26.720 --> 06:32.480 But without identifier, we locate a web service. 06:32.480 --> 06:36.000 We're using the Dr. Well-known address. 06:36.000 --> 06:38.880 We're going to get a redirection to where we have the AI service. 06:38.880 --> 06:41.760 It could be in-house or could be a service. 06:41.760 --> 06:46.720 We actually pay for external. 06:46.720 --> 06:53.600 And based on that, we look up the actual product. 06:53.600 --> 06:55.600 And the world isn't simple. 06:55.600 --> 06:58.800 You can buy a bundle of stuff. 06:58.800 --> 07:05.360 And we quite often use the Philips U as example. 07:05.360 --> 07:08.560 You buy a controller in two lines. 07:08.560 --> 07:10.880 Those are different systems. 07:10.880 --> 07:15.920 So on the product level, you get to an index. 07:15.920 --> 07:18.880 And for each of these products, 07:18.880 --> 07:24.000 you get a service point where you actually find all the versions 07:24.000 --> 07:26.960 the leaves of that specific product. 07:26.960 --> 07:29.840 With some information, near the information, 07:29.840 --> 07:33.520 saying whether or not this is an active version 07:33.520 --> 07:40.080 if it's a testing version or other things. 07:40.080 --> 07:44.080 And in the end, you'll get to what we call the collection, 07:44.080 --> 07:46.880 which is just a list of all the documents 07:46.880 --> 07:53.680 that apply to this particular version of this particular product. 07:53.680 --> 07:58.880 So something simple, you can make very complex in PowerPoints. 07:58.880 --> 08:00.880 I won't go through all the use cases. 08:00.880 --> 08:05.440 The slides are available on first them. 08:05.440 --> 08:09.680 So our first level here is that. 08:09.680 --> 08:16.080 Artifactor retrieval with without authentication and authorization. 08:16.080 --> 08:21.520 We'll have a publication API for publishers 08:21.600 --> 08:25.840 and a consumer API for customers. 08:25.840 --> 08:28.240 We have the discovery mechanism. 08:28.240 --> 08:31.520 And we're working together with another OSP group 08:31.520 --> 08:34.400 called the Coleman Lifecycle and Immigration 08:34.400 --> 08:36.400 that tries to find an immigration. 08:36.400 --> 08:37.680 And that's real hard. 08:37.680 --> 08:44.160 But they have narrowed their scope to actually define their life cycle 08:44.160 --> 08:48.560 state of a product. 08:48.560 --> 08:54.960 7.2, which comes at somewhere after level 1, 08:54.960 --> 08:56.960 isn't that funny. 08:56.960 --> 08:59.920 We'll be an even more advanced API. 08:59.920 --> 09:05.280 Because in that case, you can query data. 09:05.280 --> 09:08.720 You don't have to download and parse the S-bombs. 09:08.720 --> 09:12.080 You can query and say, does this product in this version 09:12.080 --> 09:14.480 have log for J? 09:14.480 --> 09:15.200 And get answers. 09:15.200 --> 09:21.760 So a much more CPU intends in much more complex API. 09:21.760 --> 09:25.600 But removes a lot of the hairs you're asked for, 09:25.600 --> 09:30.560 parse it, do whatever you want, is your problem. 09:30.560 --> 09:32.000 So we'll see where we can go. 09:32.000 --> 09:34.560 We have a lot of ideas. 09:34.560 --> 09:37.680 There is discussions within Cyclone Dix now 09:37.680 --> 09:40.640 about the data model to use for this. 09:40.640 --> 09:44.800 We should be agnostic of Cyclone Dix, S-bode X, 09:44.800 --> 09:46.400 sweet, whatever, right? 09:46.400 --> 09:47.440 It's just a data. 09:52.480 --> 09:58.960 So the identifier is a URL called TI. 09:58.960 --> 10:04.800 And we're looking to include everything we can get their hands off. 10:04.800 --> 10:08.240 And user-consumer, bulk codes, we've been in Seminary 10:08.240 --> 10:10.160 's learning about that. 10:10.160 --> 10:15.920 The package URLs, hash values, is up to the vendor 10:15.920 --> 10:20.720 to decide how he identifies the product, C-cellin. 10:20.720 --> 10:23.280 And we don't want to create anything new. 10:23.280 --> 10:31.120 We just want to include it in a shared structure. 10:31.120 --> 10:38.640 The TI includes, in so far, in all the examples we have, 10:38.640 --> 10:44.880 at the NS name, then maybe we have discussions, 10:44.880 --> 10:47.920 some examples where there are other ways 10:47.920 --> 10:51.280 to discover the domain name. 10:51.280 --> 10:54.080 And we'll see about that. 10:54.080 --> 11:01.840 But from that TI, which you find on the product, 11:01.840 --> 11:07.840 you will go to the website and just find all the documents. 11:07.840 --> 11:13.440 We have said that the authorization is up to the implementation 11:13.440 --> 11:16.080 of the T-celler. 11:16.080 --> 11:23.520 We used to say that, well, you have to have an HTTP very token. 11:23.520 --> 11:29.200 What's inside of the Beer token, if it's just a simple OAuth 11:29.200 --> 11:34.080 open ID Beer token, or if something else, 11:34.080 --> 11:37.760 that's up to the implementation, really? 11:37.760 --> 11:42.080 But that could be used for authorization, saying that this user 11:42.080 --> 11:45.280 only have access to this product range and not that product range. 11:45.360 --> 11:57.280 So the way we're looking at it is that you have the T-pot, 11:57.280 --> 12:00.480 or I should say, T-service. 12:00.480 --> 12:06.160 I'm looked over to Redline, and you have a storage. 12:06.160 --> 12:12.800 In some cases, the storage is just an open HTTP server, 12:12.800 --> 12:16.960 because we're discussing also with Apache Projects and others 12:16.960 --> 12:20.720 that they have this, the highways are distributing it, 12:20.720 --> 12:24.000 but they need to follow the T structure. 12:24.000 --> 12:30.080 In other cases, this is S3 buckets, including the T-service, 12:30.080 --> 12:33.680 and not reachable from the outside. 12:33.680 --> 12:37.600 So we have to be a bit open there and not create an API 12:37.600 --> 12:41.840 that is depending upon the server architecture. 12:41.840 --> 12:46.800 We also have a bit of discussions about software transparency 12:46.800 --> 12:50.400 log, very much like certificate transparency logs. 12:50.400 --> 12:53.920 We're not done there yet, but it's an interesting area, 12:53.920 --> 13:01.920 but I think that we'll have to come a bit later in the life of T. 13:01.920 --> 13:08.960 And we also realize in complex organizations between many lawyers 13:08.960 --> 13:11.760 that there has to be an internal T-service 13:11.760 --> 13:15.840 where you publish data for approval 13:15.840 --> 13:19.600 and internal compliance and legal issues, 13:19.600 --> 13:23.760 and then the process to publish it on the customer facing side. 13:28.400 --> 13:31.520 Much like this, you've been systemed 13:31.520 --> 13:35.600 that automatically publish to the internal service, 13:35.680 --> 13:38.560 and someone sits there stamping saying, 13:38.560 --> 13:44.080 this is okay, this is okay, but this doesn't work for us. 13:46.320 --> 13:48.880 I won't come through all this. 13:48.880 --> 13:53.040 But I want to mention the common life cycle and admiration again. 13:54.240 --> 13:56.960 This is an over project. 13:57.520 --> 14:00.160 If you're interested in this area, they need your help, 14:00.160 --> 14:05.200 and it's a real an area that we all want to have some sort of 14:05.200 --> 14:10.560 resolution for, but we need to be able to find out in 14:10.560 --> 14:13.520 as bombs and in services like T. 14:13.520 --> 14:16.400 If our component is end of life and the support, 14:16.400 --> 14:19.760 end of secured fixes replaced or whatever. 14:21.200 --> 14:24.320 See how the URL down there, go and take a look. 14:26.720 --> 14:29.680 And I want to get the question about package URLs. 14:29.680 --> 14:33.440 Yes, we will support package URLs, 14:33.440 --> 14:35.760 much like we support anything else in the S-form. 14:35.760 --> 14:40.480 It's not a matter of TI, TI will include package URLs. 14:41.440 --> 14:46.160 I want to mention though that exactly like cycling DX is now an 14:46.160 --> 14:49.680 eggmastanded, we got slides earlier talking about 14:49.680 --> 14:51.440 the other standard being ISO. 14:52.720 --> 14:54.560 Cycle and DX is eggmastanded. 14:54.560 --> 14:58.240 We're bringing in T and we're bringing in package URLs 14:58.240 --> 15:02.400 into ECMA for standardization, and that is work that is going on. 15:03.120 --> 15:06.400 As we develop everything, it's part of what we call 15:06.400 --> 15:08.000 ECMA TC-54. 15:10.400 --> 15:17.120 So we're all we, I think we have fixed all the concepts, 15:17.120 --> 15:21.200 the object models, and stuff, we're down to discussing naming. 15:21.920 --> 15:26.000 And I really, really prefer Swedish names and everything, 15:26.000 --> 15:27.440 so that's Victor. 15:27.440 --> 15:30.000 There's some other people that have problems with Swedish. 15:30.960 --> 15:32.160 We just have to convince them. 15:33.840 --> 15:36.960 We are working on the open API spec. 15:36.960 --> 15:41.440 We have a first version thanks to Victor and Paul Horton or Sonotite. 15:43.920 --> 15:46.640 We have to work a bit on the data modeling there, 15:46.640 --> 15:50.480 so we have all the names and structures right, but we have very, very close. 15:52.560 --> 15:58.080 So we're aiming for starting to create code, starting to create 15:59.040 --> 16:02.240 I would say clients and so on this during the spring, 16:02.800 --> 16:05.280 and have a hackathon and open hackathon 16:05.920 --> 16:09.440 at Uva's website conference in Barcelona at Endo May. 16:10.640 --> 16:14.080 So we encourage all of you that great tools in this area 16:14.080 --> 16:19.680 to join us and come to the hackathon or participate online 16:20.560 --> 16:24.720 and make sure we build something that helps all of our customers. 16:28.160 --> 16:33.200 So to summarize, T is going to be the standard for transparency exchange. 16:33.200 --> 16:38.080 It's going to be an echema official standard within a year. 16:39.280 --> 16:43.360 It fits very nicely to all the world-wide legislations we see 16:43.360 --> 16:45.200 for software supply chain security. 16:46.560 --> 16:50.720 We mentioned it during a meeting with the European Commission this week. 16:50.720 --> 16:52.320 And they are interested. 16:53.440 --> 16:57.360 We have one API for publication that's not mandatory to use. 16:57.360 --> 17:01.760 That's just an idea on how we can look, but the consumer side 17:02.560 --> 17:06.640 is the hardcore part of the specification that we all need to follow. 17:09.280 --> 17:13.680 So get the board, help us. 17:16.000 --> 17:17.280 You have the URL here. 17:17.280 --> 17:21.520 You have the URL on this Torx page on the first-in-web site. 17:22.880 --> 17:26.080 On the GitHub account page there to read me. 17:26.160 --> 17:28.320 You get pointers to Slack or other things. 17:29.120 --> 17:32.320 If you want to have a discussion, find me, 17:32.320 --> 17:34.320 from LinkedIn or anywhere else, 17:36.160 --> 17:41.200 just about any communication media, shouldn't be hard to find me. 17:42.720 --> 17:43.520 Any questions? 17:45.520 --> 17:46.320 We have a few. 17:56.880 --> 17:57.200 Yeah. 18:00.480 --> 18:01.680 Talk with me after the talk. 18:02.960 --> 18:04.960 How do I get involved in the hackathon? 18:05.840 --> 18:07.040 We're just planning. 18:07.360 --> 18:11.200 So contact me and I'll get you inside the discussion. 18:12.880 --> 18:16.000 Is the open API a data API is public already? 18:17.040 --> 18:22.480 The open API as we have it today is within that GitHub repository. 18:22.480 --> 18:23.760 So you can start playing with it. 18:24.560 --> 18:27.920 And we are tested the syntax of various generators and tools 18:27.920 --> 18:32.240 and it works well, but it's still a moving target. 18:32.240 --> 18:34.400 We will modify the data models. 18:35.840 --> 18:39.520 If you were at about that, Victor is the man to talk with. 18:41.200 --> 18:43.760 Really, we have a few open pull requests. 18:43.760 --> 18:46.240 We're Victor and I are trying to agree on the proper 18:47.280 --> 18:49.360 Nordic room scripts and other things. 18:54.160 --> 18:56.960 How are you looking at the internet? 18:57.760 --> 19:00.240 One other slide to mention a transparency log. 19:01.600 --> 19:07.360 Yes, that's a topic that we have been discussing. 19:07.360 --> 19:11.280 I've been discussing and I've been following very closely 19:11.280 --> 19:13.120 the ITF-skit working group. 19:13.120 --> 19:14.720 They're doing some cool stuff there. 19:15.840 --> 19:19.120 I've also been in the discussion with a SIGSOM open source project. 19:19.520 --> 19:23.520 I don't think we're there yet with version one. 19:23.520 --> 19:26.960 I think this is something we as an industry 19:26.960 --> 19:28.960 will have to continue to talk about. 19:30.320 --> 19:33.120 The idea with our transparency log is to make sure 19:33.120 --> 19:38.160 that if a vendor publish an S-bomb for a version of product 19:38.160 --> 19:44.000 that's critical to me and they change it without releasing a new version. 19:44.000 --> 19:47.440 They change the S-bomb for the version of software I use. 19:47.520 --> 19:50.640 I want to know why and I want to know that it changed. 19:52.880 --> 19:56.160 Transparency log can help me with that report of the trust. 20:17.440 --> 20:22.240 They want to change the version of the position because in this case 20:22.240 --> 20:26.480 the customer would be required to pull information from somewhere. 20:26.480 --> 20:30.880 Right now there are a lot of new documents that exist with the state that you have today. 20:30.880 --> 20:36.880 No, I just want to move on to the conclusion for the review of the cost of the SIGSOM. 20:39.280 --> 20:45.920 In short, the transparency exchange API today is customer pooling. 20:46.640 --> 20:50.800 There are some pressure in the business for vendor pooling to customer. 20:51.520 --> 20:55.680 I don't see how that would scale actually. 20:55.680 --> 20:59.440 I understand that it's very interesting. I haven't heard that before, 21:00.720 --> 21:04.320 but let's think about it and see what we can do. 21:06.960 --> 21:09.760 And just a comment that you mentioned, 21:09.840 --> 21:16.400 Pocket URL is becoming a standard. It's also an appendix in SPDX, so it will be an ISO standard. 21:22.000 --> 21:23.680 That's all. Thank you very much.