Defining the Protocol for Internet-Scale Digital Trust

Good afternoon everyone. Thank you for coming. I'm Judith Flanner, I'm the Executive director of the Trust Over IP Foundation. The Trust Over IP Foundation is a Linux Foundation that is 400 members, actually almost up to 500 members now of individual contributors and corporations that are working together to meet our mission, which is to create a complete architecture for digital trust at scale. It's an easy task, right? Right.

No, it takes collaboration. And that's why our, our systems work. So today we're here to talk about one of the things we're working on in one of our working groups, which is a part of our stack, and it's called the trust Spanning Protocol. So what I would like to do is I put a polling question in your apps for you, if you can start the polling question for us. And the question is, have you heard of the concept of a trust spanning protocol? And you can be answering that while I introduce the rest of my panel here today.

Today I have been joined by three of our steering committee members, plus a long-term member of trust over IP, who has used our governance metamodel and is actively working with the technologies, developing things in our world, in our working groups. And so they're actually deploying this stuff. So it's not just theory. So we'll start with Andre Kra. Andre KRA is the CIO of a status, although you're gonna have to correct me, I always say that wrong. Say it with the German.

It's, it's, it's ITOs the only one Tto. I always put a T in it. A status.

Oh, It happens to, It's everybody. Well, he is an information security has been his passion since the turn of the millennium, but he's been specifically working on decentralized identity as a visionary since 2015. That's about right, yeah, around them.

Yeah, yeah, yeah. Okay. And then we have Chris staff who is the head of IT development and operations for the Global legal Iden, global Legal Entity Identifier Foundation. I'm gonna use what I usually call it, which is glyph. So you may have heard of glyph. And in 2017, he joined the International Organizations for Standards as the co-leader of the technical committee 68, and the FinTech technical advisory group. So for those of you that like the acronyms, that would be ISO t c 68, FinTech tag and his work.

He has experience in developing and implementing solutions in the financial technical industry. And then we have Daniel, Daniel Weimer is from Accenture. He's the Digital Identity innovations and technology lead there. Biometric based digital identity has been his focus for the past two decades. So we have a biometrics expert in the room with the addition of decentralized identity solutions tied to, or not tied to biometrics in 2017.

And last, but certainly not least, we have Drum and Reid, who's the director of trust services at Avast, no, sorry, Jen. Jen Digital. So for those of you that do not know the history of that, it's the ever changing company name. He was with ever M back when he was working on W three C decentralized identifier, did Spec 1.0 and you were still with ever and m when you were the author of the Manning publication, which has the Self-Sovereign Identity book that is really the definitive book on self-sovereign identity.

But then it became, you know, they were acquired by a vast and then a vast Norton merger, and now they are Gen Digital. So we wanna put up the, the, the polling question and see what the results were here. So 92% of you have not heard of this, so this is good. This is why we are here today. So I'm gonna start, you can close that. Now I'm gonna start with our first question to Drummond, and within the session brief.

Oh, with Andre. Sorry.

Yeah, I, I think I am Andre. Yeah. Within the session brief, we talked about the T O I P stack. Can you kind of articulate for us, give us that elevator pitch on why it is both a technical stack and a governed stack, what we call the two halves or a jewel stack, and why are both needed for infrastructure to become internet scale interoperability?

Yeah, let me, let me revert this with a question at first. So what do you think is, what do you, This would not be our deck. The other one was better. Yep. We can do PowerPoint That's good. Yeah. So who of you, well, who thinks the technical side is either is, is easier to implement?

Okay, only one hand up. Okay.

So who, who thinks the governance side is the, the tough part? Ah, okay. We are getting there. So you now already see why it's two, two different halves to the same equation, basically. So we need the technology, I think we have tons of technology evangelists here at the conference and all the other interesting community activities around the world. So this is not a technology topic as such.

It's, it's a governance topic and it's a regulatory topic. That's the reason why we have defined the trust IP dual stack in that way. That we have the technology stack on the left hand side and the governance stack on the right hand side. And we have currently defined the four layers of it. And you see the, this is, this is a cool slide rep representation, let me get up. It is in very interactive model on the trust of, of IP website, which is even cooler to, to look at and slice and dice.

But we have the layer one where you have the, the trust utilities, the, the basic layer of verifiable data registries and this good stuff. And this is kind of the baseline where we start off and then we get on the agent layer where we have peer-to-peer communication. And this is always both on the technical side and on the governance side. We implement technology, but we have governance frameworks driving the implementation and the use of the technology. So we have layer two peer-to-peer communication protocols. So agent to agent communication, really vital in the really decentralized world.

And layer three is the trust task protocol. This is usually something like credential exchanges. So you get data in this commonly known issuer holder verify model across the, the stream. And this is what happens on layer three. So credential exchange is one great example of this trust test protocol.

And then, then we are not at the application layer, but coming to that because all this is needed to build the applications, which is what the end users do with all that. So this underneath is what we as an industry have to solve. But the application part, this is the upper layer to make this all easy to use, convenient and secure at the same time.

This is, this is our task. So that the user experience is really cool on the top layer. So I think I'm probably, Drummond would've told it totally differently, but I think having all this underneath is what is vital that we get to the great experience on top. And this is why we do it on both ends, technology and the governance side. Thank you Andre. And now to the meat of the, the topic today, which is the trust branding protocol and why we need that.

I'm gonna invite Drummond to focus on that keystone protocol that we are working on right now or set of protocols and why it's so important to interoperability at scale. And Andre explained why we have the two sides of the stack. And we are known at trust r i p as he explained for the governance side, the trust IP meta model, the governance tools we've created there. Ironically, today's session, we are going to talk about the technology side of the stack because there are real interoperability challenges on that side too.

And after spending, say our first 18 months really focused on primarily governance, then we've spent the last 18 months focused on the technology stack side. And in doing so, we published something center website called Design Principles, which was trust by trust over IP stack. And one of the most important of those is called the hourglass principle. And anyone who's familiar with the, the architecture for the internet is, is, is familiar with this general design that you can see on the left side of this diagram.

That's, that's a, a, a classic, it's actually from a 19, I think it's 89 paper that shows the hourglass model and, and the fundamental ideas that if you want broad, scalable interoperability of a protocol stack, you need to design what's called a spanning layer. And a spanning layer has exactly one protocol in it. It's as simple as you can possibly get. All the protocols below it are called supporting protocols. All the protocols above it are the supported protocols with the internet.

As you see, we start with the, the, you know, the, the, the wire level protocols and then up into the, the networking protocols, local area networking protocols. But what made the internet possible was the additional of ip, which is really justifies two things. Internet addresses, right? Addressing scheme, that's, that's colly scalable and the basic structure of datagrams from moving around data in a standard format. All the protocols above that were necessary. And I'm gonna point out, actually I brought my pointer here, oops, I gotta turn it on.

These two in particular, this stack is generally known as T C P I P because you had to have that protocol to actually define essentially a messaging protocol to move around IP packets. Almost no developer uses the IP protocol directly. You either call these higher level protocols called tcp i p, I mean tcp. And that was actually the dominant protocol used until there were enough uses where you didn't want to establish a session you wanted, you wanted to be a session list. And that's when the UDP protocol came into use.

Ironically, I've been educated, I wasn't around at that time, and I'm not that level protocol architect. UDP has steadily gained. And every time you're watching, you know, your favorite series, how many TED Lasso fans out there, that's what you're actually watching streaming over, over out there.

So anyway, handful of protocols there and then many more protocols as you move up towards the application layer. So that's the basic idea of the hourglass model. One of our 18 core design principles was to say we need to do the same thing if we want iop trusted interoperability at global scale. And I think with everything you've heard here about digital wallets and you think, how are we actually gonna get all those digital wallets to talk to each other in an interoperable way, exchange verifiable credentials.

But a lot of other things we're gonna tell you about, we need a similar architecture. So we said if you apply that model to trust, you're gonna end up with these same basic four layers of the supporting protocols. We caught that, the trust supporting layer. Technically you're gonna have this spanning layer that we're gonna tell you more about next, and that's gonna support a whole set of trust tasks that are needed by the applications.

And, and essentially this hourglass is gonna be up here on top of this hourglass when you're using it over the internet. But we will, for any of your protocol experts say, we call it trust over ip, but it's actually trust over any transport protocol, Bluetooth low energy or 5G or whatever. Okay.

So that's, that's why we designed it. Now, I can't remember, I think I've got one more. Keep going.

Yeah, This is the slide you're really supposed to be talking about now. The next one. The next one. Okay. So what is the, what's the design and what's the role of that trust banning protocol for that, we're gonna go to this next slide, which shows you a much more detailed view of where we are in the design of the trust banning protocol. And we're gonna stay on this slide for the whole rest of it. So if you wanna take a picture now or anytime in the rest of the session, this is it. There is a fair amount to explain here.

So again, the trust support that's needed here is anything you need on a device, whether it's an end, you know, end user mobile device, a tablet, a laptop, a car, an IOT device that wants to speak this stack, just the way it's speaking the T C P I P stack to be on the internet today. And that means yes, you need, you need a, a cryptographic processor, you need secure storage, you need basic, you know, protocol transport protocols.

But what we're trying to do with the trust manage protocol is put a single thin layer over that that establishes a standard way to establish verifiable authenticity of the two endpoints that are talking to each other. And notice mutual, we want both end points to be able to, to verify themselves to the other. Now to do that, this whole stack relies on cryptographically verifiable identifiers. That's the best known form of that nowadays is dds. And I spent seven years of my life working on the D I D specification. Turns out that's not the only way to do a cryptographically verifiable identifier.

Every HTTPS URL that you're using out there is cryptographically verifiable. It doesn't have some of the other properties of ds. They're not decentralized, but they will work. That's a way to do it. But every time you connect with an HTPs website out there today, 99.9% of the time, it's a one way verifiability. You are verifying that site. It's not verifying you, it's not that to say that protocols didn't support it, they do support it. It's just never been practical for you as an individual to be verified to the other end.

We're saying, oh, this trust bending layer, what's at those two ends are wallets. All the wallets you're hearing about here, your personal wallet, but you keep hearing about the cloud wallet or, or, or the organizational wall you're connecting to or the IOT wallet you're connecting to for a device. That's what's speaking that protocol. And all it needs to do is verifiable authenticity that the basically every message is signed by by, you know, my private key on my side, your private key on your side.

And we're verifying, okay, we don't know anything about you as a person or as an organization at this layer, but we know we've got a mutually verified connection. So Drummond, if we had a tres panning protocol, then what would be the next layers that we would need to have?

Boy, we sort of scripted this, didn't we? Okay, so we're gonna talk about the rest of what appear in, in this, what we call the trust task layer, this layer three, right? And I'm only gonna really speak to these and then we'll go on to the other things. So there are two fundamental types, just as we talked about ip, very simple. You've almost never used that protocol directly. You use TCP or you use udp.

Well, when it comes to trust and exchanging messages between two parties that wanna have a trusted relationship, turns out there are two fundamental ways you can think about doing that. And one of them is call it messaging based. Think what did we do with smtp? What was the original killer app for the internet? It was email, right? We all have a standard way to move around messages between us. This is what we call trusted messaging. The closest thing out there to that protocol today is dicom DICOM is been a working group at, at the decentralized I identity foundation.

Claire's here, their executive director. We're very closely with that because DICOM is designed to be did to, did communications. The only thing about DICOM V1 or V2 is it didn't anticipate a common trust bending layer. But we don't have Sam Kern here, do we right now? I don't think so. He told me he had a conflict with this session. The co-chair of the DICOM working group at W three C is working closely with us on how DCOM will evolve to use this trust Benning glare. Okay. So that's how we, we anticipate to handle trusted messaging.

There's a second way to look at what you need to do, and guess what, that's the other predominant protocol or the, the, the other predominant architecture for sharing information on the web on, on the net today. And that's the web, that's HTD p, that's state transfer. Well it turns out there's another group at Diff that started down that path and said, we're gonna do did to dip messaging, but we're going to do it to exchange data and synchronize data every place you need to do it in a trusted and encrypted manner. That protocol is called decentralized web node.

I didn't have room to spell it out here. D w n. So there are two diff working groups working on essentially the, the, the prototypes, the forerunners for what's needed at this next layer right above with those two protocols, just like with the T C P I P stack, we can start to do trust tasks that suddenly look a lot more like what we need in the real world.

I mean, how many of those verbs up there would you recognize and say, oh, that's something I need to do on a regular basis on the internet in a standard interoperable way. Every one of these above and, and well my other panelists are gonna talk about them, are, are protocols that now can be designed once and reused between any two applications anywhere? I'm done. Thank you.

Drummond, never give Drummond a mic. He'll be here for 45 minutes, but that's just because he knows so much and he's been the chair of our technical working group, et cetera. But now I wanna kind of switch the focus to someone who's actually being deploying this using our stack. They first started using our governance metamodel to write the governance for what they're doing. And this is Christoph. Can you explain what drummer just talked about, all these trust acts that are at the top. How do the trust talk tasks involve the use of trust registries?

And can you explain what a trust registry protocol, another working group at trust over IP that's working on right now, so we don't have siloed trust list here and trust registry there, et cetera. How would you like to explain how you're using that and how did that fit into this stack? Sure. So the trust registry protocol provides a standard mechanism for communication and exchanging between trust registries basically. So each peer trust registry can answer Veris, whether a particular party can be an issuer, can be a verifier, is trusted for once and is authorized.

Secondly, to perform particular tasks, for example, issue a credential or request a presentation. The trust registry protocol also enables trust registries to disclose which peer trust registries trust each other. And that enables a, a governing authority of an ecosystem governance framework such as life to specify which governed parties are authorized to perform specific tasks in the context of this ecosystem governance framework. So as an example, in the WEI ecosystem governance framework, life qualifies to be issuers to issue certain WEI credentials.

And the, the, the trust registry service would then list disqualified via issuers. Thank you. Another box up there says biometrics. And since we have our biometrics expert here in the room, Daniel, can you tell how biometrics fits into a, a trust task in the, the stack? Sure. And two sessions ago in this room, Eric started talking about that a bit with the EU digital identity wallet as a, as an example. So the EU legislated and put in the A R f that authentication to the wallet, which is binding to the the user to the wallet shall be at Elway High.

Elway High is defined in different legislation, is using two of three factors. One of the factors being biometric according to yet another piece of legislation says the biometric com binding would basically be the comparison of a physical attribute against an authoritative source. And Eric introduced the, the, the, the caution, I think he said the buyer beware on that because what does that mean? An authoritative source we probably saw heard a lot about phyto authentication, which is a good protocol, but phyto protocol says that I'm going to the biometric never leaves your device. Right.

Oops, my light is on here anyhow. And, and so, which is fine for certain applications, but at Elway High is, is that an authoritative source? If I take a selfie and, and put it on my phone, the the that's not issued by the government that was self issued. Is that an authoritative source? I question the US department estate with our passports in the uk, Canada, US and other countries, the government doesn't take those photos.

The, we take them ourselves. So it was a US passport and authoritative source. So in a lot of these sessions, oh you could, you could onboard from, from home and in your identity wallet, you know, you could scan your driver's license or your passport and put that in a wallet to bind the biometric. Is that gonna be good enough for all these applications that are, we're talking about, hello? Questions to be answered. So this just gives you a flavor and with the shorten amount of time we have, we can't go over every box.

So I'd like to kind of go up to layer four, which is where the applications, the end users and we talk about how end users is what's gonna really drive adoption, right? What is a real use case for all of this stuff. So I'm gonna go back to Christoff and Lyth. Can you share with us how LYTH has used the T I P metamodel to create governance for V eis, which are the legal identifiers, right, for organizations? Sure. So here's the the practical application side of things. Yeah.

Practical application side and and why you feel the trust over IP stack and the trust spanning protocol is so important to what you are actually deploying out in the world for organizations. Sure.

So the V L I ecosystem governance framework defines the V L E I operational model and how we L E I issuers qualify for and perform their tasks in the context of the global L E I system, the V L E I ecosystem governance framework was created in full accordance to the trust of IP Foundations standards and recommendations respectively toward the trust over IP ecosystem governance framework metamodel. And it consists now of 24 documents, which are all published on life's website. Some of the documents are basically iterations of the same type.

For example, there are six specifications for credentials that we have defined, but still a very comprehensive set of documentation. And this, the structure of this was provided by the, by the meta model. Glyph has built the v i governance on the very strong global EI system governance. And that means we have put life as the root of trust of the ecosystem and of the infrastructure of the V L E I. And life is also the governing buddy of the V E I ecosystem governance framework.

The ecosystem governance framework does not only guide the governance, technical and organizational requirements for the v i, but actually many of them are enforced by the v i software that Glyph has developed. So as a counterpart to the ecosystem governance framework, there's also a technical enforcement of these aspects. And then the trust over IP stack was very helpful to focus on the aspects that we needed for the v i ecosystem governance framework. So the life framework consists of an ecosystem governance framework and a credential governance framework.

So that would be layers three and four of the trust of IP stack. And we are using the foundational lower layers like layer two, which would be the trust spanning protocol that Dramatize explained. Thank you. And you're giving a session on tomorrow, correct? It's on Friday just before the lunch. So if you are, if you are very patient then please be welcome to learn more about the verifiable l e I and life. Great.

And so as, as somebody who's working very closely with the EU digital wallet reference architecture or, or a rf, right? Can you explain in that they have designated open ID for verifiable credentials is how do you see that exchange protocol and the trust over IP stack emergence? How do you see that kind of coming together in the future? Well this is a very, very complicated question actually because the whole, In two minutes or less, Everything around the IDAs two large scale pilots FC and A R F is a complex mess actually.

So what you, what you see, what you see there is with good intentions, the regulator tries to revamp the IDAs 1.0 to a revised version 2.0, which is much more flexible, encompasses not only digital identity, government state issue issue, digital identity, but also all the different stuff of verifi fiber credentials and they call it electronic ation of attributes. So these guys who were very well intentioned tried to write up also technical specifications for this implementation which have been distilled into the architecture and reference framework.

However, not all of them really are so technical as you can expect that people who write usually laws can write technical specifications, right? So I think there is a conflict of well competencies or skills and expertise. This is not a bad thing, but if you want to write something that is technical, you should also involve with the experts community. So this is the place where all these trust organizations come into place, including trust O yip P because they could have done well if they had just looked at the four layer trust o I P model.

And it's a similar job as did and applied this construct to creating the technical specification and the law. So this all has not happened, but i, I think this could be a really cool conversions potential going forward to basically drive the regulation in a very expertise distilled community fashion as the trust of IP dual stack. So if if we find a way to bring that together, I think we would have even a bigger winner because otherwise we are doing siloed things somehow interacting because individuals interact but not with a strong imposing a standard standardized, unified format.

So I don't know if all totally makes sense to you guys, but I've been thinking about that quite a lot and I think if we want to achieve convergence, we need this kind of standardized models to apply to this field to come to good solutions. And I think this is the part that trust o p can play in this game. Thank you.

And, and and from what little birdie's tell me, there are people that are working in the large scale pilots that are working to educate people on how, you know, maybe we should adjust some of this stuff. So we, you said that the legislators shouldn't ma write technical standards and I think probably most of us would agree with that. We need to influence the legislation but not write the standard. So I'm gonna give a question to, May, may I just quick, quickly comment on that just one second.

So I think if we want to have interoperability, it would be well advised that the regulator does make some kind of technical cornerstones into the law, otherwise the interoperability will just not happen. This is my greatest fear that we will have an IDAs tool, which is so great and it will just not be adopted because it's not work working interoperably. So with the implementing acts, we could have a chance to do technical specs driven down to all the member states, but this has not been done before. Laws are not to mandate everything technically. So this is going to be very interesting field.

Sorry for, I had to add that I think we'd agree with it. Ed, I I'm gonna ask, I want Okay drumming. It's Just gonna be very short, but I want point out cause I just got messaged about it that one of the large scale pilots in which my associate Andy Tobin here is quite active, has done a mapping of AI DES two, the trust r p stack. He tried to get the slide to me to go in the deck, but I, it was already locked at that point. So if you wanna see that mapping, talk to Andy after the Session. My bet I should've No, I Raise your hand. So back in the corner is Andy who has it?

10 we're good. So Daniel, you're on a lot of standards buddies, we're in a lot of standards groups, so I wanted to talk about the standards organizations and the development communities. How does trust over IP fit in with some of the ones we hear a lot about here? There was a whole opening session on Open Wallet Foundation. We've heard a lot about the different protocols going on at ISO and you know, Etsy, et cetera. How does this fit in with those other standard organizations?

Right, so there was a, a, a preview from Andre and, and Paul and Andrew session earlier where some of the, where we talked about, well, DICOM being a W three C standard, the ISO standard associated with issuance was brought up there or a, an issuance standard. The ISO 20 23 2 20 dash three is the issuance standard, but then there's open ID for verifiable credential issuance is another one. So there's lots of standards, but as, as Andre was saying, it's, it's, I want, I won't say a mess, but there's a lot of, a lot of variables there.

So in the initial, there was six versions of the A R F that came out before the final one came out and, and picked two disparate standards for type one and type two credentials. So they picked a couple standards, but, and, and they're emerging.

So the iso, so we heard a bit about mobile driver's license and those standards, well that's coming out of you wanted ISO soup, SC 17 working group 10 are the, the working group that's coming up with mobile driver's license standards working Group three is the, the passport, which is probably the, the largest exam, the biggest example of a, of a cryptographically verifiable credential, right? But it was 193 member states that picked the format, protocol and signature that's used for that back in 95 and, and somebody.

And so for trust over IP to, to contribute to that, what we're working on is some of the, the mappings of the, the different protocols, the pros and cons. And I don't know if there's gonna be a single protocol, it's, it, it'll probably be driven by use case. Thank you. And so the, what I would be accurate to say, part of what we're trying to achieve with the stack is not a protocol to end all protocols for everything all the way up and down the stack, right?

But to have just the trust spanning protocol be the minimal part that you would need so that people can use other protocols going up the stack or down the stack and making their own choices. So I would like to give a little shout out that if you did not go to the session, what was your session called? We have two of the people who were in the session today, The one of about the verify credential comparison and With you and Andrew Hughes and Andrew Hughes Toten year, Toten and myself did this. Well it's a community thing that we have been doing over one and a half years actually now.

Yeah. So we basically compared different credential formats and now a group has started to work to compare the different protocols for issuing and verifying or exchange protocols for, for credentials. So that's the, that's something that will go on actually. And this will drive the decision-making going forward, what is going, going to your use cases and to also the regulation. So I think this is, is a cool Expectation. What was the name of the presentation that you did today? Because I'm telling, I'm gonna tell these people it's to go listen.

So to this presentation, I, I sat in it and I thought it was one of the best explaining what, what's needed for a wallet. We keep talking about issue a verifier and holder. Well there's a whole bunch of things that have to happen before it even gets to the issuer based on the, you know, the specifications and the A R F et cetera. And I thought you guys did an excellent job. So that's one worth listening to.

Yeah, Verifiable digital credentials, comparison of characteristics, capabilities and standardization of verifiable digital credentials. Now with that long name, you see why I didn't know what the name of it was.

So yeah, because have Four parts in it, that's kind of, it's Four parts. It was really great and, and some of the continuing work on that is being done now at the trust over IP foundation. We've spun up a group to continue it and part of it's continuing it O Wf, O W F, et cetera.

So we are, we, we work together as standards organization. So with that, I wanna leave the last question to you before we go to the question of the floor. What is the kind of call to action that you would have for these people and the ones listening online? Thank you for whatever time of day you are in whatever time zone you are for joining us today. So as beautiful as this picture looks, it's not done right. We have been working our way up as, as I said, there are wonderful set. If you're interested in governance, you can come use the, the governance tools.

The metamodel, as Christoff talked about, it's already implementation. In fact fairly recently, like about a month ago, the first country that's embracing trust over IP stack as a whole started to give talks about it. That's country of Bhutan. I think it's significant that the country best known for gross national happiness is embracing SSI decentralized identity as a core tool for its citizens to achieve gross national happiness. That's your big takeaway here today. Okay.

Anyway, as we work our way up, we are as as, as you've heard here we have one task force working on the trust banning protocol. One task force working on the trust registry protocol up here, just in the last two weeks we've identified that these protocols immediately above this, just like if this was ip, this might be TCP and UDP are so critical to what we're doing, that we want to begin working directly with those two groups at the decentralized Identity foundation to adapt the work they've done to the trust banning protocol and suddenly the stack starts to look really strong.

What'll happen besides the trust registry protocol is all these boxes will start getting filled in. Where does open ID for VC that you've heard so much about that we've heard has been already selected by the, the architectural reference framework for EI DES two. It's a credential exchange protocol. The whole reason for all these elaborate comparisons is there's a whole bunch of those out there.

Well, about, what was it, 45 years ago, there were a whole bunch of ways to move data around and then we had this thing called the internet. What do you want to bet that we're going to get to some standard credential exchange protocols. We're gonna start to harmonize or adapt those protocols up there so that they take advantage of this machinery. Now notice there's a whole layer here that when you only are talking about credential exchange, you're not hearing about.

But at the Open Wallet Foundation we made it clear from the very start, we're not just building wallets for identity credentials, we're building them for payment, we're building them for access, utility, car keys, hotel keys, NFTs, digital assets, all the things. And, and that's before we even get up here to interesting things like well electronic voting or digitally signing documents or delegating to your, you know, to your spouse or your kids.

All of those are trust task protocols that get an order of magnitude easier if you have these lower layers to build on exactly the way it did with the internet. So call to action, come help us finish this work and then start to look at how you're gonna adapt or use this work. And of course that would, you know, it would help if you join either trust P Foundation as an organization or an individual or any of our sister organizations like Diff Open ID Foundation, open Wall Foundation, all of us that are working together on this. Thank you.

And with that, can you open the final poll so we have another poll for you, which is, now that you've heard this, 92% of you had never heard of a tres panning protocol before you walked in the door. Do you think that having this type of layered tres panning protocol architecture would be beneficial? Yes or no? And with that, while they're doing that, did we have any questions come in? Nope.

No, no questions so far. We have one in the audience or two in the audience. The audience do that while people are doing this fall. Thank you. This is for Andre. You mentioned complexity and you hope that interoperability is achieved. Could you talk a little bit more about the scope of interoperability? I assumed EU nation states, but is there anything beyond that and what could be done to make sure that interoperability does happen?

Yeah, I think we have to have at least a common kind of standard set of protocols that we all wanna support. But the devil is always in, in the details as the, in we say in Germany. So actually what is quite very important in that, in that spaces that we have a test test bed or test harness when to which we can test against that, all this stuff really works together because if you look at IDAs 0.1, 1.0, there is something like in the IDAs bridge, which should allow you to basically use your digital identity for one of the members said than the other in the digital fashion.

But I have the feeling that doesn't work so well and isn't so, so widely used. So basically we want to have a strong mechanism to really test out this interoperability and all this can obviously help to select the protocols and you know, in the aircraft they're also already too selected and credential form is selected. So this is one point what I, what I have as as a vision. And I mentioned that earlier in, in another, in another session. So I think at one point in time we, we don't wanna compete about this, these protocol things anymore.

We just want to make this as commonly used as T C P I P. So if you buy a router or any type of device today, you just want it to use the protocols that are used by the other things so that you don't think about it. Does it work together anymore? So exactly on this layer above with this trust architecture, trust banning we need the same. So basically all the vendor products or custom implementations that want to do something in this trust world need to support this protocol and you don't want to think about this anymore. So you don't make bespoke applications for identity and access management.

Like all the good people out there probably have done for years. So we want to make this interoperable seamlessly out of the box. That's my vision. Thank you. And we have one more question but I wanna also note that we are done with time. So the keynotes are starting upstairs so if you need to leave, but we will take the time for the last question and I will say until we get the credentials inside the phone, if you need something to stick on the back of your phone to put your current credentials in, please feel free to grab some and we have some stickers up here as well.

Thank you for attending. Go ahead and ask your last question. Hey I'm Paul, my question like maybe two questions. So how much is did and did com tied to the trust over IP stack and what's the technical foundation like? What's technical protocol for the trust spanning layer two? So first of all, I think the first half of you answer your question. So the trust banning protocol is between cryptographically verifiable identifiers. The best known are dds.

We're not saying that's the only thing possible, but it's gonna have to have the characteristic of dds and not all DDS are gonna actually meet the requirements, right? For instance, you're gonna have to support key rotation if you want, if you wanna do the trust banning protocol, you know, on an ongoing basis the the oh you, so you asked how closely is DICOM tied to it today did com because there was no trust spending layer there.

DICOM does not require in fact what the DICOM working group is now, our very last meeting was with the DICOM working group to to basically say how can dicom, what may become did come V3 incorporate the trust bending layer so it doesn't have to define it itself but it's using a common layer and actually decompose some other things that are in DICOM up into trust tasks.

So DICOM gets thinner and more universal as a trusted messaging protocol because it's using that the discussion with D W N and that working group is just beginning, they too have had to do their own way of defining authenticity and encryption. And so we've got different ways of doing that whereas with this stack we could have a common way of doing that. And we think that same thing is gonna happen with protocols that are designed at the higher layer, which is exactly what happened with the TCP p set of protocols.

There were all kinds of ways to do things that today are just SMTP and H D V P and we all know the results. We believe we need to do the same thing for trust. So a nice way to say that is each one of those protocols will get thinner in what's defined in it because it does isn't needed to do it. It had to do it originally cuz there wasn't anything else. Exactly and that's what they're working on and we are working with, you know, people at diff come to our working groups all the time. If you ever wanna come, you know we have a one for Europe in the morning, one for Asia in the afternoon.

Some people go to both of 'em so that those cross conversations. So we'd love to have you. Is that it? Well I really wanna thank you for coming. We do have the result of the thing, but I hear they have technical difficulties and so far based on the respondents, I dunno if they closed the poll already a hundred percent sought that the tres spanning protocol and having a layered architecture like this was beneficial.

So yes,