identity space to to imagine a world where there is no federated identity. Yeah I mean there's cognitive dissonance when you were when you were coming from a horse and carriage world to automobiles and from you know various other transformations that took place that so maybe you know the point I think is going to be how easy is it for ordinary people to use? Yeah well I think blockchain in the sense that people have had to manage keys to be able to use blockchains i.e wallets that's their key management mechanism and we have you know practical levels of security in mobile devices now and there are quite a few ways to manage those so that you use your device as your mechanism for authenticating to access your private keys so we have some practical solutions that may not be universally applicable but they certainly apply to a large segment of the population and increasingly that technology is becoming more pervasive so I'm optimistic. So the question is if you say key management is what you have to do then you start to find solutions if you say oh we don't want to do key management it's too hard then you never find solutions so FIDO2 you know says passwordless we want passwordless we want web authentic we want not want to have passwords that means managing keys so so so you're well on the path to to finding solutions as soon as you you know say we're going to we're going to manage we're going to expect users to manage private keys and we're going to provide technology to make it easy for them to do it in a secure way then then adoption goes up if you say well we'll never expect users to manage private keys so we always have to have federation then then then you never develop new solutions. Well we have a couple of more people although not up to our usual standard but it is also it's also going to be made available through recording okay so it is not a complete waste of time for you to present even to this slender audience but I'm sure that people here are you know are adherents or at least curious about this so that is a very good thing and should I get started yeah let me spend oh two minutes here because there are some administrative things that I have to take care of one is that we are as we all know a part of the hyper ledger hyper ledger foundation and hyper ledger is part of part of the linux foundation and we have two requirements one is that we adhere to the antitrust policy two is uh the code of conduct which means that even if you disagree with people you don't make yourself disagreeable so these are the two principles that you have to follow to attend this meeting it is completely open otherwise so it is not censored it's not you know just have a clean community so that you know obviously we don't have to agree but everything but so that that's it other than that we are recording this and so it'll be made available later and Dr. Smith whatever you want to do is fine but it would be wise to leave space for questions later okay or even during your presentation yeah I think it'd be better to do questions during and sometimes when I get talk I'm not paying attention to chat and stuff like that so feel free I'll I'll keep an eye pop up that that that I should address without moving on just interrupt me and say hey we've got some questions on what you just covered and that will allow me to stop and address the question yeah so even though we are competing with an important event we seem to still have about well we have the magic number 13 13 participants there we go so we are ready to go Dr. Smith and we are recording and please go ahead and you can share a screen you should be able to share a screen okay let me do that can you see that is that working yes indeed I can see it very clearly yeah so Cary stands for key event received infrastructure and the the the big picture for Cary is that it's meant to be a secure identifier overlay for the internet so that's a fairly bold statement so I'll try to back that up for contact information I've set up a evangelism site for Cary Cary's completely open source under the aegis of the Decentralized Identity Foundation which is under the aegis of the Linux Foundation so we're all on the same page there but you can go to Cary.one and the resources page you'll find quite a few resources on Cary so if you want to dig deeper you can go there and this particular slide deck this version which I've made changes this morning isn't there yet but link for it will be put up at the end of the day but just to give you a sense of resources Cary is being developed under the Diff Identity Discovery Working Group and you can go here to see that there's a documentation repo for the Documentation Association with Cary and and we're developing a standard for the protocol we have meetings on Tuesday mornings this is the time for those meetings here's the zoom link and and the agenda if you want to participate there there are currently five implementations in development I'm working on the Python one probably the two most mature of the Python and Rust although the go implementation is going quickly there the Java JavaScript lagging behind a little bit I mentioned the Cary.one site here's links to the fundamental white paper there's related work going on in the trust over IP authentic chain data container task force which I'm the chairman of as well so there's a link to that wiki page so you can look into that if you want to dig into that I'm not going to go through these but there's but but if you're if you're really interested in digging into the background of where Cary comes from I think the most influential thing is something called self-certified identifiers which were actually developed in the early 90s well early and late 90s throughout the 90s and it and it is the innovation that makes Cary possible and so and it was overlooked it was originally developed as you can see from these titles to to prevent using a centralized certificate authority system for the internet but to use something that was decentralized back in the 90s before blocking so so it has good it has good good roots it's just people didn't care back then so much but but now but now there's there's work in that space and I added something here on something related which from the trust of computing group which is sort of which is revisiting self-certified identifiers they call them implicit identity instead of self-certifying and then some early papers that I developed in the space you can read through those and they'll be in the slide deck the idea of Cary oh and a little background on myself I used to be an academic I was a full professor in electrical computer engineering did a lot of research for the department of defense in autonomous underwater vehicles survivable shipboard automation and computational intelligence automated reasoning AI machine learning that that that's what my most of my research papers were in those fields I then at one point I retired from the university became a serial entrepreneur continued to do research from the Navy and various related fields eventually those became classified and so I switched to non-classified work in cloud automation systems and then back in 2014 I started looking into decentralized systems mainly to solve the problem of decentralized reputation systems and read some white papers and they became influential in the space leading to some of helped incentivize or inspire what later became sovereign and a lot of some of the work in the decentralized identity space for those you're not familiar I recently served for a short period of time as interim chairman of the sovereign foundation but and have been active in open source development for quite some time the the basic idea is and most of you are familiar with this but but I want to sort of set the table a little bit the we have a human basis for trust and and we have all these mechanisms as humans that that we can know people and trust them but on the internet you can't really know anybody you can't really trust anybody so we have a secure attribution problem and Kerry is meant to solve the secure attribution problem and that is I want to make secure attribution of any communications to its source that another way of saying that is I want authentic communication so so what I want to support is authentic interaction based on secure attribution of all statements by participants in those interactions that requires verifiable authenticity of any data that another way of saying that is data provenance and the phrase that David Hughes be uses is the authentic data economy and I like that because it's you know the idea is we want to build we want to build systems that are based on authentic data and that's the secure attribution problem so we want to replace the human basis of trust with a cryptographic root of trust because that's all we have we don't have anything else so the the the the the core attack is simple it's verifiable digital signatures from asymmetric key crypto it's nothing new here we're using the the the simplest basic form of crypto and and so the problem is is that with asymmetric key crypto we can't trust in what was said we can only trust and who said it where the who is narrowly defined to be the controller of a private key or set of private keys so we can we can make attribution that a statement but not the validity of the statement but that's the problem i'm trying to solve the secure attribution problem if i can solve the secure attribution problem so that we can have consistent attribution then we can address trust in what was said by verifiably consistent statements i.e reputation so that's the reputation problem but first you have to solve the secure attribution problem before you can layer on reputation so so one of the things i found out in discussing carry is that carry is the platypus of the identity space most people when i start talking about carry assume carry is not a platypus they assume carry is a mammal or they assume carry is a reptile or they assume carry is is something else because carry you know platypus is a unique combination of features right it looks like any of these things because it has features drawn you know fairly unique to those those creatures but but the platypus has them all and carry is is similar it borrows features from lots of different systems that you're familiar with but not in the same combination and and so carry is solving the secure attribution problem in a unique way and and often what happens is that if i don't set the stage well enough people forget that it's a platypus and start discussing it as if it were a bird or or or a reptile and and then and then and then the discussion kind of takes a while to bring the discussion back so for those who are familiar with the identity space carry has elements from the dnsca system from pretty good privacy web of trust from blockchain etc you'll see elements of those in carry the closest comparison would be the dnsca system and carry essentially it could provide a replacement for that that that secure because the dnsca system doesn't have secure attribution it has very weak attribution so the point of this talk because there's no way in an hour i can cover carry in depth or completely is to provide perspective and set expectations about carry so if you want to dig deeper you at least are looking at it from the right point of view right and so that's why i said look at it as it carries a platypus you're going to be surprised expect to be surprised respect to see features that you're that that aren't that don't fit what what you're used to seeing especially if you're coming from the blockchain world which is usually the biggest cognitive dissonance is is they make us is that blockchain people make assumptions about carry because it has elements of blockchain but those elements are put together in a way that that they don't fit what total order distributed consensus systems because it doesn't need them so so another another perspective is that i come from a background of building autonomous vehicle systems in hazardous environments and and one of the design methodologies we approached that is mission survivability and in this case secure attribution we want survivability of the mission of making secure attribution and that means that we usually break the problem into the susceptibility vulnerability and recoverability features and this is a in my view a much more comprehensive approach to security than the than the typical it confidentiality integrity and availability approach i think that's a too narrow approach it misses too much and one of the key things to recognize in survivability is that failure is inevitable preventing all failures is free a few times that's that's just a rule of thumb instead you focus on never failing to detect fail that is a that is a reasonable goal so high fidelity failure detection limits exposure to failure equals protection equals security that's the approach so carry takes that and and and and builds out on three principles make authentic sources of statements responsible for any making a yeah a statement responsible for any failure in the secure attribution of their statements enable the secure attribution of any failure to the source of that failure and failure detection is provided via duplicity detection and so those are the basis for carry's guarantees and and so explain what those mean but i can stop for a second before i go on if anybody has any questions at this point anybody have questions please ask after all uh dr smith to say it's an academic is used to questions i can throw questions out but i'll kind of i think it in my case it might be better to wait till you're finished rather than okay all right that's that's fine um thanks so so one of the things is that is that in building a system there's a system design trade space and so the principle that carry use and if you've read the white paper it's mentioned multiple times is minimally sufficient means if i want to solve a problem i want to do it with minimally sufficient means and the reason for that is that it's a way of pruning out stuff that you might think you need that causes unnecessary complexity and insecurity system design unnecessary complexity usually equals less secure um and so i wanted to start with the bare bones and so i i didn't assume anything about about my my system design trade space so so what happened is that i started with a bunch of possible things that i could have used but but but i built it incrementally using minimally sufficient means and what ended up happening is i was able to to to get rid of quite a few things that i didn't need to have um and i didn't need total ordering which or or um uh double spend proof i didn't need share control of anything and so it wasn't much so i ended up with a different set of features that solve the problem but have other features that i didn't have to trade off against uh that some features imply and so a question here from me uh you you gave up on total ordering yes uh did you give up on relative ordering no what local ordering is still there that what carry does is it says that an identifier only has one controller that is the controller of the keys that controller is the only entity that can make authoritative statements about ordering and so we let that entity make the authoritative statements about ordering which is local ordering to that entity in that identifier there's no commingling of identifiers which is which is important if you want to have a gdpr protection or support for gdpr because you can be you can be erased with carry because you're not commingling identifiers in a totally ordered cryptographic data structure you have local cryptographic data structures that are unique to each each identifier so so this is a short short summary of carry um it's open source of pass or two it was designed with scalability as as as a principal feature if it wasn't scalable then it would have been a failure so performance being able to work asynchronously on bare metal tcp utp non-enveloped messages and events um it's based on something called self-certified identifiers which i mentioned and i will go through in detail because it because if you understand self-certified identifiers then then the rest of carry starts to make sense um so the root of trusting carry is is is comes from cryptographic derivations from entity not in trusting algorithm or a trusted entity it comes from it comes from cryptography because of that you have truly decentralized identity because the control over identifiers is not dependent on any shared controller resources each controller is solely in control of all the resources that are used as the the basis for control over that identifier um this allows us to have something called n verifiable authenticity what that means is is that it fits zero trust uh design architecture which is never trust always verify everything is verifiable at the end or at the edges right so you have something called key event logs which are actually blockchains they're they're technically blockchains but each identifier gets its own blockchain so they're not commingled there's no trusted entities which means there's no trusted intervening infrastructure and and the end state of carry is we have something called ambient verifiability so so if we get to ambient verifiability then carry has very very strong security guarantees to the extent that we haven't reached ambient verifiability then carry the carry is is has it reached its end state um but but a good example of its end state is the google certificate transparency project which which provides an equivalent end state that carry can achieve so it's a practical it's a practical solution it's not it's not a pipe it's not a pipe train at all it's already been done but in a different way uh decentralized key management infrastructure uh if you if you understand self certified identifiers and everything that's gone above then you realize that that everything is based on key management and carry introduces some unique features one of those is pre rotation for key rotation um a compromise recovery of keys which is post quantum secure carry is has built in multi sig and advanced weighted multi sig so multi sig is a first class citizen in carry it's not a bolt on it's not a afterthought it's not like pay to script hash or or some you know uh uh custom you know bespoke contract on on on ethereum to do multi sig multi sig is is you know part and parcel with carry everything is designed to be multi sig at first it um so so that you can benefit from it carry also provides a delegated enterprise key management can we stop for for a second yeah i want to ask a couple of questions yes one is this concept of uh derivation from entrap entropy uh entropy uh is difficult to achieve of course and you know um you're saying that each participant is in control of uh that entropy that uh creates the cryptographic derivation uh i so if you think about the the public key cryptography and actually have a slide that covers that but i'll cover it now because you brought the question up uh in public key cryptography you create uh a private key a private key is is captured entropy that's what it is it's a it's a pseudo random string of random numbers typically provided by a cryptographic strength pseudo random number generator um if it's if the if the pseudo random number generator is a cryptographic strength then you can classify it to its cryptographic state you can say i've got 128 bits of entropy in this uh cryptographic strength pseudo random number generator therefore that's the cryptographic strength that the entropy have captured 120 bits is considered best practices is considered sufficient for current computation so if i build a system with 128 bits of cryptographic strength and all my derivations then i maintain that cryptographic strength and so because pseudo cryptographic strength pseudo random number generators are widely available like any operating system has them then anybody essentially that can capture entropy and and become the root of trust in their identifier because that's what a self-certified identifier does and i'll talk to that in more detail okay it starts there it says everything we do is going to have cryptographic strength cryptography we're going to we're going to do 128 bits full stop anything less than that yeah yeah yeah beautiful now um because that is the foundation of all this uh the uh the you know the generation and capturing of entropy yep that's the only thing we have in cryptography yeah everything else is you capture entropy and then you have one-way functions on the entropy all the cryptographic operations can be modeled as capturing entropy and then applying one-way functions to that entropy and so so theory is designed to maximize that set of functions and minimize dependence on anything else i mean the minimal sufficient means is if all like if i could do it all with just cryptography why use anything else just use crypto beautiful now going to the multi-seq the built-in multi-seq stuff uh i assume it means that the same person or or or the controller having that multi-seq capability by approaching the uh signing or whatever it is through multiple uh no it means the identifier is controlled by by by multiple uh public private key pairs exactly that's that's what i was going to say uh that is that the controller has multiple private public key pairs or the controller could be multiple entities each of which have one of the key pairs of course the controller now is a group yeah um anyway let's go on yeah before we go on one last question what exactly is the weighted adjective there um so since most people use a simple threshold so they say you know k of n like three of five two of three but in enterprises you want to be able to have more sophisticated combinations so you might want to say any two of these any three of these in any one of these and so and so you're basically weighting the signatures differently they don't all contribute the same yeah like like a guy from somebody who's a managing director plus two directors who are in this group or something like that right yeah so it's so so one of the complex complex condition yeah complex addition so so carry has that built in that's that's a feature you get that for free it's not a bolt-on it's not so that's actually a big thought it's not like well let's make some let's make some custom you know thing that we bolt on to a to a ledger to make it so that we could do that it's built in to carry because carry wants to be the trust spanning layer for the internet so it needs to work for enterprises as well as individuals right but then what you just said is that the weighted multi-signature policy i'll call it for a given identity model really is primary to the governance of that specific identity that's that's right that identifier that's right but but right if i said is this thing a center or not i'm basically going to have to evaluate that policy and the governance of that policy is huge and i assume the policy can change as well yes um so the threshold of that policy is a rule right it's a rule that anybody can verify whether the signatures match that rule and you can rotate the rule so you can change the rule right that rotation right but so the answer i guess the question i have is it sounds like the entire system is predicated on the management of the governance policy of this multi-signature rule for identity authentication to say how authentic is my identity depends on that policy and it's important to track as you said the rule changes on that policy yes and that's what carry does the whole point of carry is is to track and manage key rotation so that it's and verifiable there is no a verifier doesn't have to trust governance a verifier just verifies did they follow the rules that they committed to so so everybody's making cryptographic commitments and then you can verify if they satisfied their own cryptographic commitments you don't have to resort to any external mechanism it's all self-contained but according to you yes cryptographic verification automatically make is easy the thing though is is the verifier comfortable with the rules that govern that identity yes or no and that's their choice and that choice actually is fundamental to whether or not the system actually works well it's fundamental to whether the the verifier or validator trusts the the the identifier right i want to interact with this identifier they make that evaluation right so the whole system right the whole system is i'll call it crypt crypt automatically cryptographically authenticated which is fine that's great but at the core of this thing sits that the verifier has to decide that the current rules in place are acceptable that's right but that's right right that's for any system yeah yeah verifiers come in all sizes and shapes yeah and so and so a given ecosystem a given set of transactions a given application will have different rules determining whether certain levels of of of key management are acceptable to those parties that the point isn't that to try to design a one-size-fits-all but to to to try to design a system that gives the participants complete control over the decision of of how and to what extent they want to engage and so and so it's a it's a completely totally decentralized system it doesn't it doesn't avoid the problem or solve the problem of making those decisions but it puts the decision process totally in control of the participants independently that they're not dependent on any shared governance for that decision they can be if they choose to they can abrogate their decision and say well i'm gonna i'm gonna set up some entity that's gonna determine this for me or do something for me that that's fine but they don't have to do that and so it avoids the ledger wars it avoids the the those sorts of constraints but but i'll show you but those are good points and so and so kerry doesn't kerry doesn't have an opinion about any of those things kerry says here's a protocol that allows you to do end verification of the crypto so that you know so that you can make secure attribution and and secure is a function of of of your own standards for security you can say either it's acceptable and i and i and i and and it meets my standards or it's not acceptable but the point is that you make that attribution you you can make that decision you have all of the evidence you have all of the information in front of you to make that decision and you're not dependent on some of their entity so you're not in any way locked to a given system it's completely totally decentralized completely totally these self-solving in them in the most extreme way possible which has trade-offs of course let's let's go on yeah let's go out so one of the one of the advantages of of having separable identifier trust bases and non-enter twine key event logs which are the you know micro blockchains is that you can support GDPR compliance that's a huge win because now you can erase you you don't have to worry about putting private data on a ledger and then and then the having the the ledger nodes have liability because they can erase erase that information in a lawsuit which was a problem with the sovereign foundation had to address in in terms of we're trying to get GDPR compliance and never did never did get a final determination from the GDPR regulators whether or not what to what extent that liability existed so so you sign agreements and stuff like that when you when you put stuff on the sovereign ledger public identifiers that that you have to sign liability waivers and that became a problem if you for you know public right access without liability waivers it also supports electronic digital signature compliance so the regulation for eids ueta e-sign that's the european and the us regulations that are generally accepted most of the world is that because it's based on digital signatures and the digital signatures and the keys for those are under sole control of the identifier controller which satisfies the core condition for legal liability for digital signatures whereas if my digital signature key state is maintained by another by other people over which I have no control then I can repudiate it and therefore not be liable for it so if you want legal liability for digital signatures then you need separated control so that each controller has sole responsibility for the control of their identifiers and that and that and those are important features that that that kerry provides so let's talk about identity system security overlays so the basic problem is with an identity system security overlay is that I'm using this thing I have a asymmetric key pair the identity system maps the key pair to an identifier I then send a message I want that message to be authentic so I put in that message the identifier the data and attach the signature so verify the authenticity of the message I use the identifier to look up the key pair I then verify the signature against that key pair so clearly the security of that system is contingent on the security of the mapping between the key pair and the identifier if I get the wrong key pair for the identifier then the signature might not be the right signature it's not an authentic signature it came from some other key pair that wasn't by the entity that controls the identifier so the binding in identifier issuance is the source of security it is the source of weak security and the source of strong security there are three bindings that are made you have the controller of the key pair because they collect the entropy to create the key pair and hold the private keys that binding is strong as strong as their ability to to keep their their private keys private if the key pair and the identifier have a strong binding then that makes it so you can't mismatch key pairs and identifiers and if the controller has a strong bind to the identifier then you can't mismatch identifiers and controllers so what we want is this trust triangle with strong bindings between these three entities so let's see how that works with self-certified identifiers the self-certified identifier the controller captures entropy uses that entropy to generate the key pair because it controls the private key that's a strong binding if it's a self-certified identifier then the identifier itself is derived through a one-way cryptographic one-way function from the key pair so now that binding is strong and because the controller holds the private key he's the only one who can verify control over that identifier controller derived it and can verify it so all of those bindings are strong so we start with a secure root of trust which is this self-certified identifier issuance trust triangle the certificate authority system doesn't have such a strong root of trust and I have a slide to talk about that a little bit later if we get to it so what does a basic self-certified identifier look like well we start with a random seed we stretch it get a private key that's a one-way function if I do it at cryptographic strength I have a private key I generate a public key using another one-way function typically ecc I then attach a derivation code to the to that to that public key and that makes what do we call an identifier prefix and the reason we call it a prefix is because identifiers control namespaces so the thing that controls the namespace is this unique cryptographic string not all the other stuff in the identifier not you know the query and string whatever namespace technology used like did those are all part of the namespace it's the prefix that's that's the cryptographic item and so in carry what we do is we have a prefix that consists in the simplest form a public key with a derivation code prepended to it the derivation code is part of the identifier and then we have an inception statement that includes the the the derivation data like the public key and any other configuration data and then we sign that with the public key that was used to generate the prefix so this inception now is is the root of trust it's the start of our blockchain it's it defines the keys it defines the signatures all secure so we have this totally decentralized issuance it's not dependent i just provide this inception state to anybody and they can verify the root of trust for that identifier that's the start of the identifier it's not dependent on a root of trust on a blockchain or ledger or or a trusted entity or anything like that it's completely verifiable it's a basic system and if you think about it ethereum addresses bitcoin addresses are all self-certified identifiers they're trivial ones because they're just public keys they don't have any other mechanisms to make them more more useful but but they are a trivial version of this sort of self-certified identifier they just don't call them that but back in the 90s that's what people called uh making identifiers that way so this would be the cryptographic stream um this would be a namespace using that cryptographic string or prefix so this would be a full identifier within a namespace but that same prefix controls all of the identifiers in that namespace so a more sophisticated one was we call a self-addressing self-certified identifier and in this case we have two derivations we dare we derive the public key with the derivation code so we know how to derive the public key we then add to that additional information we take a digest of this additional information add a derivation so we know how the digest was created and that becomes our prefix now what's happened is the identifier is not just a function of public keys it's a function of any of this inception configuration which means we can make our full key management infrastructure bound to the prefix so we make a cryptographic commitment to our key management infrastructure by the identifier if i change the key management infrastructure i have a different identifier so it's a secure cryptographic binding that performs the whole route of trust of this identifier because i've made a cryptographic commitment to it by virtue of the derivation of the identifier so that's a self-addressing one and then of course we can extend that so it's just it just has a different derivation code but it's the same same same basic idea i can extend that to multisig by including a set of public keys and the inception configuration each with derivation codes and then with the final derivation code that all ends up through with the same length prefix but anybody who sees this prefix based on the derivation code and the inception statement can then verify the derivation know that this is controlled by a set of by a set of public keys knows how to verify the signatures because the threshold is included in the inception configuration and if i that threshold is weighted it's included here it you know so everything that i need to verify that this is this statement it makes secure attribution understand we're solving the problem secure attribution that means i can securely attribute the signatures this statement to these private keys and the public keys um and verify them without without needing any other resources anywhere else all someone has to do is present me this inception statement and the prefix and i can do the verification and the prefix included in the inception statement so i don't need the prefix inception statement itself is self-contained so that's the root of trust and then i can do more sophisticated ones but uh where i do a uh a delegated self-addressing self-certified identifier where i have a delegating prefix that has its own root of trust with delegating configurations so that i can do nested identifiers and which is really useful in our enterprise applications because now the nested identifiers basically can use the delegator as a source of a trust and you can do recovery through the delegator it can recover loss of keys in the delegate and and and so on so so it's enterprise class key key management and identifier issue we're all the way down and so far we haven't we haven't needed anything else all we're using is just cryptography and they and everything that is needed is is is a cryptographic commitment in the inception statement i might ask a question yes okay so i'm probably missing something since i'm a bit confused with my understanding of the basic concept what is kind of what an extremely simple you're just saying okay since you have the problem of binding an identifier to the public key which is sometimes a business of certification authority okay well just drop the identifier and use the public key as the identifier and then you also add the possibility of signing it in order to confirm that they are the owner of the associated private key but that you could every time do with any challenge so that's not an issue so the basic concept that i'm wrong the basic concept that's what a self-certified identifier is what we've done is but that's something that uh what we're going to see is my night the public keys we're generalized it to anything else you want to make a commitment to the identifier becomes derived from from any set of cryptographic commitments not just the public keys okay okay so let's say i want to make a commitment that this identifier is based on some other information like a server i want to say i'm going to put my key event logs on this set of servers this practice of using the public keys and identify it well but now the identifier isn't the public identifier now is a hash so yeah so this digest is a one-way function so the public key jet is contributes to this hash but what but the protocol says how i prove control over this hash is via the public key but the identifier itself comes from a hash of of a public key plus other information the the hash is a one-way function so it's a cryptographic commitment the protocol says how i prove control over this hash is via the public keys so unlike a hash that's just a hash anybody can create nobody controls the hash but with a hash that is self-certifying you have a way of proving control over the hash itself and so the hash becomes the identifier so now what you've done is you've made your identifier a self-addressing content addressable identifier that has provable control so that's the innovation that's the that's the next step in the evolution of self-certifying identifiers is not not trivially public keys but anything you want is now part of the derivation of the identifier but you still have the same control in the in one or more public keys beautiful now you're saying basically i mean if you take like let's say the did analogy the did document could participate in this that could be your inception statement yes so right now coming at because the did document itself includes the prefix and i can't make a hash of something that is the hash so it's a recursive problem so yeah right so it has to be a subset of what's in the did document yes of course the document since it contains the hash but that's uh you know that's that's the problem that is there in many many different infrastructures what what attributes participate in the hash and what yeah it did peer did peer by the way uses that approach did peer public uh public keys i mean pre identifiers can be derived from information in the in the did doc but that way okay my eyes is that and and provide similar features but does it uh for all classes of dids so did key did peer and then public public dids so my my question is about the witness that is your uh inception um you know row that you created uh out of those various things including the signature now that witness uh in order for that witness to be uh exposed there has to be some mechanism right that's right so you put you the witnesses are part of the inception configuration the initial set of witnesses are in the inception configuration yeah yeah but uh the that row that you created there inception statement that has to be accessible to the verifiers that's right uh i mean either this inception statement or the key rotation stuff in any of those things have to be actually and in order for them to verify that that is the correct inception statement and the uh you know and the basically the wit the witness has to be somehow secure in itself uh when you present it right um no i i think i think we're i think we're moving in we're moving into a space of you're making assumptions about witnesses that that i haven't made yet i you're you're skipping ahead and and i don't and and so i want to be very careful because because kerry makes very specific guarantees about things and it doesn't make guarantees and it doesn't make guarantees that most people assume it makes that's usually the source of confusion people look at a set of witnesses and they assume that that means it's like a blockchain and it's not that's not how witnesses function they don't they don't serve the purpose of that the the the key event log it is the source of truth and so the witness isn't a source of truth it's the key event log so so and that's why actually my next slide is the uh is this slide because this is usually where i need to explain duplicity to understand the guarantees that kerry makes because this is this is the place where it's really hard for people to understand because they look at kerry and says okay you have this cryptographic structure but can a controller and this is usually the question the back of people's mind can a controller just create any number of inception statements well no they can't because if i'm using a self-addressing identifier then any change to the inception statement means the identifier changes so i can't make any number of inception stations there's one and only one inception statement for a self-addressing identifier i mean if i use a trivial one i can but but but nonetheless look that one's gone away but if i do rotation events because now a rotation is replacing the keys with a new set of keys then could the controller create any number of rotation events and therefore essentially create multiple you know copies of a key event log for a given identifier and the answer is yes that's absolutely possible a malicious identifier malicious controls can do the kerry kerry does not prevent a malicious controller from doing that what kerry does is protects a validator from harm should a malicious controller do that and that's an important distinction so that's why i brought that's why i had the slide about uh uh detect a failure if a malicious controller is ever duplicitous i want to be able to detect the duplicity before it does mean any harm if i can detect the duplicity before it does mean any harm then i'm protected and that's all kerry has to do kerry just has to provide high fidelity duplicity detection to protect validators it doesn't have to prevent duplicity it just has to detect it it doesn't prevent malicious controllers it protects validators from malicious controllers by detecting duplicity that's that's a guarantee so so this is a civil uh protection basically this is kind of a civil civil protection or a same person sort of masquerading oh yeah yeah duplicity a civil attack is is duplicity but it's but it's attack on a ledger so it really isn't a civil attack it's it's it's duplicity but yes it has the same features of uh uh in in the sense that you can create multiple uh so understand if i can't create multiple identifiers it's not a civil attack right i can create multiple rotation events so i'm inconsistent so it's more like a certificate uh forging certificates it looks like a certificate it looks like a uh you know in certificate authority space it is the main attack that that it's susceptible to and the problem is you can't detect it and certificate authority is going to carry you can and so as long as it's detectable you're protected and so that's so what kerry does is it makes strong guarantees about detection of duplicity to protect validators and makes controllers liable for their duplicity and so and so if you're if and so when i said secure attribution if i can if i can make uh if i can make failure securely attributed to the source of failure that is somebody either had their keys compromised or maliciously used their keys in a in a duplicitous way that i can detect that and and and and hold them accountable for it then then i then i protect that i'm protected from from from that behavior so so let me let me go through these slides because i think this is this really this really nails it down um but but hopefully this helps so in kerry i have a sequence of events so we've talked about the inception event when i want to rotate keys so understand if i don't ever need to rotate keys i don't need a key event log i just need the inception statement i'm done because i'm never going to rotate keys and so uh ephemeral identifiers or identifiers that are used a lot in the decentralized identity world don't have key rotation i can't rotate my bitcoin address by the way i can't rotate my ethereum address so they're not rotatable so so they're they're ephemeral identifiers even though people act like they're not they're ephemeral because they're not persistent across key compromise whereas a persistent identifier says i can maintain control of the identifier in spite of key compromise because i can rotate my keys to recover to a new set of keys and and i do that with the pre-rotation and i haven't gotten into the detail pre-rotation we'll get back there in a minute but pre-rotation provides protection for that and if i do delegated identifiers i have additional layers of recovery and protection so i'm lost once again ma'am sorry i'm sorry i can't really figure out how rotation may happen if you have the public key which is say i'm not written inside your identifiers i think let me i'll pull up a slide for pre-rotation um okay well i'm sorry that we only have an hour otherwise yeah okay so here's pre-rotation so the way pre-rotation works is that in the inception event you you the configuration includes the public keys in this case it's one key but it generalizes to multiple keys and you have a digest of the pre-rotating key or or the next key so you really have two sets of keys you have your current signing set that signs the event and then there's another set that you don't use these are your rotation keys so when you want to rotate these are the keys you use but the way it works to make it simple is that when you do a rotation the the rotation keys become the current signing keys and the rotation makes a cryptographic commitment to the next set of rotation keys so you can think of your keys as a sequence i have c0 set c1 is my next but i don't actually publish those keys i use a digest that makes it that makes it plus quantum secure a sufficiently strong digest is quantum computers have no ability over conventional computers to invert a really good digest like SHA-3 or blake-3 and blake-2 also is good enough SHA-2 is questionable some people say it is some people say it's not so if i have a next digest i've never published the key i've never used the key to sign anything that's not been exposed to any side channel attacks i just created the key pair saved the private key someplace created a digest of the public key and then published it in the inception of it now when i do a rotation i use the next key i take that out of cold storage use it to sign the rotation the rotation now declares this key this is when i first publish it says this is the key and you can verify that it is the key because it verifies against the digest i create a new c2 as the next digest and now so what i have are one time used rotation keys each event declares commits to the rotation key for that event and then when i want to rotate i rotate using that rotation key that rotation key no longer be used for rotation but it can be used for signing i make a new rotation key and so on so pre-rotation is a very secure way to do rotation without having any other infrastructure it's all self-contained it's all in line it's one key sequence so so that that's a and a lot of people have said i wish they had thought of pre-rotation because it solves the infinite regress problem of key rotation most key rotation mechanisms say i have my signing keys and i have this other rotation key and whenever i want want to replace my signing keys i just use my rotation key and everybody recognizes the rotation key as the rotation key so you do the rotation but what happens if my rotation key gets compromised well if my rotation key gets compromised then i've lost everything so then i have another rotation key to rotate my rotation key and so on because i need to because any key that i use is weak the moment i use the key it's weak it's been exposed i uh site channel attack may have compromised it so i don't want to have exposed keys i want to have keys that have never been exposed i want to be able to bury my key in the bottom of coal mine and have never used it and only use it once so one time use keys the strongest possible type of key so kerry gives you that for free you get one time use rotation keys you just have to remember two sets of keys the current signing key private keys and the next set of pre-rotated private keys you don't have to have any other infrastructure it's just it's all in this one infrastructure so so so kerry gives you pre-rotation so now assuming that we we have rotation events when we're rotating keys because they've been compromised then we get back to how do i protect um validators right because i've got a controller controller now has protection the controller can do things to protect its keys it can use pre-rotation it can use multi-sig it's got lots of ways to protect itself from attack but but a controller can be malicious or in a controller can be stupid so what i want to do is i want the validators to be able to detect when a controller is either stupid or malicious and from the validators point of view they're the same thing because what is it what how does stupidity and maliciousness exhibit in in kerry there's only one way for it to exhibit and that is duplicity so all of the failure modes for kerry become one failure mode duplicity so now i can be protected from that one failure mode if i have high fidelity duplicity detection so i've simplified the security problem down to one simple problem now that that now the how good i'm at solving that problem is burns on how much protection i have so let's let's see what that means um we have a sequence of events we have inception events and rotation events these change the keys interaction events or other events in a key event log that don't change keys so we can ignore them for all intents and purposes that they're not changing the key state they're just there for convenience i can do everything with just inception and rotation events i don't mean interaction events the only reason to have interaction events is i may want to sign lots of things and not rotate keys because rotating keys is inconvenient so they're there for convenience and performance they're not there for for any other purpose um uh so i define let me play this a little bit there we go so i define the dictionary definition of inconsistency is lacking agreement as two more things in relation to each other so i can think of a key event log and say is the key event log consistent is it internally consistent that means all of the events are consistent because there has chain data structures that then i can verify the whole log and say yes all the hashes verify all the signatures verify everything's consistent all the events fit right this event is hashed into the event before it and so on so it's a fully it's a full blockchain according to technical definition of blockchain as a data structure now duplicity has a slightly different definition it's talking about not agreement but when you act in two different ways to two different people concerning the same manner so a given key event log can be consistent but if i create another consistent key event log and share that key event log to two different people right then i'm being duplicitous because i'm not acting the same way to both people i'm acting in two different ways into different people so i use the term inconsistent duplicity to to distinguish between internal consistency which is an event log anybody can verify that a given event log is internally consistent if it's not you throw it away the signature doesn't verify throw it away if hash doesn't verify throw it away it's not internally consistent you don't have to trust it nobody can create uh and trick me into trusting an event log unless it's internally consistent because it's designed to be completely verifiable so external inconsistency is different so log verification from a self-certified root of trust and we i've proven that that you could you have a self-certified root of trust that protects me from internal inconsistency i i can't ever be tricked into accepting an event log so cash poisoning the dns cash attacks bgp attacks all of these attacks that that the current internet is susceptible to are based on the fact that i don't have this internally this internal consistency proof for all all statements or all information and all routing but we carry you have that so an externally inconsistent log means that if i have two purported copies of a log for the same identifier and they're both verifiable that means they're both internally consistent then i have duplicity so let's think about what that means it's been signed with non-reputable signatures so any creation of the duplicitous log is a provable liability i i'm a provable liar so the only thing i can say if i'm a controller and and two duplicitous logs exist for my keys are either i either i'm duplicitous and you can't trust me or my keys have been compromised and therefore you can't trust me so so in either case if there's duplicity the validator knows that there's a trust problem and can detect it the minute the duplicity happens or even the millisecond it happens so so duplicity detection is the mechanism that carry provides to protect against external inconsistency which protects against both maliciousness on the part of the controller and or a key compromise on the part of controller so so it's re re it's refactored the problem into this one problem so let's play the duplicity game and how much time do we have oh we're out of time we are out of time it's it's we can we can stretch it to another let's say 10 minutes well i can i can yeah i'm happy to go if you guys want to stretch it yeah i'm i'm good with it uh the thing i want to say is that you know no matter how much you stretch it we are not going to uh you know we're we're never going to get through all of it but but yeah yeah yeah but i understand that duplicity is essential to understanding carry if you don't understand duplicity you'll confuse carry with something else carry's a part of us because of duplicity okay so back to duplicity uh one thing that you said was that if you're uh if you see those inconsistent logs then you can easily say that they're both coming from the same source and they are inconsistent but if you don't have access to both of them then what you do then then you don't then you can't then you can't detect duplicity so duplicity detection mechanism is something that you need for carry so the way carry provides a duplicity detection is through a watcher network and the watcher network is analogous to the google's certificate transparency uh network so if you're not familiar with google's certificate transparency um i can spend some time talking about it but certificate transparency is trying to solve the problem of uh forge certificates and because certificates don't have a cryptographic root of trust they don't have uh event logs they don't have the concept of duplicity but they do have the concept of inconsistency and that says if at any point in time they see two inconsistent certificates being used on the internet anywhere for any dns domain then the certificate transparency network will flag it and that then enables anybody using that certificate to go i may have been compromised because i only want one certificate to be there at any point in time and there happens to be more than one being used so there's a there's no which one it is huh there is an eye of god sort of thing yes but i understand somebody's somebody's observing the whole thing otherwise you can't detect this that's right so so so in most cases if i'm going to interact with another party i i i what i do is is i look up their identifier and i look up their key event log and in the duplicity detection network i ask the question have there been any have you detected any duplicity with regards to this identifier so before i i i engage in a transaction and do that check the um a global i have got certificate transparency network which is the end state for carry is not technically infeasible at it's actually not all that difficult and you have and certificate transparency is is global scale with millisecond latency to detect all of the certificates on the planet and any any decentralized hash table like ipfs or any system like that could be used as your global duplicity detection network and so your so your ability to have that that observability is is is practically feasible that's the main that's the main constraint of carry is that is that the validators have watchers not witnesses watchers make the distinction and the watchers share information and it's in they're highly incentivized to share information because the more they share information the better protected they are against duplicity so the end state is is that everybody shares information and the latency to detect duplicity is on the order of milliseconds and and that's the way it is with certificate transparency so radical decentralization comes with radical decentralization comes with the eye of god well but it's a decentralized eye of god but god has no control well we have observability we have in in in indian mythology there's god with eyes all over his body or her body or whatever oh okay yes so it's a universal eye that exists everywhere but not anywhere but not anymore yeah go ahead so so we used up the 10 minutes so i guess we're you know i mean you know uh look i don't know how we can continue this because it's a very interesting uh presentation we we should be able to you should be able to send it to me and we we can share yeah yeah it's online if you go to carry that one site there's a there's a there's a link to the carry presentation and maybe we can ask questions on the website and then send them off for answers yeah um there there's also a q and a in the um and you'll get it on if you go to the carry repo or diff you can file an issue if you have a detailed question and that way your questions get answered for everybody instead of just one on one but if you want to send me they're probably that question list is searchable i assume right yeah yeah so we can prevent duplicate questions yeah and there's and there's a question and answer uh actual like in the wiki on the on the website there's a there's a question and answer so you can search that as well right so if you post those links that would be helpful to the yeah it is there on the it is there on the meeting just like yeah i'll send it out on the identity working group but it was on the here carry dot one carry dot one has links to everything so if you just go to this one then you'll get to everything so it is i carry dot one is the eye of god yes anyway so um it has been a delightful hour and some i think what i want to say is my deepest thanks to you to show up and basically it's a pig in a poke you didn't know what what exactly you were getting into so you know it's it's it's great that you make yourself available for these things and you know one of the questions i wanted to ask was obviously there are several things that weaknesses or let me not even use the word weaknesses uh pre-existing conditions or other other things that are necessary for this sort of uh uh system radical decentralization to become um reality so i mean i i was going to ask that on the site and anyway we'll we'll have an exchange well yeah and some curious view on that is is that we want to use cloud and because clouds everywhere and people already know how to use it and it's cheap and scalable and all those good things so can we do it with just cloud and key management and so the answer to that question is yes if you want to use ledgers you can use ledgers with carry so if you want to take advantage of whatever feature ledger has you can take advantage of that but but but but then you also have to live with whatever disadvantages using the ledger have and use those disadvantages have to do with governance control scalability performance and cost but but you get other things for it but carry is agnostic about the support infrastructure and so you can use cloud and and the thing that it isn't agnostic about is key management but then carry says okay we're going to do best of class key management we're not going to punt key management we're not going to push it off we're not going to bolt it on we're going to build it in as the core protocol of carry is key management in fact I call carry a decentralized key management infrastructure because that's what it really does if you can do key management then you can do secure attribution you solve the secure attribution problem and how you protect people is through duplicity detection and what are you detecting you're detecting duplicity duplicity in the use of their keys so it's it's it's a key management function inherent all right yeah like I said it's been a delightful hour and 12 minutes thank you and we will connect yes in other venues and I don't know if you guys know this but the global legal entity identifier foundation has adopted carry for issuing verifiable legal entity identifiers beautiful it's is an ISO standard so carry has a very important adoption vector already so because the glyph did present here in this very forum and they talked about their extension to roles enterprise you know roles in enterprise and I assume that some of that is going to be through carry and I yeah you notice we did those enterprise features in carry so that was very attractive to life because they can do enterprise delegated identifiers and they can do weighted thresholds for multi-sig so so we had Carla and and Kristoff present yeah schneider and column a canal so they're probably going to come back here for a reprise and yeah I'm sure and I work with them on a on a regular basis now so oh that's great so now we'll probably have you at Florida price sometime later to see how things are going and I would like to participate in your rust rust you know fantastic yeah okay and because I'm I'm getting my rust up to shine you're shining your rust okay yeah okay all right well you guys have a good day thank you all right bye