Thank you. Good afternoon, everybody. As he said, my name is Judith Fleenor. I am the Executive Director of the Trust Over IP Foundation. The Trust Over IP Foundation is about creating a complete architecture for digital trust over the Internet at Internet scale. It's an easy task. It actually is some easy components to it, but what it takes is a whole lot of collaboration, and that is why the Trust Over IP Foundation was founded.
Our membership started with 20 founding members, and we'll talk a little bit about the two-sided stack that we created and why we felt governance was important beyond just technology. But we are now over 500 members of individuals and organizations helping to create this world that we are all moving into. What we create, we create standards, white papers, recommendations, templates, things that anyone in this audience can use. That's the whole idea.
It's all open sourced, that once we create something like a metamodel, you are able to download it, use it with your consultancy, when you're creating your own digital ecosystem, et cetera. That is our goal. I am very blessed today to be joined by six of our steering committee members. Why don't I get to introducing them to you, because they are the meat of the show today.
First, here in the status T-shirt is Andre Kudra, who is the CIO for that organization. Information security is his passion. Since the turn of the millennium, he has a decentralized visionary and has been in very many active roles, both in SSI and other things related to decentralized identity, since 2015. Christophe, wave your hand, Christophe. Christophe is the head of IT development and operations at GLEIF, Global Legal Entity Identifier Foundation.
I know that a lot of times people say GLEIF as if everybody knows about it, but it's just about global legal identifiers, so everyone needs to use these. In 2017, Christophe joined the International Organization for Standards, commonly known as ISO, as a co-lead of the technical committee 68 FinTech Technical Advisory Group, ISO TC 68 FinTech TAG. So for those of you that are in the ISO world, you know what that means, but it is to deal with digital identity. He has an extensive experience in developing and implementing solutions for the financial industry and financial technology as well.
Drummond-Reed, here on the end, is the director of trust services at Gen or Gen Digital. He co-edited the W3C Decentralized Identifier Spec 1.0, and he is the author of kind of what is known as one of the major publications in the area of SSI, if you're first learning, which is the Manning publication Self-Sovereign Identity. It is kind of the definitive book, so if you're trying to learn about this, that's a book to get, and he pulled together experts from the field to create that book.
Carla McClenna is the managing director of standards for GLEIF, and she has project managed the entire VLAI development process, authored the VLAI ecosystem governance framework, which you're going to hear a little bit more about later in this talk, and we are very blessed to have you here.
And then on the end there, Maria Wallace, she is the managing director for digital identity for Accenture, leading the decentralized identity innovation for Accenture, working with clients that span not only geographies but industries, as well as various use cases to realize business process, reinvention, and optimize that is powered by the digital wallet and verifiable credentials. And certainly, last but not least, is Wenjing Qiu from FutureWay. He is the director of technology strategy at FutureWay.
He is the lead author for something we will be talking about today, the Trust over IP trust spanning protocol, which just came out as a draft specification, an implementer's draft, and he also co-authored – when I say authored, this is all done in community, but a big part of the work was done by him for the technology architecture specification draft, which a new version of will be coming out later this month, so check back to our website. So as you can see, we have a panel here with a lot of experience and background in identity, decentralized identity, data management, etc.
So let's start with the first question to you, Drummond, and I'm going to turn the clicker over to you. Drummond is going to go through what I would like to do. We have a dual-sided stack, right? Why do we have a dual-sided stack? Why is that important to the scalability of decentralized trust or even trust of any kind?
Okay, good. So first I want to say that this is our mission right here. The next set of slides I'm going to show you are what we call our third generation of diagrams for communicating the trust over IP stack and all of what we do, and I'm going to call out right now that Mr. John Phillips there led the work on this third generation visual architecture for this, and it was a good six months' worth of dialogue among our different working groups. So this is the first time we're showing it at a major conference, so here it is. We're going to reveal it.
So we're going to step through this as if we're sitting at a whiteboard, and you can explain this to almost anybody as our goal. Obviously, if you're going to tackle internet-scale decentralized digital trust, you've got to start with technology, okay? So there's always been that component. As Judith said, the key reason that we started the Trust over IP Foundation, we said we've got to pair the technology by which you can achieve technical cryptographic trust with the governance that will allow you to achieve human trust, no matter what or where you need to do that.
Now, the next aspect was that Trust over IP, the whole reason we started the Trust over IP Foundation was that we said if we want to achieve trust at the same scale of the internet and as global as the internet, we should be following the design of the internet. It's a four-layer stack, and we have a document called Design Principles for the Trust over IP Stack, it's about two years old, that will explain why are there four layers in the internet, why do we need those same four layers for what we're doing with Trust over IP.
Wenjing will tell you more about layer two, which is the critical one, the spanning layer that actually enables interoperability just like the IP protocol does for the internet today. So that's why the four layers, and you can see they're all technology layers. They extend into governance because governance is not layer-specific. When it comes to governance, you're designing and operating a real ecosystem, a real community, we call trust communities, of any size, of any scale, of any location, for any purpose.
You could say with the trust communities we have on the web today, there are roughly 200 certificate authorities in the world, and every website in the world that uses HTTPS, which thankfully is not a majority, relies on those 200. And yet, do we really have 200 roots of authority in the world? It's roughly the number of governments we have, but there are many, many more than that. So we're going to get to decentralization, we need governance that can operate everywhere.
So the next thing is the trust model is about how do we get to interoperable technology and governance models that can be referenced in the same way. How you govern and your policies and your ecosystem are up to you, but others are only going to be able to interoperate and you're only going to be able to span trust across ecosystems if your policies can be understood in the standard way someplace else. So what you see now is with the trust model for the technology and governance, it's instantiated by digital trust ecosystems.
Everything you see there is something that an ecosystem, any particular ecosystem says, this is what we're going to do, we're going to use these elements of the technical stack, we're going to follow these templates or models on the governance stack, but they're all of their policies. And ecosystems don't stand alone.
I mean, you obviously could do that, but just like in the real world, we use the term ecosystem, which is now being broadly used here in these conferences, because digital trust ecosystems all interoperate together. You hear all about IDaaS here at this conference, headline bulletin, IDaaS is not going to be the only digital trust ecosystem in the world. If they want them to be interoperable, ecosystems learn and interact with other ecosystems. This reinforces that both in and out.
So all of this, if you get the sense of living, evolving ecosystems, that's the other, that's exactly what we're going to have with digital trust. Now we expand up to the full model and I'll take a second to let you appreciate.
This is, if you wanted to say, okay, let's now instantiate all of the, yeah, the cameras come up. The good news is, this very picture at scale is now on the TrustRP website. If you go to the main page and then just click on TrustRP model, you'll actually see the complete set of slides that I just ran through. And is both the light and dark versions available, John?
Yes, exactly. Last thing I'll say about this before we turn it over is, this is now what we call this third generation model. It's a template. If you're familiar with business model canvas, this is the trust model canvas. So John has created actually Google Slides templates. Anyone can come, download those templates and start to design and put together the trust model canvas for your ecosystem and your partner's ecosystems. And you can even start designing. And it will start to look like a global network of interoperable digital trust ecosystems.
That's what TrustRP was founded to help you achieve. And I think that's it for me, Judith.
Thank you, Drummond. Let's give him a hand for going through the entire thing so quickly. That could be an hour presentation on itself when it normally is done. But in the description of this panel, it was minimum viable protocols for maximum interoperability. And so the keystone of our stack here, you see how there's a stack, is one of them at the second layer, which is something called the trust spanning protocol. And so I'm going to invite Wenjing up to talk about the trust spanning protocol. And when you want the hourglass, let me know.
Sure, yes. So we have, I think your keyword is a minimum and then the maximum interoperability, right? So there's two contradictions there, something minimum and maximum. And this idea came really from the Internet or the original Internet itself. I'm old enough. I was involved as a young person actually writing some of the earliest versions of the original version of some of the Internet protocols.
Now, the network Internet come from networking. It's really to connect networks. So at the time, there are many people, smart people invented many networks. And they thought their network is better than others. Like we all think, you know, if I have an idea, I design it, it's better than my competitors, right? So they thought the same way. But in the end, there's all many different reasons and competitions on that. And what really people found is like rather than trying to settle which one's better, how about we find a way to connect them?
Like even though they are different networks, we can still be able to communicate. And what can we communicate over very different design networks? And they find out like that would be something minimally reachable to all the people, all the nodes in the network. And that is the beginning of the Internet and the beginning of the Internet protocol. One thing they left out of that, that is trust. And so we thought maybe we can follow the same philosophy and maybe find a way to add trust back into it, right?
We don't want to miss all the other benefits, but still be able to somehow come out to some trust. And what is that minimum thing we need to do? And so rather than going to technical details, I'm looking for a few quotes. Maybe those were better to illustrate the purpose of the protocol. The first quote is from American poet Walt Whitman. In the poem he says, I am large, I contain multitudes. We human beings have many, many different multitudes in ourselves. And we're not going to have one identity. We're going to have numerous of them. Some people call personas.
But, you know, your ID to pay tax and your ID to, I don't know, date to go shopping are not going to be the same. We shouldn't be looking for one identifier. That would be, I think, actually quite scary. So I want to think about that. And our nature and our needs are definitely multitudes. The second one, it's from Greek philosopher Heraclitus, who says, no man ever stepped into the same river twice. For it is not the same river, and he's not the same man. And so we change all the time. Our identity system will change. Some of the identity only lasts for seconds, even milliseconds.
So depending on the longevity of the identity you are doing, all the evaluation and everything is different. And maybe we can say, oh, I'm going to create a permanent, you know, forever lasting identity. That's going to be very costly and also very dangerous because you'll be keeping track of lots and lots of data, too. So I just want to say that in time domain, these things will change, right? So but that being all being said, we still need to communicate, and that's the end goal. How do we get the maximum communication possible with the level of trust that you may need in that moment?
So my last quote is really about a language. What we need is a language to really for different people with different IDs to talk to each other. If we have that protocol and all the ID system, we'll actually be better off. And that's maybe the most critical thing we can build. And so the last quote is from Ludwig Wittgenstein, which says, he's my favorite philosopher.
He said, the limit of my language means the limits of my world. So we want to reach everywhere. We need to know a lot of languages. We can't try to force people to speak one single language. And so we need some kind of a meta-language, maybe something like a gesture that we can say hi and be able to know each other before we pull out our passport and try to verify, right? And so that's the spirit of this trust-spanning protocol. And if you go to the next slide, on this deck is a Layer 2. We think that will be the spanning part.
Before I present the passport, I need a language to get to a level that you and me recognize each other. And then you ask the question, can you show me your passport? And then we can continue, right? So you need a language to start with from whatever credential you may be required for the conversation you're going to have. And I think that will be the critical core. If we have that language, then all of a sudden, the design space for IDs, which we call Layer 1, the trust support systems.
So the Layer 1, you can have identified very, very strong for international travel, for taxpaying, for banking, et cetera. But you can also have very casual, very easy, short-living identifiers that you create one and sort away right away, right? So all those become possible. And it becomes possible for these diverse identifiers to reach some level of minimum requirement that we can then live with and then build a possibility for the conversation that's going to follow. And so really the key thing people can ask is, what are those minimum requirements? And so we identify three of them.
And that's been built into Trust Spanning Protocol. I wouldn't go too much into detail, but there is a draft specification on the standard. And there's also a draft implementation that lives in Open Wallet Foundation, which is called TSP. So if you want to really get into code, that's also available. It's written in Rust. And you are welcome to also contribute or join that effort too. So what are the basic things we need to do in order for the first level of trust to have for other conversation, more interesting one, to happen? And we identify number one is so-called authenticity.
Authenticity is very abstract term to say, well, there's a unique identity or unique thing here. Allow, you know, it's like me going to a border. The officer see me, I see him, and that is the authenticity. We already established that. You don't need to know who exactly I am, not yet. But that's the authenticity you will create. The second one is then depending on your situation, we may not want this particular conversation to be public. So that's confidentiality. People know a lot about that.
We can use, you know, public keys to encrypt, to keep the conversation actually confidential between the parties involved. And that is optional. Some conversations don't need to be, you know, confidential.
So that, you know, for a lot of them, we do one. And so that is an optional feature that will be our second. The third one is harder to explain, but we call metadata privacy, which is really the fact of the knowledge that this conversation ever happened. So you can think of it like a room. You want to not only keep the, you know, discussion private, but also that the discussion happened between so-and-so. So those metadata information also private. And that's even more optional.
For some conversation, that may be necessary, especially for people who are concerned about their conversation being tracked, for example, on the Internet. So we have a lot of bad cases where those tracking can happen. And so that will be another potential optional feature that we can have in order to do this. And we do that by introducing concepts like intermediaries, support systems, et cetera, that go into how to make this much more scalable into the scale we're talking about in billions of nodes and, you know, really planetary scale for these systems.
I think that will be a key introduction of what TSP is, what we're trying to do. It's trying to do the minimum. And if you think about all the, you know, things you really care about, that sits on the IA layer. And that's why the bigger picture is showing the rest of the things. But I would really encourage you to think about, like, as a philosophical design for the system to last long and be flexible and be able to evolve as real applications happen. What do we really want to do? We don't want to link the whole thing up. If you build a, like, skyscraper, it's really hard to change.
But if you build, you know, in layers, you are more flexible. And this system can last longer. These are very expensive systems to build. So we want to make sure that it can adapt to future needs.
Thank you, Wenjing. And I'm just going to back up and ask you one last question here, Wenjing. It's a yes or no. So if we go back to this. Yeah.
Layer two, what we call, is our trespadding layer. And a lot of what's being talked about in a lot of the sessions here this week is really at layer three, at the trespass, all the other stuff we talk about, credential exchange, et cetera. So in the trespadding protocol, you could use various, what we term VID, which is a verifiable identifier. There are multiple types of verifiable identifiers. You've heard about a lot of them, everything from DID to, you know, I'm not going to name them all here. But you could use any of them at the exchange layer and still use the trespadding protocol.
That's the way it's been designed. Am I accurate? Exactly.
We, even higher level, we hear quite a bit about centralized identifiers, federated, decentralized, which one's better, et cetera. I would say you will find one is better for, you know, you will find applications that one particular one is better for it anyway. So there's no one answer. And we shouldn't be seeking one answer. I think we can be inventing even more varieties of these identifiers. And the protocol is designed so that there is a introduction or exchange we call appraisal capability within the protocol, allow you to ascertain where that trust level of signal or information is there.
And so that verification step allows you to have a meta protocol in a way that actually, you know, determines how much trust information you really need and can you verify it and then decide to go to the next step. Again, it's very similar to we, you know, shake hands first and then before we pull out our business cards, right?
And so, but this allows you to get to the next step. Thank you very much, Wenjing. And so going back to this where there are then trust tax, and there's a myriad of them. This is just some examples. But one of the things in generating trust that we would need is trust registries, because each ecosystem you are going to be dealing with that ecosystem's trust list, trust registry, whatever. And so we created a trust registry protocol.
Dorman, would you like to just very briefly talk about the trust registry protocol? And then we're going to get to the people who are actually using all of this to see how it is being used in the real world. Right. So in the four-layer stack, we consider one of the supporting systems as a trust registry. And you notice it's different than verifiable data registry. The verifiable data registry is what the two parties connecting a layer to would each check the other verifiable data registry for usually obtaining the public key and or endpoint they're going to be dealing with.
And then assessing is that a strong enough cryptographic trust for what I need. Right. So blockchains, it basically all did methods or vid methods, vid types we call them, would use verifiable data registry of some kind. Some might be blockchain based. They may be wallet based. They may be X509. But it doesn't matter. Right. That's the whole idea is whatever it is.
Now, the purpose of the trust registry is when you move up to the higher layer, the classic example is, okay, now you're going to present me with a verifiable credential. And it's from an issuer who could have any one of those dids or vids behind that and signing it. I can verify the signature just using the cryptography. How do I know if they are authorized in that ecosystem to issue that credential? Right. We ran into this program. We started the work on the trust registry task force when we were faced with COVID credentials and making them interoperable worldwide.
That's actually where I first met Marie when she was coming to that problem from then IBM. So and we said, look, it's, you know, it might seem a little abstract to need a trust spanning protocol. But when we get to how are we going to have a worldwide network of COVID credential issuer and verifier registries, it was obvious we needed a protocol. And it needed to be as simple and standard as possible. So it's one example of the trust task protocols that you would see at layer three. You saw many others examples. But that one is the other one that we've leaned into.
And that's also an implementer's draft now. So both of those are being implemented and being put to work.
Oh, that's right. There's this diagram. So the co-chair of that task force, Darrell O'Donnell, unfortunately had to fly home today. But it's a good example of if you're out there as an ecosystem and you need to talk and discover what other systems can you, the trust registry protocol, you see at that top layer, could be used to talk to any of these systems.
Now, if you have a native system that's designed directly for that protocol, that's this example here. You want to talk to an open ID federation, that's this example here. You want to talk to some other trust establishment bridge like the U.S. Federal Bridge, that's this example here. Or you can bridge to other protocols such as TRAIN or EU's trusted list. The goal of the TRP is doesn't matter. Let's make it as interoperable, for instance, as a DNS protocol for the web. So I think that covers that one. I think that was good.
And the main point is, as I talked to the ‑‑ I think it should be called the trust registries protocol. But what Darrell, the chair, said to me is, well, it's a trust registry protocol because you could make your own ecosystem's trust registry using this protocol. But I think the secret sauce of it is then the ability through API to connect to whatever the other jurisdictions protocol or trust list is to be able to make the trust decision between trust registries. So let's talk to somebody who's actually been doing stuff in the world using some of our protocols.
And we're not mentioning them all here. We didn't talk about the Cary stack or anything like that. But we have Christoph. And can you share about how Glive has used the TOIP meta model to create your governance framework and for the VLAI ecosystem and how that all ties to what we're talking about here?
Thank you, Judith. Yes, very happy to do that. So perhaps you can bring up the Glive slide already.
Basically, Glive used the Trust over IP ecosystem governance framework meta model, a very long term, as a blueprint for the VLAI ecosystem governance framework, short VLAI EGF. And the VLAI EGF basically defines the operations model for the VLAI ecosystem and things like how are the organizations that we call qualified VLAI issuers qualified by Glive and which roles do they play in the VLAI ecosystem to make all that happen, that needs to happen. The VLAI EGF has been created in full accordance to the Trust over IP ecosystem governance framework meta model.
And that results into a set of more than 20 documents that make up the VLAI ecosystem governance framework. And it contains, for example, credential definitions such as our role credentials, as you can see here on the slide, where it is laid out that the role credentials contain the organization represented by the legal entity identifier, the person by their person identity, usually their name.
And then, of course, the role that they have in the context of their organization, because we're not talking about natural persons here in the context of the VLAI, but about persons and roles with the organizations. Unless I missed some important news, I believe the VLAI ecosystem governance framework is still the most comprehensive implementation of the Trust over IP meta model.
And for those of you who have seen my presentation on Wednesday in the big room, where I talked about the European Business Banking Authority and their pilot project that they're currently doing with us, they had hired Gartner Consulting actually to review the EGF and we received very positive feedback from this organization. Yeah, the VLAI ecosystem governance framework is based on the very strong governance of the global LEI system. And that means that GLEIF is not only organizationally, but also technically the root of Trust.
And you can see that here at the Trust chain that we have in the VLAI with GLEIF being at the top. And all of these credentials, for example, we have here these role credentials. This is persons representing organizations can not only be verified themselves and whether they have been revoked, but through the whole Trust chain. And that is what makes the VLAI system so unique. Next to the rules that are laid out in the VLAI ecosystem governance framework, we also enforce technically a lot of these rules by the VLAI software development kit that we offer to our VLAI issuers.
So that we can also ensure that the governance is actually followed. So what we found very helpful, and I think Carla specifically, that the Trust over IP stacks help focusing on specific aspects of a ecosystem governance framework. And you can just use other existing ones like the Trust Spanning Protocol that we just have heard about. And we did that. And I thought a very good comparison is that the IP addresses and the internet is basically, I believe, a very good comparison to what the Trust Spanning Protocol is to the Trust over IP ecosystem governance framework meta model.
And if you look at the Trust over IP technical architecture specification, you will see that there are 18 requirements in total for this Layer 2 Trust Spanning Protocol. And 7 out of these 18 are actually about identifiers. And in short, what Trust over IP requires for identifiers is verifiable identifiers. And then there's, of course, different categorizations. So within verifiable identifiers, you have centralized identifiers and decentralized identifiers. And then again, within decentralized identifiers, you have non-autonomous and autonomous identifiers.
And for those who are not familiar with these terms, autonomous identifiers are those that are cryptographically bound to the key pairs of the identifier. So you need no other mechanism to look up whether this identifier really relates to a private key that has made a signature, for example. And at LIFE, as we have selected Cary and ACDC as the foundational technologies for the VLEI, we have chosen such an AID, an Autonomic Identifier in this case, which is the strongest class of identifiers that are covered by the Trust over IP model.
And yeah, if you would like to learn more about this, I think Judith is the perfect partner to ask for. And that's it from my side. Thank you very much, Christoph. So I'm just going to step back one slide here that we kind of skipped over. So we talked about governance and the governance here, you can see the whole cycle.
One is, you know, defining the requirements at the very beginning. And what our Governance Task Force has done is created all these tools that you, as consultants, as organizations, as somebody putting together a trust ecosystem, can utilize. These are all available on our – this is just straight from our deliverable page. So you can pick those, use the templates, use the guides as a way of forming your governance framework. And so I'm actually now going to invite Carla up. Carla is the person who used our meta model to create the governance framework for LIFE to manage all of this.
And Carla, I'm actually going to kind of harken back a little bit to what Drummond was talking about with trust registries. Could you link into not only how the meta model works and how many documents and what you've done, but more importantly, how does it link to the other things we've developed, like the trust registry protocol?
Thank you, Judith. It's nice to be able to bring this all together because what LIFE is trying to offer is a solution for organizational identity, as Christoph has reviewed. And before we can do this, cryptographically binding a person in their role to their organization, we first have to verify that the organization actually exists. We have to verify that when the organization presents its credential, that it's linking back to a real-world identifier. And so when Judith asked me the question about trust registries at this particular point, the trust registry is not a trust registry of VLEIs.
It's a trust registry of LEIs. And so we're talking about the global LEI system as something that was created a number of years ago that ended up presenting the perfect opportunity in order to be able to leverage these codes and reference data in a repository by linking them with the verifiable ACDC credentials, and then to remind what Christoph started with in that corner up there. LIFE has placed itself as the root of trust for the VLEI system, but the first thing that one needs to verify is that you got your five minutes. Yes? I don't know. He just went like this.
So the first thing that one needs to verify is that the LEI is actually belonging to that organization, that that organization actually owns that identifier that the verifiable credential is pointing to. So we have that first level of verification in the LEI system, which is the trust registry that we go back to.
Then we can combine these data points, the legal entity identifier, the person's identity, and the role that they play, and then cryptographically bind the person and then be able to verify them, all the way up and down the chain, all the way up to the global LEI system, and LIFE is the root of trust. So that's a very, very good way of being able to bring some of these concepts together and how we combine in order to be able to use the tools. Tackling the entire VLEI ecosystem governance framework was quite a task, I have to say. We had a lot of the governance already foundationally in GLIFE.
We're under regulatory oversight. There is validation that's involved in being able to get an LEI in the first place. We extended that, as we've just spoken about, by using the LEI as a core foundational element in the VLEIs that we then designed the ecosystem around.
So we've got our business rules, governance rules, the entire set of documentation that we sign with a qualified VLEI issuer, including the specific requirements in order to be able to become a qualified VLEI issuer, the kind of program that they go through and they need to pass, both operationally and technically, as part of the ecosystem governance framework. And then a large part that Christoph referred to before. So each one of the VLEI credentials that we designed that is tied to the autonomic identifier that GLIFE established, the root of trust, each one has its separate framework.
So the one for the qualified VLEI issuers, they also get an autonomic identifier, an external identifier that can be delegated. And they also get a credential from GLIFE when they pass the program. And this starts the chain of credentials. So GLIFE at the top, the qualified VLEI issuer, they sign up clients who are owners of legal entity identifiers. They get almost a root credential, if I could call it that, starting with just its LEI inside. And this is the first one that we just talked about that can be verified, all the way back to the Global LEI Trust Registry.
And then the organizations decide how they're going to put together their collection, their issuance, who they're going to authorize in order to have VLEIs. We involve our qualified VLEI issuers in issuing VLEIs to officers. And we can involve either the qualified VLEI issuers or the legal entities themselves can decide to issue more functional credentials that also fulfill this role here.
And each one of the documents in the ecosystem governance framework describes the rules of the various roles and the procedures that need to be gone through before somebody becomes eligible in order to be able to get a VLEI. The other thing that we've done is we've built some very, very strong governance into the issuance and revocation process. We actually use a credential that gets inserted into that chain so that the legal entity itself's authorization instructions to issue and revoke are also part of that chain as well.
And some of these ideas came just from taking a quick look more closely at governance and how to be able to strengthen it with the VLEI system. Thank you, Carla.
Carla, I'm going to ask you for a one-number answer. Okay. How many documents are in the governance framework for the framework? Twenty-four. Twenty-four documents. So when we talk about governance and why Trusted by People thought the governance side of everything was so important, developing that takes as long as the technology, and it's something that you really need to be discussing in each ecosystem or use case that you're working about.
And so I'm going to kind of turn it a little bit when we have Andre talk here because being here in the EU and working with the digital identity wallet ARF, they have specified certain protocols in certain cases like OpenID for verifiable credentials. How do you see the evolving emergence of a stack like this that actually allows for multiple protocols affecting that?
Yeah, maybe let's start a little bit behind that. So maybe I would like to warm up after the lunch break a bit more. So who of you is using trust registries every day? Who of you is using a smartphone every day? So should I ask the first question again? All right. So this is not just a theoretical framework, right? So this is like real-world stuff, and this is in our daily realities today. So what we have done at Trust over IP is make a model that you can make it approachable to your customers, to your clients, to governments, to anyone who you want to talk about this to.
And this is exactly what we are doing also with our customers who are interested in getting into digital trust ecosystems. So make that digestible for them to understand what it actually is they are entering. And Trust over IP is an extremely great model with the trust model canvas, as we now call it. And I love that term because I always loved the business model canvas, so trust model canvas is a brilliant term for that. To discuss with your clients how you want to model your use case.
And it keeps on reminding you on every single bits and piece that you want to discuss with them to get to a solution that is workable, particularly in the jurisdiction you are trying to achieve it. So if you want to be EIDAS compatible and compliant in the end, so whatever that means with the 2.0 version coming out, you have to consider what the mandatory steps are you have to include in your modeling. And this is actually what you have to do with a framework that is easily digestible like the Trust over IP trust model canvas. EIDAS regulation is a very complex thing.
Those of you who have read it, you know it's not just the regulation itself. It's the EU ARF, which is like a pre-spec of an ETSI standard. So it's tons of different things. So if you want to discuss it with your client, you can go through all the different layers and tell them, look, this is what it looks like in EIDAS. So what we have done with our customers is in every single use case we implement, we go through that model. We ask them, what is the partners, the stakeholders you are talking with, and what is it they are interacting with in your world?
So let me give you an example we have presented here at the conference. We work with a global construction company, and they have implemented a use case very specific to that industry. So we ask them, okay, what are the stakeholders you are talking to? They are collaborating on construction sites with dozens of different organizations. So you want to identify these organizations and establish a trust relationship between them. So you have to ask how you get the trust spending between them, and what are the identifiers you are actually using? Are you using certificates from the BKR world?
Are you using extended validation certificates to ensure the endpoint? Or are you using DIDs to basically establish something like a DITCOM connection? These are all the questions you want to discuss and ask in modeling such an ecosystem. And we have implemented these solutions going through that. And this is not only in the creation phase of the ecosystem that we use it, but also when we write up the governance framework as Carla and Christoph have so vividly laid out.
This is a work that is worthwhile because you can prove that you have considered every aspect of the trust ecosystem and have solved it. And if you want to discuss with regulators or other interested parties or other customers, you can basically tell them, look, we have written it all up. And if you want to have the details, you can go along this model and understand what we have considered and come to the conclusions. And this is not a single thing. And I think this is what's also very relevant to understand. If you see this model, this is like a plan, do, check, act thing.
So this is changing over time. So regulation changes over time. Technologies change over time. So you want to do a true up every time something new comes up. And you want to take into account if this is relevant for you. So let's say at some point the IDA 3 comes around the corner. You want to be ready to discuss and see what the changes are. You have to apply it to your ecosystem governance framework. So I want to just close with the urge to not see this as a theoretical construct. This is very relevant.
If you want to create a use case that you want to have rolled out through the world, you better do your homework and go all through the layers and the bits and pieces and write it up. And be ready to challenge your decisions as you move along. And this is a brilliant model. And I hope you like to use it as we do.
And, yeah, so if you want to learn more, come to Trust OIP. We're always happy to encounter new members. But as you know, it's open source. You can look at it. But hopefully you come to us and help us drive it further. Thank you.
Thank you, Andrei. And now I'm going to invite up somebody who was one of our original founders of the Trust over IP Foundation. Accenture has supported to your IP all along the way. And they are kind of leading the way in a lot of ways with actual multiple ecosystems. The term that I always hear Marie say is minimum viable ecosystem.
And so, Marie, I'd like to invite you up. You know, you could give an hour-long presentation on this. But if we can keep it to, like, five minutes so that you talk about ecosystems of ecosystems. I want to give the audience some time left over to ask a few questions. Can you tell us why this is all so important? Absolutely. So people often ask us, why did IBM get involved? I used to work with IBM, which is also a founding member, Accenture. Why was Accenture involved in this? And it's not because we're a charity and it's not because we love. But we do believe in the open source.
We fundamentally do. But also we're a company and we see a huge business opportunity. So I was talking earlier on and I talked about that this is a trillion dollar opportunity. And I think I'm being conservative. And why do I think it's a trillion dollar opportunity? In Accenture, we spend our entire days and nights, weekends often, helping our clients reimagine the world, reimagine their businesses. The world is challenging for businesses at the moment.
You know, they have to save money. You know, AI is coming along.
You know, job security isn't there anymore. There's just so many challenges for companies. And all of our clients are asking us to help them figure out how can they weather the storm? How can they be more efficient? How can they look at new business models? How can they bring new offerings to clients? How can they minimize their risk? And one thing that has become fairly evident, and I think it was Drummond that said this to me at one stage and I always use it, is we live in a decentralized world.
You know, we all walk around the world. We live in a decentralized world. A decentralized world needs a decentralized infrastructure. So when we start to look at complex use cases with our clients, we do absolutely talk about minimal viable ecosystem. And minimal viable ecosystem can initially be two companies. So you can argue with two companies, you don't need a lot of this infrastructure. But the reality is, is when you think about very small, simple use cases, and they're super important, you want to start simple, that gives you incremental value.
But what we find, as we look to generate more and more value, you start to grow out the participants. And this is what's the power of decentralized identity, a decentralized data economy. The ability to allow you to very, very flexibly grow the entities that interact with each other for a specific business process. And this is exactly the reason why I stand on the shoulders of giants, because I can't take credit for any of this really cool stuff. What I absolutely do do, though, is I use this all the time.
And I find that this is what's going to enable us to weather the major changes that are happening as our world becomes more digital, as it becomes more data-driven. Because what this allows us to do is start to completely reimagine the value of data, the value of identity. And specifically, we work a lot when we talk about the interaction between ecosystems. So we talk about the acceptance. And very often what happens, I see, is we have one ecosystem looking to address a very specific use case.
So earlier today, I was in a panel with a guy doing amazing stuff around supply chain in the pharma space. And that's a brilliant use case, and there's huge value for that. We also have another ecosystem that's doing stuff around consumers or it's doing stuff around health care. That specific supply chain use case is looking at verifiable drugs, as an example. But that's also a use case that's very interesting.
We did a lot of work around things like if somebody's taking a vaccine, if there's a negative reaction, how do we actually start to capture information from individuals about reactions they may or may not be having to drugs. That's a really good example of if you can actually now take this ecosystem over here, this use case, and you can start to translate it. You can start to exchange data between that ecosystem and another ecosystem. Now all of a sudden, you completely change the value proposition. And what I always talk about is the utility of data.
You start to completely transform the utility of data, both for the individual and for the organization.
So what I guess I would say before I wrap up is even if you are looking at simple use cases and even if you are looking at just a handful of entities that you can maybe manage this in a very simplistic way, recognize that I absolutely guarantee that while what you're doing will give incremental value to your clients, there's no question, but there's an exponential value opportunity there if you start to just look and explore in the future, maybe two years from now, maybe three years from now.
And this is when this type of stuff is going to be absolutely fundamental to realizing the type of value that we all expect and hope, and to enable us all to start to realize this trillion-dollar opportunity that we see just bubbling away waiting to be leveraged. Thank you. Thank you. And so what we want to do now is open it up to any questions. But before I do that, I just want to let you know, if any of this sounded complicated to you, on the front chair up here, I made a sheet that anybody can come and get with QR codes.
So if you want to learn about a specific thing, it takes you right to the blog about that where you can get to the GitHub repos, et cetera. Also, because we are trying to get all the digital credentials into the phone, but right now it's still not there. Do you have your phone there, Carla? Can you hold up your phone? What she has on the back is this with all the cards because they're not all in the phone yet. So if you need a place to put your cards and tell the credentials are inside, I've got a few of those sitting up there for you as well.
So I don't see the Kippinger-Cole moderator here, so I have to just apologize to anybody who's put questions in online. I don't have the device to read those, so I will just open it up to the room. Are there any questions for the panel? In the back here. So I like Cary. I think it's very interesting, but I find that I only hear about it in very narrow spaces so far.
Here, IIW, things like that. What's your view on sort of getting that more widely adopted? And even in the event that weren't to happen too widely, say in the European Union, for example, how does it interact with people who choose not to use it? So there's kind of a two-part question there. He's talking about a protocol that we did not talk about today in this meeting, which is the Cary suite of protocols, which is actually three different protocols. You can find the QR codes to learn more about them on here. But what I will say about that is you say it's not widely adopted yet.
It's just a public review at this point, and that was just launched in March. They jumped on early on and have been a part of the development of it, so Glyve is utilizing it today. There are other startups, several of them in stealth mode, using it today that we can't speak to. But do you want to speak to that a little bit as well?
Yeah, just two additional points on that. So it's true it's not very broadly adopted yet, but one of the important reasons why we chose it is the interoperability to be able to actually connect to other systems and not creating a siloed system or a lock-in effect that we had seen with other protocols that we had looked at before. And I believe it's always the question what you need. So I talked briefly about the different verifiable identifiers that are defined in the trust over IP stack, and we decided for autonomic identifiers because we believe we have a very high requirement for security.
And if that is not the case with what you do, then that's just that. But we want to be interoperable, and we can only recommend reviewing the requirements that you have for your use case.
Wenjing, did you want to add on to that? Yeah, I want two points to add to it.
One, of course, if you think about TSP or the trust spending protocol, one type of potential IDs will be the AIDs in phone carry, so that is one. But that's only one. You can use many other different IDs. We also have several new identifiers being developed right now. I will give at least two examples. One is called DitTrustedWeb. The other one is called DitWebS. Both of them take some part of a carry people really like and trying to simplify or make it more compatible to web technology as it exists today.
And so those are different variations of IDs potentially can all be interoperable within trust spending protocol. Other questions? So I want to apologize to the people online. If you put in questions, okay, good. I don't have a way to see them. So I would like to thank our panel for being here. But more importantly than thanking the panel, I know you're all important, I would like to thank all of you. There's been more than 45 people here today on the Friday after lunch.
And so you guys are the ones that really should be thanked for being here, being interested, educating yourselves, and moving everything that needs to happen for humanity forward. So I'm thanking you. And I am going to ask Drummond one last question. Okay. Yeah. What is the call to action for these people? We'd like all of you to go straight home and start implementing trust spending protocol.
No, seriously, if you do one thing, I would, again, pop over to the Trust R&P site. You can get the straight QR code. But take a look and read through.
Again, I want to compliment John. The fine work on what we're now calling the Trust R&P Trust Canvas. And start thinking about how you can use it with your project. It doesn't matter if you're on the technical side and you want to look at, all right, do I have everything covered top to bottom on the stack, or you're on the governance side, or you're both. It's about the whole thing. And then tell us about it. Tell us about it at Trust R&P. It's all about the feedback. It's been four years to get to this point.
And it will probably be four years more we'll be telling about this until we've got a world of interoperable digital trust ecosystems, at which point we'll have to have another conference. So thank you, everybody.
Yes, like he said, the Trust Canvas that we use, we just call it the Trust Canvas, slang like a business canvas, is available on our website. It's under this place that says model. And so you can use that in explaining things to people. But also at the bottom of that page, there is an interactive model for how decentralized trust works. And I think we chose the airline industry or something anyway. You can click and see how different things work. So thank you, and have a good rest of your conference. I know there's some more sessions, and then there's some more keynotes.
And have a safe journey home.
