Listen to this Episode about ToIP 101 on Spotify

Introduction & Digital Trust Challenges

Mathieu: I wanted to start the conversation today, John, by making the statement that achieving digital trust is difficult. Some background to this, and showing in trends overall, is that businesses, governments, and organizations, are adopting digital mediums to interact with their customers, their employees, their vendors, and their citizens. Everyone’s on a digital transformation journey today. Secondly, people are demanding more privacy in all their activities nowadays, and I think we’re seeing the best signals for this coming from the largest companies in the world. Apple is a very good example of this; they’re using privacy as a feature inside of their marketing, but they’re implementing capabilities inside of their operating system and their ecosystem to really push user-centric consent and privacy. At the same time, the laws around privacy are changing rapidly, and everyone’s trying to adapt to these. That brings us around again to the statement I started off with; achieving digital trust is difficult. I think people realize it’s tough to achieve today, and there is a great deal of fraudulent behaviour and other issues that seem to get in the way of people conducting businesses online.

This takes us to where we are today, in the internet era where there is a trust gap. To illustrate my comment about fraudulent behaviour; a very straightforward example of this that occurs frequently is phishing attacks that happen online. It’s quite easy for someone to gain access to my email address, which is a central point for me to interact with all sorts of different organizations. It’s very easy for someone who gains access to that to reset my passwords for various accounts that I have all over the place. Once they’ve reset my password, then they are able to take over my account. This happens every day, because it’s very easy for people to impersonate other people on the internet. That’s one side of it, and then there’s another side; there are just tons of things that aren’t possible to do on the internet today at all. When we start talking about more high-value, high-risk transactions, these are situations that are the most challenging. Most of the value that’s generated out of the internet today comes from advertising or e-commerce, but high-value high-risk transactions still rely on this real-world or paper credential era. As we’re looking to move from the current internet era towards this new era of digital trust, I think it would be helpful if you were able to give an overview of how we got here. Perhaps we can take a step back, before the internet era, and discuss the paper credential era — I think that sets a good framework for where we’re going with these new digital trust models.

John: Sure. Thanks for that introduction, Mathieu; it’s good to be here. That’s a lot of material to work with there, so I’ll give it a crack.

First, we’re talking about digital trust and trust in general. That’s a very high-level idea, so let’s break that down a little bit. When we talk about trust, generally speaking, we’re going to focus on a relationship between two parties. For example, perhaps between me and another individual like you; or between me and a business that I’m going to do something with, or a business to a business. My full-time job is with the province of British Columbia, and there’s a trust model between the government and its citizens. In all of these cases, I’m talking about a relationship between two parties. The determination of trust is a combination of things; do I have some type of method of conveying trust between those two parties in the context of a transaction, and do I have an understanding of why I would trust that other party?

In the case of a business to a business transaction, we tend to develop relationships through human interaction. We find each other’s business, we’re going to become a supplier or a customer, and then we tend to have a mechanism by which we formalize that relationship. We call it a contract, and contracts are everywhere. That’s one of the key mechanisms we have in society for establishing a formal relationship, and defining the boundaries of that relationship. If somebody goes outside of those boundaries, it’s governed by the contract. And, what is the contract governed by? Well, it’s governed by law, that has been set forth by a democratically elected society, in our case. Those laws set out the boundaries for what can happen between businesses, between people and businesses, and between governments and people, and governments and businesses. That is the nature of our society right now.

Essentially, personal identity is given to you by the government in a lot of ways; that is, in an administrative sense, and not your philosophical sense of being, and who you are. Rather, the fact that you can say that your name is John Jordan, and your age and so forth; those attributes or characteristics of you are attested to by the government, based on an administrative process of registration and their authority to manage that. In the same way for businesses, we have business registries, and they have a process for creating legal entities. It is these sources of truth, or these administrative authorities, which allow us to enter into contracts. We know who that party is, and we have physical evidence of this through an identity document, such as the BC services card, which we commonly call a driver’s license. Or, contracts such as the legal contracts that are drawn up and can be referenced, like articles of incorporation and so forth.

Back before these things we call computers were around, it was difficult to create or recreate these documents, because printing presses were big and expensive, and there were techniques that could be deployed by them to prevent fraudulent copies of these things. Because things happened at paper speed, the risks were relatively low in terms of the wide-scale ability to defraud.

So, that’s in a way the foundation of our society: we have Acts; those Acts create powers in the government to identify persons, including humans and legal entities, and the rules by which those entities can interact. We formalize those rules and contracts, and that’s how the world effectively operates, in a lot of ways. However, now in the era of the web, we don’t have a way to convey that architecture into the web. In turn, the web has introduced a new actor, that we don’t have an equivalent for in the physical world. On the web, we have this idea of ‘login’; there’s an intermediary between me and another person, or between me and the business I’m trying to do something with, and so forth. This intermediary has no defined role in any of our legal structures; there’s no such thing as ‘the login service’ in the Business Corporations Act of British Columbia. Likewise, in the Freedom of Information and Personal Protection Act, there’s no concept of ‘login’; there are only ‘persons.’ Because we have this login service, there’s a sort of ‘middle person’ in between our relationships, which has some very significant consequences.

One of the consequences is that it means that none of my relationships online are confidential: meaning that they’re not known only between me and the party I’m trying to interact with. If I go to the gym, or I go to rent a car, or I go to the doctor or the lawyer or whatever, that interaction that happens is private. It’s not known, generally speaking, by any other entity, including the government. If all of my relationships were known, then we would be very unhappy — we call that surveillance, and that would be an erosion of our privacy.

As a result, we don’t even have the conditions on the web for privacy. By the very architectural structure of it, there must be a login service in order for me to connect to another party. By definition, that means it’s not confidential. Often, the information or data that I exchange with that other party is subject to loss; that other party I’m talking to gathers a lot of information about me, and if they don’t protect it well, it can be stolen. Then, the really bad side effect occurs, which is that personal information that has been stolen about me can be replayed. It can be used by a malicious third party that has gained access to it through possibly poor stewardship of it by the business that I did business with, or worse; they sell it. A bad actor can replay that information and pretend to be me, and we call that identity theft. I think I’ve outlined here the two big, unforeseen consequences of the login architecture of the web, which is that a) none of my relationships are confidential and b) the data that is exchanged through that non-confidential interaction can be lost and replayed without my permission and knowledge, and therefore I can be impersonated.

I don’t know if I covered all of your domains, but to me, these are the fundamental flaws. It’s not as if that concern was foreseen 20 or 30 years ago; it was simply the way we built computer systems. Computer systems were expensive, and we needed a way to share them. The way to share them was to provide access to that computer system, which we accomplished through a new ceremony or ritual called login. To use a funny word, there’s no analogue of that digital ritual in the physical analog world. So, this is where we find ourselves, in a difficult situation.

Mathieu: There’s so much to unpack there. I love the focus on relationships over and over again between two parties. When you think about login being this new party that shows up in the middle there; at the end of the day, there’s a reason why it showed up — to try to make things more secure or make it actually happen. However, they inherently ended up removing value from the system altogether. It seems as if there’s a back and forth in technologies, where things go from distributed, to centralized, to back to distributed. It feels as though in the real world, or in the paper credential era, it’s really a distributed way of doing things. There’s nothing centrally stored: everyone has their credential or their ID, and they use it how they wish, with the relationships that they interact with. Whereas, in this internet era, you lost that direct connection or direct relationship with the entities that you were interfacing with.

The Credential Trust Triangle & The Role of Trust over IP

Mathieu: People are always curious about this when they’re looking to move into this next phase — let’s call it the digital trust phase. They play inside of the model, and the model has been represented in different ways. The one that’s gotten the most traction, is this Credential Trust Triangle. There’s another model which looks like a diamond, so I could call it the Credentialed Trust Diamond, which is otherwise known as the Government’s Trust Triangle. Is that type of model similar to the model that existed in the paper credential era? How is this model being replicated or ingested into this new digital trust era?

John: I discovered the Trust Triangle, as we call it, in around 2017. As we started to understand it, we said, “But, this is how we do things already in the real world.” Sometimes, I talk about, “Let’s just forget this really awful nightmare of the last 40 years of computing and remember how we did it back in the old days, when we developed relationships with our friends, our business partners and so forth, and we had the underpinning of the government.” You know, the government is there; we don’t always know it or acknowledge it, but I described how the government underpins the ability for us to establish these trusted relationships. We can go back to that now.

When we talk about the trust triangle, we use this jargon called “Issuers, Holders, and Verifiers,” and that exactly maps to the world that we have today. We often play those roles at different times and in various interactions. To give an example: let’s use the business registries because I’ve been doing a lot of work with BC Registries over the years. Originally, we would say that BC Registries is going to be a Verifier. It’s going to take on the Verifier role; you’re going to show up at BC Registry’s door, and you’re going to say, “I’d like to incorporate a business.” They say, “Great, tell me some things about yourself, so that I can understand who I’m doing business or working with. And then, what is it you want to do?”

They’re verifying this information. They have a business process to approve it, and when they approve it, they become an Issuer. What they issue to you, are your Articles of Incorporation and perhaps other documents (I don’t dive into the super gory details of the corporation). The ultimate expression of your successful administrative act of creating a corporation is your Articles of Incorporation. You would take those Articles of Incorporation; you might go down to the bank and open a bank account with them, using proof of your identity, proof of your Articles of Incorporation, and proof of you being an officer in that company. At that point, the bank has been acting as a Verifier, and then they issued you a bank account. All the while, you as the individual, and you as the individual representing the corporation, are what’s called the Holder.

So, the Holder is the person or entity that receives things from Issuers, and presents them to Verifiers. This is extremely common. As soon as you put the jargon aside, you realize that this is exactly what happens in any trusted interaction — all of them. The fact that you play all three roles; it depends on where you are in a particular process what role you might be playing. You might not always play all three, but you’re likely going to play a couple of them. That’s the way we’ve always organized things, and it has simply taken a while for the computing world to come to a place where we recognized that there is a way to replicate that set of relationships using digital technology.

That’s exactly what the role of the Trust over IP Foundation is trying to do, which is to introduce a couple of things. One is to bring a little more structure to the set of technical capabilities that allow us to do this, and the second, (and this is really a key differentiator of the Trust over IP Foundation mission) is that it recognizes that there are actually two parts to trust. There’s the technical or mechanical aspect of trust, which I referred to earlier as contracts. Those are technical documents, that are highly structured and understood and recognized by law, and in the paper physical world. And then, there’s a set of governing authorities and aspects that make that contract enforceable. That’s why I talked about the Business Corporations Act — it’ll be named different things in different jurisdictions, but it’s always there. That’s exactly the legal framework, under which a contract is even valid. That’s what makes it possible to have a corporation, or a non-profit society, or different legal entities that can be recognized in a court and able to enter into agreements, and so forth and so on.

That’s the governance framework. In fact, in the digital world, it’s the same. It’s just that we have no way, digitally, of representing a contract, or an agreement, or even a relationship, in some legally recognizable way. That isn’t something that was foreseen by the technical model of the web, so yeah, that’s the mission of the Trust over IP Foundation. The uniqueness of it, is this bringing together of the business/legal aspects, combined with the technical aspects, that allow us to create the conditions for trusted digital relationships. We hope that if there’s broad adoption of this, the big vision is that if parties choose to have any contractual relationship possible, using the internet as the communications mechanism and essentially replacing the web model, then there would be no logins. Relationships will be peer-to-peer, and there would be trusted interactions between those peers. Ideally, privacy laws and other laws would recognize those interactions as equivalent to what we have today in the physical world. Contracts would be upheld, and all the correct legal terms would be able to be upheld in the court systems of your jurisdiction. It’s a big vision, but I think that’s where we want to go. I think that would be a fair representation of the goals of the members.

Mathieu: I would agree with that. Having had many interactions with several dedicated and smart members of the Trust over IP, I think that that’s everyone’s goal. The internet has done such incredible things and created so much value. But now, to take it to that next step; it’s about creating this other layer that gives us this digital trust. You’ve described perfectly the trust triangle model of the Issuer, Holder, and Verifier, where today, the Verifier in scenarios is often referred to as the ‘Relying Party.’ In that model, they’re relying on data from someone. Whereas, today, they don’t have to rely on anything specific. Whatever they’re given at the point of a transaction can be verified against its source. It can be verified that it’s reliable, that it’s authentic, and its provenance; there are transparency features with this too. All of this is made possible, and the whole model fits within the dual stack architecture that you just described. That is, the governance and the technical layers, where you have the business, the legal, and the tech, on the technical side.

To finish off this dialogue, John; right after this discussion, we’re going to have some working group leads have a conversation with us, to talk a little more about the different working groups and different layers within the dual-stack architecture. Would you mind giving listeners of the podcast, who might not be familiar with this, what are these four layers? How do they play together? And, why do they matter so much in this model?

The Role of Working Groups in the Community

John: Sure. As I mentioned, the idea of the Trust over IP model or stack is that it has two sides. One side is concerned with the technical means by which to establish trusted digital relationships. That is, peer-to-peer connections, with protocols that can work through those peer-to-peer connections. In particular, protocols that allow for what we call verifiable credentials to be issued to Holders, and for Verifiers to be able to request from Holders cryptographically protected proofs that they’re holding these credentials, and sharing the data that’s held with them under the control of the Holder.

The other side is the governance side, which says that the services and means by which these technical capabilities are offered actually have a set of rules and actors behind them, that you can inspect. You can decide if you like how they’re operated, and therefore, make a determination about their trustworthiness. The working groups are structured in similar fashions: we have working groups who are focused on the technical stack, and we have working groups concerned with the governance stack.

Essentially, the first set of working groups looked at creating a community of practice around how we create governance artifacts, and decided to have a community of practice around how we create technical artifacts. Then it was decided to have a group where we understand what it would take if we want to put these things into practice. So, we have the Governance Stack working group, and the Technology Stack working group, both of which are more concerned with creating the generalized tools, documents, standards, and so forth. And then, we have the Ecosystem Governance working group, and the Utility Governance working group. I might be messing up the names; I apologize, they’re not in front of me right now.

However, these are communities of practice, where practitioners come together and share their expertise and their experiences so that they can help others create new ones, faster and better, with less friction. We can learn from each other, and it’s been just about a year that we’ve been together. I think the real value that we have right now in Trust over IP, is this idea that there’s a community of practitioners out there who are learning together, sharing with each other, and creating outcomes. Whether it’s implementation guides, or blueprints, or other kinds of knowledge-based artifacts, they can codify how to create digital ecosystems or communities, where there’s a common set of trust interactions that they want to be able to describe to their members.

I think that is really an important part of the Trust over IP organization, and is something that’s new and different. What I’m really happy about, and what I think is going to be our area of growth, is that we are bringing people into this world who would never have been involved in the more technical communities out there. We have organizations, that are not technology-based organizations. They obviously use technology, and they recognize the importance of trusted digital relationships to their business. They want to learn more and participate in the growth of that, and they see it as a competitive advantage to their businesses, to be able to understand how to do that. I think that’s clearly the direction that we want to continue; to keep growing that community. And, more and more, helping others understand why it’s important that they have trusted digital relationships with their customers, with their citizens, and with their friends and family, for that matter.

Mathieu: I think it’s incredible to see the number of ecosystems that have been popping up over the past year. New ones that are popping up, as well as existing ecosystems, are coming into the Trust over IP for guidance on how to build with digital trust in the core of their digital transformation strategy. I think it’s been over the past year since the Trust over IP has been active; the popularity around verifiable credentials is growing like crazy. I think everyone is interested in it.

Once people get their beaks wet a little bit with verifiable credentials, they begin to be aware of all of the other activity that should be taken seriously: the governance pieces that we’re talking about at the core, and the peer-to-peer communication channels that totally disrupt the way we do things via APIs today. Once people start realizing this stuff, they begin to see the value beyond the simple economic efficiencies, or the checkbox compliance stuff that people use these tools for, today.

The last comment is that I really echo your thoughts of the community. The community is strong; it’s vibrant, and it’s growing. You and everyone else have done a fantastic job of bringing these people together. As you alluded to, it’s so interesting to see people from different areas that you would never talk to in your day-to-day life, but you’re able to learn from them. The power of these open communities, is that you could build on top of what’s happening, in order to really leverage the learnings and the failures of other projects, and build on top of that experience. I think in this digital age, or in the age of digitally native people and products, the value ultimately comes from community. Whoever has the strongest communities is going to create the strongest digital value. So, I love how the Trust over IP is set up to really push this forward. A huge thank you, John, for what you have done to move this forward. It’s incredible to see the community growing around this.

John: Well, thanks, and really it’s the members that do this, so thank you for this as one of our members. To all the other members who are working hard and well, I look forward to the next year and seeing where it goes.

Introduction to Working Group Leads

Mathieu: Hey guys, thanks for doing this. Some of you may be new to the audience listening to this, and some of you have been on existing podcasts before. What I wanted to do today with each one of you is to have you give a brief introduction on yourself; your background, what expertise you bring to the Trust over IP, and what interested you in the Trust over IP, to begin with. Let’s start with a newcomer to the podcast; I’ll throw it over to Karl; if you want to open it up, Karl?

Karl: Thanks, Mathieu. My name is Karl Kneis; I’m the COO of idRamp. Our background is in building enterprise ecosystems, solving complex identity problems, and service delivery for multinationals. Our interest in Trust over IP, particularly, was based on our experience working with corporations and business organizations solving ecosystem development problems. We find that the need for repeatable design patterns and open source standardized frameworks helps our customers save time and money. These features simplify adoption of the new technology around verifiable credentials, so Trust over IP was very much a natural fit for idRamp. We joined up as founding members, and I’ve been working on hosting the Ecosystem Foundry working group.

Mathieu: Thank you, Karl; we’ll get to the Ecosystem Foundry in a few minutes. Maybe I’ll shoot it over to someone who’s participating in another foundry working group; André Kudra. André, you’ve been on the podcast before, talking about identity and access management, and how verifiable credentials and the Trust over IP stack could be used for those use cases. I know Karl is familiar with what you guys do as well, but, André, would you mind giving a brief introduction for any newcomers, on yourself, your expertise, and what brought you to the Trust over IP?

André: Absolutely, Mathieu, thank you for the opportunity to be here again. My name is André Kudra; I’m the CIO of Esatus AG in my day job. In my night and weekend job, I fill various roles in SSI community groups. I’m a trustee of the Sovrin Foundation, and my company Esatus is a founding and steering member of Trust over IP. I am also a board member of the Teletrust IT Security Association in Germany, with more than 340 members. I try to promote Self-sovereign Identity everywhere in these groups. Since 2015, when we first ran into SSI, I saw that this is the way ahead. Last year, when the community convened to form Trust over IP as the organization that will deliver the missing trust layer in the network world, we said, “Well, we absolutely have to be part of this group, and we have to be part of the community in this new foundation, Trust over IP.” From the European perspective, since we are based in Germany, we want to bring the European angle into the works. Since the beginning, I’ve proudly been serving on the steering committee and as the co-chair of the Utility Foundry working group.

Mathieu: Thank you, André; it’s fantastic to have you back on here. Now, I’ll throw it over to Scott. Would you mind giving a brief introduction on yourself and what brought you to the Trust over IP?

Scott: Thanks, Mathieu. I’m Scott Perry; I’m an auditor in the identity and cybersecurity space, and I’ve been doing that for my whole career. I became very focused on the PKI (Public Key Infrastructure) area about 15 years ago, when I was working with the US Federal PKI. We were creating standards around how you can interoperate identity credentials in that ecosystem. I am also a licensed WebTrust Auditor and a player in that ecosystem, where you exchange secure certificates that get attached to websites. So, I have worked with several different governance authorities. I was seeking fairness by actually participating in the rules that are established between interoperable trust. I got involved in the verifiable credentials in the SSI space about five years ago, working to establish the governance framework for the Sovrin Foundation. I have architected the Trust Assurance Framework for Sovrin as well. I’m a co-chair of the Trust over IP Governance Stack working group, and it’s great to be here.

Mathieu: Thanks, Scott. Last but not least; someone who’s been on the podcast before, with quite a popular episode. Paul, a lot of people are interested in what you’re bringing to the community, but for those who don’t know you: would you mind giving a brief introduction on yourself and what brought you to the Trust over IP community?

Paul: Sure. I’m Paul Knowles; I’m the head of the Advisory Council of the Human Colossus Foundation. At the foundation, we have combined expertise in three synergistic domains; decentralized authentication, decentralized semantics, and decentralized governance. We sit at the centroid point of those domains. My background is with clinical trial data management and statistical analysis, and in that domain, they have 25 years of very rich semantic experience. At Trust over IP, when it was first developed, there wasn’t a space specifically for semantics; at Trust over IP, they work with a dual stack model of governance versus technology, which doesn’t mention semantics at all. So, I approached the leadership group and suggested, “Why don’t we set up a semantics group so that we can talk about how data can geometrically and semantically fit together?” This is something you need to do for good machine learning, and analytics, and stuff. At Trust over IP, I’m the convener of the Inputs and Semantics working group. The Input side is more about authentication, and the Semantics side is more about deterministic semantics. I’m happy to be here and looking forward to the chat.

Trust over IP – Working Groups Overview

Mathieu: Thanks, everyone.  What I’d like to do now, is jump into the day-to-day of what’s happening inside of the Trust over IP. There are tons of activities happening throughout various working groups within the Foundation. For background; when the Foundation came to be just over a year ago, there were four initial working groups that were established. There were two working groups that fell within a ‘Stack’ category and two that fell within ‘Foundry’ categories. The two that fell within the Stack category, were the Technical Stack working group and the Governance Stack working group. The two that fell within the Foundry category were the Utility Foundry working group and the Ecosystem Foundry working group.

Throughout the past year, as Paul described, he, and others, realized that there was a gap in the work that was happening. A new working group was created — the Inputs and Semantics working group — which fell inside the Stack category, as well. We’re going to go through each of these working groups to give a better idea to the audience of what’s actually happening within the Trust over IP. I think an exciting one I would like to start with is the Ecosystem Foundry working group, which sits at that top layer of the Trust over IP stack. Karl, you’re very lucky to have visibility into this and to be a chair of this working group. Could you give a bit of background of why you got into the Ecosystem Foundry within the Trust over IP? Why you took that leadership position, and how things have evolved, and what’s happening within the Ecosystem Foundry?

Karl: Well, part of my background included over 20 years of working with enterprise architecture, solution architecture, service delivery, and in that ecosystem development space. When the opportunity came up to form the Ecosystem Foundry working group, I was very eager to volunteer to chair that.

Mathieu: What happens from session to session, now? Are you seeing the rise of more ecosystems that are using the Trust over IP stack? What direction is this going in?

Karl: The Ecosystem Foundry working group is focused on acting as the ‘front door’ of that business layer of the Trust over IP stack that you saw in the introduction. As that front door, we help business organizations and consortiums incubate their governance frameworks and their ecosystems. We want those aspects to be shared as open-source, repeatable design patterns, for whatever or whoever their stakeholders may be.

We have a diverse community that is growing at a pretty regular and rapid pace. For example, we have the Yoma ecosystem that’s sponsored by UNICEF, focused on helping youth in Africa up their skills and promote themselves for employment opportunities. We have the Global Legal Identifier Foundation (GLEIF), which has been acting as a pioneer in adapting verifiable credentials as global legal identifiers. The Good Health Pass ecosystem that was recently formed as a working group within Trust over IP, is working with ID2020 in the World Health Organization to create interoperable solutions working with many different providers. I think that ecosystem alone has roughly 80 people that I’ve seen in some of those meetings, all from different organizations; medical, private consultants, government folks — very dynamic.

There’s another ecosystem sponsored by Identidad and the United Farm Workers, that’s focused on helping migrant farmers have an identity and use identity in their food distribution networks. We have education ecosystems, and the list goes on. There are so many; I couldn’t easily go through the whole list. But, at the end of the day, what we see is that businesses have a need for a standardized architecture and a standardized approach to these governance questions, that they can reproduce and repurpose to help them do business. Some of the discussion in the industry around governance is a little bit confused because governance is often perceived as a blocker or a bureaucratic inconvenience. In the Foundry working group, we can see that we’re leveraging all the great thinking that comes out of the Stack working groups to incubate and form these business models, and help accelerate adoption of this new technology. First and foremost, we’re standardizing trust across different business communities and business objectives.

Mathieu: Thanks, Karl. Scott, since you’re a co-chair or the chair of the Governance Stack working group, are the Foundry working groups’ customers’ to the work that you’re doing? How do you collaborate with the Ecosystem Foundry working group? I know this is probably the broadest question I could ask, but could you perhaps give a bit of background on what governance is in the context of digital trust?

Scott: Sure. You’re exactly right in what you’re saying, as far as the way that Karl’s group and my group interrelate. Karl’s group is out there, doing the outreach and working with a diverse group of needs in the marketplace. Karl needs standard specifications, recommendations, templates, white papers, and tools, so that he can provide that outreach for his customer base. So, that’s what the Governance Stack working group is focused on; where you start.

If you’re building a house, you have got to have a blueprint. If every builder that’s building a house has a standard set of how blueprints look — they have certain colours, certain notations, certain categories — then, when they get that blueprint, they know exactly how to build a house. Likewise, you have to start with the blueprint of what a governance framework looks like, and so we’ve spent time and energy on putting together what we call the ‘governance meta-model.’ That is, the standard set of categories and requirements that every governance framework needs to have. It also needs to have the structure so that when they become interoperable, you know exactly where to find certain pieces of information. Certain pieces of information are required in every governance framework, and it also has to have the flexibility to be able to work with a variety of different risk models associated with it. Some ecosystems are dealing with lots of requirements due to the mitigation of risks; some don’t have those constraints. So, we need to be able to provide all of the options in order to serve a wide variety of different needs.

We do have very focused areas that we’ve already invested in; we have a scope. You have to define what the ecosystem is, what are the boundaries of it, what the components are, and the players and actors that participate in it. Who governs it, whether there’s an authority or a designated party that drives the requirements that are listed in ‘must’ statements, or ‘should’ statements, or ‘may’ statements. These outlined requirements drive the directives that happen from the governance authority: what are the principles that are operating within that governance authority. Certainly, the Sovrin Foundation has advanced many of the principles of SSI, and some of those are actually baked into some of the governance frameworks that we’re seeing. So, we also need to have objectives within those governance frameworks. What are they? What are the outcomes they’re trying to achieve? It obviously needs to be risk-based to drive the mitigation, because, in the broad spectrum of things, governance frameworks try to reduce risk in some way, shape, or form and should include privacy and security by design.

Mathieu: Awesome; we’ll get back to governance a little later on in the conversation. I’d like to hop over to the other Foundry working group.

André, I think it’s interesting, and Scott described this too, that they’re serving the Foundry working groups. You obviously want to make sure that you’re serving it with a purpose, so having the business requirements being driven down from the Ecosystem working group is really pushing where a lot of the innovation and standards need to happen throughout the rest of the stack. André, you have a similar experience to Scott through the Sovrin Foundation. Additionally, you have quite a nice lens, in that you are not only working on an ecosystem solution through IDunion, but you’re also co-chair of the Utility Foundry working group, which is on Layer One of the Trust over IP stack. Would you mind giving a little more background on the activities that are happening at Layer One at the Utility Foundry working group, and how you look at the collaboration with the rest of the organization?

André: Absolutely, Mathieu. I think we need to start off by getting a better picture of the utility we are talking about. Everyone is talking about utilities. These are the fundamental things that are laying the foundation for everything else that’s happening on the dual stack. A utility is something that everyone has a different understanding of. To try to put it in layman’s terms; we are building an infrastructure that is comparable to things like a mobile telephone network. With a utility, we’re essentially creating the trust infrastructure where you can have the cryptographic trust mechanisms in our network that everyone can use. The utilities are building the fundamental block of infrastructure upon which the use cases are based. These are then defined by ecosystems, with the governance in place.

This is what the Utility Foundry working group is dealing with. We help everyone who wants to embark on their own utility journey, with getting up to speed and getting started. In more practical terms, what we do is that we give them a guideline, based on which they can execute their own journey. This is the six-stage model that we have laid out, which is called our Utility Project Lifecycle Management Guide. First, you gather your information in the ‘learn stage,’ then you convene to get the people who want to do it, to get together and build your utility. Then, you define the management and governance scope, and the methods and tools that you want to use, and then you actually create. So, before that, that’s all data gathering and getting up to speed. In the ‘create’ stage, you actually get together and establish a legal entity, which you may want to have. In the ‘implement’ stage, you implement the governance model, and onboard the members. Then, you maintain everything, which means you run the ledger, the utility, the infrastructure, on which the trust layers above are built. As I’ve mentioned, you have to have some kind of governance framework, that is, in fact, governing the network, and the utility, and the actors of the utility, and the participants in the network

This is what we helped people to understand, and to traverse through these stages to ramp up their own utility. As an example, IDunion is a very major initiative in Germany, and it is both a utility project as well as a project that is funded by the Federal Ministry of Economic Affairs in Germany to implement use cases. This is precisely what we are doing; getting through these stages and making it work on this example. Sovrin has been the pioneer in that round, having done all that without the Trust over IP stages being there to guide them.

Mathieu: Wonderful. I think we share the same thought, André. I’ve repeated this over and over again; people tend to overlook this layer sometimes, as it’s not the most attractive aspect from an outside perspective. However, the need to have this root of trust under the stack is crucial, and I think the work that the Utility Foundry working group is doing to provide that base for everything to function is tremendously important.

André: I don’t want to forget to mention that this is obviously something that is not only driven by me; I have great help there. Dan Gisolfi from IBM has been the co-chair all along, and obviously, you, Mathieu, are doing a tremendous job with supporting all the activities and throwing in many work hours. So, let’s take this opportunity to thank you, also, for being there.

Mathieu: Right, that’s why I talked it up! Thanks, André.

Paul, how do you see your work in the Inputs and Semantics working group being inside this? As a Stack working group, you’re also functioning as a supporter to the Foundry working groups. The way I look at the activities that your working group is doing, is that for this stack to take off and for adoption to really pick up, a lot of the stuff you’re doing is going to facilitate that. What’s the output that’s coming out of the working group, and how are you collaborating with the various ecosystems?

Paul: As you mentioned, it’s a different lens than the other stack groups. Where they look at governance versus technology, we look at data inputs versus semantics, or data entry versus data capture, if you like. Because we’re still obviously a very full space without having to specify where people are in the four-layer stack, it’s turned into a bit of an innovation space. That is, people who are working with centralized solutions and everything, still have a space in this whole ecosystem to be able to express what they’re doing, and their needs. They are bringing all of their expertise within their domains into this rich space.

I would say, for anybody new coming into Trust over IP, the Inputs and Semantics working group is a nice entry point from a centralized space. They can come in, they can learn about decentralized technologies, and then, when the time’s right, they can be pushed into the ecosystem side, or the utility side, or the technology, or the governance. I think it’s a nice place to enter the space.

We work on a vertical structure and a horizontal structure. When I say a horizontal structure; we’ve got a bunch of task forces underneath that. We have the Notice and Consent task force, the Privacy and Risk task force, and the Storage and Portability task force. All of these discussions happening in those groups feed back into the Inputs and Semantics working groups so that we can start thinking about how some of this stuff knits together. We’re building this huge amount of expertise. For example, in the Storage and Portability task force, we’ve had people from Inrupt talking about solid pods; next week, they’re talking about authentic chain data containers. We’ve got all these new technologies coming into this space. As a group, we find out what the best bits of those are, and we try to work together to get a nice, interoperable solution for all of those things.

We work on a vertical structure, as well. We’ve got a Healthcare task force, and underneath the Healthcare task force is an FHIR (Fast Healthcare Interoperability Resources) focus group. Those guys have been super busy at the moment, because of the Good Health Pass Collaborative. I co-chair the Common Data Models and Elements group. In that group, the EU and the World Health Organization have said that FHIR is the common data model that they want to use, so obviously, all the work they’re doing in the FHIR focus group is super important for that whole initiative, as well. It’s a very active group, and it’s pretty unrestrained with the stuff that can come into it. I hope that answers your question.

Selling Digital Trust to C-Level Executives

Mathieu: That was fantastic. I really love that all of you have showcased the collaborative aspect of the Trust over IP; how the Foundation is able to work with different communities, and people are able to come in, people are able to share stuff. You mentioned Inrupt just now, Paul; and Karl, when talking about the Good Health Pass earlier, you mentioned a couple of other organizations. I think that’s not talked about enough: how friendly the community is, and how easy it is to work together and learn from each other. Everyone has the same goal of driving digital trust forward, and that benefits everyone. It’s more about growing the pie together.

From that perspective, I think what we would like to do now, is maybe open it up and have a little more of a discussion. We’ve covered the different working groups, and I have a few topics here that I’ll throw your way. I’ll throw the first one towards you, Karl. Anyone else, please feel free to jump in, as I’m sure you have thoughts of your own, and experience around this as well. The first thing I would like to ask, Karl, is: how has your experience been, selling the Trust over IP stack to enterprises or to C-level executives? How do you approach these conversations?

Karl: Well, our enterprise customers come to us with enterprise stacks, right? A typical enterprise already has a pretty robust, and usually complicated, governance and their own conglomeration of technology that’s architected together. What we do, is show them how Trust over IP can be used to augment those existing investments in existing ecosystems, to help amplify standardization, amplify interoperability, and ‘future-proofability’ (I think that’s not a proper word). We help them to adopt incrementally things like verifiable credentials and great new utilities, like the ones you’re hearing about in this session. Again, these things are a toolset for the Trust over IP stack to help organizations. Most of our customers are established enterprises, so they come with all of that baked in, and that’s my day-to-day reality. However, in Trust over IP, we also have what we call ‘green-field ecosystems,’ meaning that they’re starting from scratch, and they don’t have to traverse all that. To use your term, the way it’s ‘sold’ is to say, “You have a hundred questions; well, here’s a hundred answers.” It’s a simple way to help answer repeated problems around creating trust in a digital and distributed ecosystem, if that answers it.

André: If I may add a bit to that: obviously, people have often heard a variety of things about  SSI, and the missing trust layer on the internet, and so on. They don’t have a defined understanding of what’s going on and what this can do for them. In fact, the dual stack model helps very well, to slice and dice the problem and illustrate connecting points for the solution, and for their understanding. You effectively can use the model to pick people up where they are standing, and traverse through the dual stack and make it more tangible to them. Then, in the end, you can come to an understanding, where you tell them, “Look, if you embark on this journey, you have the potential of cutting your own complexity.”

It’s exactly what you’re talking about, Karl. The complexity and conglomerates of infrastructure, which has heterogeneous governance and processes that are not well aligned, so you can help them portray a better future. In this new model, they can reduce the complexity and use the modules that Trust over IP with its technology components is delivering, to solve this and get to a leaner organization that is more future proof. That’s exactly the same way that I perceive the situation. Trust OIP is a great vehicle for transporting all these messages in a concise and consistent way.

Scott: Mathieu, I think one of the things that’s key, is that, as Karl had mentioned, people come with their own sphere of control. If they issue credentials, they can manage what it is. However, we’re dealing with situations where an ecosystem creates and issues credentials, whether it’s for SSI or for other purposes. Other ecosystems that are not related need to be able to rely on that. Where are they going to go to create that transitive trust between ecosystems?

That’s what we’re trying to define within our organization. We see that, for example, with the Good Health Pass, where you have health credentials that are very focused and very health-related. But, these individual credentials are being used for travel — a totally different industry — and they have to be able to work together to compare the requirements between those needs, between the issuers and the verifiers, in order to benefit the populace.

Paul: I’d also add that in a truly decentralized economy, or a dynamic data economy, we call it; there are three main domains that need to be truly decentralized. There’s identity management, there’s data management, and there’s access management in those spaces. You’re in a data life cycle; you can think of it as data entry, data capture, and data exchange. In those three spaces, it’s really about authentication, in that what you enter into the system comes from an authentic source. There are deterministic semantics, meaning that once data has gone into the system, you have to capture and structure it. You want to know that those items that you’re capturing are deterministic, meaning that no matter how many times you copy it across various networks, that same hash always equates to the same thing.

The last piece is decentralized governance, and that’s all about access management and authorization; that’s more the data exchange part. When you talk about decentralized governance, you want to make sure that there are no roadblocks getting in the way of those sorts of access issues. It’s quite rich; it’s not only focused on verifiable credentials. I think a lot of people come into this space and think it’s all about authentication, but it’s actually broader than that. It’s about authentication, determinism, and authorization. We can handle all of that somewhere in the organization, or within the foundation.

ToIP Governance Models

Mathieu: Just to riff off of the comment about the fact that if you’re creating credentials within an ecosystem, you don’t necessarily know how they’re going to be used in the future. With the comment about health credentials being used for travel, this comes back to ensuring that when you are creating a supply of credentials inside an ecosystem, you want to make sure that it’s good quality data. It’s the same thing over and over again: if you have garbage in, there’s garbage out. You want to make sure that what’s coming in, is high quality.

Scott, some of the stuff when you’re talking about building governance models, and maybe working with the Good Health Pass to do these things — what are some of the components that you take very seriously within the governance models, if it comes to registries? How do you look at that whole concept?

Scott: Well, there are a variety of ways that you can get transitive trust. You start with the cryptographic layer; making sure that we’re all using the same cryptographic tools. We have machine-readable rules engines, and the rules need to be built, and everyone needs to have agreement on what rules need to be put into these engines, and on the output. There are requirements, but also you have great disclosure. As Paul was mentioning, you have to have clarity on what the payloads are in transactions. Finally, you need to have clarity on the requirements: what do you require when I issue a credential? What am I getting, when I get the credential? What was built into the credential? What verification was done when the credential was issued? What’s included in the payload of that credential so that it can be used outside of its potential sphere? We’re focusing mostly on disclosure and clarity of requirements to allow others to actually use it.

Mathieu: When an external organization comes in, and there’s been quite a few that come in through the ecosystem foundry and directly to the foundation, as well for consultation. The Ontario government is a good example of one that came into the Trust over IP, and I know the UK government had come in as well. Anyone could jump in here, who was involved with these consults, but how does the Trust over IP guide these public sector groups? Are there differences between guiding the public sector versus the private sector?

Scott: Well, I could start it off because I have been working with the UK, and I was involved in the Ontario activity. These are interested communities; they want to promote digital life, digital communication. We’re still in the midst of a pandemic, and we’ve changed our focus around how digital life is. We want to improve digital life, and we want to foster trusted communication, because our lives have been restricted over the last 14 months or so. How do we create the communication and interoperability standards, to allow these communities to foster more trustworthy online communication? They’re interested parties, but they’re basically incubating the ecosystems that would fall more into Karl’s realm.

Karl: You have the side question there, about, how did we convene that? How did we respond? It’s an open community, where we all collaborate. We say, “Okay, there’s this call for a response: is this worthy of the community, to put together different resources, to try to articulate a response?” When something like the BC Government project comes up, it’s a great opportunity to educate a large group of people on best practice approaches to decentralized architecture, decentralized design, and all the principles around trust. The way I like to discuss it with some of my customers, is removing the need for trust. That’s the problem: the fact that if I need to trust you, to me, that’s a problem. Personally, I’d rather just not have to trust you. What is it you say, Paul? Assurance, not trust.

Paul: Yes,  cryptographic assurance, right!

Digital Trust Ecosystems & Collaborations

Mathieu: André, I think that what’s happening in Germany is extremely exciting, where people are taking this architecture and this viewpoint very seriously. How does Germany go about approaching this whole thing, really looking to adopt the Trust over IP architecture?

André: Yes, I think we still need to pull them in a bit more to Trust over IP, so I’m trying my best here to make that happen. I think it’s good, that at the higher political levels in Germany, at least they have an understanding of what’s going on there in the world. They are leveraging the great momentum that the SSI community has built throughout the last few years. We are very happy that, on the highest political levels, the understanding is now there that with Self-sovereign Identity, and with the European ecosystem of leveraging Self-sovereign Identity, they can have a distinction against ‘Big Tech.’ Plus, they can have an interoperable and open ecosystem that will help to drive European interests and organizations forward.

I think this is now well-known, and the momentum is ever-growing. In fact, this month, coming from the Chancellery in Germany, there will be a project that has been driven for the past month. The first pilot will become public, and then I think we will see a lot of stuff happening. This is on top of the IDunion initiative, which is funded by the Federal Ministry of Economic Affairs, so there are lots of different streams working in the same direction in SSI. I think this is based on the understanding that this is a global topic, which Trust OIP is helping to shape, and build, and make more understandable and digestible for everyone who wants to get on the journey.

Trust over IP has such a great resource pool of talented people who are thought leaders and experts in their fields. Trust over IP is a great point where you can tap into this knowledgeable resource pool. This is exactly what we see happening with Good Health Pass and the government transportation works that have already been done. This wouldn’t be happening if there wasn’t the notion that the thought leaders of the world are getting together to work on these topics, and everyone sees the benefit of tapping into that. I totally see the value and the advantage that the Trust over IP is providing there.

Paul: It’s a nice place to incubate new collaborations between the people that are interested in decentralized technologies without necessarily being at the government levels. I’ve seen a lot of people that are working in spaces, and then they think, “Oh, I love what you’re doing, we’re doing this. Oh, that’s cool.” They collaborate, and they build some kind of new technology, so that’s really nice to see — it’s very organic. It’s not all about Trust over IP; they can shoot off and do their own side projects and then come back to Trust over IP and explain what they’ve done and what kind of things they’ve solved. So, in that way, I think it’s a super organic space.

Karl: I think André hit a really important point for me in the day-to-day; the value of Trust over IP is that you’d be hard-pressed to find any community that has such a diverse set of very well-informed and intelligent members on the subject. I don’t think most budgets could support paying, even on a consulting basis, to get this diversity of skill and diversity of perspective. For me, personally, that’s the day-to-day value that’s really immeasurable when you consider the commitment to the community. The reciprocal value back to me, is simply learning from all these fascinating minds, and these projects like the IDunion project and all the LISSY work out there, that in turn, is inspiring ecosystem and utility envisioning in the United States. I know that US senators, for example, have been discussing the great work that André’s been talking about.

Scott: To add to Karl’s point, the Good Health Pass joined with Trust over IP in solving a global problem. They marshalled nine drafting groups together, and there’s been a concerted effort in the last month to put documents out. We have 150 pages right now; very well constructed recommendations. It’s just a tremendous amount of effort that could not be done, unless you have an organization putting them all together.

Mathieu: It’s tough to keep up with all the momentum that’s happening in the space. I echo your thoughts, Karl, and everyone else. With the number of intelligent, hard-working, well-intentioned people that are going in the same direction, it’s tough to keep up. It’s interesting that as more projects or ecosystems are popping up, they’re laying the foundation for others. Something you maybe didn’t think was possible yesterday, is today, and you have the blueprint in front of you to create a project based on that.

Karl: Another wonderful aspect is that you also have competitors — companies that are competing directly in the same space, doing the same thing — joining their minds together and coming up with better and more powerful solutions for their customers, because of that reciprocal benefit. It’s something you hear about with newer members: sometimes they’re shy about their own Intellectual Property or their own companies. But quickly, as you start to participate in the community, you’ll see that there are very fluid and agile ways to share ideas and really improve your own commercial objectives while improving the greater objectives around digital trust and interoperability.

Paul: For all of this to work, there’s an interesting space that’s going to be developing over the next couple of years in the data governance authorities, at the jurisdictional level, and even more for the trust ecosystems within those jurisdictions. You’re forcing this sense of collaboration, for people that are trying to solve a common problem or working for a common purpose. I think Trust over IP is just a fantastic framework to start noodling these spaces, which are becoming inevitable for the whole thing to work. It really is a fantastic space to be noodling in.

Mathieu: One aspect that excites me quite a bit, and I know André brought this up in the past, too, is that there’s so much momentum behind verifiable credentials as a whole. If you take the bigger umbrella, the whole digital identity space is understanding some of the benefits that come with verifiable credentials. But, one of the underappreciated innovations that I think is going to disrupt so many things is the API-less aspect to it. I could completely disrupt spaces and be significantly more agile than others, by being able to leverage services without needing to do an integration.

André: Totally. This is one key part of my speeches these days. We call it Self-sovereign Identity, and the ‘identity’ word implies we are dealing only with identity, but in fact, it’s so much more. SSI is a key enabler of any type of digitalization effort, because we’re able to pass on trustworthy data, without ever having agreed on an interface before. Obviously, this requires our understanding of the data model and the semantics, which is totally Paul’s domain. This is the key requirement that we have to pass on with each credential, but then the whole merit of a data-driven economy can unfold without APIs being specified upfront. I think this is the real game-changer.

So, even though it’s called Self-sovereign Identity — this is the term that has been coined, and I know that many people don’t like it — it’s so much more. It’s an enabler for transporting trusted data across the network world. This is brilliant, and this is the reason why everyone’s going to like it and love it at some point. It’s an inevitable piece of all the digitalization efforts.

Karl: That perspective matches our day-to-day with our enterprise customers. As soon as they understand the concept of a verifiable credential, password-less login, data privacy, data minimization, and all that, they love all those ideas. However, that’s just scratching the surface.

We talk about digital transformation; think about all the analog processes that are still moving around. All the papers are still being pushed for verification and any kind of business process. For example, we had one education customer in a public sector engagement, where they wanted to issue payslips as verifiable credentials, to be interoperable with loans, and in getting real estate and housing for their students and their alumni. I think that digitization is where you find the full depth and the breadth of the value of this technology. The credentials, the password-less login, that’s all great; the market’s seen a lot of that, but there’s real depth in answering the call to digital transformation, that the enterprise has been trying to resolve through several generations of technology. We finally have some very important quantum leaps forward to improving the digital trust experience for everyone.

Paul: There’s another important aspect, as well. We’re talking a lot about the transient objects with verifiable credentials, but I’m really interested in where the source of that data is coming from. That’s another nit that we’re working on; not just in this community, but across a number of communities. Finding out the persistent records in a database — when I say a database, it could be a database that’s held in a personal data store, that’s under your control — but that’s your root of authenticity, if you like. From there, you can build your verifiable credentials and stuff.

It’s a super interesting space, because you can think of it as the control being totally right back with the citizen with all of this. They have access to their data; they can create credentials from that; it’s got an authentic source that’s been certified by certifying authorities. The important thing is that the data throughout all of that can flow from peer-to-peer, being safe and secure using verifiable credentials, semantic containers, good semantics, and all of that stuff. You’re working peer-to-peer, and it’s totally secure. The whole ecosystem will just unfold and be an amazing place for safe transacting.

Mathieu: That’s fantastic. I love your point, too, Karl, where you’re only scratching the surface with use cases like password-less authentications and certain access protocols. With these types of use cases, you could 10x current processes. But, the stuff that I think excites all of us, is the hundred and thousand x possibilities that are going to grow the entire pie.

Thank you so much to all of you for doing this today; it was a wonderful conversation, and I look forward to part two at some point.