DappCon23: Introducing The idOS - The Self-Sovereign Identity Layer Of Web3 - Julio Santos

Transcript

hi everyone good morning um it's very good to be here um my name is Julio I'm a CTO and co-founder at fractal ID and uh We've helped hundreds of uh companies and projects in the blockchain space over the past five plus years um work on identity verification and I I was here on dcon last year talking about um what that meant for us how we saw our product uh I talked about uh the importance of not being an identity maximalist and of delivering identity solutions that folks using web 3 today need and um I talked at the time about the the spectrum of

products that fractal ID offers but I'm I'm here today to talk to you about like the next level of that um and that's the idos it's the identity operating system and it is born out of a very pragmatic approach to how folks in this industry like to use identity because this industry is unlike any other as you know we've got a very particular ethos we've got a very particular Tech stack and we've got a very particular type of user and uh identity verification is something that is extremely messy identity itself is something that is extremely messy and to do it well well you're very often working with regular

at compliance which is also extremely messy and you're very often working with supporting users which is also extremely messy and so even though we've seen a number of solutions emerge over the years we've always seen folks stay away from the actual hard work of identity verification so we we've built a lot of um technically impressive deserts that uh don't really meets the needs of the market as it is today and so the idos is born out of that Insight that we have the experience that we've built but it is not just built by us so I'm I'm very excited about this still this is still being built we're launching it in November and um it was hard for me to

fit slides into 20 minutes because there's some muchat so many trade-offs that go into building this thing and I really like to talk about them all but well we can't so um instead what I'm going to do is I'm going to give you a brief introduction of what what this is and why we're building it and I'll show you a few of the technical details about how it works uh under the hood so um the idos is uh a chain agnostic protocol for self- Sovereign data management and we will see what that means in practice but the tldr is your keys your data and uh the chain agnostic part is critical because well I mean web 3 isn't just ethereum or just noses or just salana

right and folks used UPS wherever they are they're not going to know where they are soon enough anyway and so we need a solution that works for everyone everywhere and that's why we have such a an odd collection of building partners for this that we're looking to expand in the in the short term if you're building an identity do please reach out and that is because like even though we've been doing this for a while we can't do this alone this is something that we're trying to build as a common good for all of the space and we need good partners with good use cases and good perspective and alignment with us on identity to push this forward and so um quill is a strong technical partner that we have

that uh built the underlying data storage that I'm going to show you in a little bit um near has a very very keen focus on adoption and user on boarding that we can relate to very very much they're very pragmatic in that sense as well they're integrating the idos into their blockchain operating system for the new.org Gateway we're working with gnosis as you've heard many times and you'll keep hearing gnosis pay allows you to have a self custodial visit debit card which is a highly regulated use case for which the OS is also very well suited we're working with Alf zero who is a very strong privacy team who are building a compliant version of tornado cache identity underpins all of these cases

and so we're helping everybody build this together um hm all right there we go so um I mean if you're in this talk you probably know a little bit about like why decentralized identity hasn't been done right yet and um why do we need it in the first place and the fact is that most of our interactions have already moved online over the past couple of decades what's getting increasingly harder what is new is how easy it is to confuse you with a bot with an impersonator this erods trust and that trust is required for I don't know what's going on here but uh that trust is required for human

interaction and for us to be able to coordinate and Thrive and coordination is one of the core tenants of blockchain Technology anyway and so ignoring identity as a core part in that is something that well um I don't agree with and it's also very important that what we build here just like everything that fractal has been built so far before is not something to show off a piece of tick and it is a product that is used for actual people in the space with a with an actual user base now why are we doing this personally fractal fractal is a what in the decentralized identity context you would call an issuer or in a tester we do identity verification and the reason that we're

well there's many reasons why we are doing this um but uh one of my uh personally one of my favorite ones is that I have to secure a database with over a million passwords and first of all I shouldn't have access to this database this data shouldn't live with me and second of all this is gigantic Honeypot that we need to serve our customers and I don't want to have it and so the idos decentralizes the storage of this data and removes control from us and we're going to see how that works in a little bit but this shows this shows an approximation of how fractal would work today we've got user accounts we collect their data verify their identity and then folks that consume this have different options to integrate with us whether or not they

need the underlying data um but this has a number of problems uh um and well we'll see that in a second so what we're doing next is we're first launching the OS in parallel to our current system so that we can still later this year get rid of it so this destroys the Honeypot that now we have to secure and everybody else has to trust and what's also cool about this is is that there's we have no special privileges as fractal again we're a partner in building this and any other aester say a credit score an identity verification company whatever it might be they can also use the OS with

no any requirements that we wouldn't have um so this is a Level Playing Field for everybody and we think that competition is going to be very healthy here but the coolest part is that everything that we've built so far always relies on us being around and doing a good job for ever but what the idos does is allows fractal to disappear if we build an ecosystem where other people contribute data and information and insights then we've built a common good that doesn't require us to be around or folks to believe that we're going to be around now this is great for users because your keys your data um you are the only person in control of the data

that is in your profile and and you can edit it add to it delete it and you decide who you share it with you do this without needing special tooling like identity wallets to carry your data around and requiring you to be present for every interaction you don't need soulbound tokens to dock you on chain you need the idos and it's got a much better UI anyway um the for daps this is good because they get a guarantee that they haven't been able to get a to get before which is their user data is stored in a compliant way and it is stored in a way that allows for retrieval once the user is no longer in your D and we're going

to see how that works in a little bit but something that we're really trying to make sure happens is that folks copy as little data as possible and so if you need some information about a user or might need get access to that data rather than the actual data because this will well discourage duplication and um again we're not the only ones playing here so this is not a closed system this is a public good now the idos is a uh as I said before it's a network of um decentralized storage nodes and an access control protocol and for you to be able to pull data from the idos or read data write data whatever it

is you need a signature and you can only read that you're the only one that can read data that's associated with your wallet and you're the only one that can write any data against the profile that is associated with your wallet once you have an idos profile you can rotate that wallet you can add 10 more you are the signer you are the only party that can get access to this and through say the data dashboard that we're building through any dap integration that is building on us and in general just using our SDK it's very very easy to control the data that you've got stored against you and and to be able to well help other people get access to it access grants are a core

part of the system where somebody can tell you you can access this data tomorrow and you don't need a signature from me to do it again you authenticate with the idos with the signature and I can pull my data or I can let you pull my data tomorrow with your signature instead you don't require me to be online don't duplicate if you don't have to these access grants can optionally be configured with a time lock this is something that I can tell you hey you can have access to data ID for T2 that belongs to me or you can have access to that for a whole year and what that does is it prevents me from deleting the

underlying data or deleting this access Grant this is particularly relevant for uh some AML kyc compliance use cases that I'm very familiar with where many jurisdictions require that you still have access to the underlying data for 5 years again this entirely dependent on user consent they don't have to give you the access Grant this is an option to bring the system into compliance right now for daps they can also think about this about it's not just identity verification it can be a whole backend for their data uh data privacy regulations and how you are supposed to store data that belongs to your users and the rights that you need to give them I mean they're not particularly

complicated to implement to be honest just don't be an do the right thing put them in control and it's going to be fine but this is a Minefield and if you don't need to maintain your own backend if you don't need to maintain your own database because the data lives with the user on their idos it's well one less concern that you have and it really helps them with things like data portability and the data in the idos is stored um well most of it in the form of verifiable credentials so so this is a it's an interoperable dou 3C standard that a lot of decentralized identity tooling knows how to consume and to operate with and our tooling helps data be written in this form to facilitate

portability and interoperability wherever we can now let's look in detail uh about a couple of things of how this works internally so uh decentralized storage is uh not done with uh ipfs or ceramic or any solution that you might know because while uh those are great as well we wanted to go with something that more resembled the relational database which is something that is a lot closer to the normal data workflows that we are used to using and developers are used to using and so this system acts instead of it being a file store it acts as a relational database driven by SQL as you will uh know and this this gives us some

interesting affordances um so what does this database look like this is an earlier iteration but you should get the idea across uh you having an idos profile means that you've got an entry in that humans table up there and everything that is associated with your profile attributes wallets and credentials have a human ID because this is a relational database so the way we know if an attribute belongs to you if you can read it if you can modify it or how you can add a new one is by looking at wallets at signers that are related to the corresponding human and that's how we determine ownership of own data now because there's also data grants

grantees are also um sorry about that grantees are also like uh subject to access control here obviously and so when you ask the idos for your data it checks do you own this data because you've signed it correctly and it's associated with your wallet grantee Works a little bit differently um so the idos uh just in terms of internals a little bit uh this is not Coda you would have to write um this is how we Define the read and write operations that the idos exposes for example through our SDK and um when you whenever you talk to it uh your publicly key and then address or extracted recovered from your signature

so there's this add caller variable that you can then use in later queries as we're going to see so say for example that you're trying to get somebody's credentials of a certain type for example kyc and of a certain issue where for example fractal this is a very very standard query to get that information except we are joining it with the wallet's table so that we can match that the caller the signer of the message that was just received by the idosos indeed has access to the data that they're trying to get now access grants have this they're from a data owner to a grantee for a certain piece of data and they include this optional time lock and

this changes the logic of how what the idos does in the background a little bit so to give you an example like this is a simple interface and solidity for we've got several of these contracts because we we we need them deployed on the networks that people use for the wallets that they are that they have installed um and this is relatively trivial in terms of functionality so you can only insert a grant for data that you own so you have to be the grantee here obviously you can only delete a grant for data that you own as well that is yours for a grant that you created is something that only you can delete and inside the idos note instead of seeing hey who's signing this message trying to

get this data and matching internally in the relational structure what we do is we check these contracts to see if there's still an active access grant that would give this new wallet access to this data and time LA are time locks are enforced in the contracts and in the idos nodes by not letting you delete grants or data that are associated with something that you promised somebody would last until say next year now the idos itself the storage system

doesn't really care what you store in there and so if you're storing personal information or anything that is sensitive then you need to make sure to encrypt it our tooling does that all by default so all of the data that is stored in the idos in this database anything that is sensitive is something that not even node operators of folks running these databases should be able to access and so the keys for decryption and encryption they're generated private in userland we've got an enclave in our SDK that makes sure that data dashboards and daps and anybody else integrating it can't get access to it and that is how the user is able to do cryptographic operations on the data so we take a password or a SE phrase from them and we

use a uh key derivation function in order to extract a key pair on a d255 19 to perform the encryption operations over this data so that well wallets don't really offer encryption interfaces that are very consistent these days and so this way we make sure that the user is in control of the password that they have and again this is done via the SDK that we have which doesn't have to right you want to use the terminal you want to have your keys under your full control inside your air gap machine you do that um kind of skip ahead of this this is just more detail on the same um well uh an interesting Coral are

of this is that when you're storing data in the idos uh you need to be very careful not to encrypt things that you shouldn't so if you're authenticated and authorized with your wallet address if you create a new wallet and write it against your profile if you encrypt that address the database engine is going to have no idea how to match it so there's guidelines about what should be and shouldn't be encrypted Something That We're struggling with at the moment and that I would love some put if anybody has any ideas is how to prove that when I take a piece of data that was requested of me and I re-encrypted with your key to create an access Grant to prove that I actually re-encrypted the right thing

we've got a few mechanisms around to kind of mitigate this issue when we were thinking of others um and of course data can always be shared directly but this is something that is not one of our core skills so if anybody has any ideas I would love to hear them how can you build with this well user SDK this is very very trivial we abstract a lot of the idos operations from you you're essentially just going after reading and writing data and R SDK will make sure that uh it is prepared for encryption with the user it gets their password if it doesn't remember it and it does all of those operations in the background so you take a signer uh like metamask for example you initialize

the idos with that and then you can perform straightforward operations like current user like who is here right now what's their idos profile how do you get credentials from them for you this is one line there's a lot happening in the background the user will often have to sign a message Pro to the idos that they can get this data it will need to be decrypted with the key drive from the user's password the SDK deals with all of that all you need to do is ask for credentials you can create access grants based on objects that you have seen with the SDK or otherwise and you can later get access to it very much like you would get access to a piece of user data except it's you signing instead how do you verify these

credentials well they're verifiable credentials for a reason and R SDK helps you do that and I am out of time I was going to tell you about a couple of things that you could do with this um but I think that the examples are enough and uh I will respect the clock so thank you all very much and if you folks have any questions I'd really really love to take them awesome thank you very much um because of time we'll just take two questions I can see the gentleman over there and there's a gentleman in front here uh thanks for the talk uh you mentioned there is this Enclave in the SDK that you like to generate this key what could be a tack Vector on this Enclave uh the

browser for one so if you don't trust your browser your browser could be leaking uh they could be not implementing the d3c recommendation on iframe sandboxing for example and that could eventually lead to the DAP there's uh there's other ways that we've thought of um dealing with the user password and the key uh we didn't want to build an extension to deal with that it's something that we will because there's going to be a subset of users I'll prefer that additional layer of security but uh so far we haven't been able to break the iframe sandbox in any way it's something that's been around for over a decade now standardized and so it's something that adap will not be able to get access to um um because of the Cross origin policy yeah thank you and also is

there any computation layer or you're leveraging something like te or computer data or similar things not yet no that's something that's the kind of service that we would love being uh to see being built on top of this so the credentials that we generate some of them have selective disclosure capabilities so you can you know disclose only a subset of the credential and maintain the proof zero knowledge proofs on top of that would be a really interesting mechanism to create derived proofs from them but on a level above being able to use aggregate data to reach conclusions without actually inspect the underlying data is something that other folks have built already uh and is something that I think is going to definitely be a very

common use case of this it's a bit of a Next Level Target for us and we will likely work with Partners towards um making sure that that happens thank you thank you good morning thank you very much um I uh understand the point that obviously you have a a database underlying um way store the credentials and and all the um uh yeah revent relevant traffic you also said you have fire storage um no you don't have fire storage no so that was a the decentralized database as opposed to traditional uh decentralized uh storage which is filed based so this is a

relational database something similar to sq light U and with a consensus protocol to make sure that all of the database nodes reach consensus on data modification okay right so that makes it clear because I thought if you have data storage that would be kind of defy the purpose because you want to offer your service to all data storage okay thank you all right thank you everyone uh please let's put for jolio Santos again thank you thank you folks