Architecture and implementation of a cross-ecosystem trust framework: Concepts & experiences

This talk explores the complexities of data ecosystems and the necessity for trust frameworks that enable interoperability between different verticals in artificial intelligence, particularly in Europe. The speaker emphasizes that traditional data sources like CSV files are insufficient for training comprehensive AI models and advocates for the adoption of automated trust frameworks to facilitate data sharing among various industries. The discussion highlights the growing need for a unified methodology to establish trust across different data ecosystems, including automotive, logistics, and manufacturing. In the context of GEX, the speaker outlines how their organization is focusing on developing these trust frameworks, integrating legal and technical requirements to support data exchanges. They detail how automated systems can streamline compliance processes and ensure that participants from diverse ecosystems can reliably interact by adhering to common rules and trust standards.

We are going one step below the artificial intelligence part which is also part of the OC4 AI community and this is namely answering the question where the hell does all the data come from if it doesn't come from a CSV file or a stream. So I'm talking about ecosystems like data spaces probably you have heard about that and we understand or we know for sure for now

that data from one ecosystems like automotive um manufacturing um defense will not be enough to drive large language models. You need vertical models which in Europe is called vertical AI in contrast to the Americans which do horizontal AI. But you will need data from different ecosystems. By the way, also for supply chain like digital product passport. So like 600,000 companies in the automotive supply chain, they need

this kind of data. But also the AI models. How then do you solve the problem how these ecosystems can agree on a common trust basis? One a little bit to what uh we are doing at GEX and what I'm doing. If you want to understand what Gaik is doing, you just really literally have to read our mission statement and our vision. We only do trust frameworks for

digital ecosystems. I know that in 2020 people believed we are building the largest European hyperscaler ever. We were a little bit short of money like 10 50 billion euros. STI is doing that a little bit the Schwartz group but we never got that funding. But we concentrated in the last three or four years on the only thing which has not been solved anywhere and please challenge me.

I have not found anywhere else that someone is providing first automatable trust frameworks. I show you what it is in a second for single data spaces. So within a single uh kind of vertical space but also between and that's completely new. And what is also new and discriminates us as an association from other organizations is they do a little bit standardization. They do a lot of mission

evangelization but we also have software teams and in the back we have Yasia my team lead for the implementation because if you have a lot of data and you have like 10,000 in the Airbos supply chain and you have a lot of data exchanges the exchange the evaluation of your policies and the identities of the other partners in your supply chain has to be automated. So we

built that automation and of course inside um open source projects. I'm this is what we do but I have a little bit more um um flesh to that what that really is because you have to understand a little bit what a trust framework is before we can show how that would work between ecosystems and that it's generally accepted. Trust frameworks consists of a little bit of a

like the legal part, the business part like the requirements specification. You typically have PDF files and you typically have some kind of governance authority in Kataina X that's the Kainer X association even for GIA X it's our policy and rules committee who set up the rules how an ecosystems wants to establish trust and we come to the technical details of that how an ecosystems establish trust so

whom to trust like in PKI what are my trust anchors and at the lower level. This is where the code sits. But not just code but also operational procedure. If you look at the not just the software components but also the operational processes. This is KYB know your business in Cain X. You do you get if you want to participate a little bit of a know your

business kind of evaluation. Is it is that a legit uh supplier in my supply chain before they give you a BPN number or some other shenanigans. And uh of course the actors are like clearing houses one or more federated and automation in the form um of course of um software. We know that there are a lot of different trust frameworks out there. Eyesshare is an important one.

Eidas of course is also a trust framework. None of those solve the question how can you establish trust between Eyesshare and GA and EI does. So that's completely new and no one else has covered that. uh unless you provide a a contrary example. trust unfortunately and there is unanimous agreement both in practice and in the academic literature since 1985 or something like that is very hard to

capture in ISO and did senle we tried to do that I'm also an editor of a standard in that for trust frameworks so we tried to do that so if you want to have a definition which is currently being actually this one is from senelch then stick to those the standard actually has already been um finalized um but not all the elements which are in contained in

the slides have been standardized because it's three parts. This is kind of really more the the fluffy stuff. The meat the flesh is in the other part how you automate that and that's the critical thing and many people do not understand if they read the standard how that would relate to software. And at the top part you have kind of the idealistic the legal part of a

trust framework. The rules people have to obey or claims or processes or your IoT devices the rules they have to obey in order to be trustful. So that's the policies and then you have someone who brings an IoT device who brings a connector or who is an entity. I have a small company and I want to be participant who then the thing I present to someone is

called claim. That's also in ISO 17,000. So I provide a claim look I'm a legit company like typically with a registry um excerpted from the company house and then someone needs to check whether the claim and the policy are sufficient or whether the evidence contained in the claim is sufficient that someone else believes that the policy is met and that mechanism is called reconciliation and this is

what we automate because in reality You have in a database kind of data space participant agents are connectors and they do all the exchange of the data and before they start they get agreement on some access and usage policies but that has to be automated. If you don't do that and you have a person overseeing like millions of exchanges uh in any live project it won't work.

So that reconciliation part is the important part and that has to be automated of course. Um just a few glimpses into how the top part the business part of a trust framework would look like. You have certain labels, you have definitions in in in that case and then there are two important things which also spill over into the implementation and that's how you kind of provide evidence.

We are a little bit this is of course the uh the policy part. So someone is defining that but every policy and wait until the end to the learnings this is important it's easy to define the policies a little bit but then you have to find and this is where declaration comes in and certification you need to define ways how someone in our case a machine is

able to check that and the the primitives the most primitive form is declaration someone says I'm honest I'm 1 m 79 cm toll. Of course, if you trust the person and you can make it liable, the best form of assurance you can get is called in ISO certification. That is that I do that you do not trust myself or my wife measuring me, but I go to

a physician and the physician acts as a so-called conformity assessment body. But whom would you take? I mean for for physical hate that's a physician. for identity of a company that would be the company registry but for compliance with I don't know Senum cloud who is that you need to find those trust service providers that will is crucial for implementation but that's all written in such a

trust framework so we get that in GA we have done that for service credentials for service policies we have done that but this is just a PDF how would you automate that and unfortunately there is currently no universal policy definition language where you can automate everything. ODRL the open um open data rights language is not does not have a semantic um a common semantic for execution. There

is not even an engine. Rego is a little bit um is descriptive of course to some extent but also not used um for the trust frameworks on the preceding side. So what we did because we our policy and rules committee developed very complex patterns and very complex policies. We had actually a manual at that time three years ago cloud code was not available at all. So we

had manual translation from the rules on the previous slide into main graphs or whatever because that will be for every single rule in a data space or ecosystem. The crit critical part you have someone who defines well-intentioned rules and then you need somehow to come to an execution environment. Um so the normal engines the universal engines are not totally available. All the rail cannot even capture all

potential policies time or other policies. It doesn't have causal um inference for instance. So we will have a little bit of development effort for any compliance engines and however only if you have very extended rule sets. So this is what our compliance engine does. So and this is of course done by by part of um my team headed by Yas in the back. So this is what

differentiates us uh from other organizations in the data space arena because they give good advice but no software and good advice is nice but without software you don't get anything or you have to do everything yourself which is the other thing. So if we um look into a single data system in at a data ecosystem that works but we had actually together with other ecosystems a request

uh from our policy and rules committee from our members basically. Initially everything was monolithic. So we had one compliance document the the thing I showed two slides before. We had some compliance engines which implemented a certain set of standards but actually it was a monolith. Every ecosystem would have to install that engine and interoperability of course would be solved because there is one engine to rule them

all and then people discovered two years ago that this form of rules does not fit every ecosystem. So, Cartain X has different ecosystems. SCSN, Aisha, they all have a little bit different ecosystem rules. So, we wouldn't be able to accommodate them. But then we developed together with the policy and rules committee at the top layer and you see the distinction between the kind of the law the

legal part and the technical part on the bottom. They developed a mechanism how to extend our once very closed compliance document with all the policies. Yeah, I will share the the presentation with you. If you send me an email, it will also be on the web page later on. And then we also invented an idea where an ecosystem says, "Oh, that's all nice, Skyex, what you have

been doing here, I need complete another set of rules." And we had the request uh that we also need to be able to kind of implement that. But if you look at that you have one ecosystems it's just sky the other one does a little bit playing around and adds a little bit of flavor and then we have other bring your own rules who are completely different

and then we remember and we know that also from our members that this ecosystem needs to talk to that one and how how would that be able and then they would of course come back to and say hey guys we are implementing your rules and they don't work together and that was an idea which is captured in that GA technical compatibility which we actually have been thinking

of four or five years already that all these different engines for compliance for the different policies that they would work against the same set of standards and if you look into our architecture document you'll find that VC ch web um ch VC chot whatever however what we also wanted to provide to kickstart ecosystems software which allows them in a technically compatible way. So across all the ecosystems

with the same set of standards implement different rule sets. How would you do that? And this is the denup architecture which we released uh last year. It's a very uh straightforward architecture based on the requirements. We had of course something like a dispatcher and then you have we call that extension that's not so important but you see that within a single execution context and that could be

kubernetus doesn't need to be um but that you have that you run that you are able to run to execute and to manage different compliance um domains we call that extensions compliance extension and maybe they have some outside registries or so we don't care because this is the micros service IMX international manufacturing X has of course we have built for them a very small compliance engine and

then we have um we call that local for other reasons and then we have our own big one from the past the lower compliance engine we also know from eyesare that they have big other compliance engines which we will not be able to move into that kind of den platform and for that we invented the idea of having some proxies is and doing um something which we

call um remote extensions, compliance extensions. One thing which is important for this audience because this is completely new not just for us but also for the ecosystems. It's not like Yasia and I and Pa our chief innovation officer that we get together once a year and develop the ultimate vision of how that looks. Yes, we do that but at the same time we work together with our

ecosystems in in our in a co-inovation co-development form to understand their needs and in the next step if someone of you is in ecosystem and says oh Christopher I don't need that I need I need something else I don't know I need an eye sharing implementation or something like that then we would prioritize that because our belief and I know that from IoT it's not we do

not as technical guys we are not the best ones to to preempt your business requirements that would be you as an ecosystem but let's work together to make the most of it and that's called co-inovation in IoT that worked for the last 15 years very well and we're doing the same so very simple architecture and the layer at the bottom it's like basic functions where we implement

a few and this is the current slate of functions a few things and if you use that layer by default you Guy technically compatible. So that's kind of the the the bonus you get when you use the platform that you for free or automatically become GX technically compatible. So any ecosystem which is using that platform and is making use of that kind of technical compatibility layer implemented

in software will automatically be interoperable at the level of trust. That's the promise of that. You can of course say ah I don't want that software implement everything ourselves that's also possible but only a few ecosystems do that it takes about two and a half years three or four developers be my guest perfectly valu possible but that's not how ecosystem starts because no one is interested in

investing into two years effort for developing something which they can get for free and then extend and have us extend it so that's Daniel and this will be initially it was just a helper function for the dispatcher and this will be a prime in ingredient for solving the trust um that the trust dilemma between ecosystems but uh that's too early for that let's first before we jump

to the solution sketch the problem you I have already sketched in one of the earlier slides that you have different ecosystems how can they trust each other And we implemented a use case actually for the last six months uh with the international manufacturing X council. Normally for the international manufacturing X guys and ladies everything is at the top but at the bottom they need some trust service

providers because you cannot trust all the opcua machines all the standards you need a participant identity in your ecosystems. So one ecosystems the manufacturing guys X they have that and then you have an adjacent ecosystem in our case ites was a little bit logistics supply chain who do similar things they also have a notion of oh I have a Japanese um company registry for identifying Japanese companies

or South Korean ones and then you have another adjacent ecosystems like the users is downstream the the customers of the manufacturers who also form an an ecosystem of their own. And in classical data space um how should I say consulting and implementation approaches, you have one ecosystem very egotistically developing their set of rules and policies including their trust service providers. We only trust Deutsche for our credentials.

We only trust Koffinity for handing out participant credentials which is fine for that one. It's also fine for the Japanese guys to define someone else and also for the for the usage. The key question then and we call that uh yeah the yeah the key question then if I'm a participant in I'm a manufacturing company and I want to have a link using data space technology with

my logistics supplier because I need to get some input from my raw material providers or I need to hire and manage some lorries some supply chain things for my customers and those guys sit in the other ecosystems. How do you do that when they have selected completely independent from myself from my ecosystem? They have selected other trust anchors. How can we do that? And actually what we

did is we copied the way how you do that in real life when you send PDFs or faxes. These ecosystems normally would also select company registries in Canada, in Japan whom they trust. you would not trust all the other trust service providers from the other ecosystems because maybe they are shady and also the Japanese or the other ecosystems will select a few probably the Japanese ecosystems will

trust eidas to trust service providers. I mean honestly they will. If you do um uh the business like sending roses or receiving roses from Kenya, I bet you will trust the Kenya revenue authority because that's the only authority they are giving out digital identifiers for Kenyan companies. If you go do business with the UK, you will trust the UK company house. There is nothing else. But on

a technically implementation and automation level, what would that mean? It means that you have kind of a trust profile with your own trust service providers, but you also include on that side the Japanese ones and this kind of um intersection the the union of all those common trust anchors that would go into the ga mater registry together actually and this is a technicality I'll show you later

together with the things they are trusted for because potentially not every trust service provider is trusted for everything else. Uh let's look into a little bit in in more detail how that is implemented actually and this is running. So this is not like an idea but we have been implementing that since uh h since uh Daniel bit was live since last August. So that's all operational. So

you have the ecosystem and that's only abbreviated. it's not so simple and you have some clearing houses as trust anchors and then you have in that case it was a Canadian manufacturing ecosystem or the IMAX with some other trust anchors uh and trust service providers and they all have a registry which is a simple database maybe distributed where you all list the trust service providers the credentials

they are allowed um to to issue which whom you trust and also the the first element here of these triples which this is what we call a trust scope. Um I'll show you later why that is interesting. Strictly speaking it's not necessary but it has fantastically mathematical properties which makes um interoperability easy for many ecosystems. GA has that and Canada has that as well and then simply

literally in our meta registry you select from a guy site oh I don't trust for instance constellation for whatever reasons the ecosystems decide this is made up so that's not the reality in IMX we have that better so we trust a few of the other trust service providers for their credentials and vice versa and normally you could stop here because that's all what is needed if you

if you stay with I stay technical compatibility that's all you need but this is not going to work because this ecosystem doesn't know what's the trust anchors of the other ecosystems and vice versa so we actually invented the g meta registry for as a vehicle to put together to collect all those trust service providers which ecosystems share with each others so that the Japanese participants can look

up if I want to do business with the um with the Gaik ecosystems. Oh, whom would I trust? Ah, Nister Aerospace. So, if I get a credential from Nyster Aerospace, I can automatically exchange data with the other ecosystems. If I do that with someone else for instance with delta dao that would not work because we do not accept that for whatever reasons. So that's the idea you

mutually specify and accept trust anchors trust ecosystem and that can be done and will be done by every ecosystem totally autonomously. There is no governance entity in the world which can tell the Japanese or the Canadian whom to choose. They will choose their set of trust anchors and whom they trust and ges or any other ecosystem will choose their owns and the foreign ones totally autonomous. No

one can change that. There will never be a super United Nations trust registry for all what we trust that no governance entity in the world will be on top of ecosystems. If they agree the meta registry will show. So if they find common ground, if they don't find common ground, we cannot solve that technically. That's an organizational governance issue. I we can't do that. We can't force

we cannot tell autonomous ecosystems whom to choose as trust service providers and that's we call that the trust dilemma. Uh so you can't do that. If they do not want to agree, you don't get it. If they agree then that's the mechanism to go for because then you are you get universally accepted. This is how we present uh that actually to end users. They will not have

to look directly into the meta registry but some kind of catalog and this is actually work in progress because ecosystems uh progress in their trust service providers in the credentials. So this is live actually if you if you go to to tape it uh to Hanova fair sorry uh I will be there the the rest of the week we can show you that live how that looks

like so it's not that the JSON files will not be exposed but something like that and uh we also um developed very small kind of credential ontologies because everything has to be automated and the lingua frana for exchanging um claims and evidences honestly is verifiable credentials. If someone tells me you have to use something else, I don't think that's going to fly. The whole world, those parts

of the world who are embarking on that, but please challenge us and the whole ecosystems are using verifiable credential data model too. So that's kind of then you you see that here and what you also see is several interesting things which in real life will be important. So that's an a credential by an application. So you have a foreign application, you have a trust service provider who

says that your application conforms to I don't know the cyber resilience act but then you have some typically some entry somewhere in the credential which says yeah but that's only valid if it's operated by one of the participants. So you can of course with the ids and linked data so JSON ID is also mandatory. So if you just if you just specify JSON we can't work because

then it's um you know you if you don't have a context it's not interreal you are really doomed you so that will then link back to participants and these kind of very simple kind of u verifiable credential data models are also easy uh to implement also in form of a compliance engine. So the IMX use cases which are based on real digital product passport use cases they

are not so complicated initially. If you look at the GI service credential had 62 other credentials inside that's the full breadth after two years or three years of working you arrive at that but you don't start with that you start with something like that and then over time it will get more complex. we have other device credentials etc uh which have which share similar elements. Um the

most important but not so interesting actually is the provider credential which is kind of a participant credential but that's not in the focus the we will come back in the learnings uh in the in our experiences how that relates to that and you see we also have operated by something like that we invented um because we are also basing the meta registry on um on on JSON

LD we invented a very small ontology And if you remember the triple with a trust scope, a trust service provider and the credentials the trust service provider is accepted um to provide for that scope that's simply implemented. Um so that's the the the raw ontology. Uh at the last page you will find the a link to the ontology where you can find it implemented in our including

shuckle shapes if you want to check whether something conforms to that. So very simple and one important thing is which is often overlooked the classical data space and ecosystem theory says you have to have kind of organizations as participant in an Our ontology does not specify what type of participants we accept or not. You can have for instance IoT devices like you can have an opcua compliant

ecosystem of devices and servers who are compliant and no participant credential in the sense that an organization is paying container ex I don't know a fee for being member or ga or something like that the ontology provides that this is actually a um a me um an approach a best practice a pattern in standardization we also to see that in in the IP protocol and it's called

under specification. If you don't need to specify what is a member credential or so then don't the ecosystems will kind of find um uh that yeah we um also have um of course the trust profile and I showed that just for completeness reasons and also for purposes of education. If you look at real trust profiles which you can find on our web page, we simply followed the

ontology. So there is no this is I don't it's not like um how shall I say it rocket science. You do not have to learn category theory or matrix multiplication. It's not like holomorphic computing which is really kind of or zero knowledge proofs which is mathematically kind of really weird and I'm a theoretical physicist so I understand I can deal with quantum uh computers and quantum mechanics

so that's really simple you just have to do it and I think the difficult part is not that one but a as we will as we will see later agreeing on what we specify in that uh kind of language so That's very easy and I've already provided a link. So that's really trivial almost and uh if you follow this um this kind of triple patterns everyone else

would be able to discover your trust services and providers in the meta registry and can then pick and choose whether they also would like to trust them or not. Yeah, that's the trust proposition. We also actually have developed a mathematical theory for that. If someone is really into set theory and a little bit of um it's not category theory but it's applied set theory and and relations

theory. If you know mathematical notations you will find all the elements which I have in the first slide said oh this is a a trust proposition scope etc. you will just find it rigorously defined um so that it makes sense and we discover a very nice property and also the kind of if two ecosystems agree on some trust proposition like trust service providers that's here that's exactly

the thing which makes the property of shared trust um very nice because then and this is actually a mathematical proof because if if if for some trust scope like participant credentials. We find every ecosystem finds um kind of one trust service providers whom they trust and that is shared or you have a chain of shared elements then you get almost universal interoperability at the level of trust.

If someone says no I'm out you don't get it and you will not be able to um stop that ecosystem from doing that. Yeah. It's like with uh with measurements or other standards. If you don't adopt it as a country then you are out and you have to pay the price for that. We will also Jita and I have written a paper um on that or actually

a book article like 25 pages which is due uh later this year. We are waiting for some reviewer feedback. So if you we have a tech x actually in May by that we should have a final version available. It will be open access. So if anyone wants to kind of read what I have just told you and and with similar background a little bit um more kind

of structured or more rigorously formulated then just drop me a note and you can get a preprint of that. So we really wanted to make sure that this is not something which you lightly say ah we have a trust framework and it solves interoperability. So this we really put some thoughts and tried it out with um IMX at Nuremberg in in Hanova. We are there. We will

present uh one or two cases of a successful application of that in at the end of May at our tech. So both theoretically and practically that works. You can also communicate that because it's not rocket science. you can communicate that even though trust is a very elusive concept. We tried it with Japan and Canada and people are able to follow that line of thinking. I don't say

it's totally easy but they understand that and they can also implement the software. We tried that out. What did we learn the last one and a half years doing so and actually we have two kind of learnings or two areas where the learning happens. One is very simple and expectedly it's just coming up with the compliance rules for your ecosystem. That seems to be difficult because as

we learned um actually I learned it at the data sharing festival in Rotterdam a couple of weeks earlier only 5 to 10% of data spaces have a database rule book where that has to be described. So they operate like kind of a oh we have KPN let's trust KPN yeah whatever they do they have not written it down and of course if you do not formalize trust

it's very hard for the other ecosystem to trust your things you're doing if you can't even explain what you are doing yourself that was very interesting for us to understand um you need to spend some time it's like requirements engineering you need to spend some times a little bit and then we have a little bit also technical or technically rated things whom would who are my trust

anchors or trust service providers? You need to get the those companies on board otherwise you no one who will issue the credentials you trust and technically we only had procedural or very basic um findings. This is mostly related to the fact that the workings with verifiable credentials and the tool chain is new for many people. A few companies know PKI, you know, maybe um a key management

is an issue in IoT but not totally because they all username password a little bit exaggerating. So that's new and also um working with the yeah if your ecosystem does not work with the you are out. Um that's my prognosis. Everyone is using DID. We cannot describe the method. So we using DID web potentially and others you have D eye share but that needs to be uh

the decentralized identifier standard otherwise it's really hard to come to terms and it works very well. If you look at the um at the examples from the IMX we invented a D colon IMX identifier and it's it works like a charm. The resolution is of course not perfect and you can't people can't work with that and that's just like oh I can't work with my I don't

know PowerPoint slides and animated because I'm not used to it. So the technical things will diminish and will vanish in the future who is going to do the compliance rules will stay. It's an a task for the data space governance authority and I also want yeah I told you about the key management and credential management and uh what was interesting is what was not questioned and these

are actually the underlying technical standards. This this this is kind of a common set. If if you are outside of that it will be hard for your ecosystem. And what was also really nice for us and for Yas team is we provided a lot of software for doing that. I'll show you on the next page. We provide all the basic ingredients that you can get started with

simple examples, very elaborate examples, so you can get going without having to develop anything from scratch. And that apparently was well accepted over the last half year or nine months or so, which is also good. And by the way, it also challenges our technology. So the more people who use it, the the better the the um the the functions etc are tested obviously. And last one we

are ga everything we do is from our members by our members but for the broader community. So all of the elements you see here are available to anyone there. So please go to to GitLab and clone the project or become a GX member. So I'll I'll leave it with that. Um if you want um to have more information just Google us. We have an academy actually. So

that's interesting. We have an academy with also some free courses. So normally I mean we are an association so the members pay my salary and the flight to Brussels. So we can't give away everything for free. Then we have a free rider problem and no one would spend anything. So try it out. If not, we have a Slack channel and weekly open source community calls. So, give

me drop me a note or something that the Slack invitation link should work every week and that's a discussion not for the nerds but for those who care about it's also for nerds of course but those who care about the implementation because that is what the G trust framework eventually wants to do. You have nice implementation or definitions of your rules, but eventually in large ecosystems 10,000

in the supply chain of Airbus. All of the nice trust things and policies have to be implemented in software and you'll get that with the GI trust frameworks even across ecosystems and you won't get that from anyone else. Thanks for listening and I think uh we are the last before the reception. Thanks a lot for coming. Any questions at this point in time? It's Yeah, please. Yeah,

>> I see that with delta that is not a data space connector based. >> No, no, no. That's that's made up. So what my question is how far or how near is Eclipse ecosystem implementation of data spaces of supporting GA X trust frameworks DNA or and what is the plan for making it compatible the current implementation with this amazing trust framework. the the current um standards and

projects in the Eclipse data space working group are fully compatible and complementaryary to um what the GE trust trust framework does. Part of the trust framework is even uh a project a standardization project within the eclipse data space working group that's part of the a little bit meta registry cup the project is called cup uh other so it's these are complimentary standards the edwg the eclipse data

space working group provides standards at the level how um um how how data exchange happens data the data space protocol decentralized claims protocol to exchanging. So the GE trust framework is one step above that and we complement that because that's the technical thing but before the technical data exchange can commence you need to check the policies and the claims to m whether they match or not and

currently the projects do not have that they leave it open for this time. So this is where our trust framework complements that and it remains to be seen to what extent the cup project can evolve into maybe something like a GI trust protocol which would also go into the EDWG um working group. So that's possible. So today it's fully complementaryary. So complementary >> you if you go

to the standards DSP doesn't give you a trust framework DCP it's completely it doesn't know how to make your credentials really it's complimentary 100%. Okay. So the way to go is that you first verify before making the negotiation using tractorus X you will verify that the credential are trustable and then after you verify you make the negotiation with the data control plane >> right yes exactly there

is a um a way so Antonio is referring to the steps in the data space protocol where you have first um a catalog retrieval then contract negotiation and in that contract negotiation between data providers and data data consumer you ship around credentials which the the typically the consumer ships around the credential telling the provider look whatever policy the provider has I am fulfilling the policy but the

EDWG does not define policies in any way gives you no way how to automate that in which language and how to structure that how to define the trust anchors so the policy reconciliation is complete at this point in time completely outside of the specification. This is where we complement it because as you have seen policies, claims reconciliation that is where we what we provide and that's nice.

>> Thank you. >> Any other Yeah, please. So how to trust an agent? >> We have uh several requests on doing that. Um in in in the trust framework is open to do that. Uh we have um at the level of the policies uh the policy and rules committee we have an AI sprint. uh so if if you want to become a and if you don't uh

are already become a member and work in that sprint we work together with domainic ex experts like in AI agents uh how the MCP protocol or A2A would relate or could relate to to concepts from the thrust framework we've identified 10 or or so elements like MCP server identity uh training data or AI agent identity or something like that I don't remember that but that's very fresh

so we don't have a a a ready solution for that but we know that several of um the questions in such an AI agent ecosystem can be solved by our trust framework we need to define the rules and then the implementation we are working on that yes yeah thanks a lot and uh enjoy the remaining rest of the evening and of of course the two the two

further days of the OCX26. Thanks a lot.