 and the title of the application. Efficient FinClient Verification of Identity. Great. Any more questions? Next person, please. OK, hello? And by the way, class, you said you could be standing by, since you're like very excited for waiting for execution. Hold it sort of, go all-est. I would say the short summary. I'm that TadgeGridgent. We're going to like the norms. Where it's TMI, too much identity. And we sort of took a different view of all these things. And we're sort of like, well, identity is sort of not good. This is sort of something that we're trying to avoid in a lot of the systems that we're building. You want the least possible. Only rely on identity when you've already gone through all the other options. And we already think there's too much identity. There's all this tracking, all this unique identifiers and stuff. And hopefully we can get rid of that with some of this technology. And so we sort of wrote about a spectrum of identities where you can have nothing. You have no idea what's going on. And move that to some kind of ephemeral identity, where there's either ephemeral key pairs or some kind of session cookie kind of thing. And then move stronger to a persistent identity. And then move even stronger, where you're now linking these persistent cryptographic identities with some kind of legal or biological entity. And so sort of a best practice would be to use the weakest and least powerful identity system that can be applied to what you're trying to do. So use attribution and a set inclusion proof rather than a unique identity when possible. So for example, you go to the taco truck and you order a chicken taco and they say, what's your name? I often give a fake name. I don't know if people in this room do. But I'm like, yeah, I'm Fred. Because they don't actually care what your name is, right? They just want a unique identifier so that when your taco's ready, they call out, hey, Fred. And I go get my taco. That's an ephemeral session token. And it does not need to be linked to a legal identity. So that's one aspect. Another attribution aspect is, let's say we're in the future and I've got a taco drone delivery service that's over in the darknet market or something. I want a inclusion proof that the FDA or the city inspector has inspected the taco production facility. Yeah, it passes code. Who's making the taco? Right, so I know, OK, the inspector, this is a clean place. I'm getting the taco drone delivery. But I don't know where it's from. So yeah, so use attribution when it suffices rather than a unique identity. Also use ephemeral identities when there is suffice and you don't need to persist in identity. And if you need a persistent identity, use one that's not necessarily linked to it. So basically, and also have repudiation when possible. So don't sign, use Diffie Hellman. If you can, have something where it can be deniable after a fight. And this is sort of thinking this way because we sort of thought data is a liability and you don't want lots of customer data. You don't want lots of user data. This can hurt them. This can hurt you. So minimize that. So that's sort of what we discussed in. Next steps. We sort of discussed we should have a sort of best practices or sort of strive to work on this. When make. Questions? I have a question. How does this relate to persistent pseudonyms, pseudonyms? Yeah, so that's like a fairly powerful identity, which can still be identity. So it's pretty useful. Like a lot of what Bitcoin and things like that is, okay, we don't know who it is, but we can see that there's a persistent entity here. And so if you need that, you can use that. But having an ephemeral identity which gets discarded after each use is even safer in many ways because once you link a persistent pseudonymous identity to an actual person, you can sort of, so you don't have forward secrecy then. But yeah, it's complicated stuff. And this is what we were sort of arguing about all these different aspects. That's our perspective on it. Okay, thanks. Next person. Hi, so my group was a little bit different. We were not one of the working groups here for the project we were actually listening in on the hyperledger call where IBM was presenting their identity thing. So to give the title, it would be hyperledger comma IBM's membership services architecture. What that was about was some folks from IBM and folks who'd worked on the service spent about an hour going over the architecture that they are proposing for the hyperledger project which is based on their membership services system. This system is a combination of centralized and decentralized services. IBM actually leans very heavily on the certificate authority, both nomenclature and structure as a way to build this service out. It is a system that's built with the idea of both long-term identity pieces and short-term identity pieces. When you first are creating, you are setting up on the blockchain or connecting to the blockchain. Actually, this gives me a good reason to step back for a second. With hyperledger and with IBM, one of the things they said was really when they built this, they built this proposal with the idea of private or permissioned ledgers in mind as opposed to kind of open permissionless networks. So some of the things you'll hear me talking about here may end up being more relevant in the private case than in the public case. So a couple of the things they're doing. One is they have this idea of long-lived certs, which are called authorization certs. This basically gets generated when you're creating your account or signing onto the blockchain for the first time. And then the idea of transactional certs, where the transactional certs may have a subset of attributes in it and are to be ephemeral only used on a single transaction. And the purpose of the transactional certs and doing it that way is really to help reduce or prevent correlation. So that someone who was involved in one transaction can't necessarily see the other ones that you were involved with. There were some interesting concepts that they had built in there. One of them was the idea of building something where for the first authorization, you may be looking for a generic attribute like this person is a licensed plumber. When someone initiates a first transaction, but when they come back, you may wanna know it's that same individual coming back, not just that it's any individual plumber, right? And so there may be cases where specificity actually goes down over time in terms of who you're dealing with. They, as I said earlier, were really heavily dependent on third-party validators and kind of certificate authority structure. And a lot of that had to do with relying party risk, right? If your counterparty is taking any risk in transaction, they may wanna have somebody other than you yourself who is signed off on your attributes. I think that was a lot of the high-level pieces that came in. There was a lot of technical detail that went from there. Is there anyone from my group that thinks we missed anything major there? Christopher, anyone else? No, and they actually, they went into enough detail on this that after an hour, we weren't all the way through the proposal. So there's still somewhere to go. Any questions for anybody? Yeah, I don't think we covered where those identities get stored at all. That was never talked about or discussed. We're gonna go through the rest of their proposal on the next call, I believe, right? For the reason why I felt this is relevant is that Hyperledger is an open-source project. It is not a standards project. They've sort of deliberately said we're not doing protocols, we're not doing APIs, things of that nature. So I think there's some opportunity, especially in what we started talking about, one, multiple blockchains or interoperability blockchains, et cetera, that there may be some things from that world that can be standardized and be used elsewhere, more vice versa things that can be useful for other technologies, other projects that we need. Hi, I'm Bart from Phillips Blockchain Lab. We've been talking about blockchain standards in healthcare. I think in large part, what we are missing from the discussion is how standards tie into existing regulation, which can sometimes be contradictory on the use case. So we discussed, for instance, self-sovereign technology and how that can bring great value to healthcare. On one hand for individuals giving them control, having better privacy measures, but also for companies like Phillips, big aggregators that make money out of doing big data analysis, but also become liable for all the data they have. So if we can drive the liability to the edges that would drive down the total cost of ownership of data for companies like Phillips. And I think that will be a big driver for adoption of standards. So meetings, making some sort of business sense as well as technical systems. So we need to solve two things, the aggregation issue, which is kind of optional and the transactional issue, but these two, they need to come together because I think we need this to be bottom up, but also in regulated environments, we also need it to be more top down for adoption purposes. So we need to be able to safeguard integrity of what happens for dispute resolutions for audits. We need to allow for data aggregation in a privacy friendly way and preferably leaving all the data at their points of origin and not on rupture. So what we suggest is to break down in three standards which are related but orthogonal to each other. On the one hand, we have blockchain and self-sovereign identity, for instance for physicians and patients. We have standards for authorization, so private information, but also OAuth, fire standard, stuff like that. And we have something we call the digital postmark, basically being able to prove whatever happened and I think our main conclusion was that standards need to take into account regulatory requirements or adoption will simply not happen. And looking at the medical space, you have this big paradox of transparency versus privacy. And I think we need use cases going forward that work together with regulators that demonstrates this functionality. And so to sort of bring this all back again to standards, we talked about the three kinds of standards that you just mentioned. And we could also talk in terms of three kinds of technologies that these standards tie together. The technology that I would call self-sovereign mobile device, which is clearly the only place you can have a biometric, for example, control of private keys. Self-sovereign server is like, for instance, an authorization server in the OAuth sense and an attribute server in general. That's the second kind of self-sovereign technology. And then the third kind of technology is what we would call reputation. Clearly that's the part that cannot be self-sovereign and it might be the one that both in terms of the compliance sense and in terms of the reputation sense, the blockchain is most relevant for. So these three kinds of technologies need to be tied together by the standards, these three kinds of standards. Any questions? Authorization, next in there, I'm helping you. Is it built on interconnectedness or not? The authorization component is essential for self-sovereignty in the sense that just like we wanna control and have sovereignty over our private keys for non-repudiation and for all of the obvious reasons, we also wanna have sovereignty over our policies. We do not wanna publish our policies, we only wanna publish authorizations. Or another way to think about it is we never wanna have any kind of informed consent in the big data case, in the high-dimensional data case that we're headed for. We only wanna have flexible authorization for transactions that involve our personal data. So this layer, this O-authority, UMA layer to be exact, which is also a standard nowadays, is what separates our policies, which are just entirely ours and not to be shared with anybody with the transactional parts of the system. I guess this summarizes our sessions on identity. If you'd like to talk more, I'm sure we'll be talking more, please feel free to do so. You know, who was leading the sessions, there's the summary there on that to the next session. Hi, folks, we caught up some of our time. So not all of it, but some of it. So I think that we've got more of a hang on how we're gonna be doing this. This is gonna be the format for the remainder of the workshop. And I'd like to introduce Neha Norula. Neha is driving the thing on the hosting session on providence. Hi, everyone. First of all, just real quick, does anyone have any comments on format? Is there a tweak you wanna see? Is there something you think is working or isn't working? I just wanted to give an opportunity to kind of raise that. And if you don't wanna do it right now, but something occurs to you, please tell us and maybe you can make a modification. Okay, just keep it in mind for later. Okay, so this is the session on providence, which includes, there's a card up here, okay, which includes licensing of IP, assets, sourcing of any sort. And so could the speakers who agreed to give lightning talks come up here? Sure, that's a great idea. Okay. So everybody, please, I see some boxes. I'm guilty of this myself. Please, read in five minutes. Essentially, I got interested in Bitcoin and blockchain fairly recently, simply because I came to understand that it's not only as many called the distributed ledger value transfer system, it is also a memory transfer system. And when you talk about a distributed ledger technology, you are talking about a technology that captures memories of transactions and allows those memories to move through space and time. And essentially that is something that I recognized. I recognize that as a type of record. So a ledger is a type of record, traditionally. And there are a number of international standards as I will get to. One of them is ISO 1549, International Reference Management Standard. And you'll see this idea of memories of transactions as evidence, something that we might think of as proofs on the blockchain is very synonymous with records as information created, received, and maintained as evidence of information by an organization or person in pursuance of legal obligations or in the transaction of business. So this is why, as an archival scientist, concerned with record keeping, I am fascinated by the blockchain. So here's a claim, potential for record keeping. Blockchains are archival record keepers, permanent and transparent. They are the perfect solution for an industry-wide problem of transmitting and archiving. So if this is our objective, then we should understand that there are a number of archival standards out there. These are just a few of the international standards organization standards that are relevant to record keeping. I won't go into details. I just give you these numbers and you can look them all up, but they have to do with persistent archiving of records, record keeping standard, digital record keeping standards, and so on. But what do they all say? So fundamentally, we're really talking about the requirements for proof. And if I were to summarize all the different standards and some of the basic underlying principles and theories from archival science, it would be that first of all, the requirement is that your records be reliable. And that is the relationship of the facts in the records is representations of real-world assets or things or people, whatever you will have. They should be accurate to complete. So there should be an underlying quality. There's different aspects of reliability. There's the reliability, the truthfulness of the facts. That's historical reliability. And then there's a documentary reliability, how well the representation actually represents the real-world facts. So it's nuanced, but I'm giving you the five-minute summary. Then there's authenticity. That talks about how reliant we, how much reliance we can place on establishing and preserving the identity and the integrity. So this notion of authenticity and non-reputability, also the persistent integrity of the record from the point of creation to a time thereafter. Something I'm not hearing a lot of is this concept of archival bond. It's probably something you're not familiar with. But what I do hear, at least on our table this morning, we talked a lot about not storing actual records on the blockchain, but just hashes on the blockchain and having links for the mappings. So this is what we would call an archival science, the archival bond, be specific and authenticating archival, getting archival bond. And those also have to be persistent. So one of the attack vectors or weaknesses in the system can be to actually rupture that bond, the link between the hash and the originating record. And then you also need bonds between the real-world ring that you are representing as a record and the hash representation. So it gets complex as graph theory comes into play there. And then of course persistence, which a number of you've mentioned already. So things like semantic persistence, representational, technological persistence. So some of the standards are encapsulated in these ISO standards that I mentioned, the open archival information systems framework, for example. So that's an overview of some of the requirements, risks. So the risks that I see is if we don't think about record-keeping standards, we don't make use of the principles of archival science. We risk reliability and authenticity and also long-term utility and persistence, obviously. We don't want to do that. We want to avoid that so that we can take advantage of the opportunities. So we're researching some of these problems. We're looking at in this Ninja Kari's Trust organization, it's an international research partnership that I belong to. We have a project called Trustor, where we're trying to investigate long-term preservation of trustworthiness of digital design, timestamp, and or seal digital records in various jurisdictions. That's the URL to find out more. And so basically what I'm trying to convey here is that there is an archival science that underpins record-keeping and that because blockchain is fundamentally not only a value transfer system, but a memory transfer system that record-keeping theory or archival science is highly relevant to conversations about blockchain and even some of the issues about identity and problems that we'll be discussing today. So thanks. So next up we have Kenji Saito from Blockchain Hub. Hi, I'm Kenji Saito, I'm with Blockchain Hub and we also are with Kari Westy, both their best in Japan, and where I come from, it's three in the morning. So excuse me if I fall asleep, they're in the slide to the talk. First, my background with Blockchain Hub, so thank you for letting me be part of Blockchain Web. I'm from Blockchain Hub, and it's a startup based in Tokyo that hosts the community of blockchain developers and their quotation clients and giving the series and also consultation to the industry. And my trip to this workshop is sponsored by Blockchain Hub and by mentioning that my mission is accomplished. And I can prove to you a more important topic of digital assets and the specific. And here's my understanding of blockchain technology, there are four layers of independent technology from the bottom, it's a ledger structure, distributed timestamp, consensus mechanism and application logic. And by these interworking of these layers, blockchain can give total controls of the assets to the ends. And that actually realizes the end to end philosophy of the internet, which I think is a great thing, although I've been criticizing the other aspects of blockchain, but the intention is I think great, but there is missing link. It would be nice if this blockchain can manage the digital representation of these assets by real estate. Actually, I've been working with real estate escrow service company in Japan to work on the proof of concept service of the real estate trading based on blockchain. And in order for this service to be usable, there must be some official and trustable connection between the digital asset again on the blockchain and the physical entity. So there's a missing link between the blockchain and the physical or physical entities that must be trusted. And the official, they cannot be solved by the technology alone. And also, since this is a workshop on web and the version, we cannot ignore the web technology, although I'm not really particularly fond of the internal service architecture. But in fact, the real estate trading services, I just mentioned, it's using the web technology, it's a web service. So the first thing we have to realize is that the web element on the web page is associated with the digital asset on the blockchain. If that can be done, which can be done in a technological way, then we have trusted web elements backed by blockchain, which is useful for the services trading, but also in any web page, we can now have a system of trusted management of the elements, the history and the identity. So on. And then the logical elements model, as the verbal elements, must be mapped to physical entities because of real estate and things. And that can be solved by technology alone. So it's a social technological, social technological or technological whatever you call it. And that technology can assist that. For example, by describing the physical entities. Like I think as a real estate, we can describe the real estate by these address and the size and the shape, and then we can cooperate and get the future to services like in a separate, if one real estate, real estate and the trade and separate, they still have a consistent nothing between the physical entities and the project's logical assets. And in fact, the W3C has been working on the ontology on the web. So maybe that's usable or maybe we can use boxonomy, which is a distributed and autonomous approach to achieve a similar thing or maybe a combination of the both. So the question here, one question is how we can map the digital asset and the logical entity on the web, which is a new question, we can be much welcome. And here's another question, which is an existing mechanism that connects the real world and the web as sufficient as the foundation for this. And this may be a question we can ask in this session. You guys can make. So I'm going to talk to you guys about rights system. So a system that allows us to break down and trade rights like the right to a movie or the rights to make money off a character. My son is two of the things that Disney makes and I buy all kinds of stuff. So the rights are really important in the media world, not only for the physical asset, the song, video, but also for all the type of intellectual property. So what I'm going to have, I was probably able to know as the media rights watching, but what I'm going to talk to you about is a very specific aspect that will be discovered about how to model rights and why is it important, kind of extending and maybe contradicting the point that Daniel is making further but the rights is not just a contract. You can hash and put a blockchain with identity map to it, not have to necessarily have any record about the rights of the blockchain because in a lot of cases you're trading the rights, I'm selling the rights, I'm lending the rights to you. So maybe the digital scarcity aspects of the blockchain and Bitcoin blockchain specifically is all one of our views but it can be accessible. Could be a good way to think about whether other types of digital assets or physical assets with an archival bond or linkages can be actually represented actually using the graph of spends and tokens, not just saying, hey, I have a contract, I'm going to hash it but actually trade some sort of tokens on the blockchain to reflect the reality of the ownership of those assets. So I'm going to go deep dive into this and I'm the government CTO and I'm also here because one of our OVC members and I will talk about some of the work we do on semantic aspects of this at OVC. So let me just go and quickly go through a story which is exactly, it starts here which is an artist's creative work. So you have the source file, you created this media. You have a new computer, you have it somewhere. What you get is if you get automatic copyright in some registered copyright, your jurisdiction but you get some circle C thing but that's nothing to do with a blockchain until you say, let me hash this work, hash a contract, this work, title, something that I'm claiming. I'm going to register that title in the blockchain and that creates a record of the blockchain reflecting this media you just created. But that's a lot of rights, that's just the thing itself but a lot of times what you're really thinking about is a picture of the waterfall and licenses like the stock exchange or something like that. What I'm really creating is another way which is an offer to licenses or to other people and if one of them owns this license then therefore has to use it right. So I'm creating possibly two more things whether they're tokens or their records within a document inside of there. And then what I can do when Bob comes along and say, hey, I want to buy this license. So this would be a royalty free license and with the possession of that rights I can download the source file. So you can imagine the source file because it's somewhere, decentralized or centralized. You've got a contract language to express and the token exchange of the rights and the contract itself. And then obviously payments needs to be settled. These are all the things that needs to happen for simple buying stock of edge to do it. The blockchain currently doesn't do this very well, decentralized, but if you mix together centralized, decentralized is a good chance. But it gets a little more complicated than that but if you're buying a fine arts work not only are you giving a usage right to display this work you're also giving a resell right so that when someone buys it that person retains the token to not only use it but also to retain the token to resell that. So if someone comes in the future so I pay that person for the work but if I want to resell that right based on the fact that I possess a usage right I can then go to Charlie the third person and then say I possessing a usage right allow me to transfer this title to the third person and therefore that person would get paid and that payment could actually if with models certainly with the business logic require some sort of a commission for the original owner this is related to the seventies of the artist reseller agreement when artists would gain from the rise of value of the work in secondary sale. The one that you see here on the title version one, two and three is the provenance of the work which is the record of history of ownership of that work but that is not the entire equation there's all the other rights issue associated with it and most of the money that comes beyond fine art actually becomes much more important in those other kind of secondary rights or derivative rights use. Consignment is a complicated thing because you're saying I want to give someone permission to sell this work for me and then what I'm basically selling or trading temporarily usually is a publicity right and the ability to sign a contract of agency so that that person can represent me legally and also provably legally in a verifiable way and then that person in this case Delta gallery or gallerist can now resell this work and then when that work is sold the rights the usage right and resell right does not pass through that agency but go directly to the end buyer in this case Charles and then when that happens the payment is split in fine arts unfortunately is 50-50. So as you can see as this stuff gets more complicated where there's a commission of work there's a whole lot of relationship and intersection here of usage right use of receivorship right. One of the most interesting thing about receivorship right is that you can now let's say I sold some work, commission of work I can actually trade the receivorship right which is a royalty like a bouillon the revenue received from this work being commercially useful and I can sell that independently of the title of the work. So I can own the work but not own the revenue that come from it because I've mortgaged it or sold it to another party. That allows financial services to participate in the rights equation which they already do but by providing these primitives and thinking about how this maps to the rights expression we can allow this kind of ongoing payment to go to the right place and allow that to actually happen there. So I'm gonna just jump to the conclusion. The conclusion is that this is a complex field where just on the constellation of rights and we see the contract documents and clauses which are the tradable tokens of having rights to do certain things. The media themselves and then the payments associated with it is an extremely complex thing if we were to actually model what actually goes on today in films and movies and TV shows that have a constellation of rights across multiple worlds. And I think getting this right requires a standardization effort. Semantically Monograph has supported and participated in the W3C permissions of obligation expression working group which is really thinking about the contracts, language and the way to express what is actually being traded. And but as far as the mechanism of what rights are actually on chain, what are hashed on chain, can we use other blockchain provision ledger which between industry trade groups, those are all the things that I think is gonna be a very important discussion going forward. Thank you, Chris. Next up we have Dennis Nazaroff from Media Chain. Our days and what's been really so many people's context and history about, you know, we see this daily on platforms like Twitter. The problem today is that when someone that calls us to count Chris is like that gratitude goes to approaching this from an information problem rather than scarcity or things. One is taking a decentralized database and so a decentralized database allows anyone to participate. There's no central point of control or fails a single logical database. On the other side is content ID. So content ID allows us if we have two instances of the same work. On the top you see the Mona Lisa that's slightly greener in the JPEG format and on top is that they represent the same work. What this allows us to do is one, to collaboratively participants are making a statement about the same concept. For example, MoMA says that this painting is by Pablo Picasso while the Tate says the title is puro. We can use content ID technology to unite these two statements under one content ID allows us to search with the global reverse image search before. How much does AMP identify? So with content ID, to read and pick an example of that anonymous image in the media chain system you can use the instance of the image yourself as a way to prove the system as a statement that participants use. So here you see that the title signed by MoMA and metadata in the system is derived from existing metadata that already exists. We're saying that let's not invent a way to translate certain fields to the system so you can index by a property such as the artist. And each statement is a cryptographically signed with the participants. These statements about a work are tied together in a chain. So here is a statement by Tate of the top, a statement by MoMA. If there is a bad statement, so in this example, Donald Trump has contributed something. Openness of the system allows the data is in the system. And some of that implications is our attribution and analytics. So creators can work in use more across the internet. And also we can surface metadata conflict. So today, data that is in silos that don't speak to each other or aren't aware of each other. So in one logical space, we can see which institutions have. So we can search across datasets. Hi guys, I'm Trent. And this is actually on behalf of the Kuala IP worker for IP that is working here in this company. I'm from Big KDB, which is a former company. As well as IPDB, which is a non-profit that has a public blockchain database. So a bit of background. I started working full-time in the blockchain space about three years ago at Dubake and Scribe, which was focusing on digital art in the blockchain. And there was a whole bunch of self-problems to solve back then. And as we generalized from Scribe, which was just starting with digital art, as we generalized, we asked ourselves, how else do we serve other types of IP? And as we tried more and more things, we realized that it's really useful to have a general license and framework. Some of the specs include, it should be really easy to use by all the different participants, whether they're developers, rate holders, copyright societies. It should be extensible, future-proof. It should have immutability and time-persistence. So a couple of nice characteristics of blockchains. It really should be agnostic of blockchains. And it should be free as in, it's our software for everyone to use. So that's the goals of this framework. History of Koala, it actually started with a workshop at MIT slash Harvard a couple of years ago, it's been happening. And these workshops happened three or four times a year. And starting last fall, there was a working group for IP that emerged from it. And some of the collaborators in this, including Koala itself, KPS, Ujo, Census, Mycelia, ourselves, Scenario, Media Chain, and more. And relations with copyright hub, both music and more. So, and you know, these individuals alone just represent people that are working building on top of the Ethereum network, KPS, IPV, and more. And when we were doing this, one of the major goals we had is simply to invent as little as possible and to reuse whatever well-considered building blocks are already open. So, there's one building block that is maybe the centerpiece of this, and that's simply called the LCC framework. And it is the culmination of a lot of work. If you've ever used SoundCloud or YouTube or listened to a song in years of music or anything, all of those are following a standard from the music space called P-Deck. It goes back a long time. If you're using getting images or any other standards for photos, it comes down to a standard called Plus. It turns out that the people who developed Plus and some others, collaborators, they got together with many important organizations and they developed something that generalizes all of this and it's called LCC, the Link to Funding Coalition. And an organization called Copyright Hub basically drove this over the last several years. So that's what LCC is, I'll talk to a bit more about it. Also, there's other standards out there that have been, that are valuable as building blocks. One of them is Link to Data itself. And in particular, the Link to Data format out of JSON, one of them is JSON-LD. There's also something called IPLD, which is very, very useful for integrity. Maybe one I'll talk about a little later at IPFS. And finally, intellectual protocol, which allows these data blocks actually to live on many ledgers at once and to transfer from one to the next to the next. So I'll talk a bit about these different building blocks in the next few slides. So LCC in general, like I mentioned, it generalizes why they use IP standards and putting indexes in more. It has a bunch of different documentation. So if you're ever going to be developing standards or write standards, this is a really good starting point. Principles, and the real meat is the entity model and the rights reference model. And to give you a feel of what this looks like, this is the rights reference model that has seven entities within it. And these are entities like party, creation, place, and so on, and how they relate to each other and how they do its edges. So this is something that's extremely well-defined and a lot of documentation, actually too much documentation, but it's out there, and it's been well thought out. IPLD is basically a way to take a decent object and it's limited in what are your passions even from one object to the next to the next. And then you can also path to do this. And these objects, they are native IPFS, but they can also live in other networks, blockchains, et cetera. So this is actually standard in IPDP as well, for example. I'll just skip this slide. Of course, there's RDF, we all know about this, so I can probably see what that's like too. DSNLV is one way to serialize RDF and JSON, it's emerged as probably the most popular standard for linked data in JSON. And there's also, if you look around, you might ask, okay, well, if you're using linked data, what exact definitions of data are you going to use? And schema.org is one that has emerged as a big one, and it's used by Google and Facebook and many others. And there's been tons of work to define this very, very refined. So there's actually very good definitions for a person, an organization, creative work, use a composition, a book, a movie, and more. And so we don't have to go and reinvent this wheel, either, we just re-learn that. For connecting different blockchains and ledgers, there's something called the ledger protocol, which is actually W3C Community Group, and there's more than a hundred organizations that are participating in this. It was initially released last fall. And so it's really good for connecting blockchains and sort of thinking of it as like routers. It also has something called crypto-connections, which is really nice, a building box for crypto-primitives, so you get things like multi-save and escrow. But it doesn't go as far as loops or recursion. So it's a very useful tool for basically connecting these chains when you want to transfer value from one network to the next. So overall, what the Koala IP protocol is about is bringing all these things together. So it's got this minimum viable set of data for IP licensing. And that's basically these RDF schema definitions using JSON-LD, as well as a free and open messaging protocol for license transactions. So LCC is really the part of this. And then also, we can leverage it. So with this, basically what we've done is taken this and come up with very specific examples for these sorts of things. So here's an example of a place. And notice on the top where it says type, it's got a hash from your RDF schema place. And this is a hash using the IP of the expander. And then the geolocation, the name, et cetera. So that's a place in the Koala IP spec. You can also have a party. And of course, this relates to identity. You can have a creation. So this is actually an RDF schema for creation. And you can have creation in a couple ways, a digital or a physical manifestation. And manifestation itself is something that is defined, but while it's in the org. Here's the physical. You can also have rights. So this is something that has been defined as well. And rights assignments. And rights assignments is actually kind of special because it needs to be transferred from identity A to identity B. And this is where intellectual protocol comes in very handy. So it basically, what you do is you follow the intellectual protocol. And from that, you get provenance to be as much as it works. And it appears to be these different rights that you assign. And then you can also do things like escrow, which is kind of cool, if you can pull it off. It also supports the idea of insertion. So a person A can say, hey, this person's name here, okay. This person's here claimed as no, that's an incorrect name, or yes, that is a correct name. So to wrap up, to summarize, the goal here was a license framework for digital assets using the previous building blocks as much as possible. And so this protocol is a data set for audio licensing as well as interchanged messaging protocol around it. And there is a community that's coalescing around this and it's going into these different networks already and you should be able to get involved. And of course, one of the purposes that this company can tell well with a lot of work that they've seen. So that's the WALL-IV protocol, thank you. Thank you Trent. So we're gonna change up the format a tiny amount. So you just heard five talks, so that will be roughly five tables. And we'd like to gather, would anyone else like to need a table? We're gonna have people volunteer to leave tables and we're gonna take a five minute break and kind of figure stuff out. And then when we come back, we'll do the actual tables. So would anyone else like to volunteer to leave a table in this space? Sure, so the five of you just went, if you wouldn't mind sort of saying your three word summaries as we kind of get things together. And also the board tables probably better. Smaller groups discuss things probably better. So it would be good for you to suggest a comment. So who was it? Could it be applied to the blockchain and also interested in the issue that came up? So I'll be talking, I think my group of both, and I think probably just to differentiate that you'll probably focus on this because it's a great assignment. And with Dennis, I'm just gonna put words that you want to speak to this. The QOLIP protocol is actually quite general enough. And as I said, you can have very detailed break assignment as well as you get, as I said, there's attribution and you just read on attribution. Rich metadata. And so just watch that. So I'll talk about the higher level sort of value transfer aspect and sort of the IP protocol for the QOLIP system. I wanna talk about use cases, just media rights use cases, getting onto today and all this kind of stuff. So if you wanna talk kind of not about the protocol and stuff like that, just like what are the ways that blockchain and blockchain are going to get onto today? Aspects. So basically linking, link this with physical entities. Anybody else? Five tables. It's gonna be pretty big. Anybody else? I think one suggestion, a lot of us covered intellectual property, but that's really only one aspect of provenance. I guess you're going to talk about linking to physical. But there's a whole bunch of other really interesting sub topics in physical. So I might encourage you maybe to talk about that. You know, like diamonds in the blockchain and used running trees in the blockchain, that sort of thing. So that's one idea. There's also a potential for internet of things kind of related types of stuff. Guri? Yeah, I'm looking at you, Guri. Would you like to lead a table? Why don't you lead a table, Guri? So I'll stand in for Guri. Now come on, come on. So you are going to be talking about IoT. So basically it's around using blockchain with IoT and then application. There's some work that needs to be done. So... I think we have one more volunteer. This is a problem that I'm looking at in the case of the supply chain movement or really the trade finance of goods movement. Does that fall under the call IP or do you take that in call IP? Is it meaning, could it be mean because these guys had such a broad topic? Could it be meaningful to have two different topic tables? I'm hearing yes. I want to propose that I would like to be a part of that. So even if you don't want to lead a discussion but you have a question that you feel in Providence hasn't been addressed by these things, if you have a question, that's also good because that might be a topic table. I'd like maybe a quick hand poll on things. So there's a legal... So some of this relies on proof of existence. It's kind of an underlying primitive that is required for these types of things. And I know that Wayne and Manu are working on some of that type of stuff. But there's the legal side of the question. So maybe Gaza, wherever you are. Are there other people that are interested in sort of things like New Hampshire just made a law that allowed records that are put on the blockchain through proof of existence type things are now legally records in that one state. So you don't have to go through extra stuff in court to basically say your thing was there. So is there an interest in the intersection of proof of existence and law? And Daza, are you? Not necessarily to be the table. So I might need to step out and do some more. But one question is of ownership of data on the web. So like really actually W3C stuff on web browser and what happens when we go online and we have all of our identity and our own data that we share with the web and how the blockchain to support the tracking, how we share data online. And then finally, if an open system allows anyone to make a statement, and finally if none of this interests you, it just isn't a topic you're not interested in the Providence aspect, but you have something else that you think other people might be interested in. You have space, anybody? Okay, so we're gonna be able to divide up into these groups. Okay, we're gonna take a very quick five minute break and then come back and divide up into groups. One of these that you- Everyone, so real quick, we're gonna start with these tables, okay? So I'll go over it really fast. So right here we have physical assets in the real world and bonding. Okay, here we have media, like real media use cases, music in particular. I forgot what yours is. IP protocols over here. Attribution and metadata that are not payment related. Supply chain, law. And then I don't know where Guru went, but he is doing internet of things. So did everyone get that? Follow the person that you're interested in. And we're gonna do this for half an hour. The first 20 minutes are gonna be discussion. The last 10 minutes will be kind of reviewing in your small groups, and then we'll come back and share. We're gonna spend about 20 minutes, was it? About 20 minutes, talk about the topics. 10 minutes, sure we have the summaries. And then we're gonna spend another 20 minutes summarizing everything. So 20 minutes, 10 minutes to wrap up, and then 20 minutes to discuss, okay? Everybody should find a facilitator, somebody who has one of these. If you don't have one of these, combine me and ascribe. That's gonna ascribe back, that's gonna report back. Somebody is missing a lightning to USB adapter. If you picked up a lightning to USB adapter, probably somewhere in that area, please check that you got the right one. And if I cut somebody else's, thank you.