 OK, and we're welcome to the Digital Identity Working Sessions. And I'd like to introduce my colleague and friend and teacher and collaborator on cool projects, Christian projects, Christian thoughts, what about some of you? Share some background on the research that is happening here on digital identity. And also, some good spots on the topic in general to help set the stage today. So thanks for joining us, Christian, and we'll be back with Laura. Laura. All right. Thanks, Tazza, introduction. I want to point out that this may turn into a rough landing as we get towards the end, because I was cranking on slides until I got here and trying to find a balance of material between the really super high level and insanely technical. And I think we have a mixed audience, so they don't want to bore 50% of the room. So when we get towards the end, we'll start getting a little more technical and feel free to stop me and ask questions and maybe open up new subjects if you want to, especially if we have some time left. I think this is for 30 minutes-ish, maybe a little less. So we end up a little bit of a late start, but I'd like to suggest that we go for 30 minutes. And we might be able to actually do the conversation as one group, but one Christian's done, and we talk a little bit about where the threads are. At that point, let's take a look at if there's two or more smaller groups that want to break out. We can figure that out. If there's one group that wants to keep going, we can do that. And I'll suggest we do one set of breakout groups or a session of general discussion after Christian's talk, and let's discuss that. But I think it would be in our interest to hear the entire talk. So if you're hearing no objection, you've got the floor for half an hour and our minds are open. Okay, well, the subject of this is identity and privacy and trust. They think all of these things need a little bit of clarification because there are a lot of different things that someone could mean when they use these words. And it's really hard to have a meaningful discourse about any of these subjects unless we can agree on just the general meaning and scope. We'll get done in a second to get the thing going again there because I have some nice apples to show you guys. And not to complicate things, Desi, but are you live streaming us? Mm-hmm, okay. Depicted now, pile of green apples. Yeah, pile of green apples. And the point of this is there are a lot of things that someone could mean when they use the word identity. But the common thread in all of these meanings is some idea of sameness. So you see all these green apples in the slides. That's what that's about. If you look up the word's identity and same in the dictionary, you'll see that they are mutually referential. It's probably a really frustrating thing if you're trying to learn English, but it might help us English speakers to shake up our understanding a little bit and shake up our assumptions a little bit and try to come to a better understanding. I have some other fruit here. I think fruit quite a lot, actually. So when you identify something, you determine its sameness or the lack of that to something that you've previously observed. So there's an important distinction there that this is something that you either do or do not have previous knowledge of. This idea of sameness is really, it's still just as overloaded as identity. So I'll get to the next slide. We could mean individual sameness, like I am me, no one else is me. This is my dog and I used to live on this particular mountain, but we could also mean categorical sameness. So I'm nerd and there are many of us here. You guys are not offended by that categorization. So this kind of sameness is determined by observable behavior and characteristics and or the attributes of a thing. So then there's the idea that sameness could be objective. We can all easily agree about the identity of an entity or its characteristics. Like this is Media Lab. It's a real place and we're all in it, hopefully bringing on them, except for the people in the hangout if they're not here. But this kind of identity is public information. This is the important distinction. It's public information and it's not inconsistent with other things like GPS coordinates or the street address. This may sound like trivial stuff, but when you're designing systems, it becomes a very, very important. The devil's in these details. So sameness could also be something that is subjective, like internally in MIT, I use one email address and in the outside world, I have a Twitter handle and a different email address. And those things function kind of like personas, so that I have different identities in a different context. And we can even, what happened there? Empty screen, yeah. We could even reason about sameness in terms of the relationships between things or people. One single person could be a teacher or parent, a student, sibling, boss, subordinate, peer, offspring, any of those things and one other party might know them by one of those things or they might recognize that role, but not the other ones. So that's another important distinction. We may only see one side of a person or one side of a thing. Yeah, here's the obligatory math, because we're at MIT. So, there's gonna be a quiz. When we talk about identity, in principle, we're talking about associating a symbol or a category with some identity, sorry, with a person or a thing or some idea, a symbol or a category. And the purpose of this is that it acts as a heuristic. It gives us the means to reason and communicate and interact with a lot less effort. Sorry, I'm not having a process with you all this time. Yeah, it's a good read, huh? Yeah. Yeah, if you've read that one? Yeah. Yeah, it's a good read. So, when we're considering real or actual entities, I think it calls them, their observable or measurable characteristics tend to change over time. So you could think of identity as being a function. State could be mapped onto some constant symbol, sort of like a thumb print. So I have a beard and my beard changes in length. It tends to get longer over time, but I have a thumb print and throughout my life that tends to stay the same. So there's this important dynamic aspect of identity as well. And so identity is process. And this guy, Alfred North-Whitehead, he quoted Heraclitus, very nice quote, that no man ever steps in the same river twice for it's not the same river and he's not the same man. It kind of gives a little philosophical stimulation there to something to think about. So if identity is a function, it might be expensive to invoke it in the real world that's bound by our experienced laws of physics. Not everything is nice and tidy like math. This has no cost, what you're seeing on the screen, but in the real world, running this function, if it were a computing function would have a cost associated with time, space, possibly money, if we're talking about a smart contract, something on the blockchain. So if we want to avoid repeating that cost, identifying symbols and use those things instead of recognizing the thing, instead of recomputing this function. So identifiers and categories are shortcuts to determining sameness or identity and they allow us to bypass this recognition function and identify things very quickly. There are different kinds of identifiers. We've talked about a couple of them. There's the idea of a public identifier like Media Lab, but for a second, let's stick to the subject from self perspective. Everyone could know me by the same name. That would be kind of a public identifier. If there's no restriction on that, you all know that my name is Christian Smith, but I could have sort of a persona or a personified name so that different groups would know me by those different names. Another kind of identifier would be a pairwise identifier where each person or each website, for example, run into this in authentication systems would know me by a different name. So, and this is important because in the case of, think about websites that you visit and authenticate with, if they all know you by the same identifier, then they can collude and they can track your behavior across websites and that has some big privacy implications. So, protocols like OpenID Connect and other things like that, there's an option to have pairwise identifiers so that every client, in this case, every website would have a different identifier for the person. Then there's this notion of a transactional identifier where every time I interact with some party, I have a different identifier. You find this, you hear about this mostly these days in blockchain and Bitcoin types of things. And you may wonder why you need an identifier if you're gonna use a different thing every time. That is that you may want to later associate yourself with a given transaction where you don't at a certain time. You may want to do that at some point without exposing all of your other, all the other transactions that you've been a party to. So again, privacy implications for this. Another interesting question about identity is provenance. Where do we get it from? Particularly with personal identity, this symbolic notion of a person, where does it come from? People have different views on this. My identity, does it come from me? Am I self sovereign? Do I own myself? There's some loaded language in there. But it could come from my parents or my tribe or school or employer government. People actually really care pretty strongly about these things. If you start pushing, where does my identity come from? Who issues this thing? There's some pretty good arguments to be made all around about where identifiers come from. It might be a good topic to discuss today in some of the groups, but it is quite a loaded one and it can get emotional. So where your hazmat suits. There's a small problem with... What was that? Sorry. Oh, this is a, sorry, this is a... Oops, going back, yeah. Where is it? There it is. This is a birth certificate. This is in particular, this is a birth certificate from 1880. So I don't think that person, it probably wouldn't be feasible to steal their identity at this point. But yeah, you can see that this was issued from some place in New York, I believe. And they call it return of a birth, which is strange language. The Bureau of Vital Statistics Health Department and something word in New York. But this is a birth certificate. There's, we talked about these, oops. We're the reveal, there we go. There's a problem when we're using these symbolic shortcuts, these identifiers, which is now we need to be able to prove, we need to be able to prove that the subject is related to the, is bound to the identifier. Like there's an identifier, but who is it for? Is it for me? And the same thing actually goes for category. So you could say, am I in the category of people with a credit score above 750? Maybe, depends on the day. Do I work at MIT right now? Yes, I do, but that's a category. You might need to prove that. This is one of the things you hear about people talking about attestations and verifiable claims and verified attributes and things like that. These things, your membership in the category also has some implications for building systems. We want to be able to prove those things. And so I can assure you that this guy is not the real Elvis. He's putting on a pretty good show. But I almost used the picture of you there. We should say what's real. So let's take a look at this thing. Okay, we're good? Okay. So if you want to prove, oh, there's a piece of it, jeez. Oh, I forgot to show you. Okay. So, excuse me. This is an identifier in the form of a URN. And there's a proposal of this as a kind of format for a new identifier, but the idea of a decentralized identifier. But if I want to prove to you that a symbol like this one characterizes me, that it accurately identifies or characterizes me as this unique specific individual blob of flesh and puff of consciousness and stuff like that, we need a reliable way to do that. And that means authentication. So traditionally in the field of authentication, there are three first principle ways of doing authentication. There's something you have like a key or something you know, like a password or a secret handshake or something that you are, like biologically, and this is where we start talking about biometrics and stuff like this. Pretty interesting. But there are questions here about privacy as well. This business of identity is very, very hard. These machine-friendly identifiers that we were just looking at, they turn out to be pretty lousy for humans. Can you imagine knowing somebody by this, by did, colon, trust, colon, BI, 786, F89 and so on? No, that's a lousy name. You couldn't even just look at it and use it. Keep it track of it in your head, let alone say it. So what happens is people tend to augment these neat little byte sequences with metadata into trouble with privacy because now you've got an identifier and you've got all this data attached to it that may or may not be more than what you need to prove sameness. So consider if you were to store your merchant and you store a credit card number. This is a somewhat decent example. You store credit card numbers for everyone that you do business with. All of a sudden you become a target for hackers. If you're negligent in handling them, then you're going to be liable if that's stolen. So there's not just a privacy issue with protecting this information that you collect about people. There's also your own liability of, I mean, you're going to be hacked, you're going to have the cost of the systems and so on. So this is kind of obvious stuff, but I'm trying to frame it in a way that might be novel to help people think a little deeper about it. So my slide's stuck. There we go, okay. So a couple of years ago, the Office of Personnel Management for the United States government was hacked and the entire database of security clearance information for everyone ever cleared was stolen. I don't want you guys to hear about this. And so let that one sink in for a minute. Every personal detail that you would have to give the government qualify for some kind of six. This was like CNA assets in the field, everyone and everything about you that goes on with clearance. I have not gone through clearance, but I know some people have and it can be very invasive and they collect quite a lot of information. So to have all of that stolen is a really big deal. But around the same time, our website of Bill Repute that was hacked and it turned out that there was no small overlap between information between identifiers that were held in this clearance database and this other data set. So state level adversaries were able to put two and two together and now they have a very long list of high value targets to exploit for things like espionage. So this is serious stuff. This is, it's no joke. You were saying that you could tell who was in the Madison, the government and then any user's leverage and blackmail. Exactly, particularly because some people, a surprising number of people currently use their government issue email addresses to sign up on the site. So, I don't know what this says about humanity but I know what it says about designing systems. And the adultery is not just in the military, it's a crime. Oh, that's right. Yeah. That's right. Yeah. So you could lose your career. Yeah. Yeah, it's a serious issue and people don't take seriously enough. So what does this mean for privacy? In the past, the conversations we've had about privacy very often, privacy and security have been framed as these opposing goals. And that's one of the justifications for these big databases of like the one that got stolen from the office personnel management. We collect all this information about you. We have to know everything about you or else we can't trust you. We're not secure if we don't know everything. And that's been a commonly accepted belief that we have to sacrifice privacy or we won't have security. But I think this particular set of circumstances that we just looked at illustrates that maybe this is not the case. Maybe not having or care in handling of private information. And then there was care and handling. I don't wanna disparage the folks that were protecting us because it's actually really, really hard because I understand that this data was in an encrypted database already. And the details of that are a little interesting and almost amusing, but it wouldn't be amusing if it happened to you if you were the system administrators that were or the software vendors that were dealing with that stuff. But it turns out that having all this information out there that's saying a lot of information that would be private it makes us vulnerable on both sides. It makes both parties to an interaction vulnerable. So going forward, what we really need to be thinking about is building the capability for privacy preservation that needs to be a first class goal of infrastructure that we design and implement and also everything that we build around it. So like right down to the level of TCPIP, I think it's gonna be hard to deal with that one, but at the level of the web and at the level of talking about blockchain things and new kinds of federated decentralized data storage, we definitely need to be addressing these things. So there's another thing that people should be really highly aware of which is the principle of least privilege. And basically this has to do with disclosure. You should never disclose anything that you wouldn't want someone to know. You should never disclose more information than is necessary in order to accomplish some kind of thing in some interaction. Disclosure is irrevocable. You can't undisclose and you can't re-confidentialize something. Have you ever tried to take a secret back? It doesn't work. Sorry. If you type these two fake words that I just made undisclosed or re-confidentialized, we type them into a computer. You're gonna see the little red, curly, swavily thing underneath because they're not words. They have no meaning. So in the kinds of future identity systems that we design, I'm sorry. Oh, the, oh gosh, yes. Sorry. I hadn't changed it. There was nothing interesting. I just said this since the full release of the language continues to be important. Yeah. So, so. It's known as data minimization. Yeah, exactly. Data minimization. That's exactly right. So in the systems that we're designing and implementing, even if you're not designing the protocols, even if you're just taking tools off the shelf and deploying them, you need to be thinking about these things. And disclosures, I would have several characteristics of disclosures that I'd offer for people to consider. One would be that they're minimal, like Dazha just said, minimization of the data that you're sharing. Another one is that disclosures should be informed. You don't wanna find out later after the fact that information was disclosed. That it's consensual. Disclosure, if you have data about someone else, you should always be asking their permission to disclose it to another party or even, yeah. Even a party that you're doing business with and their intention is to keep it private. There should be, it should be informed and consensual. Should also be just in time. We shouldn't be giving away a lot of information before it's actually needed because it might not be. And then you have it laying around. Another principle about disclosure would be granularity, only giving away just the part, just a little bit that's needed. If you have a big record on somebody with lots and lots of fields, just give away the one thing that's needed at the time. And here's one that's really exciting that I don't think I've ever heard anyone talk about this and I don't think I've seen it as a feature in any systems. But the idea that disclosure is, so particularly when there's verification involved, like I'm disclosing some fact to prove to you that I'm worthy of credit or that I can join the company and there's no, or credentials for school or something like that. I mean, actually you do see this, you see this in academia because of international students and things like that where you're coming from another country and you don't have the same kinds of credentials that would be expected from a domestic student. So there has to be a certain amount of negotiation and I think that idea could apply to other things like say lending. Maybe I can't prove that my credit is above a certain threshold but I can show that my income and my bank balance is above a certain threshold. Or maybe, yeah, there are other cases like this that negotiable disclosure might be really useful. So that's another one to think about. So now I want to talk about trust. And really they want this, I'm going to go hand through this one because this is a good piece of fun picture of this one. It's time. So we have a tiger and a person that's leaning over and letting the tiger lift their head. That's a little scary. There's some trust involved there. So as with identity, the meaning of trust is something that we tend to take for granted. We use it so much that we don't really think about what it means. And it's a little surprising to people, especially in places like this where we're dealing with systems, trust is actually an emotion. It's an emotion, trust is an emotion, right? Let that one sink in for a minute. So you're not talking about the human perspective? Yes, yes. Because I mean, when we're designing systems and I think you'll relate to this as a UX designer that we're making systems for humans to experience, right? And to solve human problems. So we're definitely speaking from human experience. And trust is actually an emotion. And it just seems really mushy and subjective when we're talking about security and things like that to talk about an emotion. I mean, how do you compute that? So we need a definition that is a little more expansive than that. And I have one I'm proposing here. I'll read it to you. Trust is the emotion of confidence, belief that some party involved in risk will behave according to a set of tacit expectations for an explicit agreement. And this emotion derives from a belief in the honesty, reliability, or competence of another party. And the notion of belief here is really significant because a trusted party has to yield control in some way. Remember the guy leaning over and letting the tire lick his head? He was definitely not in control of that situation. Definitely not. So yielding control this way when you trust could be dangerous. And we don't always have the ability to eliminate every unknown or resolve every ambiguity in a meaningful enough timeframe to take advantage of an opportunity of any kind. And so trust, actually, this emotion of confidence, this idea serves as a heuristic in situations that involve risk. Okay. Situations that involve risk. Yes. And then there are all kinds of them, actually. Maybe real stuff. Yeah. And yeah, so risk, we can get happy about risk, right? Risk is a good thing. Risk is a good thing, especially the banking people in this room will appreciate this because risk is something that we can measure and compute. And there's a vast body of knowledge on risk management. People know how to do this stuff. This is good. So if we can think in terms of risk, we have opportunities to collect data and study that and think about what does it mean for trust? And this understanding of trust that we've just talked about, emotions and risk, and the ability to collect data and study, it hints at opportunities to potentially be able to predict behavior of networks by observing without having, if we have privacy respecting identifiers and we can observe the network as whole, maybe we can understand things about behavior using statistics and be able to instill higher levels of confidence in a transaction with someone that you don't know. And like provenance, this is another really big issue and there's a lot of social implications and concerns about privacy and open questions. So it's probably something to consider discussing. Now we're gonna start to get a little more interesting because we haven't used the word blockchain so far. Right. And you'll hear about this notion of a trustless system in blockchain circles. And a trustless system supposedly doesn't require trust between parties in order to function correctly. So you don't have to trust, you don't have to have any trust in the system. There's an idea that there's no corruptible party, a sufficiently dominant position for the network. So if there is someone in that dominant position then you have to be able to trust them with the third party. But the idea in blockchains is that there is not someone in that position. And so it's a trustless system. You can, it's a kind of ironic supposition. So a couple of things to discuss about this. Firstly, this idea of being a trustless system is different from people using the system not having to trust each other. Those are two very different things. So if you're using something that might be called a trustless system, two parties still have to, if I give you the money, I still have to trust that you're gonna give me the car or the, whatever it is that I'm buying. The silk road away. So we won't be buying any more fun things. Not that I ever did. Not that I ever did. Not that I ever did. Not that I ever did. Not that I ever did. Not that I ever did. Not that I ever did. Not that I ever did. Yeah, so again, not needing to trust the system is different from not needing to trust counterparties. But does this idea actually fold water? I would invite you to ask the folks who lost $31 million in an Ethereum heist last week how they feel about not having to trust the system. There's a pretty good article on this and it's worth looking up and studying what happened. There's this, oh jeez, I'm sorry. I'm not forwarding the slides. So, second for people to check this out. 31 million bucks in a matter of minutes and it could have been a lot more but people figured out what they actually did is the hackers figured out the good guys, figured out it was happening and they went out and preemptively stole the rest of the money that was vulnerable and held on to it to give it back to the intended owners but 31 million got the work done. That's not right. And Mr, wasn't it the exchange house that was hacked? It wasn't Ethereum itself that was hacked? Yeah, it was a smart contract. There was a smart contract in Ethereum. There's a language called Solidity and there's a sort of a default function in there and I think it's a best practice to always define that function so that you know what happens if none of the other conditions of the state machine are bad. They, if you leave that undefined, people found a way to use that as an attack factor and run off with the money. So there's a pretty interesting essay that I would like to offer folks to check this out. We can send people a link to it. You may or may not agree with everything in there. Sorry, this is not rendering well. They should have put the full link and made it bigger. The essay talked about trustless systems and explores a lot of different avenues around us. And the takeaway quote is that blockchains don't offer us a trustless system but rather a reassignment of trust. So you don't have to trust some centralized dominant party that you would in a more traditional kind of system but you still have to be able to trust your counterparty. You still have to get it's running. You still have to trust the protocol. You have to trust the math that whoever's choosing algorithms chose to do that they chose good algorithms and the math supports what they're trying to do. And trust the sum total behavior of the various other actors and stakeholders that are involved at every level of abstraction in the network. So this idea of a trustless system, I think it's really good marketing to speak but I personally don't believe the culture. We still need trust. And a good illustration of this is the idea of a notary. So people talk about being able to use blockchain as a notary, I'm gonna tell you why this is not really a feasible thing all by itself. When a notary witnesses a signature they have an obligation to not only to verify your identity and it sounds like oh, you can do this with blockchain and using the asymmetric key pairs and so on and this is really good at identifying information. But there's another obligation that comes back to this more human level as well. Which is that the notary is obligated to take steps to ensure that you are of sound mind. Is this a crazy person that's come in, make it off the street trying to give away their family fortune? Do you understand what you're doing? Is the contract or whatever's in front of them that they're signing so complicated? Have you really read the fine print of that, Mr. Smith? This is a really important function. And another one is are you under duress? Is there a band full of ninjas holding your fiancee hostage in a parking lot and you're pressured to sign this thing or go through this transaction? And maybe AI or something like that will eventually save the day. But blockchains can't actually do this. They can't do this human part. So it's pretty important to keep that in mind in these conversations. So I would propose that the real problem that we're trying to solve here at this stage in human history and technology and so on is how do we establish trust quickly without direct experience that we can use to gauge the risks? So you don't know someone. How do you trust a stranger? And at the same time, at the same time, you protect the privacy and protect the privacy of everyone involved. This is a really, really hard problem. It's full of all kinds of complexities and subtle gotchas. So, and the kinds of situations where you might want to do this is something like when you're lending money or renting an apartment or hiring an employee. And these kinds of things often get done by way of massive disclosures of personal and private information. And we've already seen how this could be disastrous on a large scale, like with the OPM hack. But they're more common and individually harmful ways that these disclosures could be problematic. Like an employer or landlord or lender might engage in discriminatory practices. An employee of a merchant might take some customers private information and use it for some nefarious purpose. And then there's also the problem of stale data. So, you know, stale credit scores or ex-criminal records, those kinds of things. And anyways, I think this is one of the big problems right now. How do we trust a stranger? And someone added this image to this slide that was helping me find images for slides. So I haven't seen it yet. There you go. There's a few missing links that we need to deal with here and changing notes too, cool. And our boss, Sandy Pentland has outlined some opportunities the kind of higher level goals that we're looking for when we're designing these new systems. One of them is contractual auditable control over data by all stakeholders. Another one is security of identity, data and transactions, minimizing data sharing using trusted local computation. We have some interesting approaches to this here at the lab. Total encryption. So at rest and end to end encryption even if the actual data packets are stolen they should be unusable. And then also the last thing, and this one is close to Daz's heart is matching technical architecture with legal and governance models. I'm sorry. Yeah. Could you say that again? Matching technical architecture with legal and governance models. So we need these things to be harmonized or we're always gonna be at war in court. At this point, I think looking at the time, I'm gonna say good night or something. Did you have any, were there any other major points that you wanted to? Yeah, I think we're good. Probably not time to go into specific technical details. Was this helpful or appropriate for people? Can you just go over those four goals a little? Just sure, slightly more. Sure. Contractual auditable control over data by all stakeholders. So not only is there data, but you guys familiar with the idea of an adhesion contract? Anybody? So when you go, you have all used them many, many times. When you don't have a choice and you're presented with a button that says I agree and you can't go forward and do the thing unless you click the button, that's an adhesion contract. So you don't necessarily have control over the data that's being collected. You don't necessarily have control over how it's used. There's no legal recourse from your perspective. I mean, you're kind of giving up all of your rights. We kind of need more open systems that are dealing with people's rights over data. Contractual auditable control over data. And that would be by all stakeholders. That's an important point is that a lot of these, a lot of situations that is very one-sided that not everyone is even on the same playing field, let alone having it be level. So the second one is the security of identity, data and transactions. The next one is minimizing data sharing with trusted local computation. I could talk about that one all day because I write a lot of code around that one. Trusted local computation. Minimizing data sharing with trusted local computation. Trusted local computation. Yep, this is the OPAL stuff, open algorithms. So in other words, you wouldn't share the data out to everyone asking. You're not giving away the data somewhere trusted. Or you keep it somewhere trusted. So for example, we have a system that we're working on where this could be a personal data store or it could be some company and companies and businesses and governments and healthcare organizations and nonprofits and things like this. They have very valid and good reasons to share data to improve their understanding but their vulnerabilities when doing that. And so the new proposed approach is that they hold on to the data and that they do the computation and get back the insight without the data. So instead of giving away the data, we're giving, we would be holding on to the data, keeping that safe and protected but sharing the insight itself. So. There's something called, I've been thinking in healthcare about informed consent and the huge gap between what somebody goes through and informed consent. And it's a very big gap. And it's just for first, I know too, that's been probably P minus 15 seconds which should be informed consent and I want to call on you first. But can you tell us the four things? Oh, sure. Narrative medicine is the, to the gap. Narrative medicine? Narrative medicine is the, no. I'm gonna have to repeat that in 15 seconds. And then we'll figure out like, oh, that's what you mean. There's two more. You gave us five seconds. Two more. Yep. The fourth one is total encryption. So encryption at rest and end-to-end encryption. Total encryption. Yep, total encryption. So that means that when your data is, when it's stored, it's in an encrypted state and that it's end-to-end encrypted when it's being communicated. So things should never be passed around in plain text. They should never be stored in plain text. And if we can get away with it, they shouldn't be computed in plain text. There's something called homomorphic encryption that people are working on here that deals with actually computing over encrypted data without decrypting it. It's kind of neat. Number five is matching technical architecture with legal and governance models. So this is the technical architecture. I feel like that's one of the five things that's a lot more possible. Yep. With legal and governance, you said? Legal and governance models. Yep. And what are, this is a list of what is the, what five, what? These are the things that we're working on in the trust consortium. This is the high-level goals of our work there. And we're designing future infrastructure and we're thinking about these problems and the things that we talked about today and how to control those things into new systems. Awesome. Okay, so those of you who are not individually involved in the Hatch Tag is? MIT ID 17. MIT ID 17. So we're going to turn off the LivePass channel and watch the GitHub and Twitter channels to see if we have a LivePass again. I think we're probably will toward the end when we're synthesizing and wrapping up. And feel free to take questions and ideas coming over Twitter. Thank you.