Okay, my name is Oliz Johansson and I have to actually admit that I want to see coders.
I've been coding C for 25 years, project like Asteriske and Al Camerillo, Camerillo
is 25 years old.
We've been having a make-fall system for a very long time and recently we tried to convert
that into C-make.
I wasn't part of that story, but during that transition we realized that no one understood
the make-fall system either.
It has lived its own life, but I quite often use Camerillo as an example of stuff that's
really, really hard to automate making C-bombs of or S-bombs of.
But I'm not here to talk about Camerillo.
I can do that if anyone asks, how many here are active in S-PDX?
Great, O wasp cycle in the X.
Wow, or CVG.
Let's see, that didn't raise hands, you belong to me.
I need you, right?
So I'm going to talk a little bit, I have too many slides, so don't worry about that.
I'm going to skip a few because you already know.
We had so many good speakers here, but we have a problem.
That is, I was in a seminar a few years ago in Sweden, and in the old TV industry, and
they described how they work with their supply chain and S-bombs, and I tried to figure
out how did they get S-bombs.
When I asked three times to say, well, we look into this portal, right-hand click, download,
save, and then we go to our system, click, click, click upload.
From all vendors, now we're getting an email, and we're getting, we can't have it that way.
We need automation, especially with stuff like vex files, that for complex systems, we'll
have to change almost every day.
So I started looking if anyone was targeting this problem.
I've been acting in IITF, I've been writing protocols, I worked with real-time communication.
I know how to send data 50 packets a second, right?
Super real-time communication, we send a lot of packets in real-time.
And I didn't find anyone, and I spoke with Cyclone DX, and they said, well, look at the
bomb exchange API, a very old and sleeping project, but they had a very cool logotype.
The koala is nice.
Supported koala got new life.
Why a koala?
Well, when they started this, they discussed, oh, we need a nice animal, very much like
the Riley books.
So that's why we are creating the transparency exchange API,
which is called T, I never drink coffee, so I loved it.
So that's koala drinking T, you always remember that.
So the problem here is, as you understand, you're well aware that a customer has many vendors,
and each vendor has many vendors upstream, and some of them are commercial, some of them
are, yes, dependencies and open source, they're not even vendors.
We need to automate the flow of software transparency documents in here.
I found the CSS bomb sharing group, that's not where you've been involved with, right?
That's another group.
That's a different group.
But they talk about sophistication levels, and we are really aiming for a very high
sophistication level, because we can't afford having human beings doing all this work manually.
And while the S-bomb is very fun to talk with, people talk about S-bomb.
This is the S-bomb Devroom, but we talked about C-bomb's earlier in Vexfals.
There are lots of different administrations, and since I'm in Sweden, which is part of the EU,
certificates compliance with the CE-marking will be a document we will have to automate and over together with many other documents.
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.
That's another problem.
We just want to make sure that the files are transferred.
So I'm not going to go through all the details here.
But we start looking into something we call, I'm not allowed to cross the red line.
It's really hard for me.
We start looking to discovery how does a customer figure out the AI server location?
And since I come from I-P-Tell for me, we use, in that case, we use DNS heavily for load balancing and failover.
And I tried really hard, Victor can support me in that.
But the HTTP world doesn't bother with that.
They have their F-5 load balancer and someone else fixed the problem.
So we can't operate in two data centers. I'm sorry.
But we have a discovery called Transparency Exchange Identifier.
It's a unique identifier.
But we're not trying to create news identifiers.
We're building upon others and I'll show you soon how we do that.
But without identifier, we locate a web service.
We're using the Dr. Well-known address.
We're going to get a redirection to where we have the AI service.
It could be in-house or could be a service.
We actually pay for external.
And based on that, we look up the actual product.
And the world isn't simple.
You can buy a bundle of stuff.
And we quite often use the Philips U as example.
You buy a controller in two lines.
Those are different systems.
So on the product level, you get to an index.
And for each of these products,
you get a service point where you actually find all the versions
the leaves of that specific product.
With some information, near the information,
saying whether or not this is an active version
if it's a testing version or other things.
And in the end, you'll get to what we call the collection,
which is just a list of all the documents
that apply to this particular version of this particular product.
So something simple, you can make very complex in PowerPoints.
I won't go through all the use cases.
The slides are available on first them.
So our first level here is that.
Artifactor retrieval with without authentication and authorization.
We'll have a publication API for publishers
and a consumer API for customers.
We have the discovery mechanism.
And we're working together with another OSP group
called the Coleman Lifecycle and Immigration
that tries to find an immigration.
And that's real hard.
But they have narrowed their scope to actually define their life cycle
state of a product.
7.2, which comes at somewhere after level 1,
isn't that funny.
We'll be an even more advanced API.
Because in that case, you can query data.
You don't have to download and parse the S-bombs.
You can query and say, does this product in this version
have log for J?
And get answers.
So a much more CPU intends in much more complex API.
But removes a lot of the hairs you're asked for,
parse it, do whatever you want, is your problem.
So we'll see where we can go.
We have a lot of ideas.
There is discussions within Cyclone Dix now
about the data model to use for this.
We should be agnostic of Cyclone Dix, S-bode X,
sweet, whatever, right?
It's just a data.
So the identifier is a URL called TI.
And we're looking to include everything we can get their hands off.
And user-consumer, bulk codes, we've been in Seminary
's learning about that.
The package URLs, hash values, is up to the vendor
to decide how he identifies the product, C-cellin.
And we don't want to create anything new.
We just want to include it in a shared structure.
The TI includes, in so far, in all the examples we have,
at the NS name, then maybe we have discussions,
some examples where there are other ways
to discover the domain name.
And we'll see about that.
But from that TI, which you find on the product,
you will go to the website and just find all the documents.
We have said that the authorization is up to the implementation
of the T-celler.
We used to say that, well, you have to have an HTTP very token.
What's inside of the Beer token, if it's just a simple OAuth
open ID Beer token, or if something else,
that's up to the implementation, really?
But that could be used for authorization, saying that this user
only have access to this product range and not that product range.
So the way we're looking at it is that you have the T-pot,
or I should say, T-service.
I'm looked over to Redline, and you have a storage.
In some cases, the storage is just an open HTTP server,
because we're discussing also with Apache Projects and others
that they have this, the highways are distributing it,
but they need to follow the T structure.
In other cases, this is S3 buckets, including the T-service,
and not reachable from the outside.
So we have to be a bit open there and not create an API
that is depending upon the server architecture.
We also have a bit of discussions about software transparency
log, very much like certificate transparency logs.
We're not done there yet, but it's an interesting area,
but I think that we'll have to come a bit later in the life of T.
And we also realize in complex organizations between many lawyers
that there has to be an internal T-service
where you publish data for approval
and internal compliance and legal issues,
and then the process to publish it on the customer facing side.
Much like this, you've been systemed
that automatically publish to the internal service,
and someone sits there stamping saying,
this is okay, this is okay, but this doesn't work for us.
I won't come through all this.
But I want to mention the common life cycle and admiration again.
This is an over project.
If you're interested in this area, they need your help,
and it's a real an area that we all want to have some sort of
resolution for, but we need to be able to find out in
as bombs and in services like T.
If our component is end of life and the support,
end of secured fixes replaced or whatever.
See how the URL down there, go and take a look.
And I want to get the question about package URLs.
Yes, we will support package URLs,
much like we support anything else in the S-form.
It's not a matter of TI, TI will include package URLs.
I want to mention though that exactly like cycling DX is now an
eggmastanded, we got slides earlier talking about
the other standard being ISO.
Cycle and DX is eggmastanded.
We're bringing in T and we're bringing in package URLs
into ECMA for standardization, and that is work that is going on.
As we develop everything, it's part of what we call
ECMA TC-54.
So we're all we, I think we have fixed all the concepts,
the object models, and stuff, we're down to discussing naming.
And I really, really prefer Swedish names and everything,
so that's Victor.
There's some other people that have problems with Swedish.
We just have to convince them.
We are working on the open API spec.
We have a first version thanks to Victor and Paul Horton or Sonotite.
We have to work a bit on the data modeling there,
so we have all the names and structures right, but we have very, very close.
So we're aiming for starting to create code, starting to create
I would say clients and so on this during the spring,
and have a hackathon and open hackathon
at Uva's website conference in Barcelona at Endo May.
So we encourage all of you that great tools in this area
to join us and come to the hackathon or participate online
and make sure we build something that helps all of our customers.
So to summarize, T is going to be the standard for transparency exchange.
It's going to be an echema official standard within a year.
It fits very nicely to all the world-wide legislations we see
for software supply chain security.
We mentioned it during a meeting with the European Commission this week.
And they are interested.
We have one API for publication that's not mandatory to use.
That's just an idea on how we can look, but the consumer side
is the hardcore part of the specification that we all need to follow.
So get the board, help us.
You have the URL here.
You have the URL on this Torx page on the first-in-web site.
On the GitHub account page there to read me.
You get pointers to Slack or other things.
If you want to have a discussion, find me,
from LinkedIn or anywhere else,
just about any communication media, shouldn't be hard to find me.
Any questions?
We have a few.
Yeah.
Talk with me after the talk.
How do I get involved in the hackathon?
We're just planning.
So contact me and I'll get you inside the discussion.
Is the open API a data API is public already?
The open API as we have it today is within that GitHub repository.
So you can start playing with it.
And we are tested the syntax of various generators and tools
and it works well, but it's still a moving target.
We will modify the data models.
If you were at about that, Victor is the man to talk with.
Really, we have a few open pull requests.
We're Victor and I are trying to agree on the proper
Nordic room scripts and other things.
How are you looking at the internet?
One other slide to mention a transparency log.
Yes, that's a topic that we have been discussing.
I've been discussing and I've been following very closely
the ITF-skit working group.
They're doing some cool stuff there.
I've also been in the discussion with a SIGSOM open source project.
I don't think we're there yet with version one.
I think this is something we as an industry
will have to continue to talk about.
The idea with our transparency log is to make sure
that if a vendor publish an S-bomb for a version of product
that's critical to me and they change it without releasing a new version.
They change the S-bomb for the version of software I use.
I want to know why and I want to know that it changed.
Transparency log can help me with that report of the trust.
They want to change the version of the position because in this case
the customer would be required to pull information from somewhere.
Right now there are a lot of new documents that exist with the state that you have today.
No, I just want to move on to the conclusion for the review of the cost of the SIGSOM.
In short, the transparency exchange API today is customer pooling.
There are some pressure in the business for vendor pooling to customer.
I don't see how that would scale actually.
I understand that it's very interesting. I haven't heard that before,
but let's think about it and see what we can do.
And just a comment that you mentioned,
Pocket URL is becoming a standard. It's also an appendix in SPDX, so it will be an ISO standard.
That's all. Thank you very much.