 My name is Wenjing Chu and I work as a technology strategist for FutureWay Technologies in US. I've been working on this topic for quite a while and most recently with my colleagues Scott here and others in Trust Over IP which is a JDF organization within the Linux Foundation. So I'm going to talk about a reference architecture for Trust Over the Internet with universal interoperability. Very long title because I think I covered all three things I want to talk about. So it's really Trust Over the Internet. I think you heard a lot this morning in the keynote. In Jin's topic about open-source software, how can we trust software? And also in later sessions about wallet and why that's important in order for us to establish trust over the Internet or the web. And later sessions there's also talk about the media. For example, you hear about fake media. You hear about the bad social impact because of social media and all that. So all of that is somewhat related to trust. So we want to go into a little bit of what exactly it's about and what we can do about it. We are mostly software engineers and technical technologists. How can we help solve that problem? What part we can play? And the second part is about universal interoperability. And that's the word I use very explicitly. It really means all the things that we feel I think taken for granted for Internet. Like anybody with any device you can easily know how to connect into Internet. Once you're on it, you can reach anywhere in the world. And that is very revolutionary thing. We should not forget about it. We should not do anything to compromise it. So we want to have trust, but we still want to keep universal interoperability. So that's the second thing. And the last one is the real subject, which is how do we do about it? So we can talk about reference architecture to achieve that. And reference architecture means kind of a high level roadmap of here are the steps we need to do to do it. I hope to convince all of you. So we have a small audience. I think that's good. See who can do all these things together. And hopefully I have time to do a few case studies, sort of showing why that is. This is a good idea. So I hope I don't need to convince you that trust is something that is missing in today's Internet. Anybody would disagree with that. So I think it's a real problem. And it's getting bigger and bigger. And it's going to be impacting what Internet can do. It's already impacting a lot of open source can do. It's going to impact our business and a lot of things are at stake here. So I hope we don't need to convince you that this is an important problem to solve. And so what do we really mean by that? I want to sort of go into an example and look into precisely what do we mean of the lack of trust? So this is a cartoon picture that appeared in the mid-90s in the New York Magazine. And it becomes very popular. So if you haven't seen it, it's interesting. On the Internet, nobody knows you are a dog. And there's a conversation between two dogs. What we're really talking about is that there are two parties on here. I use a smiley face for the human. And on the other side, there's a dog. They are communicating through a pair of computers, which goes connected to the Internet. And that's the basic model of what we're talking about. That's the setting of it. And now suppose you are the Bob here. And somebody sends you a message that says, hey Bob, check out this crypto. Great opportunity. What do you think of it? Would you be willing to follow up and wire some money to some crypto account or anything like that? And why you wouldn't trust that? Because the first thing is you don't know what this thing is from. You don't know the source. What is the entity that generates this information? So that would be problem number one. So I would call that an authenticity problem. We don't know who is behind this. The party behind it, whether it's even a person we don't know. And the second is that the communication is between the Internet. The communication medium is the Internet. And that medium has this property or that lack of, it does not offer authenticity. It does not offer the sort of trust we really need. And so there's multiple levels you can go down. And furthermore, even if all that is true, like who's rough? Why I believe this person or this message content itself. And so you can see even technically there are many layers of the so-called I don't believe it. But that's many, many reasons combined together. And it's important for us to sort of decompose, understand what it is. Then we know what we can solve, what we cannot solve. So trust is a complicated manner. It involves who or the identity problem or authenticity problem. It also involves competence. Even if you identify that it is actually rough. It's rough qualified to do that, right? It has about intent and benevolence, whether he's in good way trying to help me or trying to scam me. About reputation, past experience, if you have worked with this person before. The medium self. There's a famous saying, medium is the message. And we are literally experiencing that, right? The medium becomes the message itself. And numerous more. It's really a complicated problem. And so trust is as complicated as you and I can be. And we don't mean by any means trying to make it seem like a pure technical problem. It's not. However, we can help, right? And so there's no silver bullet to solve all the problems. But what we can help, I want to say, is at least two things. We can fix the media. Make the internet offer more than what it is right now. And we can also build tools so that people can handle these risks better. And that tools probably translate into, you know, software projects, applications, different, you know, maybe a wallet, for example, right? So all those are tools we can build. And so that's what we focus my talk here. Just look at what part we can do. And so again, come back to this example. Now I put a dog logo there and two parties talking. And here's a message. So first thing I'm going to say is we've been talking about authenticity. And so what is exactly that mean on the very fundamental level of authenticity? What we are really saying is we want to identify the other party. I don't really initially don't care whether it is a dog or human or a specific dog, you know, it's a roof or a Rudolph or whatever dog, right? Initially you just want to be able to say I have a unique identification of that party and that's verifiable. That means you have very high confidence. It is, you know, the party we are talking to. You may not know the nature of that party, but you have a particular party in mind that you are talking to. Okay? And so that's one thing. The second thing is we want to have some assurance that the party has good control of its own computing environment. So for instance, if they are in the computer in the public space, a shared one, that level of confidence is lower if it's on a smartphone that you own, for example, right? And so those are the terms of autonomy. Or whether, you know, the party may be a nameless entity within a large cloud platform, right? In that case, you cannot exactly control the environment. So for example, in that environment you will be more likely accessible to hacking to other parties involved in the operation of your system, for example. And so there's a lot of reasons why those systems are less trustworthy. So those are the two main components that I would say, A, it's necessary. Without these, everything else we're talking about, you have no basis to speaking about it. So these are fundamentally required in order for us to have any level of discussion of what I, what I trust you. Do I believe in this message? Because if you don't know really all that, the source of the message, trying to read the message content is kind of beyond the point. And also we will say it's largely sufficient. We'll get to a little bit on that. And I think then we're trying to show that all of these can be other features we typically associate like confidentiality, privacy, or integrity of the message. All of that can be built on top of this foundation. And this particular foundational level features are simple enough so that it can be implemented anywhere on the internet. So I'm going to start into really talk about so-called the reference architectural. So we say authenticity is what we want. And that will be as the base layer. Essentially all devices will implement this piece of functionality, no matter what it is, how smart it is, or how big it is. And there are numerous ways to implement them. And there are many of them I named here. If you are unfamiliar, that's okay. I'll give some examples of them. But I just want to show you there are numerous ways to implement these basic features in different contexts. So they are not like one is superior than others, but all of them have some reason in their own context. And that's good to have. Similar to internet, you have internet protocol, but numerous ways to make it happen. And so you are not limited to what exactly you need to do there. So that's two layers already in place. And so with authenticity, then you can have a little messaging protocol between the entities. And the messaging protocols can assure one thing. The messages are from the authentic source and receiver. Both sides know who the other party is. And so that's a very basic function to have. With that, I would say you can build really interesting things. And that goes into what we call identity. So this layer is identification, just purely technical ideas, right? Identity, you will say, oh, I'm an engineer, and you actually put people's attributes to them. So you can do that, credentials, whether you have a software engineering degree, and now you don't really need password for logins. You can add on top of this maybe payments and handle money. Maybe another regulation will require you to have more and more credentials, maybe a true ID issued by government with a photo, whatever your requirements may be, can be built on top of this. And I would say more generally, very authentic data, which includes the media, photos, videos. You can see the photographer can assert that I took this on this data in this environment, and all that information can be trusted. And naturally, you will have authentic messaging as well. And so numerous different things you can potentially build as building blocks, and these are reusable. And then on top of that, you can have your applications, and you can imagine numerous ways that you can build an app on top of it. So that's what generally the four layer comes down, and you give it just a high level pattern of four layers, and this layer two is the most important one, because that's the foundation, that's the trust spanning that allows all the devices on the net to have some basic trust. Okay, so with that, I guess I want to come back a little bit on this message. How do we, you know, do we trust this message, right? And so with the basic first layer, we have some autonomy and also a verifiable idea which allows the receiver to know that it's an authentic, true, and unique entity on the other side talking to me. And now based on that message, you may say, well, I would still not believe whether you are actually rough. I know somebody called rough, but I don't know that's you. So what do you do? You simply ask the question, can you show me, you know, I don't know, what's the plight way to ask, but can you show me something or ask a question, or you can be more formal, say show me your driver lesson idea or show you, show me some idea, right? And that communication can happen, because you already know the authenticity of the channel itself. Okay, and so whatever you require, that authenticity today will call that authentication, right? With that authentication, now you can know, oh, it is actually the rough that I happen to know. And then you can decide, like, do I trust the rough I know? And whether that's a friend that is a competent investment advisor or whatever, that's completely separate out of my talk here, but you have the means to establish all that if you want to. And the app you develop could add all those features on copyrights if you want to. And so that allows us to solve the basic problem, and different applications need to go as deep as you need for authentication. But based on, you know, you already have what you need. Most of the times you don't need the true identity, you may just need a way to know that this party is a unique party, it's not a pretending party or pretend to be somebody else, for example. So all of those can be built on this platform alone. And I want to mention something else about the second point of autonomy. So if we then go from a very old looking computer icon here to a smartphone or maybe a smartphone with a digital wallet, because how the digital wallet and smartphones build, it gives you potentially, if you build properly, more control over the second property, which is autonomy. And so that, you know, for example, with a face detection algorithm or a thumb or some other biological means to detection or other means, right, you would be able to actually associate it with a physical person more closely, more tightly. So those, you know, it's a sort of independent innovation people can do to make, improve this point as well. But the basic picture still stays the same. So now I want to talk about universal interoperability. And so why this particular way of doing it help us to maintain universal interoperability of the internet that we really enjoy, we want to keep it. This is really inspiration from the original internet architecture itself, the TCP-IT photo stack. So if you think of it, it's really how that was structured. IP is basically the universal layer. It's very simple, but it gives you a unique address and gives you a global reachability anywhere between any two devices, right. And so up top of that, you can build slightly more features with TCP-UDP protocols and with HTTP, HTML, then you have web and more and more can build on top of it. So we do the exactly same thing. The trust spanning protocol essentially is the IP layer. It's a reachability protocol, very similar. In this case, we're trying to support authenticity, okay. And then it's simple enough on that. We'll get to some examples why it's simple enough. It's necessary and it's largely sufficient as we show that. With that, you can build actually all kinds of things on top of it. And there are applications that only need that. You don't need anything else. Many of them are just casual messaging. That's all you need. You don't need a real person to be identified, right. Okay. So that allows us to really have a very scalable architecture, but also that the base layer is extremely simple. So anyway, many implementations already supported. Two things I will say we still need it. So one is they need to be refactored. Most of applications when they write it, right, they start from application layer and they write the whole thing in one piece of software, which is really a right way to do it for universal employability. So we want to say maybe you should look at your software. See how you can, using this architectural reference model, to refactor your software so that layer two is isolated and so that you have universal employability. That's a common feature. It's just that they're combined with so many others. And it's not cleanly defined, delineated. So employability is not practically possible today. And so that requires some standardization. We need to say this layer, all the functionality everybody has in a way, but we should do it in a way so that it supports common protocol for that. Okay, so I'm doing time one, so I'm good. And so now I want to go through some examples. If you're familiar, great, if not, it's okay. So I have some, you know, I don't have a lot of, I just have one slide for each example, okay? But these are, at least well-known to me, implementations of them. And we will see, like, each of them can be refactored in relatively straightforward into the architecture we have. If we all do that, then all implementation will be compatible in the fundamental layer. In the higher layer, they may serve different applications or different industry. They don't necessarily need to be entirely compatible. But of course, if your higher layers are also compatible, that gives you even more reach of your application, right? So anyway, I'm going to start with the traditional or today's state of art, I guess. So the first one is the central model, which you have two computers again. So I'm going to say that's a server, the web server. This is, you know, somebody browsing the web. And how do you show that web server is the real one you're trying to go? Well, that's usually the name or the ID is the, your domain name, UIL. And how do you know these UILs actually be the true owner? Well, that's how somebody give them a certificate. And so the browser, as a user, will be able to verify the certificate. And all behind the scene. And again, you know, why do you trust the certificate? Because it's from some authority. And the authority is really a misnomer. Sometimes it's a very small company. And the quality is not very good, I would say. So the authority depends on, you know, where you go. And authority itself can be issued by yet another authority. And you can have a whole hierarchy of it. And so that's how things work today. But imagine if the authority is compromised, which happened. Huge amount of networks are all discredited or websites are all discredited at a single moment, right? And so it's really not the right way to do it. So that's one side of that. And what about, you know, how the dog knows this is Bob? It's very cruelly. It's ID, you have your account, and a password. And you know how this thing works, right? It's extremely, and basically all that is just sitting in a database somewhere. A hacker can easily have it. The second level then is that we introduce some, so called federated models. So we introduce an entity, maybe, you know, GitHub, Google, Apple, I routinely use them. And they say, well, let's design a protocol so that you would, you want to log into this website, but you will be logging into, you know, GitHub or Google instead. Maybe you trust, you know, Google more than the nobody website. But so through the login to Google, then between a protocol, they can pass that authentication information to the website. So this can be done. And it doesn't reduce the number of passwords you have to remember. But it doesn't fundamentally solve the problem. And it ensures yet another new problem because now Google knows everything you do. Every time you go in a website, you log in through them. If they have a record, you log into this website. So they have a lot more information about you, and that may not be something you want to, right? And so that's a new problem created by this solution. That's the federated solution. FIDL is something you might have heard recently. It's very popular because it promises to get rid of the password. And essentially it's going through the same pattern we were just talking about. So you log in through or you authenticate through your phone instead. And hopefully you have better control of your phone than your computer. So it's slightly safer because you're carrying, you know, in your body most of the time. And so that allows this protocol basically allows you to do that. But you still go through the same way in logging into some website, right? In this case you may be either, you know, whatever the phone manufacturer would be, you will go through the federated logging through them. So again, this is, I would say, the most of the state of order today. The first example I have is called Indie and Eris with Bitcoin. So in this picture they all assume there's a digital wallet built into it. Okay. And so in this particular example, the layer two of this trust-spending protocol we're talking about is called Bitcoin as a protocol. And the addressing is a bit decentralized identifier, which is an aspect W3C approved just recently. So with that you could have different higher layer protocol, one of them is known as AnonCred. So it will give you verified credentials that you can, you know, you can ask for example your, so I'm going to use the American example. So the state government can issue a digital driver license, which will be some file get saved in your wallet. And then you can use some information in that digital license. For example, your name and others to do whatever you need to do. So you can use that for login, for example, for website as well. But that particular credential can be issued by other parties as well. So it could be community issued, it could be issued by non-profit, or you know, whatever that the user group may decide to issue themselves. So there's many ways you can do that once this picture's all in place. And that is one way you can implement it. That requires an Indie blockchain. Both of them are available open source from Hyperledger. So Indie and Ares are Hyperledger projects. So that's one example. And you can see clearly the picture already showed up. We've had discussions with them and they already started to do decomposing. So they see the benefit and they're seeing they can start to move in some of the, you know, rewrite their code so that the protocol portion gets separated. And also, you know, separating the communication aspect and the variable credential as two separate layers. So, you know, you can change different protocols to use in Hyperledger. The second example is called decentralized web node or decentralized web platform. Also, the new name is called Web5. But anyway, it's from Block, which is an online payment company, of course. And they're trying to do very similar things based on that and the variable credentials for a lot of things, but for them primarily for payment, right? And underneath of all of that, it's built on a very similar concept. So their blockchain of choice is Bitcoin. It's a really a side tree on the Bitcoin protocol itself. And the communication channel is IPFS, so it's, I don't know if you're familiar, but it's a, think of it not a blockchain but a file system acting like a blockchain. Maybe that's the way, a content addressable file system. And so this allows replications and basically these, think of them as like a digital mailboxes because you can create, each person with their date can create mailboxes as a receiver side of it. And they don't have, you know, any restriction on how you do replications, kind of an open protocol for that. So this allows a channel that are purely based on two dates. So this works perfectly well as well. And we can think of this whole mechanism here or this API for sending and receiving and your date identification as the communication channel. So it will be a trivial thing, sort of add a thin layer on top of it to make it look identical as the channel we want. So that's the second, second example, a survey example now for that. The last one, I think this is the last one, is another protocol being worked on in trust of IP called Cary. It is another, it is more pure web of trust design. So in this case, instead of a blockchain that's run by a group of entities, right, you would actually simply have a pool of so-called witnesses or watchers, you know, basically peer-to-peer parties. Maybe my friends or maybe it could be a professional, it could be organization that, you know, step forward that I want to be service to the whole community as a witness or a watcher or it can be a commercial party, say, you pay me five dollars a month, I will do this for you, right, whatever the reason. And so this allows a whole pool of these things not strictly as a blockchain. Basically, you move a lot of unnecessary things in the blockchain, but you still keep the basic features in place to make sure that this can be the information or in their terminology, key event, that KSK and EE key event are logged in this place and you can always retrieve it or anybody can retrieve it and do verification with. So I'm showing here as a log goes into there and you can mathematically prove the key event are sufficient for the whole, basically that's the whole necessary history. You don't need the entire history, but that's the necessary part of it. Okay, so you get the same guarantee of it. And with that, you have a minimum dependency, really. And so your identifier only depends on a group of, you know, potential friends or volunteers. And then you can do pretty much any communication you need to do. They do define more features to it, but in the base layer, I think they have a theorization, new theorization method as well. But the basic concept is pretty simple. This identifier, this produces authenticity. And then with authenticity, you can, all you need is agree on a messaging protocol without many to choose from. And so we can have the communication channel that's authentic. And so this is quite compatible with our proposal as well. We can basically isolate that layer and make sure that this works for that as well. Anyway, so I'm going to come down to the key takeaways. Hopefully, I reasonably convinced you, A, the building a better trust layer is not just for some special services like money and payment or that. You know, blockchain is automatically associated with currencies. And that's, of course, one good example of application, but really it is a problem that entire internet face, all of our applications have this problem. Number two, there are many, many non-compatible implementations today. And they're all very good, I would say. They all have an opportunity or a chance to become, you know, really successful. All we need for is we need to refactor them into the layers we're talking about. And through that, then we have a very basic layer of a foundation that supports authenticity that will be universal. Okay, so that allows us to all have the compatibility or other interoperability features as much as we want. Because from there, you can start to negotiate. Think of them as a control protocol. Once you have one, then you can create all kinds of them. They're all trusted. Because you can trust the channel to create yet another communication channel which is also trusted, right? And so it becomes really easy for us to have a large, diverse ecosystem but it's universally interoperable, okay? And hopefully I show you that the more complex trust tasks can be built on top of this. And this is a good architecture, I think, for all of us to follow, to support and to adopt and to make them into implementation. And so one of the key contributions that we as an open source community can do is, you know, have some of these implementations in place. That is interoperable and follows this particular reference architecture and make it work. And that will be really the first step I think we can do for more trustworthy internet. And I hope the rest of the community will then be able to build on our foundation and really make the huge impact we would like to see. And so that's the vision here. And that's my talk. I think we have ten minutes? Five minutes? Okay. Any questions? Any discussions? Okay, yeah. Sure. And I think that it's very interesting to solve, or at least I still don't know how we will be solving. That part of the wallet, basically, and people having the wallet in their phones, we get used to have our phones and everything, but you still will trust in the developer or the company, whatever, that will do the application for the wallet. Correct. Correct. And even if you lose your phone, then someone will have a backup of that. Correct. How does, I mean, is that like a focus point on this? They used to be, let's say, of this aspect, because nowadays it's a lot harder to use it. Right. So I think you have something, a pair of keys or whatever it is, you need to handle, let's say. Right, right. And so as the very professionals in security field would say, you look at the attack surface, areas that you feel you have control and areas that you're uncertain. So minimize them, give you better confidence. You're never entirely certain if you rely on other parties, because you rely on their goodwill. And mostly they are doing a decent job. Right. However, the more complex systems always produce more problems, because you're just harder to detect all the problems in those fields and you have no visibility at all. So if we come down to, for example, a mobile phone, it's relatively well understood. And you're familiar with confidential computing, there are methods which can actually give you a higher level of certainty that it is being built properly and it's done properly. Today the issue is that all that knowledge, all that software, how it's designed, is hidden within a vendor. So Apple did it and they didn't tell you how they did it. Right. But that's changing. The newer version of operating system is going to allow that to become the confidential computing itself becomes programmable. That means any application can be on top of that and the application can get assertions or attestations. Yeah. So imagine if I do open source code, so here's my wallet. I can attest with multiple independent parties that is built properly and the image was loaded properly, executed properly. The entire process can be attested. So that gives you much higher certainty if you want to go down there. And I'm not sure about consumer devices, whether you want to go there. But if you are building specialized devices for particular higher requirements, I think that's the right way to go and there are means to do that now today. Yeah. Driver license protocol is available. Oh, driver license. Okay. So the question is, where is the driver license protocol? Whether it's valid in TIO, T-O-I-P. So within this architecture, absolutely. So driver license will be a good example as a credential. And if you still remember the layers, credential sits on layer three. It's above the authenticity layer. So authenticity really is talking about the two phones are not being hacked or not malicious, right? And so once you have that established, then you can issue credentials. And credentials for driver license, we know driver license use one particular set of standard, ISO standard today. I think in the two states in the US anyway. But W3C defined variable credentials. We will think that will be an even better protocol to implement. But whatever the protocols are, in layer three, you can support them based on, again, the channel need to be authentic first. Then you can exchange variable credentials between the two parties. I can say, can you show me your driver license? And they can send to me. I can be certain this driver license is not being spoofed or faked. So yes, great question. Any other questions? Great. Thank you so much. Thank you for joining this session. I know there's a lot of a big event happening, but I'm glad that we have a chance to talk about this. I really feel it's very important. And it's something we can do. So hope to see you in some of our guest to make this happen into reality. Thank you.