Self-sovereign BigchainDB data injection in smart contracts through the Jolocom Identity Gateway

okay so let's jump right in hi everyone my name is Dimitri from bikini there's a junior from Jolla calm myself I'm working on bikini B interplanetary database also something called ocean protocol and in the legend and all of this combines into something we call a decentralized application stack we are trying to create an interoperability space where data is smart contracts and logic all unite and this is one of the examples for that we'll show today it's called a decentralized data gateway for etherium what it is should be clear cool so we're in a space that becomes a bit scary this is from 2005 when many companies started to realize like data becomes a new oil AI just doesn't need better models it just needs more data it's very data hungry a lot of data you got your mode you can play around you can create better models more accuracy more money I think we all are aware of that that takes a lot of scary future perspectives with it so we're in a situation where our delays in somebody else silos we don't really own and control it we don't really see what's happening but it's actually sublet about us about our personal private life and other people play around with it and that makes me a bit sad so this is how did typically do it we're very happy we get a little honeypot called applications we run on that data gets stored somewhere and gets up so now what you'll see is your versions of yourself out there you don't really know where they are how they rippled through in Europe there is something like the right to be forgotten very difficult to implement if you don't know where your data is you cannot really turn up the switch and of course of all this revenue that's happening downstream you don't really see much you only see the ads coming up so one of these ideas that that's been very well explored in this space is data sovereignty own control your own data for that you need an ownership layer blockchain is applicable to that that's what we've been doing with Puccini before a while now it's creating something like decentralized data where you own and control your data you cetera right so on your claims access control all of that so this gives us a land of self sovereignty where everybody's happy your unicorns can play around but more importantly you know where your data is and you can revoke access or grant access and you have provenance you can see what's happening with your data so how we feel it should be is that you should bring your data to the service and that service should ask you to consume your data and should be able to revoke access one either so we distinguish in this prototype we've built together with choler comm we distinguish two types of data the private data personal chain stored in local storage but also as well public claims on a decentralized public net like IP DB the interplanetary database and that's basically a database with where it's a no sequel store with decentralized control there's no single admin it's currently is it's in a federated setting where you have caretakers for future decentralization of the internet like Internet Archive and monastery I think there's like 17 of those and they host a big data or it looks and feels like a database which actually decentralized what you can put put on there is any kind of public verifiable claims or maybe standards like the decent rice identity Foundation is proposing this is the public that you know what your focus is mostly on is a private data and now you can create an access control mechanism using a gateway and claims on top of the database the benefits are quite clear the fact is that you know where your data is that you can revoke access you can grant access and if you need it you can share in revenue on upstream or downstream services so what we've built for for our DEF CON meetup here is an interface that looks like this we have Joe locum a Joe locum gateway which manages the resource access and Virginia will talk much more about that further about two parts not only the private data think you port and such but also about public claims that you can retrieve from either be Chaney bees form etc for this we focused mostly on the apps imagine you see a smart contract and it's kind of like Hoshi and and not always UI friendly but augmenting it with the data that you can fetch through this gateway gives you an enrichment of the data layer what does it contain maybe some private personal data after yourself that you inject into the smart contract but also a description and what you can grab from the public claim just maybe not it is this kami is not as people been testing it was a current version so applying this to two smart contracts gives you a bit more contextual information in a separate project you're working on something called ocean that allows a data exchange between silos but that's something that's a different project I think Jeannie's up to you now hello so can you hear me nope yeah okay there we go so you have to give a little bit of context and paint a bigger picture I'd briefly generally describe what we build a yellow form the identity gateway so generally speaking it's a personal server it's intended to be modular and lean and it stores and curates access to your personal information to user data and more particularly basically we're talking about attributes attributes are effectively things about you your name second name phone number email address mostly things you need to interact with online services perhaps also things you need for some kyc scenarios we also store verifications so verifications in the classical sense signed messages by external parties that this is indeed his email address so for example if you sign in with Airbnb they check your email address they might give you a verification you store it next time you sign up with another service maybe you don't have to go through the whole process again there's a lot of effort going on verifications now so there's the w3c working group I've done focused I represented a lot about it on Monday I think also on the first day of Def Con so this is definitely a very exciting field the Gateway also does access rights management so it basically has an internal database of what entities are allowed to view what attribute and those can be retrieved those can be revoked as well so in case some service wants to get access to your email address you'll have to go through your gateway and if your gateway has the appropriate permissions then it might grant the access and it also has identity stores so we envision a scenario where more people will share one gateway so we allow multiple users to register on one gateway up to for example 10 you can register perhaps if you have an invitation invitation code from the person who set up the gateway so the use case for this would be mostly a bunch of friends just using one gateway together because they trust each other and in order to be a little bit more resource efficient save some money so this is kind of in broad strokes what we're building at the moment a lot of these things are stored inside the gateway so locally there's an abstraction layer on top of the storage so that some of those things could be swapped from internal local databases to perhaps some of these solutions obviously when it makes sense so attributes which might need to be private might need to be public might need be easily so the access rights might need to be easily configurable maybe not all of this storage solution makes sense because it's quite difficult for example application data which can be large and some of it perhaps even public might be stored in one of these things so it's so the general idea behind the collaboration we have is we want to create a layer of metadata related to a theorem smart contracts and store that metadata on the big change B so the idea behind this is that when you interact with a smart contract you might be able to retrieve some of that metadata from big change it B in order to enhance the user experience or perhaps to provide for a safer interaction we have a short brainstorming session about what kind of metadata we would like to store so this is a very this is an initial design things will probably change and become more robust as time goes on but the claims that we decided would make sense to store on big change it'd be the first one would be the ownership claim so this is a claim posted by the person who deployed the contract so this claim contains for example his aetherium key big change a big key yellow comb identity all of them assigned with the corresponding private keys and it might also contain a field for example his email address in case you want to contact him or his home address in case he's very brave and when you interact with this smart concert later point in time you can retrieve this claim see that ok this is the person that deployed the contract and these are his alternative identities and this is a way to reach him out besides that we also have functionality claims so this is fairly straightforward the functionality claim is simply it's simply a claim that provides a user friendly name for the contract I use a friendly description so for example this contract does this and that and the list of the methods that the contract has an also a nice description of those methods so at a later point in time when you interact with the smart contract it can be retrieved parsed and then displayed to the user in a nice way we have reviews and endorsements at the moment these are fairly basic so these are external parties basically saying I've interacted with this contract and it's ok so it's kind of like an upvote or a fan Bob this could be a lot more complex and robust and I'll mention this if we have time at a later slide and the last ones are security audits which are fairly tricky to do actually these are either external entities normal people corporations basically performing security audit on a smartphone and signing the statement of this contract is secure there's a lot of things to be taken into consideration so you can't just say that the contract is secure the state of the contract might matter if it proxies calls to our contracts that might be relevant so overall this is a little bit more of an involved case so if the demo gods are with me I might show a quick example of an interaction let me see so I created this mock web site it's a little beefy room I hope the name isn't taken and I'm not gonna get sued or something but the general idea is it's it's a web site that allows you to place bets on outcomes of games so we can log in first and when we log in we get to log in with our yellow comb identity so the things that the service requires from me at the moment is my email address and also my kiram address so this is very straightforward um's gonna go over it if I click accept I hopefully get redirected back to the website but now I'm logged in now okay there we go and this allows me to place a bet on a chess game that happened in September this year so I'll place a bet on 11 because I googled the results and I know he won so if I place the bet any film transaction is triggered so this is an API call to the identity gateway which then renders this consent screen to the user and at this point in time we fetch metadata from big chain DB so with such things like a human readable name and description of the smart contract I don't know if you can read it but it says a fair betting contract on top of the aphelion blockchain we pull a small a small description of the function that we're about trigger which is it allows users to bet on the outcomes of sports games and then we also have a verified owner of the smart contract so this is just the identity I used to deploy this local test contract so normally would look probably different and we also have reviews which I mentioned are basically the farms are basically people that use it and says ok this this works as I want it to work so if I confirm no risk no fun I get redirected back to the service provider where so this runs on tester PC locally this is why things are so snappy get redirected back to TAS therapy see we're kind of the whole interaction is complete so we've retrieved the data from big chain DB to provide a better user experience and also a more secure user experience in a way so the users can be a little bit more sure about what contract they're interacting with so this was a fairly weak demo and there's a lot of things that still need to be done overall next steps were represented nows and kind of MVP Bruce of concept the the next steps of course we need further and better DP new definition of the claims so perhaps the the reviewed claims which I which I mentioned we're just kind of thumbs up people signing a message that I've interacted to this contract and it's fine perhaps we could have a message there a comment you could leave perhaps a I've interacted with this particular function of the smart contract because maybe you don't interact with everything so that could be improved we could have we could have historical or version records of claims a big change EB allows you to step back through time and see how particular assets or metadata evolve through time so perhaps we can say that the current security audit for the contract says there is a secure contract you maybe go back to the revision history at one point in time was not secure you can maybe see how long did it take for it to be fixed how often was it insecure how often is it audited so having this kind of ability to go back in time and check the reputation of the contract fault history could be important for for end users of course we would like to have support for more complex smart contracts so this also basically includes contracts that that use libraries or rely on other smart contracts proxy requests to have a smart contract so for example if we audit one smart counter at a given point in time who said the smart contract insecure but then it proxies the request to another smart contract and has a function which allows to swap that one it could be that at a point in time that contract is no longer secure or it's malicious or has undefined behavior so this is another thing we want to focus on and the last thing we want to focus on is perhaps standards and community input so it would be nice that we don't build our own silo solution and time thank you very much for your attention [Music]