 Welcome, welcome, everybody. Hello, I am Daza Greenwood and I'm joined by Brian Wilson and Megan Ma of the law.mit.edu research initiative and specifically the MIT computational law report which is putting on this year's seventh annual MIT computational law workshop. And we're going to get right into it today. We've got a really packed agenda and I'm going to hand it off to Jim Rogers. Oh, could we advance the slide? I'm going to hand it off immediately to our first speakers Jim Rogers and Danny Blood who are going to discuss our case study on a business legal and technical integrated system. So with that, hopefully my audio is okay and you can hear me and I'd like to hand it off to you now. Great, if we can just advance to the next slide. Brian, are you running the slides? Oh yeah, is that going? Oh, okay. Well, you're doing that. I'll do some intro. So, yes, I'm Jim Rogers. I actually work at the Hartford Insurance Company out of Hartford, Connecticut, soon to be underneath a lot of snow and I lead our agency automation at the Hartford. So we're about a 200 plus year old company. We're in the financial services industry. We provide property casualty and group benefits products to agents across the United States and I'm joined today with Danny Blood and I'll let Danny introduce himself. Thanks, Jim. My name is, Jim said is Danny Blood. I work for a company called Boston Software. Boston Software is a small independent software vendor. We provide software for the insurance industry. Primarily our software is used by independent insurance agents that represent companies in the property and casualty realm. Well, great. So today, Danny and I just wanted to join. We're both on the board of ID Federation. We wanted to talk a little bit about, you know, what problem our industry had or has and we want to share with you our story and what we've gone through with a lens on how we work. We tackled that problem. Danny's going to start us off with give you a little frame for what our challenge was or is. Sure. The insurance industry is probably notoriously known as being slow moving at least in a technological perspective. Maybe some other perspectives do, but when we talk about the internet age in the insurance industry, things started rapidly moving, you know, circa, you know, 2000 with the advent of web services in particular. And so what happens is insurance companies are starting to open up their platforms to allow independent agents that they represent them to be able to get into those systems. So it may be a little step back in the context. Independent insurance agencies are agents that represent multiple insurance carriers. So an independent agent is the kind of agent that you walk into and they may be able to give you a quote for four or five different companies for your auto or your home as a consumer. And this is the realm sort of in which we work in. Now with the explosion of these web services and the ability for insurance carriers to provide their offerings online, there also was the vendor space, which is where I work in where we provide software for the independent insurance agents. Our software allows the agent to enter the consumer information for, let's say, auto policy. You enter the information in one, and it's got connectivity to the RMV for the registry of motor vehicles, lookups and stuff like that. They enter all that data once, and then they can click a rate button that gets rates for maybe 10 different companies. Because an independent agent, small shops might represent three, but bigger insurance agencies that have multiple locations might represent 10, 20 different insurance carriers. So our software is sort of, if you think about orbits, how you can go into orbits and put in your flight you want, you get all these different availability and price points, our software works in a similar sort of way. So vendors like Boston Software have services that can connect directly to the carriers. So now if you're an independent insurance agency and you're representing 10, 20 carriers and each one of those carriers has their own set of credentials to get into their system, that presents a challenge. If you're an insurance carrier like the Hartford and you have thousands of agencies and each of those users has their own set of credentials, you can see how the scope of credential management really sort of gets huge. Now in the industry in general as these web services became sort of became widely adopted, more used, and people were doing more connectivity, you know, as people started saying, wait a minute, how are we going to secure all this stuff? Right. And there are, you know, famous stories, you know, and we have a slide that shows it in the insurance industry of the people that work the front lines at an insurance agency. What we refer to as the customer service representatives, the CSRs might have 10 sticky notes literally right on their monitor with the username and password for each system that they need to log into. Now clearly this is not a tenable solution for the long term for us from a security perspective. And if you're the owner of the agency, this is obviously represents the security risk for you. And then just the management of all those passwords, you know, it just becomes completely arduous and it's still a problem now. I mean, it's still a problem that we're trying, this is the main problem we're trying to solve. How do we handle one particular identity, one person as an identity that gets you into all these spaces so that you can remove all that friction, all the management of different passwords, different identities, and be able to do the work that you really need to do, which is the business of insurance. That's sort of the backdrop, the problem that we were facing as an industry and the problem that we tried to tackle. That's great. So I'll help out with this one. So Danny framed that really well. We want to eliminate or significantly reduce the amount of passwords we have in our industry. It's plain and simple. It's our mission statement. So what do we do about that? So a bunch of us got together in the insurance industry, specifically in financial services, and we decide there has to be a better way to do this. It has to be a better way that we can create a framework on which parties can work together and figure out how we can just have users have one ID and get to multiple carriers. They've got to be away. And so what we did is we created what we now know as sign on once. It's really based on rules that we created by creating three entities within sign on once. We have a business group, a technical group, and a legal group. And we formed those. And we had the great fortune that at that inflection point many years ago, Meet Daza and actually helped us a little bit with that structure. And we use those today. And it was developed by those three disciplines. I would say the three legs are all equally responsible for creating structured agreements that we created for the organization. We have technical certification process. We've developed rules. We'll talk a little bit about how we do that. The business really drives it. They drive what are we trying to accomplish? How are we going to get our messaging out? What's going on? The technical committee, they're working on more of what the standards are, where we're headed and where we're going. And then what did we do to address sort of liability and indemnification? Those were very big concerns that we had. And how are we going to deal with those? If there was a loss or there was a breach or something were to happen. And what we decided to do was we couldn't, we were branded ID Federation, like if you go out to idfederation.org, but our users, our agents would have no idea what that means. So, our business committee decided to come up with sign on once, with a little hand, and that's what you got to do. And we created an organization that's just passionate about getting rid of passwords. And today, as Danny described, on the far left are all the sticky notes. That's being generous three. We're talking like 40, 50. So, when you have an agency that has 20, 30 employees and they each have 40 passwords, some organizations are big enough where there's just one person that tries to manage all the passwords. It's really crazy. We actually streamlined it and implemented a process where an individual can log into their platform, be authenticated, and then that platform's logging them into parties that are affiliated with this framework in a seamless way. That's much more secure. And we don't have to worry about so much passwords. I'll let Danny, you want to pick up this one? Sure. I mean, I talked a little bit, but yeah. Yeah, what I was going to add was that, you know, when we're talking about sort of the parties involved are the independent insurance agencies and those users. There's the insurance carriers, and then there's also the vendors. And how do you get all of those groups of people, those three different groups of people, each with their own needs requirements into a working relationship in a way that everyone feels like their needs are met and satisfied and that we can move forward? And that was sort of where ID Federation as an organization was born from. That how can we put something together? Why DASA was involved? What kind of structures work to make this kind of thing happen? And that was where the brainchild of it all came. We have to put together something that can work for all the needs of all the interest in parties, but still solve the main solution. And the goal of it is that we are working together. This is this part of the thing that we all share, security, for example, identity management. We don't want that to be a differentiator. We want that to be something we all work together to solve that problem. So ID Federation sign once it's a nonprofit, right? We were organized in that way. I mentioned the partnership, the different people that are involved. And as Jim said, it's sort of a set of the three different legs, the technical, the business, and the legal, getting it off the ground, though. As Jim will tell, if you want to hear some stories about trying to get all those legal arrangements, insurance companies, like the Hartford, for example, is a very large insurance company. You can imagine the attorneys on Jim's team, the requirements that they might want versus my software company is a very small company. We have less than 30 employees total, right? Different needs, different requirements on that set. Trying to get all those people together, the legal piece was a big part of it as we were trying to get it all set it up. But we needed to get all those sorts of pieces as buying. Yeah, I would say too, Danny, on that front, like our board was interesting how we structured the nonprofit and the board. The Danny's point, we had Fortune 100 companies, and we had, to the size of Danny's, Danny may be a small company, but has very big market share, say, in the Northeast with his product, right? But, you know, the Hartford would want indemnification, like unlimited. Danny's like, well, that would put me out of business. So the legal teams, when we first started together, had the hardest job to really look at all the different organizations and what we did. But when we formed the board, we created, and some of the other nonprofits in our industry, or standards organizations, sometimes they're not all inclusive. Can all their members be on the board? Maybe only certain types of members can and others can't. We didn't want to have that. We wanted an all-inclusive everybody in. So we have about a third of our memberships, our insurance carriers, a third are software providers like Danny, and some are independent agents, and they all have equal weight. So the Hartford can't trump Danny's vote? Danny can't trump mine vote. You know what I mean? So we keep the board so that all the constituents are represented regardless of their size or status we actually wanted representation from the three in our industry. We have, for a sign-up, once we have business, technical, and legal, but also in our industry, we have carriers, independent agents, and software providers also. And so I think, you know, Danny brought up a great point on the legal side of that. Yeah. I mean, the last, and if we go back just for a second, the last bullet there sort of gets into what Jim was saying, that's solidary. You can, I think, easily see from the other bullet points, like the value add that an organization like ID Federation sign-up once could provide to the industry just based on the description of the, and we've all experienced this, right? The explosion of passwords and identity and management. Now, you're a small business owner, and like Jim said, an independent insurance agent, you have 20, 30 users, and you're representing companies. It just, it becomes a really, you know, really difficult situation you can see the value add. But you get that last bullet point, we needed that community solidarity. One point, we're all moving and working to the same group, and that's why you really need an organization, a nonprofit, independent organization that's fully represented by all the interested parties, but that we could come together and solidarity create a solution. So the trust framework, we created what we call a trust framework. You guys can actually see it out on our website, I think Daza posted it in the chat. But it defines the governing rules and participating in ID Federation. It's reliance, it's based on commercial relationship. Most of our partners work with each other already. So they have underpinning legal arrangements already. ID Federation kind of sits on top of that. I mean, if they don't have any, they can live within the framework and its indemnity rules and how we handle security. But if they have existing ones, it kind of builds on top of that. We want to improve the identity and password management in federated ways between the parties. The framework applies to parties who have executed it. So you have to join ID Federation. We do have some costs to cover our costs to run the organization. But as more people join, we just lower the fees because we don't want to make any money. And there is some limited liability protection between all the participants that join. So that trust framework is really the essence of what ID Federation has. We don't, just to be clear, the transactions between an independent agent and a carrier do not go through or physically don't flow through any software that we have. Or they're not going through a hub. I mean, Danny, maybe you can explain that a little bit more. But yeah, I mean, it's a really good point that I was going to add on to, which is that the trust framework itself isn't software. It's not a product. What it is, it's sort of like a bubble, a legal agreement bubble that the people that are involved in the trust framework, like the old jokes about the circle of trust, well, in the trust framework, you have to be in that circle of trust to be a participant. You have to pass the certifications, which we'll get into if you're an identity provider. You have to be a member to participate those kinds of things. But the trust framework with the three legs of the legal pieces of it, the business agreements and in the technical sort of specification and requirements provides the bubble or the arena in which the trust framework operates. It's not a specific product. It is not a specific piece of software. What it is, it's a set of agreements. So in our next slide, we encourage those constituents to join. So how we do that, we work within the industry, we attend industry events, conferences. We're constantly looking to grow our organization. And a lot of that has to do with software vendors like Danny working with carriers like myself and actually connecting up that technology and following the guidelines in the trust framework rules that we've agreed to for security. Let's go to the next one. And so Danny, I'll let you handle maybe security certificates, like maybe you can talk to them about identity providers versus relying parties and how we handle or how we, how do we trust, how do we build trust that the identity provider is, I don't know, trustworthy. It's certified. Right. Well, so based on the group, we may have made a little bit of a leap on everyone understanding what federated identity is. You know, the federated identity is the idea that someone knows who you are. And instead of everyone along the chain of communication having to re-ask you your challenge questions via your credentials or whatever, if they have a trust relationship that they will be able to trust that this particular person is who my software says to Jim. So if I am federating the identity, then Jim will trust that that person is that person because they fall within the trust framework or our software or our organization falls in the trust framework. And he believes that that identity is the identity that I say that it is because I've done things to verify that identity. So we talk about, you know, getting into the trust relationship. I was trying to find this, there was a quote that Daza had, I can't remember exactly what it is, but the idea is that you like, the trust is verified. You know what I mean? It is like there's a set of security standards and we have what those security standards are, they're defined and someone has to be certified to be able to be an identity provider. So the identity provider is the person or the organization providing the identity. They then are giving the identity, federating it out to other people that they can connect with so that the user, the end user doesn't have to sign in to all those systems over and over again. So the identity provider is the place where the certification needs to build from, right? They're the ones who are verifying that I am really Danny Blood and Jim is really Jim Rogers and that once I communicate with someone else and I tell you that this is Danny Blood or this is Jim Rogers and you believe that. So the security piece of it on that side is really about a set of standards, security standards we have. We'll get into some of the specifics a little later on. But it's all about having a very concrete security posture that meets a set of definitions and standards that we've come up that are based on best practices. I mean, we're not trying to manage that per se. I mean, we're using other industry standards and whatever to sort of define that. But the idea is that there is a security posture, it's been verified. And like I said, the trust is not given. The trust is actually verified if you're a Danny provider. We have various requirements that are built in. We go back one, sorry, just a second. Based on user ID and password requirements, there's stuff there about the management of IDs and passwords, etc. The types of certificates that can be used because we talk about the implement, if we get into implementation details, that's like a SAML security token that's being passed around and how can you verify that. Various ideas, how organization manages their certificates and logging and monitoring is important because you need to make sure that if you're an identity provider, you need to know when there was a failure as well as success because you can go back and trace and have audit logs of that information so that you can see, are we having attack situations or there's someone trying to spoof identity, that sort of stuff. And it just goes on and on from there. As you can imagine, there's a whole series of things that need to be validated for someone to be verified and enter that trust framework as an identity provider. You want to take a thing or you want me? I can do this one. Quickly, since we were just talking about the same idea, the certification process, like I said, it's required for an identity provider. So if you're on the other side, what we call the relying party. The relying party is someone who's relying on an identity provider. So in the real world example of an independent insurance agent using our My Software, Boston Software's product that's known as single point rating, single point rating, if we're the identity provider and we want to get a quote from the Hartford and send that information and be able to connect to their systems, then Hartford then becomes the relying party. They're relying on the identity that we provided. So the certification process is that, like I said, the risk flows downhill. I have to be in charge of all that risk if I'm the identity provider. So that's where we have to have the certification at the identity provider side. Relying parties don't necessarily have to be certified. They have to sign the participation agreements which has a set of its own sort of standards, but it's like we're not verifying their systems per se. The certification assessment is done by third parties. We have a couple of different ways in which it can be done. The certification options are listed there. Smaller organizations or industry organizations often will choose a third one, which is one through a third party assessment where there's a set of standards. We've partnered with a company again that helps us. We're not in the business of identifying and managing the best security practices. So we work with a company that provides that, a consulting company that sort of helps us through that, helps us define and build those questions. And then we sort of form that out to them for the certification process. There's got to be third party. I think that sort of gives the general overview of what we do. But oh, the final point there is that the board of directors sort of Jim and I are both on the board directors for IDFED. It's our job, one of our duties to and surely we're overseeing and reviewing the trust framework and changes the results of certifications. And we have the final set of approval to grant certification to an identity provider. I think we covered some of these, Danny. I would just add the, you know, Danny, the other thing too is that certification is an ongoing process. So if there's material changes to their, through their models, then they go, they re go through, if where the identity management is created and managed, if they're moving that from one cloud to another, or there's material changes into their structure, they have to go through certification again. And no matter what, even if it's the same every, every three years, they have to go through certification automatically. So it's a constant test, make sure, verify, because everybody's trust in those, those identity providers. So if you guys have questions, just put them in the chat. I'm going to cover a few more things. One thing I did want to mention before I get into future enhancements was one part of our structure when I was thinking about this early on, when we started was the structure we have. And we really had the business, technical, legal, and we had a harmonization like box. And the role of that person or individual was to harmonize the work going between the committees. So that, you know, the law department would say one thing, the technical people would say you can't do it that way and the business people would change the process. So the harmonization box we had person actually in there came from the industry and he had a background of almost like an arbitrator. And he helped us like in all the organizations like he knew where we wanted to go because the board would set the direction. But he would help and he had it. He was like an arbitrator and he happened to have a law degree. So he could and he was involved in technology. So we found the ideal and he was trusted by the entire insurance industry. So I'm like, oh, we picked him, we recruited him. We said, you're in that box. There is no way we can get everybody to agree on all this stuff. And he kind of put us in rooms. He would help us like think through what the main obstacles or gaps or issues were and ways to like work as a team to work through those. Now we don't use that role so much now. We've been mature for many years and we don't actually use the law side of it much because we have everything's pretty much going, you know, fairly well. We bring a law team in as we need it. But most of the work right now is on the business and technical committee. So when we look at like where we're headed and where we're going, one is just, you know, we're going to considering adding more to the provisioning and deprovisioning users. So we want to adopt our biggest thing is adoption. We want to eliminate passwords. It's our same mission. Missions never change. I know mission statements sometimes change as companies grow. Bars never changes. It's always the same motto. And we want to eliminate passwords. We are looking at how identity gets deprovisioned. So once an identity provider removes somebody in their system, we want a way for them to just tell the Hartford or tell all the other carriers that this person no longer is employed by this agency. Now, since they don't know their IDs to get into our systems, I mean, if they leave the agency, they can't just like log into our system because they they wouldn't know how to log in as they were federated. But we still have that identity in our system. So, you know, what we're looking at ways is to make sure our identity is like cleaned up. Like a lot of times we if we don't see somebody log in for a long time, we'll just automatically purge their credentials. But we thought it's better if our identity providers could have a way to tell us now. You know, our nonprofit is not going to create those technical standards. But the technical committee is going to look at what are existing proven standards that would allow that business function. And could we incorporate those standards into our framework. So that's one thing we're looking at. And then also in the future, how to provision new users. So right now, if I have an agent, they want to do business with the Hartford, they actually create an identity in our system first. And then when they try to do a transactions from their agency with their identity provider to us, it syncs up. We see the identity, we have keys that we match on certificates like everything, we're good to go. But we would like a way to have the agent or the person say, hey, I do business with the Hartford and just, you know, walk them through a process where it just automatically provisions on our side. So there and there's probably a lot of people on the column and much more about the technology and standards than I do. But those are what our technical committee is doing. And technical committee, you know, it's interesting the types of people that we have on those committees, because some are more into the development side of it. Some are more the chief security officers at our companies. So it really depends on what the topics are. You know, who from a technical point of view that we're bringing into those committees, you know, so they morph on the business side. I would say we've had people from carriers that are providing their marketing people. We have people from agencies and software providers that are like more product visionary. You know, this is how having a stream blind workflow can work with sign on once in products. And so from the business, there's some different people with different expertise, but you put it all together. And they're pretty powerful each committee sort of on its own. But those are some of the things and where we're headed with our users. Some of the you can see on. I don't think we have a slide with the users, do we, Danny? I don't think so. Well, just jump in for a sec, Jim, that everybody a little bit more context on the committees. The committees, we talk about those, you know, the three legs of the trust frame. We have a committee for each of those. Right. As Jim said, most of the work right now is happening on the business and technical side, but those committees are made up of volunteers from the members of the organization. Right. So the board of directors is made up of member people that are members, right? Nominated from their, yeah. Nominated from their company. So, you know, Jim and I have been nominated to be board members from our companies, representing our companies, but from our organizations, we have people that work in the committees and do some of that work. So the technical committee, you can imagine, like Jim said, you have CISOs and deputy CISOs or people that are involved in that kind of stuff, as well as developers helping formalize some of that stuff and review some of the technical pieces. And on the business side, as Jim said, it's again, they're volunteers from members of the organization, of ID Federation. So that was our logo. That was our model. That was kind of a brief, we went through that pretty fast, Danny, but that was at least an essence of our story that we wanted to share with you today. And, you know, does it and Brian, if there's folks that have questions or they want to send some in or if your group has any, I think Danny and I are more than glad to answer some questions that you may have or that we didn't cover. There's a long history here. It's a very interesting way we've kind of, it's very interesting. It was great to see all the constituents like Danny opened up with. We want to compete on product, customer service, claims paying ability, price. But we all agreed we're not going to compete on security. We don't want any of our members or anybody in our financial services to be in the news. So, you know, it's been great from that point of view and to see our members have that spirit and to work together has been great. You're here. Hi, can you all, is my audio okay now? Yes. Apologies for the, I blame Comcast for every evil thing that happened at the beginning. But happy to have said that. I just wanted to applaud you both for that presentation. This is the first time I think that there's been, outside of the insurance industry, like a coherent, like explanation of this really important federation and this important model. And I'm just completely tickled and pleased that MIT is able to provide the forum for this. And I think there's a lot of latent learning in what you just said and what you said is so dense. Like we could pick any single thing you said and go an entire semester on this. But what just a couple of things I want to highlight by way of maybe catalyzing questions and comments. Well, we'll start with Jim Hazard. Hi, Jim, who says thanks for the links in the participation agreement to the participation agreement. Everybody is it okay if I add to the group data sharing to the group of data sharing solutions. So one thing I want to say is one of the great best practices of ID Federation that's brought you the sign on once service here is that they had the courage to actually make their system rules that the the trust framework and the agreements public and they're published on the site. So Jim kindly mentioned that I've been involved in the sort of helping put this together in the beginning. I've put together many of these types of federations and you know, different types of consortia, but no one else has been willing to actually share the rules so that it can be understood and reused to some extent. And the same goes with the participation agreement. It's right on the site and it's um I mean go ahead and it's it's your just to say but I believe it's completely public and reusable for other industries that may be interested right. That's why I have a publicly available website. Yeah. Yeah. Dynamite, thank you so much for that. And then the other one of the other just before we get into the details deep learnings that was embedded in the last thing that you said Jim is that we're not competing on security. We're not competing on passwords. Like we do compete like providers like you and Liberty Mutual and progressive compete on selling insurance. The vendors compete on customers. The brokers compete, you know, for for end users and policy holders. And so that I would say this is a great example of what is sometimes in the like the Sloan School of Management or business schools they call co-operation. Where there's competition at the business level on products and services. But at the same time it behooves everybody to cooperate on certain types of things. And in this case, a network to allow a common set of functions in this case for single sign on without having to have 100 passwords is is perfect. And and I just want everybody who's struggling with this in all so many different areas in your lives and in your businesses to take to heart the clarion call that Jim said, which I think is what made it possible for the whole industry to get together on this and for to have survived and and been stable for so many years, which is that our mission hasn't changed. They have one clear beacon like lighthouse mission of we're going to kill passwords. And there's a lot of adjacent security things and business functions. Wouldn't it be nice if we can have these other services? And there's a lot of other stuff you could do. But in order to pull off something that's complex at the business level with competition, different relationships and commercial pressures, the legal level, it's somewhat, you know, complicated with like who's liable when someone relies on someone else to log in and security openings, the technical level, there's some complexity there. You need to have a clear business objective that you can measure and that the law and the technology can support and reflect and achieve. And so I just think there's a ton of leadership by example here that I hope everybody can can take us learning from this, which is get the business part right first, write it down like in use cases, and have the legal and the technical part support and reflect it and then be real careful before you budge at all from like just doing one thing right takes a ton of work. The more you start scoping and creeping the mission, the much harder it gets. And so I mean, if that's not super clear, I just want to highlight that it's like embedded latent wisdom within what we just had shared and and don't take it for granted. Okay, now then. So now let's now where those things are at a high level. I want to encourage anybody that has questions to bring them forward. And we've got our first one already from a alumni from the MIT Media Lab and actually a college friend of mine, we went to Clark University together back in the the 80s. And it's Brendan Marr who asks who says I have questions on SSH and DIDs. Okay, so could we promote Brendan to to let him on mic please? Yeah, or let him on mute rather? Just one moment. Great. And so for those that may not be familiar, DID is a shorthand for like the new new shizzle in identity, which is decentralized identifiers. And it's basically when you have a if you're doing something on a blockchain nowadays, you'd have a wallet which generates a key pair. And there's a protocol that the W3C Worldwide Web Consortium has published a few years not many years ago, that defines how that can be the base of an identifier that you can use for on for lots of other purposes, mostly it's digital signatures, but you can and I've seen integrations that you do log in with it as well. So at the bottom of the stack, the kind of credential is the private key in like a blockchain wallet. I'm not doing it justice, but that's that's the nature of it. And I might further say, by the way, that part of the reason for bringing this case study forward is to give an example of the things that it takes to get a whole industry with different players in the industry, the providers, the vendors, the in this case, it's the agents and the brokers, like we have this whole constellation of people that have to do one technical thing kind of the same way. So when you're looking at very fresh new technologies like a blockchain and decentralized systems, part of what we're trying to say here, impliedly, but I'm going to make it explicit is this is like your list of things that you want to solve for. So just kind of saying it's secure or it's trust less. Okay, that's nice as a slogan. But like, go ahead and get a spreadsheet and take each of the items that Jim mentioned, or go through the system rules, the trust framework, and make sure that you've addressed each one to the right level of proof and reliability in the new way. So this is also a great cookbook of the types of issues that it takes at the business legal and technical level to solve for. So with that, Brendan, are you are you with us? I am, I can't get video. Oh, no problem. But we have your audio. So we have your essence and go ahead and ask your question. Thank you very much. I hope you often hear me clearly. I wanted to say, great going with the BLT, the business legal technology. You know, that's one thing that I picked up from from from Daza how important, you know, all those pieces are and it seems like you're really hitting it. I did want to speak to and throw out some clarity and post some some questions. The first is, you know, I find it all very interesting, right? Because, you know, as I've come into the identity space, you know, it's clear that there's such a disconnect between how the computer industry manages and deals with keys in terms of thousands of servers in a data center. You know, nobody's in a data center remembering passwords, right? It just doesn't work that way. It just it's not the way it's done, right? There's there's SSH, you know, there's cryptographic keys for all those servers. You know, so we have we have ways of of of doing this. The issues are regarding the mapping between the the keys to cryptographic keys and and, you know, what is, you know, reasonably understood to have a meeting relative to people and organizations and teams. And, you know, this kind of gets towards, you know, the so the first question is, the first question is, you know, have you, have you, you know, thought about the, you know, the way that the technology community deals with SSH? I kind of missed some of the details of your implementation. Sorry. But the question here going towards the larger question is towards blockchain and decentralized identifiers, because, you know, blockchain at its core has signing and transactions, which are cryptographic keys. And there are large bodies of entities that are putting forth decentralized identity standards, including the web three and all the major players. And being able to map organizations, people, groups to keys is really the only path forward, as I see it. Please speak about it. I'm sorry, I'm a little long winded here. Well, I mean, I'll jump in, Jim. Yeah, yeah, I have a reaction to it, but you jump in, Danny. Well, I would say the way that I would start by catching it is that sort of in the way that does it did. So we have right now a working sort of solution. And then adding into that decentralization and blockchain is not something anybody I think is opposed to from a technological front. Now, there's probably concern on the insurance carrier side. These things would happen. But the way I would answer the question in terms of ID federation is, is that we're constantly looking and exploring about how identity is going to move forward, how it's going to be managed. Because in the end, what we want to do is solve the problem for our industry in a seamless way. And as Jim said, we're not there yet. We've been doing this for years. And the industry is slow moving. And we're still trying to get more adoption. So if that moved the needle on adoption, we would be looking at that because we're working right now at things all about adoption. So in into backtrack and not exactly answer your question, but give you a little piece of context, one of the things that we are really looking at now and trying to figure out how it would fit into our system is third party identity, identity providers. So if you're a larger insurance agency, and you have multiple locations and you probably are using a third party to federate your identity already for single sign on to different apps within the system, examples are Azure Active Directory, paying octet, etc. Right. Some people may be familiar with those vendors. But those things don't fall within our trust framework because they're not a vendor that's in the insurance space. So we're trying to figure out how can we get greater adoption by utilizing some of those technologies. Now, again, if it comes down to everything moves towards decentralization, and it just becomes a mapping issue, well, then we'll then we'll pivot that way. But for right now, we're not really even exploring those kinds of things at the moment. Yeah, mine was just back to our mission. And we have a ways to go on the adoption. And so our teams are focused on taking the framework that we have that we trust evolving it. But we're laser focused on getting this benefit out to our constituents and our independent agents across the country. But I'm with you, Danny. You know, we're constantly looking at new things. We're always looking to learn like from this workshop and others and bring those ideas back into the organization. But we definitely have a mission to spread the word because it's free to our agents. It doesn't cost anything. And our vendors and our software providers don't charge for it either. So it's more of just an implementation and awareness. And the change management of it is what we're working on now. Question here. Have you have you looked into zero zero knowledge proofs? They might be useful at some point. You don't have to expound upon that, but I'm just starting that out there. No, that's great. Just a thought on, just to follow up a little on Brendan's suggestion basically to look at zero knowledge proofs. I agree that could be useful for some of the business capabilities that you're trying to solve for. And in particular, the thing I would look to, and I'll find it when you're answering the next question if we're in the chat, but I was working with Ernst and Young at the end of last year on some related matters. And one of their projects is an application of zero knowledge proofs for basically the collection and distribution of sort of like value-added tax kind of things across jurisdiction. So that we've got a system that sort of deals more elegantly with the need to protect some information, but still have verifiable proof that some action has happened and the source of the action, that sort of thing. So some of that's just the technologies very interesting. It's also very interesting how they approached coming at their own kind of federation. In that case, it's mostly of governments and businesses that have to comply and the systems have to work together. In some ways, they were solving for even more complicated things with sovereign nations. In other ways, it's a much narrower question, but I'll find a link to that. They did an excellent white paper on it that break down all the world. And actually, the business legal and technical each all have a pretty clear section. So I'll do that now. So let's see, we have... Okay, we've got some questions here. Oh, people are asking for that link. Computational privacy. This is Mark Lazar, who's worked, I commend to you by the way, from another standards group, Paul Contara. He's done great work on standardizing a way to provide basically like a log or like a receipt. He calls it of consent. So when you've got a person shopping around for insurance or when they're filing a claim or something at some point, there's a lot of little consents like I consent to these terms. I consent to sharing information and a lot of consent management. And so he's done great strides in how to sort of encapsulate that in a way that's more standard and you can kind of incorporate into different systems for different purposes. Anyway, Mark's question is computational privacy, authorization standards like... Oh, well, there it goes, like consent defaults off C. So I think he's asking somewhat generally like where does the... So when I think of SAML, the security that is being asserted in the security assertion kind of markup language is really authentication. Correct. And so now I think he's starting to get into authorization. So how is that laying into this? Like... Well, we haven't, but we're starting to look at that right now. The technical committees are looking at the authorization side of it. It's a little scary from a carrier point of view. We like control. Once you get into our system, we like to control what you're authorized to see. But it's something that I know, Danny, we've had some discussions on that and there's kind of different ways around it too. Yeah, no, I don't know that we've landed anything harshly. You haven't landed anywhere at this point. It's a discussion point. I'm not really knowledgeable about the stuff that Mark is referring to. I would have to look into that a little bit more to see how... I mean, I understand that the idea does explain, like there is the consensus that people have to provide all the time and as vendors or companies that you have to track it and log it and keep it. So I will take a look at that information. So thanks for the question, Mark. And I can offer a little context putting on my... Well, I don't have it, but like if I put on my ID Federation hat from 10 years ago, some of the concept, as I recall, from security was that there's a kind of a clear architectural handoff for this system. So part of the narrow focus on the pillow password is its password for authentication. And then there's a hand... So when you log in, there's at the back end on the relying party end that the brokers are logging into, you get access control lists, different authorization functions. So it's dealt with, but it's sort of like we authenticate the user to get into a system, which then deals with authorization on our back end. That's how it works at every insurance carrier today. Yeah, that's exactly how it's implemented. Now, the relying party, once the users... Once you know who that person is, then the identity is mapped to the authorization that that identity has. And then, in theory, I guess in the future, maybe if there's a business need for some authorization that could be sent along in a tokenized way. That's what we're thinking, Daza. Yeah, that's kind of where we're just like, how much do we do with that versus adoption of what we already have? You know what I mean? And of course, Sam, there's other ways to do things also that the technical teams are looking at. So we're just trying to balance that and our business committees working that out. Our technical committee needs to stay a little forward in their thinking. So strategically, we've got the roadmap and the plans that they're thinking of. The business committee is like, whoa, whoa, whoa, we just need 30% more adoption. Those are our goals. You know what I mean? We just really want to see our customers, our agents, feel the relief, not be so worried at night about... Or the agency principals are signing paperwork and testing that they're a secure organization. They're following these rules. And when they don't know what people are doing with all these sticky notes, that's quite a problem, Daza, at least for the agency principals to sign security agreements and they really don't know what's going on in their own shops. This helps a lot and it allows those agency principals to execute on sales and growth and customer service and not have to worry so much about security. They can kind of have a better peace of mind. And we want that emotion and that feeling going out across independent agents. And when we see it, if you go to a conference and you start to see people raise their hand, applaud, like other people have no idea what's going on. So they're kind of, oh, why are you so happy? Oh, because I work with the Hartford and I have a single sign on and we just need more of it. And that's kind of where we're headed. Yeah. Well, MIT does not endorse products or services or companies, but it's certainly understandable at a high level to say, why am I happy? Because I work with the Hartford and look at how great. Yeah, I'm not trying to use that. We have many other carriers on the thing, but I think the agents are happy about it. Yeah, I know. But one other thing that is worth saying, as you were at the bottom of the hour, but it's related to authorization and it's part of what sparked us some getting in contact again, which is if everyone looks at the most current trust framework, which we link to, it's at IDFederation.org and com also under join us, I think, you'll see that the newest amendment is to bring on board in addition to SAML open ID connect, which is the, which is a an iteration of OAuth2, OAuth2, a really great modern standard that encapsulates identity and related credentials in a modern web facing way. And so, you know, congratulations to the ID Federation and sign on once for really continuing to adapt and evolve in ways that keep pace with it with the technical and business environment. So having said that, I want to thank you so much for taking time out of the middle of your work days to come and share about this great example, Industry Federation and I think a great, if I may say so, a great model of what we're talking about at law.mit.edu and the research and academic context of the need to take business legal and technical dimensions of a system and to be able to isolate them and then align them, harmonize them and ultimately integrate them so that you can roll them out as part of a coherent kind of singular system. Thanks very much for your time and for providing this awesome example. It was our pleasure. Thanks for inviting us to talk, Daza. Appreciate it. Yeah, thanks to you for having us be a part of it. It was really fun. I hope some people learned a little bit of something or a little something about what it is that we do and now we're doing it. I really appreciate you including us here here. And I guess in closing, if you're at a insurance agency or brokerage or insurance carrier or a vendor in the space and you are interested in getting in on this awesome action, it's the join us button right there on IT Federation. All right. Great. So with that, we're going to move forward. And I'd like now to introduce a colleague of mine, Kylian Karen, who is the CEO and founder, I believe, of Ethica. And the reason I've asked, we've invited you to join is because in addition to your for-profit private business that's in the space of privacy, you have, your company has recently released an open source platform that you've been working on for years that I think and our team thinks is a really good example among other things of computational law. And so I'm not going to change my hat from general computational law to reimagining law, which is I think exactly what this is a terrific example of. And so you'll hear the details in a moment, but just to set up the relevance of this and what I hope that you'll be listening for from a law.mit.edu context. Among other things, this platform includes a language and an ontology that makes it possible to express legal rules and legal processes in a way that you can kind of programmatically functionally execute within a system in a measurable and interoperable way. This is part of the dream of computational law, to be able to not have to have a lawyer interpret, you know, like human language in who knows exactly what ways and software, but instead to be able to start to have that two-way integration between what the, how the technical system and the legal system express the same rules and processes. And part of what's so precious about this is it really is working backwards. This is going to be a familiar theme today from business imperatives, which is, you know, we have laws that compel adherence to certain privacy rules. And there's a value proposition here that is hardly academic behind this platform. And so now with that high-level context, and I don't want to do any spoilers, it's my pleasure and really my honor to introduce Kilian to it. And actually, I'm going to ask you if you could introduce yourself a little bit and the context before we dive into the platform. And just as a special request, if we could sort of like the ID Federation leave some time for Q&A. I know firsthand from the email traffic the last few days, there's people that have a lot of questions for you. So with that, take it away. Thank you, Daza. Oh, can you guys hear me okay? Can you hear me okay? Yep. Okay, good. Thank you, Daza. Thank you for having me. Thank you all for having me. I'm really pleased to be here. I'm very excited to speak to you. As Daza asked, I'll very quickly introduce myself and then we'll dive in because there's a lot of ground cover and hopefully lots of questions and discussions to have. So I'm Kilian. I'm the founder and CEO at Ethiga. Just sort of give you a brief rundown on my history. So my background is physics and CS, nowhere near as prestigious as MIT. I went to a college in Ireland and unfortunately dropped out in my final year. My mother's still very sad about that 20 years later. And I founded my first business. My end of year thesis became my first business, which was a data infrastructure business. We built analytics tooling for legacy enterprise. We deployed on-prem in customer infrastructure before contemporary enterprise or cloud existed. And I ran that business for about 12 years. And effectively, we worked with the largest consumer package goods and household brands in the world. So companies like Unilever and Heineken and Coca-Cola effectively providing analysis across their distributed systems in an industry that was evolving very rapidly. And a big part of that was compliance. At the time, you might not have thought it was the GPR, but just risk mitigation related to the way that you were using the data. And it's a very unsophisticated time, if you think back to the early 2000s. So sort of fast-forwarding a little, my business was acquired. I took some time off and I started working on what I'm going to share with you today because I had seen this problem firsthand. And by problem, again, I should emphasize I'm not a lawyer, not a policy expert of any kind. In fact, I consider myself a dunce. But I do understand data infrastructure pretty well and particularly the commercial end of that. So what happens in real businesses in the real world when they increasingly bolt on sort of additional systems and sub-processors to generate materialized views and end up in the mess that we currently find ourselves in? And so the tools that I started working on a number of years ago were predicated on the idea of, I suppose less things code as law, right? Like this idea or law as code rather, that you could in some way translate one to the other, that it should be possible because both are primitives to describe rules of some kind or conditions of some kind. And so what I'd like to take you through today is the, well, from my perspective personally, it's six years work. For Ethica, we're three years old, as a company, it's three years of work. They were launched publicly in November as a set of open source tools. And I'd love to take you through our thinking behind them, the rationale for how we believe that we solve those problems and then show you some practical examples. So in order to do that, is it possible for me to drive and share screens, does or is that because I was going to use an ID at an editor for a while as well? Is that okay? I think so. I'm going to try to use the screen share and see what's going to happen. You can't and make it happen. Oh, there you go. Awesome. Excellent. Okay. So let me dive straight in and present. The only reason I'd like to do this is because I'm going to be jumping in and out of this and showing you a live demonstration as well. So actually, let me just open up the chat window to make sure I see any questions that might pop up. Okay. So what I'm going to take you through very quickly is when I say the problem, it's not the only problem, but the one that we see. So the issues of trust and privacy in software development at large, the way we see that solution, which is FIDES, the benefits of this, what we call a privacy as code approach or probably more concretely a governance as code approach. And then I'll show you two real world examples that will hopefully bring to life the capability of the tools and then give you a glimpse into the roadmap of what we're building and some of the capabilities that that will provide. So the problems with trust in software development is I think we'll probably all agree with this at some sort of personal level. Privacy at a fundamental level should be a feature of every technology system. It should be just an imbued characteristic or behavior of the system, but it's not. That's not the reality of the world that we live in. In fact, for most developers, even those that care deeply about privacy, it just creates a lot of friction and complexity. That gets a lot of pain and reality for them to implement because they're not privacy experts or legal experts. They are engineers first and foremost there to serve a different business function. And the source of the pain of privacy comes from how we build software and when we think about governance in most scenarios. I say most because there are always exceptions. This is the software development life cycle, the virtuous cycle of building things. So we're all familiar with the idea of design, technical design of a product or system, the implementation of the coding of it. Eventually you'll test it to some degree and eventually you'll deploy it. And if you think of the sort of venture backed world in which we've lived, particularly for the last 30 years around technology, the hope is that you'll deploy quickly and accumulate users. Lots of users, lots of growth, success in the technology you've built. But that becomes the sort on which you fall. You suddenly have data which creates a risk to you from a governance perspective. And that's when you start to think about privacy. So you invite in legal specialists, experts in the law. When they look at the privacy regulations around the world, they start to talk about data discovery because they don't know what data is in your infrastructure, data mapping and cataloging, inventory management, risk analysis, data subject rights, all of these sort of nuanced aspects of various privacy regulations. The thing that's curious about this approach though is it's happening post hoc. That is to say that system was deployed, it was designed with certain behaviors and characteristics, none of which considered these regulations that came in the future. So it's sort of one part anachronistic and the other just an ignorant stores these problems until a stage at which they're a critical issue for the business. And so you could look at it not as privacy, but general governance issues. Governance is imposed on an organization typically of a certain size. And the challenge to that is there's a low degree of education earlier in the development cycle of an early stage startup, for example. And so what is governance asking of these engineers in many cases, right? This will tell me what's in these databases, what's in this infrastructure, how is it being used, essentially provide context to the systems we have so we can govern them. The issue is one that is being dealt with downstream, right? Downstream being sort of away from the event. And where it actually occurred, the problem occurred was when the code was written. So what I mean by that is there's a common label amongst our customers, I won't name which ones for our paid products. They call the infrastructure that they don't know anything about orphan data. And that's a label that many of them use, many different businesses to identify infrastructure at scale like petabytes of data that they don't really know enough about. They can't turn it off because it might break something. The rotation of engineers, inconsistent documentation, bad management, and there's this lacking context on their infrastructure. So they start to splunk in that data to try and identify what's there. The question they should be asking is how have they arrived at that outcome, where they're having to boil the ocean to understand what data is there in order to govern it? And it's, like I say, back upstream, right? In the software development life cycle, we don't ask developers or provide tools for developers to build systems that could support governance of any kind. And so our goal when we were designing these tools, and this journey started, as I said a long time ago, from six years ago, three years as a company, was to see if we could bake governance or privacy into the software development life cycle so that systems could shift with the capabilities to support not just current regulations, but sort of future state evolving regulations. And so the concrete way that we sort of articulate that to businesses is if you think about your tech strategy, that your front end, your back end, right, angular view, react as a front end, you could have Python, Node, Java, Scala as a back end, any number of databases, some kind of version control system and infrastructure as code to deploy into the cloud. The privacy and policy function in very large organizations, the governance function, might have some role in the software development life cycle to evaluate risk. But in truth, it's sort of two asynchronous, very manual processes running in parallel, right? What we were proposing is that you create a layer in your technology systems that is designed just for governance. So a privacy is code layer that allows you to police the behavior of these systems and write new rules or conditions on them in the future, such that you can ensure trust in the behavior of those systems to comply with external regulatory factors or internal business policy. So the belief that we had was that we could solve this with an open source standard privacy as code or governance as code approach. And so what I'd like to take you through is how that works. So first of all, just a little bit about Fides. Fides was named such because it's the Roman goddess of trust for those that are interested. It's essentially a lightweight description language, right? It's a, if you're familiar with some of the infrastructure as code languages, like Terraform and Puppet, it's not dissimilar. And what I mean by that is not the grammar is the same, but the behavior is the same, right? If you think about the purpose of Terraform, Terraform is intended for engineers that know a lot about what they want to deploy into the cloud, but may not know about the underlying mechanics of how that is functioning, right? I can deploy databases with Terraform without worrying about how their scale horizontally, AWS takes care of that. So in many respects, if you think about it, Terraform is an abstraction that allows me to act on very sophisticated hardware systems with the confidence that those will be executed consistently. I just need to be able to write Terraform. And so Fides is the same, but for governance constructs, it allows me to describe characteristics of systems so that I can police and enforce on those now and in the future. In a simple form, we'll talk about it today because we focus on privacy, but it's intended for all governance conditions. It allows you to add privacy or governance directly into your CI pipeline and your runtime environment. And I'll explain the distinctions in a moment. The benefits are hopefully becoming reasonably obvious as we go through this. It's a developer-friendly language, right? So one of the issues with governance as a concept is it's not something we teach engineers about, so we sort of hit them with a stick over time to do things for us. So this language lowers the bar for entry, right? Developers can adopt this very easily without understanding all of the underlying mechanics of each policy or condition that they need to meet. They can write this language very simply, and I'll show you that in a moment. It provides tools that integrate the ability to check policy in Git and in the CI pipeline. So what I mean by that is you're actually tracking decisions you make related to policy as you write code, and you can evidence that. So if you think of the concept on an audit trail that might allow you to look at the history of the decisions you made in the systems you built, you can actually do that. It's sort of like Git history for governance, right? Like, what are the decisions we made and why over time? And because of that, we have the ability to build tooling on top of it to execute tasks, right? We can check risks in the CI pipeline, and in the runtime environment where data is being queried, we now have context over what it is, so we can execute tasks, right? So we could anonymize data consistently across a system on a given date or time, because of our retention policy, we might respond to a request to erase a user, and these are all possible because we have the context to do that with this metadata language. That's actually coursing through the system intervenously, right? And one of the last capabilities that Vidas has today is it supports sort of very large-scale de-identification, particularly for machine learning models, and we can talk about that at the end of this time. And so the benefits, structurally, it's composed of a simple number of sort of primitive system resources. There's the language itself, Vidas Lang, which is the taxonomy, ontology, and the sort of grammar with which you can actually describe system characteristics and policies. Then there's Vidas control, which is the systems that run in the code management environment. I say systems plural because it's composed of two components. There's a server that runs either locally in your development environment or from multiple developers as a hosted application, and there's a CLI tool, and the CLI tool allows the engineer to interact very quickly with the control server. And then there's Vidas ops or operations, which is the data orchestration tool. So think of Vidas ops as a task runner for very complex governance requests. You can give it a policy to pseudonymize certain data or delete things or move things around under certain policies or conditions, and it will execute those consistently in whichever way it needs to, either in response to a request or a time-based condition, for example. So let's dig into these a little bit more. The benefits of this approach should be very evident at this point. Because we now can describe our systems, we can declare, in effect, in the software development lifecycle terms, we can create a very simple way for our developers to declare what they're doing, their intention. I intend to build a system that will perform these tasks and activities with these types of data. Because we can declare that context very clearly, we can evaluate it. Is that an acceptable thing to be doing with those types of information? Does it either meet the organization's policies or external regulations that we need to comply with? And we can enforce. We can stop it. We can check it in the CI pipeline. And I know I'm speaking to an audience that is familiar with this. We're all familiar with the famed Facebook FTC consent decree. People focus on the $5 billion fine that Facebook got that's honestly irrelevant in the context of this conversation. What's interesting is that the meat of that decree states that Facebook essentially needs to impose what you might call the sort of digital equivalent of Sarbanes for engineers, which is like some kind of audit trail that allows you to evidence the decision making and the enforcement process around risk mitigation when you build software, not after it's deployed. We're not asking you to stop data flowing to a database. We want to make sure you don't ever build a system that allows data to flow to those places if it shouldn't. So enforcement in the CI pipeline and the audit trail to do that. And the mapping part that's interesting is because you're able to enforce this in the CI pipeline, if you think about it, you now have this very crisp metadata layer about all of the behaviors of each system and service in consort. So you have a very real-time mapped view of information flow in the organization. So essentially what you've got, right, if you think about it, is the ability to mitigate risk in the software development lifecycle, the ability to audit that sort of trail of decision making, and a consistent data inventory across your deployed infrastructure when you do deploy it. So now what you have effectively right is context and tools to control it. So you now have governance built into the system. Like if this were possible, this privacy is code, panacea, you'd effectively be able to enforce anything you wanted to now or in the future, whether it's for the GDPR or some, you know, obscure regulation that comes along in 10 years time. So that's a very high-level view of, I think, or a few dozen apologies. So what I'd like to do now is actually show you some concrete examples. I'm going to jump out of this document. It's going to get a little technical. I hope you'll forgive me for that, but we'll dig in to show you how it works. We will, I'm going to hold and salute you for that, not just forgive you. Okay, awesome. Excellent. And so in order to do that, what I'm going to do is I'm going to walk you through the first example, which is enforcing a policy while you're developing something, right? So this is the typical data protection impact assessment workflow proposed by the Caneal in France, that tech companies should follow when they're building something, right? They'd say giant Rube Goldberg machine of steps that should be taken to evaluate what you're building, is there a risk around the data you're collecting? How are you using it? Should it go back to another risk evaluation with another policy owner? And it runs through sort of every business unit in the typical organization with the, essentially, the objective of creating a very detailed paper trail of the decisions being taken in a sort of privacy by design-esque way, right? But if you think about it, what we're basically looking at here is, okay, we want to build something, it might collect some data. What risks do we want to avoid? We need context about it, we need to evaluate risk, we need to analyze that, identify it. We then need to look at the risk related to the severity of that data were breached or compromised, the likelihood of that happening, tree out of the risk against that. And if that is occurring, identify the high risk ones and attempt to mitigate them. So go back, Lou. This is in a well-oiled organization, the steps we should be taking, right? There's no other better way. The way we look at this at Epic is completely different with our tools from fetus. And again, remember, fetus is completely open source. So what I'm talking about here isn't a platform or product you buy, these are tools intended for every developer. And our goal here is common adoption. And I'll talk about that much more. But just to explain what you're looking at, if you look at it sort of from top left corner across, so the first row is sort of the, you could say the sort of executive level or GRC functions for an organization that often decide the business decisions and the organization's direction, right? They're the ones probably responsible for writing policies that can and cannot do things, right? You've then maybe got business unit owners or product line owners or feature owners who are defining how you might be using data effectively. That's what they do, right? We want to use data for these particular purposes. And then you've got engineering teams that are effectively designing, coding, testing, deploying things. So fetus control lives on the left side. And it's basically got the ability to allow the GRC function to write a policy in fetus, right? Describe a condition. It allows, let's say business owners or feature owners or product owners to describe data uses, so purposes of use of data, and allows engineers to describe the exact data they're using, types of information they're acting on. And it's able to use all of those components of context to effectively evaluate risk and enforce policy for the organization. So that's the part I want to start on. We'll get to the runtime side afterwards. So in this demonstration, what we're going to do is we're going to essentially do exactly those things. We're going to describe or show how we describe a very primitive system. It's very ugly. And within that, we're going to use our taxonomy. And we're going to look at the taxonomy in a moment to understand how we do that. We're going to check our system against some policies that we've already written, and then essentially fail a compliance check and update our system to comply with that regulation. So those are the steps we're going to go through. So we're going to jump out of the school doc for a moment. I've got a DS code open here. And I should just explain what's in front of you. Well, actually, let me provide better context. What we've got here essentially is a fictional system, a flask application, running a fictional e-commerce site. It's not very pretty, right? But you can see there's some products here. I logged in as user at example.com. That's me. So I've already got an account. That means this system already has in a database my name and password, at least that, probably more, but at least that, right? So let's say, for example, I decide to buy a product. So I'm going to click purchase, and I'm going to check out in air quotes. This is not a very pretty system. There's no validation and there's no credit card, but we get the checkout flow. I've now given it an address. I've bought a product. So notionally, a database behind this thing now contains some information about me, right? So for the purpose of this demonstration, I essentially have this e-commerce application running locally with a Postgres database sitting behind it. That's very, very simple. So that's enough context about the system that we're playing with here. Now, what we have open here in front of us before I get to our taxonomy in detail are what we call manifest declarations in Fides. So declarations are essentially what they sound like. They are a statement of the design of a system or its behaviors. So if you look at the label on this one, it says it's a Postgres dataset. So this is describing my database. Now, here this will look dense because we're describing an entire database. But if you think of the workflow of most developers, they only need to describe a few fields that they're working on. So the aggregate work that several developers do gives us the context of exactly what's in that database, right? So 10 developers working on a large dataset might describe thousands of tables over time, but we're all incrementally adding to that. These files that you're looking at live in a project repository with the work you're doing. So this lives alongside the code base that supports the application. So this one describes our dataset. This one describes our system. Now, for the purpose of simplicity here, we're describing our entire e-commerce application in one file. You could in a real production environment, you might think of this as distinct declarations that describe services in a service-oriented architecture or components of an application. You can sort of use it in several ways. But the goal is to describe each system. In fact, in the next release of FIDAs, you'll be able to inline these descriptions directly in your code base. And there's a linter that picks up the declarations directly in whatever code you're writing. So whether it's by Python or Scala or Loster Go. So this is how we write our declarations. Now, before I show you the grammar in these, I'll just explain the taxonomy a little bit. So this is the FIDAs Explorer. I'll actually paste this in the chat very quickly. So this is just a taxonomy explorer. I'll have it on screen, but you might be easier to look at it yourself. And this is the public documentation for the project. So just to explain what you're looking at, the language is modeled to support the GDPR today, the CCPA, the LGPD in Brazil. And it also supports standards like ISO 19944. So privacy information management systems for cloud information providers and service providers. So it's intended to be very robust for commercial use. It's also extremely extensible. And that's by design. So the goal here is to have a common standard that everyone uses. And then if you want to extend the taxonomy, you can do so, but you must extend from the top level primitive resources. And the reason for that, and I'll explain it later in the diagram I have, is so that we can have interoperable governance between external systems. If we are describing our data consistently across all organizations, we have the ability to effectively govern or impose policy on multiple systems. I'll show you that in a moment. But let's just look at the taxonomy very quickly. So you'll see here the one that will focus on is personal information for a moment. So we've got user data. Then we could just declare this as user derived data. So that is something synthesized about the user or inferred about the user within the systems operations. Or we could specify that it's provided data. So it's actually input by the user. They knowingly enter that information. And then we declare whether that's identifiable data or non-identifiable data. And then we get into details for fine-grained information, right? Is it contact data? Is it genetic, gender data, driver's license, government IDs, very specific types of government IDs, et cetera. And the goal of this is to provide context on how a system or service, like a single service, it's IO, effectively it's input. So data it receives at the interface level and data it essentially sends out or ejects or data egress. What it is. So we know what types of data we're handling and where transposition of data types occurred. So this is the what data are we handling. The next is why. What are we using the information for? Like why are we using this data? Are we using it to do advertising? First party advertising for contextual purposes? Are we doing third party sharing where we're selling that data for personalized advertising? Are we using it to optimize our systems? So this is the context of the business level for what we're using the data for. And the next is data subjects. So these are the types of users data that might exist in the system, and this matters because it informs how we might police or govern the way in which that data is used. And finally data qualifiers. Now data qualifiers is visually hard to see in the Explorer because it's a flat spectrum, but essentially data qualifiers is a linked, you could call it a linked set of nodes that describe a spectrum of identifiability. So you think of it as a risk qualifier for the degree of identifiability that a dataset gives. So for example, anonymous data is truly that, like absolutely anonymous data. Identifiable data is exactly that, identifiable data. The middle ground might be pseudonymized, but pseudonymized means many things. It's pseudonymized and unlinked. Is it de-identified? Is it partially anonymized? And these affect the risk of re-identification of an individual. So these primitives are used in a dot notation form to describe our system's behaviors. So if I go back to our code base, we can see if we look at the Postgres dataset database, we can see there's three tables, a products table, a purchases table, and a users table. If I expand out the users table, you can see this is again a very primitive example here. This is not a production environment. You can see we've got a couple of columns in this table. A created at field name, an email address, a first name, an ID, a last name, a password. You'll see after that then there's an object that contains the feed as annotations. So we can see here that the created at field is what is considered systems operations data. It's data created by the system for the operations of the system. Whereas email address is annotated as user provided identifiable contact email address. And we can add other labels if you want to identify along multiple categories. This allows us to describe a system. So a developer, if they were adding a new column to the table, provides an annotation to it. That annotation lives with that record and perpetuity. Effectively, it's metadata appended to both a central server, a metadata server, and also directly to the dataset. The system declaration is slightly different. The dataset is just declaring what is data at rest in database, for example. But the system declaration is actually describing the business purpose. So it's an e-commerce application declaring something about the conditions under which it executes. And then here we have the categories of data. And you'll see here interestingly, the dot notation is very abstract. So we're just declaring that we're using both user provided, identifiable data, and user derived identifiable data. We could be more narrow if we knew that our system was only acting on contact information. Or we could say it's only dealing with email addresses. So we could very quickly describe the types of data that we're handling in our systems. So as a developer, I can just declare these. Beneath that, then, I've got the use. So why am I using this data? We've given one simple one here. We've just said that we're using this information to provide systems operations. That's a style of grammar that comes from ISO 1944. So systems operations is anything that just sustains the capability of a service in its simplest form. And the data type reacting on it is customers. And the qualifier to its degree of identifiability is this is fully identified data. This will identify an individual. So we've got this. Now we're going to paint this fictional picture very quickly, which is I'm an enterprise developer. I work in this company. I have decided I'd like to add Google Analytics to my e-commerce system so I can infer lots of information about my users and help us improve our product. So I add the Google Analytics snippet to my code base. And I decide I'm going to declare that I'm using Google Analytics. I need to declare that code because it'll be undeclared. It won't check in our commit. Now we've detailed this with a lot of comments. So it looks very dense. But if you look at it very carefully, what I've basically said in my declaration here is I want to add Google Analytics. It's a third-party system type. I am going to be processing browsing history, cookie IDs, telemetry data, location data, and some non-identifiable data. And I'll be using that data to improve my system's capabilities like observing and improving. Now I've defined another use of data down here, which is I want to figure out their geographic location. And so I've said that I want to use their device IP address, their location, and some identifiable data to figure out where the user is. Now here's a common mistake that happens. Developers don't really know what personal data is, right? Most developers aren't responsible for this. So most developers don't know that IP address under the GDPR is personal data. So I'm going to attempt to check in my code where I've declared that I'm using this personal data. So I'm going to just, I should point out, because this is a developer environment, my local dev environment, I'm not running it in the CI pipeline. So I'm going to manually kick off the same thing as what would happen in a commit in your normal CI pipeline. So I'm basically just going to run a command to execute a feed as evaluation. So what's going to happen here is it's going to spin up the feed as server. It's going to connect to the policies, review all available policies for the organization, review my declarations as a developer in my code base, and check that I'm not doing anything that's illegal or inappropriate, let's say. Oh, I've got a red fail. So we can see here the red fail basically says I'm attempting to use Google Analytics. And I'm attempting to do so in a way that does not comply with our data minimization policies. That's not acceptable. We cannot check this code in. So I'm now going to show you the policy that enforces this condition. So we have a primitive policy. And basically, it's again, using feed as to describe what we want to do. And basically, it's a minimum data minimization policy. And essentially says, look, we want to reject the collection of any user identifiable data for anything other than system operations. Basically, you can collect user data to operate an e-commerce system. But if you want to use it for things like improve in personalizing the system, advertising it, third party sharing, general generic collection, or training an AI system, that's a no, no, we do not permit that as an organization. And we don't permit it on any of these groups of data provided identifiable data or derived identifiable data. So as a developer, I get this notice that I can't do this. So I've got to go and figure out what I'm going to do. I'm going to make a business decision and change my code base. I'll go away and look at my code base. I find out that Google allows me to anonymize the last octet of an IP address. So now I'm no longer handling identifiable data. I'm handling pseudonymized data. We could debate the degree of pseudonymization that affords, I agree. But for the purpose of this simple example, we'll all get there. So now what I'm going to do is I'm going to essentially run my check again. So I'm going to evaluate my code base. I've made my code changes. I've updated my policy or my declaration. It's going to check it against the enforceable policies. And I get hopefully a pass. I get an evaluation passed. So my code can be checked in. It generates a commit. It generates an audit trail report on what was evaluated in the policies, what decisions were concluded, and allows the code to continue through. So to go back to our original presentation here, what we've done here is describe our systems with this primitive language to the context of them. We've checked our systems against a policy we had written previously. And then I've, at a very basic level, updated my system to comply with the organization's data policies. So what in effect we've done here, if I go back to our sort of virtuous software development lifecycle, I have prevented a piece of code being deployed and ever touching data for not complying to a policy before it ever gets a production. Most of the time this happens after we discover we failed it some way. So we're going to take you from there into use case two, which is a very specific one and shows you this is a runtime environment. This is about individual rights for those that are not familiar very quickly under various privacy regulations, consumers or user afforded rights, employees as well, actually any subject type, such as the right of access to the data, the right of erasure, et cetera. These are very difficult to programmatically execute for the reasons we talked about, right? Most businesses don't know what data is where. So if Daza or Brian or Brendan or anyone else on the list of people watching here says, hey, YouTube, give me my data back. YouTube's got to go spelunking for Daza's data in the hope that they don't miss some of it, right? It's a painful, highly risky process. Also, this is what they normally look like. Data subject requests are like written documents, emails, it's a, this is a real one, I should point out. This is a legitimate request. I can't name who it's from. And this is, this is sort of what you're dealing with. This is a bizarrely an acronistic process for these very sophisticated data-driven systems. So this is what the request looks like. And this is what it looks like for most organizations. So what I mean by that is a business receives a request on the left, right? They have to triage it in some way, they generate a ticket, they evaluate it, they review it, support teams huddle around it, they panic because they've got to find the data. Eventually, they probably generate some internal tickets in JIRA and every business unit owner is notified to go and retrieve data by Kylian or Daza. And that could be automated. Maybe they've written some scripts to retrieve data from Redshift or Postgres or Snowflake, but then they've got to go like really looking under the carpet and searching all of the sources of data that they don't know about, becomes very manual, very quickly. So what I'm going to show you here is how we execute pricey requests in a runtime environment using fetus. So we can construct a request policy, which is quite literally that it's a policy about how we would like to treat requests for users. It doesn't have to be just a request from a user, right? The example I'm using to show the tools is one generated by a human being. But when we say policies here, it could be a condition internally that's about anonymizing records after 32 days, 32 and a half days of holding them. We decided we want to erase all of these types of data from our taxonomy. So we're going to get rid of anything that falls under the derived category. We're going to get rid of all that in the 32nd day. We want to be able to enforce that consistently on all business systems. So in this case, we'll use the trope of the subject request. So I'm just going to show you the guts of what's happening in the system very quickly. So as we talked about, a data subject request normally flows into a sort of smorgasbord of ticketing systems. In this case, what's happening is the subject request can flow into a UI, like a privacy center. We typically call them. So just an interface where a consumer and end user can input their request. It flows directly into an API-driven data orchestration tool that is open sourced on top of the Fidesz language. It's called Fidesz Ops. And so you can configure this to accept certain identifiers, names, email addresses, phone numbers, device IDs, anything that you term an identifier for users in a distributed system. You can then construct a policy for how you would like it to handle those requests. So you write those policies in Fidesz also. So I would like to only retrieve these types of data for these types of requests. I would like to erase these types of data for these types of requests. And you can also wire this to third-party systems. We mean sub-processors. So I can trigger requests to enforce these same conditions into a stripe or a hub spot or a sales force, etc. So let's actually do this in practice. So again, we've got our fictional e-commerce system, if you recall. I bought a product. So I'm in here as user at example.com. And so now what we're going to do is we're going to, a bit more room for myself. I'm now going to make a request here in the same way. Now, the difference is I've got no UI. So we're just doing this at the data engineering level. So I'm basically using my CLI. And I'm basically going to say to the Fidesz server, we'd like to create a policy and a request. So Fidesz Ops. So we're going to make a request. It's going to spin up the servers. Oh, sorry. Strange. Do I type or something? I think I am. So let me just double check my server is still running. That's why they say never do live demos, right? There we go. Okay. So now hopefully, I know this text is not very big. I'll zoom in a little bit maybe to help see it a bit better. Hopefully you can see that. So you'll see here, we're doing this from the CLI. But the way you can think about this is you can essentially, in the ammo files, configure the conditions under which you want to execute a request. So you'll see here, it's asking me to enter a list of the target data categories for this request policy. So what this means, if I go back to the taxonomy, I can pick categories, multiple categories or single categories of data I would like to retrieve or erase. And I can design the erasure policy, the types of erasures executed. And it supports a bunch of different things like HMAC, random number generation, and you can compare those together. You can unlink documents so you can create some true breakages in the foreign keys and reference IDs. But in this simple example, I'm going to retrieve some data, right? That's what I want to do. So for the first one, what we're going to do is we're just going to get all of the data we have about our user. Anything that relates to this individual, we'll just get everything. So we'll just use the top level user target category, this one here. So instead of declaring anything, we'll just say user. And now I'm going to provide an email address. Now, this might flow in through an API, but I'm just going to provide it here. So it's a user at example.com, it's our test user. So you'll see here, it's returned to us, essentially a JSON object with everything related to this user. So the products they purchased and the address they've entered over time to purchase products, etc. Okay. And the specific user information, including their password in the back, which is obviously scary. We don't want to return things like that, right? So what we've done there is just return everything about the user. At a practical level, that's not really the kind of policy we want to enforce, right? We're going to run something very specific. Maybe we say, actually, we would like to return only the city about the user. So we're going to return the user provided identifiable contact city. So I'm going to create a new policy and say we're going to do user provided identifiable contact city. And so now when it executes a request against this user, it's only going to retrieve the New York datasets and any of the addresses. That's all we can get. Now, it's a very simple example. We can, like I said, create like a very sophisticated execution task to erase data consistently across systems. You can use it to enforce a condition like not allowing data to flow between systems. And we can talk about how ACLs work here in a little bit. But that's a quick sort of tour of that. So if I go back to our document again, what we've done there essentially is we've constructed a request policy. We've retrieved all of the data for a user. We've modified that policy to retrieve a subset of data, just some contact information about the user. So you can sort of see the power of how you can use the grammar to execute sort of pretty complex tasks. So the last thing, I know we're tight on time, the last thing I'm going to say is just a bit about the future of VDAS. So if you're following here, what we've basically done is we've gone really far upstream and started at the software development lifecycle and we're working our way down to all of the problems that an organization faces in governance. One of the biggest ones is enforcement between distributed systems, ones you may not own. This is typically what it looks like. And this is an oversimplification here, but if I present it very quickly, so you've got multiple users potentially into multiple applications. And let's think about these applications as separate companies for a moment. And so the way in which you deal with this typically is APIs are connected between systems. But to mitigate the risk of data processing between them, we have a data processing agreement. So we have a legal document between two entities that defines or codifies our intended or expected outcomes of how we might use data on both sides. So the API is the connection between both systems, but the DPA is in fact, in fact, the enforceable documents. And it's not connected in any way to the API. They're distinct things. So it's fine when a user's data flows in here and it flows to another company, we have a DPA. But if the user starts to change their preferences about how they want that data handle, like their decisions, right, how they want their data handle, now their preferences flow in here. And now the DPA needs to be enforced. And maybe it becomes very micro, right, like one user preferences are different to another. How would we enforce those business conditions consistently across multiple companies? It's essentially impossible, right, that no system can support that promise today. Now imagine for a moment, if you thread all of these systems together with a consistent taxonomy and grammar, right, like if you can describe consistently the way data exists into these systems, actually, the enforcement layer is the API, right, the API becomes the contract, both APIs for both systems are their own data processing agreement, right, they declare the types of data they touch, the conditions under which they use that information for what purpose. And those APIs can constrain access to that information for those reasons. So in fact, the next step, what we're working on in FIDAS is specifically these capabilities, the ability to essentially semantically enforce across distributed systems provided both organizations have described things using the language. So we've covered the problem a bit about FIDAS, the benefits of this approach, two use cases, and a little glimpse into what we're working on at the moment for the future of the tools. I'm going to stop there and happy to answer any questions and obviously plead with you all to go and close the repos, play with the tools, ask any questions, create lots of issues and give us lots of constructive or terrible feedback. That would be great too. Here, here, wow, that was such a tour de force. And there's so much in that. And I just want to just congratulate you for doing fundamentally a live demo in the CLI posing a different question and then limiting the data that came back using it like an on the fly dot language to narrow down the sub categories of functionality against data. Like it's just freaking amazing. So thank you so much for showing us what's possible. And then in particular, what's available now in the context of this personal data and privacy realm. So okay, as the questions and comments are rolling in, I'll go ahead and get us started. So one thing I want to highlight that you just sort of slipped in towards the end there was the API in effect becomes the agreement. So part of what's so interesting about that is if you look from just put a legal hat on for a moment, if you will, or I'll deputize you to put a legal hat on, like you've got a the some legal primitive called a contract. You can't have a contract with yourself. It takes two or more parties to agree. Okay, fine. So what happens today? Usually you've got a contract that's like in a paper paradigm, like maybe it's digital, maybe it's PDF, but it's between, you know, two or more organizations, and it's like moldering somewhere in like a drawer or like a very in a C drive. And, you know, and but to the engineers look at it, you know, and just double check all the terms before they do anything. No. And to be kind to an engineer, but do they often even understand them like it's just not their domain of expertise necessarily, right? So just so just so and so what we have is a kind of continental drift between what the contract is and what is actually happening. Now, meanwhile, if we took an engineering approach to this, we would say, well, what is the what's the most convenient, you know, at hand intersection point operationally between the organizations? That's where I would that's where I would like to see the business legal and technical dimensions of the relationship collapse. Well, the API is a awesome expression of that. It's the gateway for the data interchange and the programmatic interchange between the entities. And it's very literally where we would like to not just express and execute the interchange between the systems, but it's also a really great place to situate the terms functionally of the agreement like they should be one in the same. And so I just think architecturally, your concept of like sort of placing the performance of the contract at the API is like that alone should be like a master's class in law and computer science. So okay, with that, let's move. Very kind of you. The last thing the last thing I'd say does it just on that point, not to but it's just to that point, I think like we there's prior form for this, right? Swagger documentation for API is effectively described, not the legal construct of what you can do, but precisely what a system will do already. What we're asking you to do now is just enforce the next layer of those behaviors, right? Which is the stuff that we want to make business conditional. I don't think this is a huge leap. That's why we think we can get there over the course next year. So, yeah, I'm very excited about it. Outstanding. So one question, okay, looks like you're ahead of me here. We're looking at them. So there was a question from Luciana, many of us from years past at lawdownmit.edu know her as Bora. Hi, welcome from Brazil. You mentioned Brazil, by the way, we've got a whole Brazilian contingent with us today. So welcome, y'all. So could we get sort of a hands-on workshop? And you kindly said reach out. And I guess I would just say if you could see see me on that, I'd be happy to sit to our, so we can invite more people. I think there'll be a lot, there'll be a lot of interest in that, including me, like I would love to go to the next level and try to do install config and run and just kind of see what happens. Happy to. I would love to. Any of you that would like to, it would be a pleasure. Thank you so much. Okay, and now we've got kind of like high level input from Brendan. What are the biggest challenges? And so if you, like I know you've been really pushing to get this out, you just deployed it and announced it just a few weeks ago. But if you could take a breath for a moment and sort of look over the horizon and I think Brendan said like 10 years, but I don't know, like let's just say like, you know, one to five to 10 years, like what do you, what do you kind of see mid and long term here? So I think the two sides, right? One is the challenges that we see and the other is where we think we're going with it. So we, like it might sound a little hubristic and I promise I'm not like excited about what we're building, but I'm aware of how hard it'll be to get there. But the hope is that we effectively are describing a language that will become increasingly sophisticated. We've kept it very primitive today in order to not scare developers off, right? Like the goal is actually to keep it as simple as possible intentionally, but, but we already have some grammar and syntax in there that allows us to describe very sort of very complex business or conditional constructs, right? I think that over the next 10 years, if we get the adoption that we believe we'll have, we, our view is that Fides becomes essentially this new layer of a text back quite literally in the way that you saw on the diagram, right? Essentially, you have a front end, you have a back end, you have data infrastructure, you have your deployed environment, you have the layer that the best label we can come up with, which sounds salesy, it's not meant to be, but is trust infrastructure. And that is to say, what's the part of the system that allows us to trust in its overall behavior, right? Like you've promised a condition about how it will behave. How can you evidence that that is how it will behave to me either within one system or across a number of distributed systems? So, so that would be the hope, right? And that's the 10 year ambition, I would say, to go back to the challenges that you asked about. I think, look, it's not lost on us. We're not ego driven. It's not lost us that many attempts to describe taxonomies for, for either specifically privacy or the law over the last number of years, right? Like efforts in sort of codifying law. And they have not necessarily come to commercial success. So I think you'll probably all recognize the difference in this and some of the others is that we are very commercially focused. I don't mean about making money, but we're trying to appeal to businesses benefits in order to encourage adoption. That creates its own challenges, right? Like there's a friction in that journey to educating customers. So for those that aren't aware, like we don't, we literally don't sell anything, but we spend a huge amount of money at the moment, deploying and educating large engineering teams of large companies that I don't think I should name so we don't get into sales pitches, but like very large social media companies, very large banks to use these tools across their engineering teams. And the challenge in that is education apathy towards governance today. And so a lot of what we're trying to do is educate the importance of sort of trust and, and this idea that it's a hygiene factor that good developers should care to build systems that are safe. You've heard me use the civil engineering analogy before, I think Daza, which is look software in 30 years has quickly become essentially civil infrastructure, right? So software engineers today are society civil engineers, right? We basically build services that are deployed to production and are used by hundreds of millions of users in moments. If civil engineers building bridges wore t-shirts saying move fast and break things, we would never cross those bridges, right? Because we expect, you know, rigidity, certain thresholds of safety to be met, et cetera, because it demands it because it's infrastructure that is important or critical to humanity. You could argue that software is fast approach to that point. And we don't have the same controls or capabilities in those systems. And so the goal here isn't to beat engineers over the head, it's to give them tools to help them make it very easy to not have an excuse to not build safe systems, respectful systems. Yes, outstanding. And so we've got one more question that has come in from our co instructor and longtime collaborator and friend. Tony Lai. And so Tony, I want to invite you to, there you are, come off mute and please elevate us to another level of the ecology of basically, you know, getting open source adopted in the bigger world. So go for it. Well, first off, Kelly, an absolutely brilliant project. Congratulations on where you've taken it. And the demonstration there, I think literally blew the minds of most people in this Zoom room. So thank you so much. I was wondering, as you're talking about the bring on board various different enterprises, and then looking at the, in a sense, the evolution of regulation more broadly, I was wondering, on the one hand, are policymakers and regulators currently aware of like the power of the standard? And are they supporting its distribution? And then, I guess more broadly, how are you looking at the management and maintenance of this ecosystem that's going to support this ongoing adoption? Have you considered yeah, what kinds of incentives or, you know, even now, like mechanisms you might sort of put in place to support that? Great questions, Tony. So to sort of go through those in order, as it relates to dealing with or meeting with regulators or regulatory bodies globally, candidly, we've only started that process. We made them aware of the projects over the course of the last three years. But I think like any of these things, until you can see it, and really it's sort of materially tangible to play with, difficult to understand, and also not to be unfair. But I think there is a degree of sophistication needed to understand the underlying tooling that has been challenging in some of the regulatory bodies, it's improving very quickly. So our hope is to, over the course of this year, try and convince them to see the value of this as an open standard, right? So that's, I would say like a long-winded ongoing discussion that we're not there on yet. On the second point of how we will manage this going forward, I can't impress this enough, and I sound like some kind of evangelical, this will remain open source. My belief is the only way this could ever succeed is that it is a readily adopted easy to use standard that the vast majority of people do tend to adopt. So it will be permanently an Apache 2 project, and the language is obviously a creative commons language. Today, it sits in Ethica, not for any reason to hold on to it, but we want to drive it forward. We have 30 engineers that just work on this project today, right? So that's all they do, although it's a huge investment for us to complete, but it's our entire company just works on that. We don't have any other part of the business anymore, they all just were completed. At a point in time, and I think that's over the next two years, we will form an essentially independent foundation, a charter governing body, and the bit we didn't kind of get into the details of it, we have technical design partners who have essentially been the testbed users for these tools. So very large businesses that unfortunately I can't name yet publicly, but they're the types of companies that have the deepest privacy issues that we all know of, right? And they've been using these tools over the last two and a half years, three years, to allow us to get a feedback loop that allows us to better make them easy to use for engineers, implement, etc. Part of that exchange is also that they would form part of the governing body in the future. If we were to do that too early, I think the agenda might be entering into the commercial interests of certain big enterprises, so we haven't allowed that to happen. The third part in terms of incentivization, it's a really interesting point. Today, we don't do anything per se to directly incentivize individual developers. What we do, attempt to do, is build lots of tools that ease the effort that developers have to go through, not with Fedes, but with other efforts. So this becomes the logical product or set of tools to use or platform to use. But we certainly haven't incentivized in the way that you said of like a DAO or something like that, which is a great idea, by the way. I haven't thought of it for this. I don't know why I haven't, but it's something we should consider. And I'm open to suggestions on how we encourage adoption or use always, but I should put it. Great. And so it looks like we've got some more here. Thanks so much for a really great workshop, came across, this is engrossed. Okay, so we're getting more fan email, I think, here. So, Tony, did you have any follow up on that? And including, if I don't want to put you on the spot too much, but I mean, you've got a ton of experience, Tony, with open source and standard setting, especially when there's a heavy legal overlay, if you have any suggestions, I think that would be in order as well. Well, I think that the broader point you made about educating regulators and sort of like taking the time and the space to do that advocacy for these kinds of open standards is going to be really interesting. I'm, Dazza, someone you're working very closely with, Ben Moskovitz, at Consumer Reports, I mean, their advocacy network, I think, would go to town on this, because this fundamentally aligns with a lot of their work that they've been doing around the CCPA and working with the ATE's office there. So, I can see a lot of very, very interested people who are going to want to jump in on this and help add to this framework that you've put in place, which I think is one of the most robust and really played out scenarios of computational law and computational policy that, as you're saying, already has these widespread adoption to the extent that you're being able to sort of build that out as a business over the last few years. And I think this approach now of being evangelical to the point of, you know, turning your entire team over this open sourcing effort. I mean, some might say you're bonkers, I say you're like way ahead of the pack. And I think that, you know, the more of us who can align with you around that kind of approach. And I think intuitively, a lot of the principles that are part of the web-free movement align with this approach. And so I think that you would get a lot of support if you were to set something like that up, you know, you know, consider with your foundation how you might, you know, involve a lot of that kind of activity. And I think some of what we'll be going on to talk about in the next hour. But yeah, thanks again for all the work and look forward to staying in the loop very much again. Thank you, Tony. I really appreciate it. I appreciate the feedback. It's fantastic. Thank you so much. Standing. So I hope everyone will join me in thanking, killing it so much, and the whole team at Ethica for just the labor of love in putting this open source platform together and supporting it and then making it available for the world. And especially for taking your time in the middle of the day. I know you're incredibly busy to share it in this session. Thank you so much. It's a pleasure. Thank you so much for having me. No, it's standing and you're welcome to I'm not sure what your day looks like, but our next session is going to get a little bit crazy now. We're going to so you began to touch on some governance things in terms of the expression of policy. But if you go up one level from that, there's a question about what is what is the governance itself of an organization that outputs things like policy and like rules and that defines the business objectives. And when it increasingly as organizations become digital largely, they become not just digital, but network, they live as components and processes that are automated. How do we incorporate governance as part of that? Oh, here comes Silke. So not just how do we incorporate governance, but how can governance become refined such that we could compose governance as part of the technology of a system? When lawyers talk about, oh, Brian, I think if you don't mind doing this print share, that'd be great. When lawyers talking about designing governance, at least when I was doing this stuff, when I was learning this stuff in the 90s, we were talking about structuring governance. And the tools that we would use were, not surprisingly, Microsoft Word and maybe some diagrams at best. But now, just like as we saw with the last session, as privacy rules and personal data rules are becoming incorporated into the operation and the configuration of the data management and the applications and the network systems of organizations, what would that look like for governance? And specifically, what would be the components of governance that we could mix and match and put together in sort of a modular way so that we could construct or compose, let us say, a governance system for an organization or if you look to the first session, we had a lot of organizations together to help reform the insurance industry so that they could use the authentication service together. There's a lot of governance there that created and debated and evolves their system rules and the branding and the technology adopting new standards, the legal conditions. How could we compose systems for organizations and for organizations of organizations? So, I'll say one bit of context that I'm going to hand it to Tony and it's, this word composable is so beautiful partly because it has connotations you might not be familiar with and I'll just highlight them now. There's a idea of composable systems and then a slightly more recent idea of composable services that is part of the connotation I hope will take forward into this new context and some of the key aspects there is if for those of you that are more technical, you may have heard of something called microservices before. The idea of composing microservices is that you can basically take bundles of functions and the word we use is decouple them so that they're independent or modular and you can then combine them and sequence them into more sophisticated configurations of functions to create like a system or a meta system or a set of applications by the constituent parts that are encapsulated within a service. In system composition, it doesn't have to be in a service like through an interface or it could also be like functional components like an identity management system, a knowledge management system, like a billing system. So long as there's a function that is modular like a Lego block and has inputs and outputs so that you can integrate it together in different ways with other such modular components, then we can begin to apply this higher level concept, the design concept of composing the system of these building blocks. So with that kind of very high level setup, it is my honor and my pleasure to introduce our colleague and our friend and advisor to the MIT Computational Law Report and stalwart long-time legal hacker Tony Lye. Tony, take it away. Thank you so much Dazza. Thank you Brian and fantastic to see you both Noah and Megan as well. Yeah, we have quite a good series of historic precedents for these kinds of jam sessions and I'm really glad to be able to welcome more folks into them and hopefully it can be the first of many such jam sessions that we can take in various different directions and this hour can hopefully just serve as a sort of a jumping off point where we sort of dig into some interesting components. We'll throw it out to a few specific people who are here with us as well, Silke, Isaac, various folks who have been deep into various different aspects of the practice of composable governance in certain ways through DAOs and Noah, we're going to be able to jump into some of the work that you've been doing as well in terms of the management of DAOs, the ways that you activate people in DAOs. But before I get into DAOs, maybe I could just like take that step back and give a quick introduction. So yeah, thanks Brian. On the introduction side, the phrase you mentioned as about building blocks I think is really applicable here in terms of this notion of composability. So Brian, can you just take it over to the next slide, thanks. We're talking about at a base level this notion of removing inefficiencies, but obviously we've also talked just now with Kilian about this idea of enforcing policies in development. And I think this is just one example of a whole wide series of inefficiencies that this promise of computational law plays into. The idea of having at continuous integration or even at runtime this ability to manage and understand whether or not you're breaking some policy or you're going against some wider governance directive is part of this notion of being able to have these legal components that we're configuring and putting together. And so this question that we were talking about Dazza in some of our previous jam sessions is what are the kinds of platonic primitives, if we can speak of those, these solid state forms that might form components. And then I was thinking also about the polarity of looking at things as they are and looking at the things in the becoming. And so this idea of the dynamics as well as like the platonic solids, what are the events and the relationships and the dynamics of those that form any particular governance. And so I think this is the piece where I wanted to play in a little bit and I think the operative word is play into this idea of Lego law because it's not just about composing the blocks and the idea that they are composable, but it's about the idea that you can play with it and that you gain familiarity through the building and the governance in many ways is not about these fixed state solid forms, but it's about the the fields of association and relationship and and legitimacy. You know, in the same way as we start now thinking about electromagnetic and gravitational fields and you know all substance deriving out of the interconnection of those fields, thinking a little bit with that comparison to waveforms and music, we can start looking at this notion of like the differences between talking about music and listening to it and then actually playing music and jamming as part of music. And so I think this broader sort of overarching way of thinking about governance, not just as the unit blocks, but also about the dynamics as to how they are used and play with is a big part of what ultimately drives I think a lot of us in our passion for both law but also how it can become encoded and made more accessible and inclusive and available to more and more people to do more and more incredible things with. And so if we start thinking about what we might use with use composable law for just next slide Brian sorry. This idea of currently this working definition just to go back to that initial piece that you were talking about as I took this essentially from that composable service architecture line and I've just replaced a few words but it's a working definition I'd love for us to sort of build this out over time but you know we're talking about a design principle essentially rather than you know a set of features or a particular set of components that you can always necessarily bring in or not it's more like a design principle or a way of looking that encourages the design of governance these components and these dynamics in ways that can be reused in multiple solutions and that themselves can be composed as well and I think that's a critical part is that you want to be able to make these so that they can comprise into these larger complex systems and Brian asked the really interesting question is you know why would we need composable governance and I made this analogy to architectural drawings and sort of like looking at a building I think having composable governance as a design principle and a way of seeing is like looking at a building through the lens of the architectural drawings or via computer assisted design. It's a tool and approach for understanding these dynamics you know by having these new lenses and these new ways of forming things together and I think areas where this kind of approach or this lens could be well particularly well suited are where we're coming into these more complex formations I think where not just where we want to remove inefficiency but for example in the case of what Kilian's talking about where we're having these complex dynamics where data is being shared between multiple different organizations and you might want policies that flow through you know as part of those not to mention bringing in you know data trust or sort of benevolent intermediaries that are going to help enforce some of these policies and you sort of need them as part of the ecosystem. Having this kind of composability is I think going to be especially important in these kinds of complex systems problems and the one that I'm particularly passionate about is climate action and the idea of how we're going to create a global stock take when there are so many different levels at which we need to be thinking about rules and enforcement and you know not just prohibition of data which is something that the Stanford climate data policy initiative that I'm a part of is thinking deeply about and I'm really delighted to say that SB 260 in the California Senate went through earlier this week and so you know that's another step in this sort of regulatory framework for what might look like a very very composable governance infrastructure because we're going to require policies not just that they're at the state level but at the corporate level and then potentially also feeding in this whole notion of nested accounting systems for auditing you know everybody's carbon emissions and things like that so we've got a whole bunch of different kinds of regulatory frameworks and policies that are being brought into play around something like climate and the way that we as individuals and corporations are being asked to respond to that will require a much sort of more complex ability to be able to compose governance and have that governance work hand in hand with each other have those governance APIs as it were exactly in the way that Killian was talking about where these legal agreements are not separate from the underlying technological API but are really built into that. This has also come out a lot more recently and there's some interesting sort of articles coming out in sort of chief information officer circles around the notion of the composable enterprise and again I think it's building a lot upon this idea of you know service oriented architecture but what does it look like to enable the flow of data and decisions you know across these sort of wider ecosystems of alignment that you know potentially include your supply chain where you need to look back into your supply chain and determine whether you know everything from child labor to you know appropriate sort of carbon accounting is being accounted for and flowed into the wider composable enterprise that's from a regulatory perspective but then obviously there's the business opportunities perspective where you're looking to be able to have that agility flexibility to manage uncertainty with a sort of modular architecture with packaged business capabilities and sort of what are the ways in which you can govern those different sort of packaged modular business activities flows back to the first hour of the session around aligning BLT the business the legal and the technical layers and so composable governance is really looking at updating and integrating the capabilities of law policy and governance into you know the same business and technical architectures that are being developed in these more modular composable ways so that was a sort of very very high level sort of like I guess context setting for I think some of these potential areas where this notion of composable governance might be interesting and I think one of the most exciting areas that it's being put into play and again I think play is the key term here it's being used and played with is in DAO's these are the decentralized or distributed autonomous organizations that have been built out on various different blockchain protocols but that fundamentally embed aspects of composable governance and might provide some lens into some of the components that we might want to start thinking about and some of the dynamics that we might want to start thinking about and so this is the sort of beginning of trying to come to some form of taxonomy hopefully we'll end up with something as beautiful as the privacy taxonomy that Kilian just showed us but for now if we get on to the next slide we can just start thinking about you know what are we talking about so I threw this picture in here just as a bit of a prompt for I guess theoretical thinking this is a reference to the concept of active inference that a neuroscientist Carl Friston has been talking about and he talks about the idea of a free energy principle and the notion of trying to reduce surprise as part of the ways that we potentially dynamically organize into any kind of thing and I'm making a parallel right here from what he talks about in terms of the internal states of the brain and the internal states of the world and the ways that we rely upon our sensors to in a sense create a Bayesian inference model of what the outside looked like we're not necessarily directly able to discern reality but we have a series of sensors and then we have these abilities to actuate action states as a word and so Carl Friston talks about this in the sort of the bodily context of neuroscience and he's also sort of elaborated this more as a sort of meta framework that has been picked up by machine learning folks and and potentially given sort of some of the the discussions I've been looking opens up new ways of thinking about machine learning you know beyond deep learning principles but the reason I bring it up is that I think that something that you were talking about earlier Daza about the idea that composable governance might enable us to sort of associate and coordinate in newer ways that might be more amorphous and might actually create some kind of overlap between you know our affiliation with you know and we see it already you know in the sense that we can be affiliated with a state as well as a federal sort of nation state and and similarly within a with an organization we can affiliate in various different ways but in thinking about the theoretical state and and looking at what the different kinds of sensory apparatus of a of a sort of composable entity might be from the corporate sense and then from the the the Dow sense but you know across different collectors and then what are those action states or what those actuators and and thinking about how those come to define the ways that we think about what's inside of what's outside I think it's worse sort of going right up to the very top and sort of thinking about some of these first principles I haven't say I've fully unpacked it yet but I kind of wanted to put this here just as a prompt as we as we go into some of the the aspects of Daza come on jump him please oh thanks so just just to see um thinking on what we're heading here is basically we're going to throw the doors wide open and ask for participation by everyone in this call and the broader um MIT computational community but one of the kind of first level questions is if there were to be a kind of a common way um to um do composable governance um and you start looking at what would be the you know components or modules you would snap together um so one way to look at this is would would the level of abstraction for the components be that each component would have the ability to um uh you know um uh interact with external things in measure state as well as other internal components or components inside of their components to be able to sense things and then to process and take actions or would this be more like a system of with an organization have to have these functions and then components would do like pieces and parts of this like maybe some component does censor like we have an oracle component that senses states and we have so there's like so it's really a wide open question of how would we interpret the components and modules that would be composable what functions and capabilities would they have what level of abstraction it's an open question and there's going to be some that will work better some that will work worse but we want to really know what do you think would be good and and what we're seeing here these are stuff we know would be part of the mix but there's not yet a point of view of how to execute upon it so sorry we're back to you Tony um thank you so yeah I think a lot of this is uh invitation to to come and think alongside us and I will say that some of the exciting aspects around how dows are operating in a decentralized way is providing some formative sort of components of aspects of the sensory state mechanism so you talked about oracles but there's also some of the prediction mechanics that go into some of the ways in which uh that that notion of reality is determined for the purposes of governance and so that really is a sort of like an evolved sensory state layer that maybe silka can talk a little bit about when she when she starts talking about snapshot and its evolution into reality east but um but yeah just here in terms of a sort of very high level comparison this is taken from the ethereum uh foundation website but um this comparison between uh the components of a traditional organization from a composable governance perspective and what we're sort of seeing emerge in this dow space um I think it's premised upon some of these these ideas of what why dows are uh have become interesting why people are talking about them and what what are some of the potential ways they're currently being used and how they how they might be used so first off there's this notion of sort of a flat versus a hierarchical organization and so the the the the initial piece is not to say that dows might not compose into hierarchical frameworks but that as a sort of base component they they tend to be structured in a in a in a flat initial way and so that immediately opens up the the the notion of what might some kind of hybrid look like how might we potentially integrate some of the the functionalities and benefits of how a dow operates into sort of more traditional forms of organization secondly there's this notion around voting and so we can dig in a little bit into some of the different ways in which voting is implemented within different dows but essentially it's uh it's premised on the idea that any change needs needs and should be voted upon and that those votes are transparent and can be viewed by pretty much anyone and so in the corporate sense we've obviously got you know shareholder voting and shareholder proxy voting although in in digging into that whole world it's it's often unclear to what extent shareholders are actively able to assert their their votes you know via proxy many brokers actually include in their terms of service that you're not allowed to sort of utilize that proxy and they often just vote with management so there's a there's a piece there there's this idea that once they're tallied that they are in effect automatically executed through the backbone of a dow which is a smart contract and you know that smart contract is what's defining the rules of the organization it's what's directing the the rules and the logic as part of the code and so you know dow's as sort of examples of a computational organization and how they've been played out it's it's interesting to see some of the things that they've initially focused upon against services to something to a large extent are handled automatically although again there are ways in which their their hybrids have developed in which you've got services that are sort of like managed you know by various different sort of freelance organizations being coordinated through a dow and so you know oftentimes obviously the services are being delivered by an organization that's connected to the dow but but this fundamental piece is the idea that the dow votes and and all other activities generally public and tied to your address with information about your holdings and your other on-chain activity and so I think there's this interesting discussion that we can have around sort of transparency versus privacy when it comes to sort of taking part in some of these collective organization forms so in looking through some of the ways that dow's have been set up and and and the way they've worked and some of the tooling related to those one of the discussions that Daza you and I have been having and and you're going back a few years with with Noah as well is is the idea that there's certain there's certain elements that any kind of organization will will need to put in place but certainly in relation to the the way that dow's have unfolded there's often been this initial coalescing around a particular objective a particular manifesto or purpose and you often see that sort of written out amongst a particular group and then you'll have that shared in a in a discord community you'll have like the people sort of joining and communicating and sort of creating a community prior to any smart contracts being set up or formed or anything but essentially you know once you've got the that ecosystem discussing and in place and there's there's sort of various other tools from sort of discord telegram element that are used as part of those those discussions oftentimes and then there's this this this next stage which is often involved with setting up your treasury tools that are are often used that include the the I think the probably by assets held the largest tool the most used tool and and silk is here is the general council of the folks who made that tool it's called the noses safe and it's essentially a multi-sig account hey silk and when we say multi-sig we're essentially talking about the idea that you need multiple signatories to sign off on the disbursement of funds but that can be done again via your your your wallet and and it's all done on a in a transparent way the governance then is this sort of like much more wider piece that sort of starts flowing out and you know in some ways that will have been developed as part of the way that the the community set up the the treasury piece is a key piece of governance but just in terms of the historic evolution of governance in in sort of Dow tooling in the early stages of Dow's being set up we we often had governance seeking to be embedded fully within the protocol itself and so potentially you wouldn't have a separate treasury tool it would be less composable in some sense and you know we have we have platforms that many people still use including Dow stack and Aragon but which many people felt were potentially overly complicated and then once you had Ethereum's price going up it led to gas prices to passing any decision getting you know in some cases in order to be high and so we had this evolution of governance back out of the protocol itself in the way that these platforms had set up and into certain gas free sort of voting or polling mechanisms and this includes things like snapshot although there's there's certain other sort of pre blockchain tools that have been used including Lumio and co-budget that allow for certain off-chain decisions to be made and then tied into separately a multi-seg transaction and then the the problem with that though is that once you've got somebody in the loop with actually taking the results of the poll and then sort of putting it through the the treasury or the multi-seg you've got one point of failure and a point of potential corruption which is what Dow's is really trying to remove and then you've also got the potential liability that goes with those actions being identified with those signers rather than with the the Dow itself and so Silke again was you know critical to actually figuring this out on in a live basis for you know a series of Dow's and that led to safe snap which was a sort of like polling mechanism sort of getting tied directly into the noses safe and so again we're sort of part of the evolution of the tooling here and I'm very curious to see how Noah's been thinking about and working on governance as part of what he's been doing but the the real piece that I know Noah's been thinking a lot about is around the the ownership and the the management of those sort of components of ownership that exists within the blockchain and Dow space and mainly tokens right so you have fungible tokens you've got this phenomenon of governance tokens and then you've got this new phenomenon again of non fungible tokens each of those tokens maybe we can sort of jam about a little bit more with with Noah and Brian because they've been working deeply as as part of this as part of upside but each of those in a certain interrupt but like speak of Noah and and Brian like we do have to make some room for him and I we obviously should have made three hours just on this session because you're you're providing a master class on this so it pains me to to prompt you along but but um but I'm doing it anyway. Yeah so maybe I can just like jump directly ahead just to my last slide so I just wanted to bring it up like so just back to the the meme actually the rage quit meme so this is something that I just wanted to seed in here as an example of the kind of governance mechanism that you might want to start composing but it's certainly been a key part of the sort of like the Dow ecosystem this is essentially the ability to to leave and you know it'd be it's interesting I think to compare race as an opponent and to what extent it exists you know in our current sort of traditional organizational models but with that I'll I'll leave it there and let's like sort of dive into some of the the stuff that Noah and Ryan Noah and Brian have to to share with us. Thank you so much Tony much more to say and uh it just is a little spoiler uh the last Friday of the month um in February uh which will be the 25th uh at 12 p.m eastern we're going to be doing the next idea flow session and um I would you know I it really pains me to have um to have cut you off before you you're quite done if you're around um that one or one of the subsequent ones let's pick this conversation right back up where we inter interrupted you at that point and let people join in okay great so with that um our next speaker is Noah Noah are you on are you with us yep yep I'm here uh am I I'm going to go let you go into share screen Noah oh great perfect um yeah well I'll just say a few things before I jump into the the share screen it's lovely to be here this has been a many-year conversation and um it's really exciting to see a lot of the projects that have been going on for for many many years like finally in in major use this year um and uh so I'm going to kind of jump into this presentation here I'll try to be mindful of the time so everyone for everybody um so uh I I've been uh many of you may know that I worked on a project called comacry for many years which was kind of gathering people together around projects we repositioned that infrastructure into something called upside and I think it fits in pretty well with uh with the topic here about composable governance going to start with where we are and then I'm in in terms of the the community as a whole and sort of some of the drivers that we're seeing moving around and then I'll talk about some uh some specifics of how we're doing composable governance and how we're thinking about it um so just to drive dive right in this is astounding to me there's 20 000 new tokens that are created every month on ethereum and growing actually the nfts even though they're like taking up a lot of the the uh the meme space are only a very small portion of this this is december of 2021 so this is this is pretty crazy um and I think one of the reasons why dial governance has become such a huge topic this year is because the market capitalization of uh decentralized governance tokens is pretty huge and a lot of that has to do with regulatory situation which maybe I'll talk about at the end um but this huge increase in value has been uh has been has really brought attention to a lot of the experiments that have been going on in the community for many years and in some in some ways the dow community has uh not gotten as much attention as some of the other things happening in the space it's really exciting that this is driving that um if you haven't seen deep dow I really recommend checking it out this is um uh I'm not affiliated with them anyway but like I love that this exists um it shows how much treasury there are like it's amazing there's 406 000 active voters and proposal makers right now it just really shows how far this industry um and uh community have come so check this out um I'm gonna drive straight into some of the things that we're working on in our private beta right now at upside um and this is kind of the framework that I want to share which is around dow building blocks so um broadly speaking governance uh can be about shaping the decisions within the community or around the the interactions and relationships that people have I think there's a set of individual building blocks that make building dows different than uh building a say a traditional organization or or a company and uh these are the ones that we're looking at specifically uh at upside there's token transfer restrictions um known as ERC 1404 or 14 there's some other ones uh so there's a token transfer restrictions useful for security tokens there's NFTs and their metadata metadata is this huge topic um there's just basic tokens ERC 20s there's dow voting uh which is also a huge topic on chain vesting uh or streams of tokens that are issued over time the token gated content I think comes into play a lot more uh in the the token space then like a long time ago if you had shares you would get a discount or a store uh and really would get access to certain events that's really become very prominent in the uh in the in this token-based community building dividend distribution oracles uh that uh feed information back into smart contract arrangements or another component staking rewards um and swap contracts there's other components but these are the ones that I think are um really in common use uh across a lot of different organizations and what interests me most right now um is how these things are going to be combined into different kinds of organizations and there's four on the left that I think are kind of like common use cases there's the company or fund which ends up having transfer restrictions there's the unregulated unregulated dow which is unrestricted but has does have the voting and may have other things like on chain vesting there's unregulated NFTs and you're not really seeing regulated NFTs so much right now but you should expect to see those uh sometimes soon so we're going to keep going um so this is uh sort of prototype uh this would be much more beautiful when it's actually launched but uh the idea is how do you launch something that composes all these things in a very short period of time so we're building a launcher for that select your blockchain um and then uh putting your token details because usually the basis of all these systems is a token so the name the symbol um who receives the initial supply often this will be a nosa safe that will be receiving a large portion of the initial treasury um and then token power-ups this is kind of where this uh this idea of those uh building blocks starts to get more interesting where if you want to add some kind of staking yields governance voting built into the token is this a transfer restricted token or a security token and then uh go ahead and deploy it goes out to the blockchain and then you end up in in admin panels for administrating this uh and uh so some of the things that we're we're finding are really um are of great interest are things like vesting schedules so this is the vesting schedule module um this one is like a one-year of vests uh and then vesting daily for four years you can actually do things that you wouldn't do in traditional vesting it's like you can do per second vesting which ultimately ends up being per block vesting but you can kind of stream vesting tokens um I think this component actually is going to become very important to the evolution of DAOS because right now we're thinking of like bounties or uh or proposals but we don't yet have this idea uh widely adopted value streams and I think this is an area of growth uh proposal voting for stake tokens um this is something we're building out you'll notice this one's on uh Solana rather than on Ethereum but um the uh this people have seen a lot of voting stuff and I'm sure we'll talk about it where we're snapshot um and then I would say one of the biggest choices that we're seeing in the space is around whether something is a security token or whether it's a governance token and broadly speaking security tokens are going to have dividends that can be backed by off-chain assets there's some kind of investment contract um it's only available to restricted or high net worth investors typically highly regulated whereas the a lot of the growth for governance tokens has been around that it separates the underlying value uh or the the off-chain asset from just the right to vote and that is what has moved these tokens into an unregulated space and that's why we're seeing um so much experimented experimentation and growth in that space um they're they're not typically associated with an underlying value although they might direct some value towards proposals um and they're freely transferable and there's high accessibility um we do have a transfer restriction module which is more for security tokens and the in this case you might want to do something like um you have uh you you're sold the token a security token to a reg d investor and then the uh reg d investors are not allowed to sell to each other for one year they can sell to reg s investors who are offshore and those investors can transfer to the exchange with each other so this basically is like a construction kit for uh modifying the transfer restriction graph and then once the issuer decides on that graph then the interactions with that are approved so right now the idea is around single token systems with transfer restrictions but the growth area the exciting and interesting area I think is around these transfer graphs that interact with each other possibly modulated with like an exchange rate driven by an oracle so you have this like more complex system about how maybe access tokens and investment tokens can interact to build these more complex systems so that's sort of something I see coming in the future this is like a visual view of a kind of graph that can be generated from those nodes and edges yeah so a couple conjectures about the future and this is where I'll I'll leave it I think that as we mentioned earlier I think that DAOs will vote to elect token stream payments in the future for fulfillments of service roles so right now we have these flat organizations I think that are and that's what we think of as DAOs but I actually think that DAOs are going to involve to elect roles similar to say some of the holocracy or adhocracy kind of structures that people are experimenting with about five or six years ago and I think that those are actually going to come to DAOs we're going to actually build more complex organizations than we have right now we have the kernel of like capital allocation through voting but I think that that's going to get more complex would be interesting I think oracles are going to be streaming a lot more data that will maybe modulate those payments or based on outcomes so you'll be able to sort of modulate the compensation or exchange rates between different tokens that's going to be exciting I really believe that like there's going to be an algorithm for that limits the power of token weighted voting for large token holders I nicknamed this whale dampening and I think it actually is going to have a huge impact on what a broad scale what capitalism means because as the shareholder roads get modulated the larger sort of token holders would not have as much impact and there'd be more community management but there'd still be sort of the profit interest so that's going to be interesting I think we're going to see a lot more innovation and the unregulated spaces as we've seen and that includes both the governance token area assuming that remains somewhat unregulated but it also means games so I think the future of work is being modulated this being the future of work is being experimented with in the gaming community where the risks are lower and that we really we should be paying attention to the play spaces more so that'll be exciting I also think contrary to popular belief that full decentralization is actually a competitive advantage because when things become fully decentralized they actually are less regulated and I think people have vastly under appreciated this fact and also that this the other thing to watch in these in in the blockchain spaces how fast are people making decisions about real assets so there has been some discussion about how like oh this could just be done in database and most people are not looking at the legal clearing side of the financial instruments that are in place so like sure you can change something in a database but like no your clearance time is still like t plus three you don't really know what's happening with like naked short selling all these other things that are happening in the database level so so I think there are competitive advantages to decentralization and and yet I think there's a lot of real world value that must be represented within a securities framework and that that will benefit from a lot of the innovation that's happening in in other less regulated areas so I'll leave it there great thank you so much Noah wow so much depth and that that chart was particularly helpful to to kind of get some traction on what can otherwise be you know very conceptual and that's a perfect bridge I might add to to to the next speaker Brian who's going to talk a little more from a design approach about composable governance and then I'm going to introduce Meakin who's going to who's going to basically give us an opportunity to play together more directly on on this topic so with that Brian I know you've got a couple of slides could you could you take it away yeah just one moment um and Brian is the editor in chief of law.mit.edu's MIT computational law report by the way and it was um his leadership uh that where he prompted us to actually try to tackle composable governance this year here we go all right take it away yeah so kind of quickly connecting the dots with some of what we've all been talking about today whether it's from the composability aspect or the play aspect or the harmonization of the the BLT or you know the actual creation of these new types of modules for how we can do some of this stuff um you know one of the big underlying themes here is what design patterns can we adopt to go from a paper-centric paradigm of law to one that sees the law more like data and more composable for me the biggest entryway to some of these notions around engineering composability and complex systems has been the work of Buckminster Fuller. Buckminster Fuller for those of you who don't know is famous for populating the architecture of the geodesic dome and critically you know some of his ideas really serve as the foundation for a lot of these interoperable complex systems that are based on parametric definitions that can be used to compose an architecture based on different limitations like what type of uh what type of material you have how big of a space do you have um you know anything that's really related to a given environment and I think that's what we're now coming uh up to the potential of with the law so now we have the opportunity to actually compose law in the same way that we compose architecture through CAD and these other systems. So bringing this into squarely into the legal context there are already a couple examples to help demonstrate how some of this works. The creative commons license framework is a notable first example here for a few different reasons. First the framework can be mapped using an expert system this means that any of these answers that you select from the creative commons license selector give you different rights. So this is selected as the creative commons uh 4.0 share a like uh or no 4.0 international license it's yes and yes um and not and and that's important because you know prior to the systemization of legal rules and processes there's there's kind of a one-off you create a legal instrument and you spend a lot of time creating it now if we create a system where you answer a few questions it quickly spits it out. The second reason I think that this is important is because the framework's modular and that that goes not only to this ability to be part of an expert system but it also goes into tying the the legal aspect of the of the code that gets spit out here to actual software code and also plain language summaries of what all of these obligations mean and then finally I think this helps show a path a harmonized path forward to prevent gaps between law code and accessibility and some of the ways like Killian was talking about so here's what one of those answers kind of looks like when you break it down and examine it more thoroughly um and and you can see here the the plain language summaries shows you what you can and can't do um there's this legal text blurb which you know spits out like an actual license like you might see in intellectual property law um and then you can embed this code in your website and um people querying it can automatically kind of see what they can and can't do with your material the the kind of bonus point here is that there's also a uh an icon that you can use to sort of visually and quickly distinguish what this what set of rights you you have and you get to play around with and I think that gets us uh we've got a little bit of time for discussion so I don't know if we want to do discussion before doing the uh the cool next part um my suggestion so that was awesome first of all Brian and my suggestion is um I think um we should have Megan um jump right in and let's do the announcement and then that can help seed the discussion because people me it may just well spark some ideas which not coincidentally is part of the idea for the announcement so uh Megan do you have the uh here we go uh I see it here um take take it away oh and I should I should say uh Megan is our um managing editor for the MIT computational law report and I want to say one other thing which is we are now entering a new hat segment this is now law.mit.edu and furthermore it's a new jacket segment we're going to get a little bit more colorful we're going to get a little bit more creative now it's time for that play box you've all been asking for all right take it away hi everyone so it's nice to see everyone here and I'm sure that after such incredible sessions you're all probably overflowing with creativity um and we're super happy that this has sparked interest so on that note our call for action from this workshop is to ask you if you'd like to join this playground um and we're doing a call for submissions in what we call an open access publication um somewhat of like an open book or an anthology of sorts uh we call it the collected works on composable governance and the reason why we decide to use the term collected works is really because we try to make it as diverse and open as possible we're trying to range from conceptual works to a little bit more practical trying to understand how you would implement or conceptualize implementing um composable governance as well as really going down to the weeds and getting a technical documentation or technical description um and probably proposing some functional modules or legal components that you'd like to see or have developed so um we also make it open in terms of formatting as well as um formatting and the length just so that you know whatever you would like to offer us we would like to see so I think DASA has dropped in the link where you could submit your submit whatever you'd like to offer us and we have the link as to the form as well as important dates and timelines just so that you know kind of the schedule and expected schedule for all of these details so we hope that uh this is exciting for you all um and that we're really looking forward to what kind of you got out from this um just as a small anecdote about two years ago I attended the IAP um and I had written a piece from it and it really took me into this computational law world so thanks again to Brian and DASA for that and so I kind of see this as an important call to action for anyone who really wants to dive further and dive deeper into not only computational law and exploring this space but also composable governance so yeah take it away DASA and Brian um thank you so much just to pick up on that last point um when um uh Megan um came to the class so we really didn't know you at all you just kind of um saw something announced you clicked on the link participated like a champion then submitted something to the call of action for that year it was so great we you presented it um uh live online and then we kept uh publishing your stuff and next thing you know you're volunteering and next thing you know you're managing editor of the computational law report and just to cherish um critical collaborate a member of the MIT computational law community so um everybody be like Megan and go ahead and take us up on this invitation to think up and then share your ideas and uh let us help catalyze the the idea flow and see if we can't come up with something that could actually legitimately be composable governance so uh with that uh Brian and Tony I invite you to sort of facilitate uh the discussion period uh that we have now on these topics sure fantastic so uh please feel free to throw the questions and thoughts into the chat but first off uh I wanted to throw it over to Isaac uh who I invited here to talk about uh some of what he's been up to uh he's been working on a uh sort of deeply in a whole bunch of vows uh and has has a sort of like a deep hacker uh mindset and experience uh which we love here fantastic hey my Isaac thanks for joining so yeah thanks for the invite you've been you've been working in particular upon a new um uh standard for uh sort of querying governance issues and and relevant data from DAO's can you talk a little bit about that and how if at all you you see it sort of fitting into some of what we've been talking about um sure yeah um we've been working in this uh in this like kind of meta governance uh uh DAO research group just trying to agree on kind of like what the fundamental primitives are in DAO taxonomy land that we can use to extend the different route DAO frameworks uh do we all have kind of seen since since like the gnosis like zodiac uh I don't spend earlier in the year um people are thinking more a lot more about just like how do you compose these different structures where you'd like keep maybe a single avatar which is DAO's treasury but basically plug in different modules over time and how do you allow it down to describe what its rules are and describe what its what its constitution is um describe how it even how it even thinks about membership um in a way that allows it to evolve and grow as the community changes um because something that we often see is that like a DAO spins up as um a multisig with two or three people and with uh with like zodiac and which is kind of the same thing at reality dot e and safe snap uses it basically allows the multisig designers to remove themselves and plug it into something else and so since these things update over time we also need to allow DAO's to update how they describe themselves over time so I'll give a uh I'll just uh share quickly this uh draft that um that we are let's see let me share just that window um this draft on what we're uh what we're using to help DAO's describe themselves because what we don't want to do here is impose a standard on how DAO's should govern and how DAO's should do anything basically because there's just it's kind of an endless creativity period where people are um thinking of all sorts of different modules to create um so instead what we want to do is just allow DAO's to say this is what we think we do this is how we describe people that are part of us um this is how we're describing state changes to our community um and the transitions between those um so uh the um the core of this EIP is this concept of a DAO URI um in the NFT yep this NF this page is open we share the link um the thing about URIs uh in in the DAO land I kind of think of it like in relation to the NFT world um to me like the most one of the most powerful things about the NFT space is not so much like the digital asset ownership but it's the fact that people have agreed on a standard taxonomy and a standard way of querying data you can technically make any smart contract look like an NFT it doesn't have to be an NFT but you can basically say you can basically have some JSON that describes it did some sort of asset and now everything that works with uh with NFTs knows how to interpret what your what your contract has and so we want to bring this to DAO's where we can just say all right do whatever you want as a DAO just give us some information about um if I were to go into ether scan or deep DAO and click on your DAO's address um can you link me to a constitution that's like what do we believe in can you link me to a member's URI which maybe is a static JSON file which is like these are our members or maybe it links to a sub graph which tells you how to get our the freshest look at our members um can you link us to a proposal's URI which just says this these are the upcoming potential changes to our DAO and these are the potential ways that they could change in addition we're we're looking at different uh for the actual management of the taxonomy um before DAO as I was doing doing more stuff in like the decentralized identity verifiable credentials space and something that I thought was really powerful there was a the use of JSON-LD where we can just define these really basic root types about a member is doesn't even have to be an Ethereum address a member can just be some concept of a unique ID and that can be extended to be a DID and Ethereum address a multi-chain address and then over time basically DAO's can say I am this plus I believe in these things um and so that we can build this like tree of of of what DAOs are doing um so yeah there's just a quick intro to like what we're and that last piece I think is super important for some of these notions of how it's going to integrate in with like some of the stuff we heard about earlier in the workshop uh with the the open ID federation because I think some of these standards are based upon you know the same sort of identity federation mechanics so that's super super exciting thank you so much Isaac um Silke we're gonna sort of see if you've got a moment to come and talk to us a little bit about Gnosis tools and privacy so we've heard a discussion about Gnosis safe which is the sort of the largest or the most used of these multi-sig accounts but there's a whole bunch of different things as the general counsel of Gnosis that you've been having to deal with so thank you so much for being here with us and yeah we'd love you to share what you have Hi guys um so Isaac has already spoken a bit about Gnosis safe and they're building on top of this but originally just to to step your one step back I mean most people probably hear know the Gnosis safe but what it is is basically a multi-signature wallet um which we built in 2017 to store our own funds after the ICO and then it it took off people thought it was really useful and what we noticed in 2019 is that in fact you could very much people when they spoke about dowels what they actually often mean is a multi-signature wallet and the Gnosis safe is a very very much used multi-signature wallet stores around 3% of all Ethereum on it at the moment and after what Tony already said was that the the tools that were built for dowels especially Aragorn the early ones and starting 2017-18 mainly when the 19 user became new usable that because of the gas price people actually stopped using those dowel platforms which have really great and still do have really great ways for dowels actually to live entirely on chain so people went back to the Gnosis safe which is basically allows you to add as many owners as you want and I'm not sure whether I can do this live but maybe I should just share my screen and I can show you how a Gnosis safe actually looks like um let me just um sorry I'm really bad with this but let me just one sec give me one moment where is it so go back normally I would I am so um can you all see that so this is basically the interface of a Gnosis safe um there's also there's also a mobile app but this is I just used this as an example now usually I have many more assets this this one is actually empty but what it is it's a smart contract wallet and you have several owners which control the wallet and what you can do and I'm just going to show you this um is that this safe I just loaded here you see that there are eight eight wallet addresses that control it and the policies in you see that four you need four signatures to actually do anything in this safe so dowels especially some of the very very big ones they use this they form this council um what has happened is actually yes people want to all vote on and they want that there's very much but Tony said direct democracy in a way to to vote on but in fact it's not very agile so for example you're in finance many went back and said okay we're going to have the eight people who um going to decide the things or like to execute the staff to dial the sites and because of the gas prices people moved to snapshots because it was gas less voting and dowels were constituted by basically having a treasury with a notice safe with some trustless community members being the signers here as you see here and you would have snapshot where basically all the voting is done which was built by balancer labs but there wouldn't be a con connection and then now you see more and more and of course also noses modules that connect the gas less voting on snapshot with the notice safe so um for the noses dow which um we form we announced more than a year ago but then it took quite a lot of legal structuring to actually move the funds with a profit entity into an unregistered dow we then requested oh actually we need a self execution mechanism so we need to have the snapshot voting be on chain executed and then on the safe um so so out of that zodiac um came about or this is actually my story for it um which is one of the noses teams and these are the apps you can all use from your noses so it's in a way like a small bank it's like an operating system for dowels this is how we see it and there you have the expansion pack and so the self execution you can basically block it in and use like the reality module sorry it's not loading unfortunately my not to worry i'm going to just take one quick program note while it's loading it's perfect timing actually uh so that concludes the formal session for the 2022 mit computational law workshop um thank you very much for for joining us and we're going to keep the line open because clearly there's a lot more to talk about including just finishing the remarks that we're in the middle of but there's also some other remarks um that are um that are that I think people are interested in so if you're available and interested stay on the line with us if it's time for you to go you've got the the meat and potatoes of it and follow up if you want to keep the conversation alive by making your contribution to the next publication that we're doing on composable governance at law.mit.edu forward slash composable governance one word so with that I want to thank all the speakers and all the participants um for joining us dot dot dot and we're in extra innings back to you you were just taking us into the same actually I'll just need more two more minutes so what you see now here is the zodiac tools for for DAO governance which you can all block in as you want this very modular it's composable as we are just talking about composable governance so the reality module from a legal perspective a lot of people forget that actually DAO's are still subject to the law and there are still a lot of um it's it's it doesn't work yet fully um but basically what it well you have different modules one of them and I think this the most important one is the self-execution one is the reality one here um I wanted to say something about privacy obviously in a DAO space nothing is private so when you use um for your company operation the notice is safe everyone sees everything all the time and what a lot of people often forget is also you see the owners you know what wallet addresses um to um control it as to privacy I think we haven't really built those tools yet so the and this is one of my actually hard the things I really want to have as process everyone always focuses on transparency with DAO's it's one of the big advantages but it's also a drawback because for example give a DAO legal advice you're going to write everything in the in the transparently in you know the forum like the snapshot my proposal in discourse what they use um for some things you might actually want to have dark DAO's and I mean it in a good way like unknown DAO's or at least shielded DAO's better vote voting of the DAO is shielded because of the potential liabilities people might have there are a few projects that actually started to work on this I recently saw the launch style by Panther I'm not connected to them but I basically realized that they decided to launch or have a token generation event and the people who voted on it you knew that people voted and what percentage voted but you don't really know which address voted um for what and which addresses were actually in it while everyone was KYC from the token sale these people had this chance to vote so I think um in terms of privacy DAO's are because they're so transparent um they are actually right now not very good and we do need more tools that can be plugged in for certain situations for example the DAO wants legal advice because they their IP rights are infringed you might not necessarily want this all to be public what you're going to do some people this is very controversial view on like whether this is any good or not I think we need those tools and I would be really interested to have to jam with people on like how these two could be built without infringing upon the advantages of what transparency DAO's actually bring that's it thank you so much I if Tony if you and Brian if I may and then we throw it open I just have one burning thing that I don't want to forget this partly but I feel like this was such a great first of all thank you for showing us um that tooling and but on that last question about well almost like a private privileged space that's nonetheless within a DAO um and and and the implications of that and and the fact that it's controversial I think it's such a terrific topic for this question of governance because I mean would one way to look at this be as a governance question for a given community would they say almost constitutionally this is a DAO where everything we're doing is transparent or might they have a different context instead of objectives that they declare for themselves that this is a DAO where some things we're doing um are going to support privacy or even confidentiality for legal advice um I mean in other words could this in fact be a governance question that doesn't need to have one answer for everyone just throwing it out there and since you're not answering I just will we'll say I'm going to just say hey everybody I think this could be a governance question itself and this could be a good example of that uh but you know maybe I'm wrong maybe there's supposed to be a uniform universal eternal definition of DAOs that never allows her or allows for this so uh you know we'll let the debate unfold and back back to you Tony and and Brian to facilitate the remainder of this informal discussion session I mean just first thoughts on what you said Daza and sort of taking a cue from what Silky put in the chat it's it is these are all open questions and it's it leads to a lot of lawyers being reluctant to advise DAOs due to these these kinds of liability issues this lack of certainty over who the client is certainly there's lawyers who are sort of like taking a position that they're sort of putting things out sort of into the open and they're not necessarily advising any particular person but they they may have been funded to do work that is then open sourced and can be applied by anyone but I think there is in some sense space for what you're talking about in terms of uh some sort of composable privacy layer that nevertheless uh is accessible with certain kinds of uh attributes that you may have within the DAO and you know you can imagine there being uh that's still being sort of open to anybody within the DAO subject to sort of meeting certain criteria but that still doesn't prevent you from having certain kind of private spaces for for less than fully open communications yeah and and kind of building building there on something that I think could be really interesting and going back to the notion of a lot of this space being a play a space to play in um you know four four years ago uh in the IAP course we you know we're really interested in in crypto kitties as almost like the model for you know what are NFTs able to do how can they operate in this kind of open and public constellation of apps and services that allow you to do different and kind of interesting things and I think you know we've sort of played around enough with that to go from you know something that was very much a play thing to something that turned into NBA top shot the NFT kind of uh collectible thing and now we're seeing the rise of NFT credentials and so you know what I would be interested in and maybe this is kind of like a almost like a moot court style idea but but having a series of challenges and and like a DAO Olympics like the Olympics for DAOs where you set up a number of different you know almost like uh disciplines like trying to accomplish different tasks and you have different DAO configurations and people playing around with those in order to try and figure out how to accomplish some goal or what the uh even what the tradeoffs are from trying to do it one way or another um I think having that space to play is very much what we envisioned when we wanted to make this call for submissions for collect uh collected works on composable governance because you know it's very much in an embryonic stage and it would be really worthwhile to figure out you know how we can play with all this stuff together and in a way that does you know it may seem silly at the time but it does provide value along into the future that people can learn from in the same way that has happened with previous crypto innovations um and and yeah I that makes me excited so Suka you came back on your video had you got something you wanted to share about your no I just I I love the DAO Olympics uh um idea and we should have different tracks you know different um yeah track and field I mean like hurdles like a privacy then I don't know spare um you know just some other jump high jump or something else I I do actually like that idea so um and and I mean you know we're building so many things right now and um a lot of the governance things had actually looked at in the past so we should not reinvent the wheel on some of the things um and but uh I think there are just so many issues also with the direct democracy ideas which um a lot of the DAOs now start start delegating you know I have the ENS DAO and um GIT coin that have very wonderful schemes which um and different voting mechanisms which you can use now also even in snapshot already so yeah I'd love it well oh and I love this comment from Noah yes but um about the Merkle drop contracts yeah let's check that out yeah we should look at that but thanks so much everyone I loved it yeah so it's just um like team we should we should look at um maybe adjusting or extending slightly the the call for participation for composable governance to include like a DAO Olympics I think that fits easily in at least two of the tracks tracks two and three which are fairly practical so it's uh I think we could do that yeah see people saying that's um oh um oh it also can I also I would also what what I would find really important in the Olympics is the the impact our and um track maybe because um at the moment I find those some of the most interesting one of course for profits are so good but yeah like you know for justice even a a free raw style not a free and smashed out so you have very good examples of trying to um impact the legal system by a DAO's yeah indeed that's so interesting and you know earlier this or last year we had Diana Stern as one of the speakers in the idea flow monthly session and one of the things she showed us how to do was integrate um legal license terms with NFTs based on a kind of a cool legal hack um and interestingly what we did was we chose a Creative Commons license so we're sort of doing a hack upon a hack that's a that's a kind of free um license type which assumes that there's not royalties coming in um and it's a different mentality and it may be the type of um configuration one could one should be able to set with a mission driven maybe nonprofit oriented DAO that's um that's not uh the for-profit type you know some of that would play out with um uh like a selector for license types as well as so many other things um very very interesting so we that could be a track you know kind of like uh you know you run on this field if it's for profit and the main measurement of performance and success I think includes revenue generation and profit but maybe there's other metrics for success for composable governance and the impact and not not for profit and mission driven uh categories as well like Tony what was on another idea of flow where we looked very deeply at um carbon accounting and um and those kinds of ESGs and how to measure that so yeah and I think I was just quickly I think that's one of the especially exciting things about these organizations that create value based on inputs from data because if you turn that input um into something like climate data you can bias the transactions of an organization in favor of a set of outcomes and begin to programmatically achieve those goals so whether it's um you know climate and sustainability oriented or whether it's related to affordable housing or whether it's related to public infrastructure you can you know create uh create a mission that is related specifically to you know different data outcomes and if the organization kind of functions as it should then you know those those are the types of things that should sort of be figured out and that's that's not really even you know that new of an idea there's a there's a european economist bernard leeter leiter i don't know how to pronounce his name correctly but he uh he's one of the guys that um helped design the euro and one of the things that he was looking at is how can we you know create the euro as a basket of is almost like backed by a basket of commodities but also services so that it's you know regenerating the forest and it's promoting commerce through toll roads and it's also backed by you know things like gold and so i think they're they're interesting um overlaps with uh analog incumbent industries that we can draw from but also extend with this ability to represent things and engineer things as uh as as law here here okay so so as we start to wrap up oh you're actually ran on point uh tony i was going to say let's go through and have everyone that spoke on this session kind of make your final remarks and not coincidentally the first one is tony well thanks i um i'm deeply appreciative of everything our crew is doing in this area and yeah i love that we can continue engaging in this with a spirit of full-on jam and hopefully others who are connecting with this will join us for future jams but uh deeply appreciative thank you daza thank you brian thank you megan noa uh silke and isek as well just a big huge thanks to everything that you guys are doing in the ecosystem as well and uh yeah let's take this forward for for maxima impact we're here thank you tony and um noa hello thank you thank you uh okay do you have so if do you have any final remarks or do you want to pass the baton oh i'll pass the baton this is wonderful session uh and you have a wonderful jacket and uh yeah really great to be here thank you noa um brian yeah i'll just say uh you know kind of i've got kind of like a dual dual thank you or a pluralistic thank you because i i think uh you know i'm i'm really grateful to you know have a chance to put on things like this that people get really interested in and excited about um but also you know very grateful for even this being my sixth iap workshop to participate in so um you know this is uh this is really fun and i think by you know getting everybody excited about these types of things and by uh exploring with kind of an intellectual uh vigor um you know how these things might play out um we're we're helping co-create the future together and so i just want to say thank you to you know everybody and institutionally thank you to um mit for using allowing for this type of space to be created you're here on behalf of mit we we we thank you uh for for being a you know part of the community and now you're part of mit too which is so great um and so one thing if i before we go to um megan um brian's entry into the mit computational law community was um not through this course but through one of our close affiliated collaborators um which many of us participate in including tony and noah and others and that is none none other than legal hackers which you can find out more about at legal hackers dot org and i forgot to mention the beginning when i was having connection trouble thank you brian that um this very event is actually a collaboration um with boston legal hackers and deli legal hackers in india and i want to just thank and welcome all the participants from deli legal hackers and and their larger community across india who who've joined and been such great contributors uh to to this workshop okay so with that um megan uh you've got the baton do you want to bring us home yeah sure so thank you everyone again this was incredible um and i just want to say don't be shy contribute um submit whatever you know comes to your heart and i think that given you know how incredible this group is that it would be something unheard of and really really innovative and pioneering in this space so um yes again don't be shy and contribute outstanding oh wait a minute we have one final question here do we have time for this i think we might why not okay um okay so this is extra extra inning at the last moment um taking as a whole some of the more embryonic and novel topics we discussed for example codis law um dow is composable governance what's that um wait a minute okay so i said let's stop but stop chatting for a minute so i can read this um and evaluating all of it through the mit lens how do large research groups within mit factor in the development of these technologies i'm talking about for example mit connection science or researchers under sandy petlin are the large informal research groups within mit more like fast followers tracking trends that originally external that originate externally in the crypto governance legal hackers community or is it the other way around whereby university research groups groups originate most of the ideas which are disseminated onwards or both what a great question um so it's like you're it's like you're reading my mind um because i think very much about those um those uh tracks and how they relate and there's some balancing there frankly to do um and so uh so the answer the short answer is both um and so there's been any number of examples which which i think we're really pleased with where we've highlighted or spotlighted i'll say really on point ideas from sandy petlin's group and from connection science and the human dynamics plot and beyond at mit um like that cool algorithmic music um idea flow we did and there's um any number of um things that we publish from mit so it's very much um a way to circulate some of the on-point ideas from across mit the other thing is that we are the mit computational law report is literally a research function of mit jointly between mit media lab and connection science that you mentioned here um so like on an org chart that's where it is but but it goes the other way around as well um so there's been any number of examples where we've where people have participated and well brian is a really good example where he came in was a participant it was very external and i was actually um a fellow at mit connection science like literally um been incorporated and we certainly vector ideas in all the time so it's fairly porous and it goes both ways and what we hope is there's a synergy that that makes um that that makes it better but part of mit's mission is is at you know key times in history when there's a going to be like a major change in a in a in a sector of the economy or a society when there's tools and technology mit that is that's changing things mit will take a very public spirited view and engage and try to assist with that transition and refactoring in many different ways and so i think some of this is on brand with the mission and the culture at mit as well so uh that would be my my answer uh i think a good uh a good single word to describe it is that it's uh symbiotic so you know it generates and flows both ways um you know one example of this would be uh there was a paper that came out of uh sandy's group about uh possible consortium cryptocurrency kind of stable coin design um you know i think 10 years ago or or so and um that was what libra used as their kind of basis for how to do that uh how to do their cryptocurrency before they kind of encountered some of the uh practical hurdles um that they ran into but uh you know i think i think part of the function of mit as was saying was just to bring people together from all these different spaces and kind of do it in a in a fun way so that's been my experience anyway yeah here here um so and and fun it has been so thank you for joining us everybody for the kind of extra session and the extra kind of uh you know um hacking and collaboration um that that followed from the composable governance and from the workshop this year and uh especially want to thank all the speakers um for taking time out of your day and for all the prep work uh that you did this year uh we just couldn't be more grateful so with that uh we're going to adjourn the 2022 mit computational law workshop