Decentralized Identifiers (DIDs) Fundamentals & Deep Dive

[00:00:05]welcome as 2ss a meet-up this is the second part of the di D marathon that we have today with Drummond Reid and Marcus a bordello like 60 minutes ago we had a di D working group update about the face to face meeting they had in the Netherlands and this is a follow up on almost completely different subject because Drummond and Marcus they're the co-authors of the di D chapter like when there's just one chapter did they call that in the book but it will be out and they are co-authoring many more chapters but what we have decided that is part of the work that we do at SSI meetup is that we will be sharing the deep insights that we have been developing in that book that will be coming out to summer you have this already available in in MEAP which is the Manning early access program and we will share a link it at the end of this presentation or just check out identity book HQ Twitter account where you will have a link to and chapter six concretely is the di D chapter so the di D chapter is an amazing chapter that Drummond and Marcus have written which I'm really impressed with and I think it's the best that has ever been written about the IDS also the other chapters but we wanted to start with this one we'll be bringing out many more specific identity booked out in for special webinars and this one well I think we all have to privilege to hear from drama and markers about what they were working on and really understand the baseline and just will help you to understand webinars like the previous one we had about the di D working group where once you understand the basics of how all the stuff is constructed it will also help you to understand um how us being developed and how to create real and society centralized solutions quick follow up on as I meet up what we're trying to do here this is open to everyone companies individuals associations what we help and desires that you use this material around the world we know this is happening already people are using it all over the place in Asia America Europe South America and so we're really happy with that and it's a creative comments by share alike license which means that you can reuse this material and you just need to give credit back to the authors which today is Drummond and Marcus and business Meetup and then you can reuse it if you have any questions during this presentation which will be an amazing deep dive presentation please pay attention and take notes ask the questions that you have because this stuff is really really interesting yeah and that's about it Drummond and Marcus and thank you so much for being with us today here again this is the landing page of the book that I was talking about before you can get SEFs on an identity book already you can have chapters 1 2 3 4 and chapters 5 6 7 which is architecture could Prague Rafi their foreign credentials and D IDs and developer credentials chap depth has been done by David Chadwick and Dan Burnett and and many other key people that we will be inviting and showing up here as I meet up and Drummond and Marcus please take it forward from here and and and all we I'll be bringing up questions as they come in excellent thank you again Alex it's good to be back for part two of our di D Marathon today and so what Marcus is not going to do is walk you through the the content of this chapter it is one of the longest chapters in the book because we we decided hey if we're gonna write a you know a full treatment of di DS we're gonna go all the way down and we actually begin the chapter with this diagram because as as to do people have been involved with the ideas for a very long time we find that there really are these four levels progressively deeper and deeper levels of understanding di DS and today we're going to actually do the same thing we do in the chapter we're going to work our way down through all four levels and you know deeper goes the heavier against but hopefully the more insights there are we won't spend a huge amount of time at the bottom level of just a couple things there but we'll work our way down through that and we'll just we'll each sort of cover the parts of the chapter that that we contributed most to and then we'll provide commentary throughout so let's start with a superficial level what is a di D and the really short answer about it's technically a URI that as you see in this diagram here the the urs space is very broadly divided into URLs Uniform Resource locators and you our ends uniform resource names and the difference between those two way back to the start of the web architecture was URL points to something that exists on the network and you can go located and retrieve the resource best example being every time you click a link on your browser you get back a web page that's the resource you're getting back whereas a URL and and by the way those resources get changed they can move they can you know they're not there's no requirement that it be persistent whereas a u RN is exactly opposite it's a it's an identifier for something that is designed to never need to change and and by never we mean like ever it's supposed to be a global unique identifier for all time for that resource and that if it does if the u RN does resolve it typically goes through the process resolving it to one or more URLs that will point to instances of that resource someplace on a network but your ends don't necessarily resolve at all they just are persistent identifiers for things and so the the interesting thing about a D ID is it's functionally equivalent to you are and it's a persistent identifier for something but the resolution process can result in one or more URLs the dew point two ways to interact with that resource on you know on the web on the network and so it combines sort of you know some some aspects of both of them and then add some others will cover in a minute Marcus anything else you want to say about this the overall structure of the IDs yeah I would just say that the main thing to keep in mind here to learn from here is that these are completely in line with web architecture right it's all right kind of your eye and when we think about the web or thing we think of HTTP URLs that we type into the browser but the web is not limited to a certain type of your eyes or you can just as well imagine the web that's built on top of this new type of identifier the dates actually it is an interesting quote from Tim berners-lee I think he said the DNS is the Achilles heel oft of the web so you could imagine a better web that's built on this new type of identifier and and then the other comment this is the SSI book right and a lots of chapters about many different components and technologies for for SSI agents and wallets and verifiable credentials but really the essence or the origin often of an SSI system is these identifiers that's that's the core building block that's how you know that's where you start when you when you build SSI if you don't have if you don't have identified then you cannot have relationships you know you always need names and numbers and addresses to to refer to one another and to build connections and to exchange data and end messages so and that's why that that's why the data community or the SSI community came up with the with this idea that we need a new type of identifier if we wanted to build a new type of identity system exactly and that new identifier if you've attended any of our webinars before you've seen this set of the four core properties of a D ID this has been I think was a enumerated and the very first version of this back and it hasn't changed and again there are there are identifiers out there that provide some subset of these properties today permit persistent identifier sources you are ends there are many forms of you are ends all HTTP URLs in two main names and everything are resolvable there are what are often called CI DS cryptographically identified verifiable identifier identifies where you can you can prove that it is the identifier for resource content-based addressing is one of the best known examples of that's used by p FS and and other systems and there are even decentralized identifiers z' probably the best-known is uu ids universally unique identifiers that are produced following one of several algorithms there's a whole Wikipedia page on it so that they're basically all but guaranteed to be universally unique based on the randomness or the algorithm that used to generate it and and they've been in use in distributed systems for several decades now what a di D does is combine all four of these properties right it's persistent you can resolve it into the same we call did document talk about the resolution in a minute they are a cryptographically verifiable in many different ways that's every did method can define how bad happens for it and they are decentralized it do not require centralized registration authorities so when you combine those four properties you get this new identifier which as Marcus pointed out is it's the first new identifier that I believe the w3c has undertaken since it started with HTTP identifiers you know and in its history so that's why we're here an identifier that does these four things any other any other comments on that Marcus where we dive down to the next level Noam up here those are the four properties yeah great okay so ah we're now going to go down to the next level and howdy IDs work and Marcus did the majority of the work on this chapter so I'm going to click in and we'll start with this quote right out of the book here I like this you know the whole sense of identifiers it's not the identifier itself it's how it's used and the particular type and keep this in mind we'll come back down to this it's a very lowest level when we talk about the semantic meaning of the IDs but let's dive into okay what is the usefulness of this so take it away Marcus right so the quote on the previous slide it basically says that there are some rare scenarios perhaps where identifiers Zhai useful just by themselves just as addresses names or numbers but in almost all cases and an identifier is is used for something you use it to start some interaction or some kind of protocols in other words you resolve it right that was one of the four core properties that's that's the nature of URLs on the web if you have that identifier you can you can access it somehow you can interact with it and the main main function of feeds is that you can when you resolve it it you end up with not with but with a web page or an or a picture or a PDF document that's what you usually do with HTTP or else when you type them into the browser but with a deed when you when you resolve it not this is not really with a web browser using some other kind of didn't abled application or service you can resolve it to this data structure that's called the deep dark amend and that the document contains basic data that is needed in order to interact with the subject then through here some kind of indirection some kind of protocol to exchange very fiber to dentures or to create connections where exchange some other kinds of messages so that's the that's the basic piece of information that the document that can be looked up that can be resolved from the data and there's an in this diagram you can see something like like a triangle between the date on top did they document on the left that it resolves to and the document on the left describes the date subject and could subject and them at the same time is what's being identified or denoted by white appeared in this diagram would it's a person right it's not necessarily always a person it can be an organization or a thing or an animal or or anything else and this again is very much in line with with web architecture itself so on the web we sometimes say there are there information these sources those are things on the web that have URLs that you can dereference that you can access that's what the document is it's an information resource but they did that it's subject that's so called non information resource that's what they did identify it could be me it could be tremendous beauty as I meet of organization and this this triangle between the identifiers the document and did subject that's really the core functionality that it's providing that everything else before we leave this diagram there is one important point Marcus Illustrated this is diagram from the book that this did subject is controlling obviously they did and the document now in the did specification we call out that role separately as the did controller because as soon as you turn around and say oh it's not a person here it is you know an organization a thing a product and animal obviously it can't be the controller of these things it is the subject of the of the did it's identified by they did and the document describes it but the deed controller would be a another party and you said we we call these two scenarios this is the did controller equals dead subject is what you're seeing in this diagram but we also have the scenario where the did controller is not the dead subject and we'll talk more about as we get deeper into the into the whole thing but I just wanted to point out that it's not always the case that they did subject is a controller all right on to good documents okay so so again the document is the is the information resource on the web that it did resolves to and and intention is to enable interaction or connections with with its object now in theory that the document could contain any arbitrary information to describe its subject it could even contain personal data such as a name or an email address most of the time we we try to discourage that especially for dates that that identify people for privacy reasons because the document is essentially public anyone can look it up just like if you have a domain name anyone can resolve it to an IP address and that's public information so most of the time were saying that the document should only contain the minimum amount of information that's needed in order to then bootstrap some other kind of interaction some protocol agent to agent protocol or exchange of very fiber potentials other other checklist the SSI booklet going to more detail on how that exactly works but the the purpose of the day document is essentially to bootstrap these higher-level interactions and so most of the time in Inadi document you will find it's essentially two things you will find one or more public keys that are that are associated with each subject that are under the control of the deed controller which again is sometimes the same as the deed subject and sometimes it is it is not and and you will find service endpoints in the day document and those tell you how exactly you can interact with the deed subject what kind of protocols what kind of network endpoints are available to connect for example 2n - an agent that represents the paid subject so that you can then exchange credentials or some some other some other messages the document may contain some some additional things like timestamps or information related to delegation authorization there different architectures different applications that use the document in different ways but essentially most of the time it's the it's the keys and the server's endpoints Drummondville huh we talked quite a bit more about about the public keys and how the keys relate to the subject but let me just make one note here that that this is really the essence of of self sovereign identity and how it's different from other identity systems the fact that it did is independent of a central authority it is created and managed by by the deed controller alone and it has associated cryptographic key material so from known I don't know philosophical point of view you could say in in an SSI substandard that's based on peds the act through which and digital identity is created happens without any intermediary without any central authority right I don't have to register it using a password in somebody else's database I don't have together and identify a register in a centralized or a hierarchical system online all I have to do is create the Toraja key material and create a deed and the public key is associated with method and in indicate document that's really the core building block I am I think of what enables inside here's a yeah go ahead here's an just a quick example typical date document it contains one public key which is it says here it's used for authentication so that public key can be used by by client or during some interaction with with the date subject to to prove controls that it's subject can can be authenticated by by the key that's in the document and then there's a second and then the second entry here is a service endpoint in this case it says verifiable credential service but it could be could be any protocol really if that's available for for communicating with because such it could be could be a social networking protocol could be an identity agent personal data store protocol but this is very typical pattern that we have these two these two things I'm doing so this is very important so there's no single technology there's no single registry for tails wherever deeds are registered and there's also not a single a decentralized system like blockchain or distributed ledger that all these use and in fact that you could think of the date of something like a framework or or a concept that can be implemented in in different ways and those those different ways of implementing dates are called date methods so it could be created and and managed and resolved using using a blockchain like Bitcoin or aetherium but there are also other types of dates and they're different distributed lashes order and we'll have another slider a bit later about different types dates but it's it's important to know that there's not one database we're not one blockchain small it's registered but they're all these different methods and the individual did methods specify how exactly did is created and updated and resolved and also deactivated within a particular system and and as long as as a deep method fulfills some basic requirements which are which are outlined in the w3c deed specification so that there's a list of requirements for forged methods but as long as these requirements are fulfilled and the four core properties that we have we talked about then then you can ever did method right the identifiers are persistent and resolvable and cryptographically verifiable and decentralized and they can be and they support the basic operations like creation and resolution then there are different so-called deed methods the that enable this and here's just some examples but by now I think we have an informal registry of about or de different dig methods yeah just some examples one thing you can see here is that that the syntax it always starts with deep : right this is a basic syntax that all your eyes all types of your eyes share not just it oh yeah I start with start with the scheme identifier on the column that's the bid then then we have this method name again that's that defines how exactly that it works how it is created and solved and after that comes what we call the method specific identifier and as you can see in these examples that can be very different depending on what it did method is a appropriate date method we will specify the syntax and the functionality this pieces type of data and sometimes this is in the case of some of the etherium based deeds these are addresses of smart contracts on a theorem but in some other cases that they identify is a hash of a public key or an identifier of a specific transaction or random number it could be different for each method as long as the core properties in the quarter now functions can be can be provided by them very good method and okay these resolutions we talked about that already is one of the four properties of deeds that you can resolve them with the document that's what what URLs essentially mean to be able to resolve the identifier in this case to twit the document again one thing that's always important to mention here is that the resolution is it's not a single protocol right so if you think about DNS resolution and that's a very specific concrete client-server protocol if you want to resolve it on main name to an IP address and you have a DNS client which talks to her in a server and then it just executes that standard protocol to resolve that domain name did resolution is is different precisely because we have all these different big methods so it's more helpful to think of the resolution as an as an abstract function or an or an algorithm with certain inputs and outputs the input is the deed plus some optional parameters and the output is the is a big document and again how exactly that that works under the hood that depends on the deed method there there even did methods where resolution doesn't doesn't require any network interaction at all and then there are deed methods where a resolution requires communication with with the blockchain the teachers is essentially an abstraction layer on top of these different methods what you see in the okay go go back just one second what you see in this diagram is just one example scenario where the resolution is is needed and in the book there are actually several more diagrams and we envision that there will be many many use cases where the resolution will will just happen on automatically or in there in a way that end-users will will never notice it will just be a very ubiquitous function in necessary systems just like today in this resolution happens all the time is just in in this diagram that's the specific example where a verifier wants to check the integrity of a of a verifiable credential so you can see a very basic example of a verifiable credential which consists of an issue then claims claims about a subject and then a proof and so when when the verifier receives this and they want to check the integrity they want to check that it was indeed issued by by the trustee issued and then that's what did resolution would would happen because you you know who the issuer is but in order to verify their to prove to verify that the credential is it's correct and has not been tampered with you need to find out what's the public key of the issue and that's what you do with resolution so you look up you resolve the issue did you get the date document would you find the public key and then you can verify there thank a grotty of them after the document but again this is just one example of many where the resolution will happen other other examples include the authentication protocols such as did all visible time for many bit based authentication protocols that are the development so again we we think it will be very ubiquitous function in SSI systems or where these will essentially be resolved all the time okay going to this slide this takes us back a little bit to fundamental web architecture where I remember we said that these are our type of your ID or a little bit like like your wrens also because they're persistent there are also URLs because they can be resolved and and you referenced but here's something else that we can we can do we can add some of the familiar some tactical URL components that we know from HTTP based web addresses we can also use them together with with dates and by that I mean at the path and the query and the fragment you know it won't be when we access resources on the web today with with web browsers and we navigate through web pages and so on them but we're not just working with domain names right we're not just using the main names but we're using these HTTP URLs which which start or which in the beginning they have a domain name but then they they can also have passed in the query the fragment component to identify other resources under the under the authority that's represented medical main name and in the the date specification we have a and an equivalent mechanism or pattern which we call did your ends and and the URLs are are essentially the deed plus other components like like a path and a query in the fragment so a deed is not just an identifier by itself but it can also be the route for for an entire namespace or identifier space to identify anything underneath beneath that did itself in this example you actually also see see another tactical component in the in the middle we see there's a semicolon so this is something that but we don't have typically in the traditional http-based URLs but it's it's an additional some technical component called the deed parameter or or matrix parameter that we think is is useful especially in in conjunction with with dates and that's a mechanism essentially to pass parameters as as part of the URL that influence the real resolution mechanism audit that gives you more control over how beads are resolved and how did your ends are Rd referenced and here's some here's some more examples again we think there will be many uses for for teeth your ends just like and we cannot predict all of them right so that the deed specification will not actually specify home what kinds of identifiers we will see in the future what kind of path or a query or fragment components we will have in the in the TD or else that will be up to so application and service developers just like just like the HTTP specification does not tell you what to do with those with those URLs maybe just to just to go over some of the examples or try to understand what what they mean the first example is just the deed with with the slash so that's a deed URL that identifies the document itself that's very simple when the second one is interesting that one is the is the deed with a fragment so them the fragment is should be quite familiar also from HTTP and tradition when web where what a fragment identifier is is used to point to a specific part of a webpage right you if you click on a non HTTP link with with a fragment that it will jump to a specific point in that web page and and we can use a similar mechanism to identify a specific part of a document so if we want to write create applications or services that don't just need to know the date by itself but they need to work they need to reference a specific key inside the bit document then then they can they can use this disk fragments index maybe just quickly the third the third example that's here again there's the semicolon syntax that's one of these deep parameters or matrix parameters there will also be different ones and and here's just one example that that would give you some control over how the deed is resolved and in this case it indicates a specific version of it a document so the documents can be updated they can they can change over time and sometimes it may be may be helpful to have an identifier for an earlier version of the document if you don't if you don't want to know what are the current services or the current public keys associated with the date but you want to reference the keys associated with a date at a particular point in time that's also something you can do with this TT or else index and and again we think in the future that we will find many more patterns for this kind of very flexible identification mechanism okay so in the in the book chapter of course we we also thought quite a bit about how deeds relate to other kinds of identifiers we already talked a little bit about domain names and and DNS and so on so we have an explicit comparison the chapter how how deeds relate to to the main names there are some similarities they are there both globally unique they're both with all the blue but there are so many differences right so deeds are are by design persistent there are some main names or reassign every word if I don't pay for my domain name I forget to renew it and maybe we assign something else and use for other applications for other not identification they're both resolvable but the resolution works differently like we said the main names they have a standard find several product orders with deeds resolution is dependent on the undertake method and of course the most most important difference kind of the last three rows in this in this table deeds are completely decentralized they are perfectly verifiable so they have these properties that we need for ourselves our own identity they are not dependent on a central or or hierarchical registry and no one can really take a deed away from me whereas a domain name can you can theoretically be deleted or so we mentioned we also mentioned your ends as a class or a subtype of your eyes and in the beginning your ends that are persistent and and deeds are certainly not the first type of identifiers that provides this property of being persistent of not changing in fact there and entire communities there is even a dedicated conference that deals just with persistent identifiers and different types and here's a diagram of some of these types of of persistent identifiers and one thing to point out here is deeds are the only ones that are completely decentralized and cryptographically verified with all the other ones that are in well that's not that's not true not all the other ones but most of the other ones depend on some some kind of registry Authority some kind of hierarchical or centralized mechanism where they where they are governed and and registered the the ones on this on this diagram at least the ones that are really fully decentralized and don't need a central registry are feeds and then you you IDs and and nicknames on the bottom but those are not resolvable right so these ability the only ones that are resolvable and decentralized and persistent and graphically verifiable and then so we we mentioned before the concept of tip methods that there is not just one type of date not just one one mechanism for waiting and resolving deeds but we have all these different mechanisms different tip feed methods again I think about 40 known ones by now has anyone anyone think rate and you did method it was divider specification land and over time we we observed that some common patterns or some common shared features of our aspects of did methods this is not a normative list this is not something that's mandated by the deed specification it doesn't say that they'd have to fall into one of these categories but it's again it's just some common common tendencies that that we are seeing so in the in the beginning we had kids that are based on block chains like Bitcoin or II the etherium the the idea was basically that if you want if you want to have a decentralized identified and we need to register it in a decentralized system right instead of registering it's in in the centralized hierarchical domain name system instead of that we registered identifiers in a in a blockchain in the init ELT so that was the first category and it's still very much in use right now the second category here where it says ledger middleware that's that similar so those are types of teats that could still use block chains but they add an additional layer so they add an additional storage mechanism that's cheaper and more efficient than a blockchain could be a distributed hash table or some some classic replicated database and the idea is you can you can write large numbers of updates into that second layer storage mechanism like a database you could write you can create or update a thousand dates in that second layer system but you only need a single transaction written to the to the blockchain and therefore to anchor those those thousands of off second layer transaction that's not that makes anything more scalable and efficient them cheaper the third one here pier deeds that's that's especially interesting those are deeds that are not globally resolvable so remember we said all dates have to be resolvable but we didn't say that all these have to be globally we saw over those there's also a class or it's known as periods that exists not on there on the global source of truth or not in a blockchain that everyone can can see but they exist in the context of a relationship between two or more in a limited number of participants and those days are exchanged and maintained using certain protocols agent agent protocols and and those are still valid dates because they still fill all the the core properties and provide the functionality it's must provide but they are just not registered on a block changer did exchange between participants relationship the fourth one static deeds we saw that we began seeing those about a year ago those are very very simple very constrained deeds that actually don't support all the basic functions those deeds can be created and resolved but they cannot be updated and and deactivated and also basically just simply public keys that are wrapped into the deed format so you can you can do that you could just generate a cryptographic key pair using any one of the after the graphic key algorithms and and could consider the key the public key you could consider that also a type of kid because it is decentralized it is it is persistent you can construct the trivial the document from it and you cannot update it you cannot deactivate it but still it's still aligned with with the intentions of what deeds are for so some people also call those those identifiers crypto names or self-certifying identifiers what the identifiers is essentially the public key itself and then final category that we've listed here alternative deeds so we we see a lot of innovation and a lot of new ideas of what deeds can look like as long as there's a well-defined syntax that that fits in with it with it the date format and as long as resolution and creation of the deeds is sufficiently specified you can you can create a date method so we see we see did methods for example based on IP FS addresses or date methods based on git commit hashes and and many other things and those are those can also be it so that shows the flexibility really of the of how deeds are are a concept with certain guarantees and certain properties these are not based on a single registry or single there you go thank you very much Marcus that's a pretty exhaustive functional description of dids and now we're gonna go down the next level to the architectural reasons why did work and this part of the chapter was a lot of fun to work on because after after about four years of working on D IDs and seeing how how broad the concept had become III person was very interested in really diving down to going what is the core core innovation here and this is another quote directly from the chapter that puts that puts it this way so so what we posit is that what did do is they really address a very core problem with PKI public key infrastructure that's been there from the outset and it's not a problem with cryptography right with the math involved with public private keys or decryption and the encryption it's a problem with the infrastructure you need to actually make it useful on very broad scale and make it easy and safe for people on organizations to use so in this section we're going to actually walk through a slide presentation I created in order to build a narrative for this chapter and all these diagrams appear in the chapter this is just a much condensed version of explaining of explaining this and this is the first time actually I prepared this but only to write it in the book I've only shown it to a couple people so its first time it's been shown publicly so let's just step through it here all right so we start out with the problem the problem again is the very nature of how public and private keys work and I call this the PKI trust triangle because basically all it doesn't matter what the algorithm is what the cryptographic algorithm is behind it whether it's RSA or elliptic curve or you know all the way up into quantum there's there's fundamentally it always comes down to there's a cryptographic binding between a private key and a public key and they have those names because the whole point the private key is that's what the controller controls in order to exert control and then improve things on the basis of this relationship and the other half must be shared it doesn't necessarily have to be shared publicly with the world but it's called a public key because it must be shared with whoever you wish to have to make proof with to have a secure relationship with so this this very basic trust triangle as a core problem spot it's right there it's how do you connect the controller with the public key specifically how do you strongly bind it so that the relying parties know that they're dealing with that controller when they are you know verifying a proof or or decrypting a communication now this half of that relationship is not the problem the public key itself is just a string of bits you either have it or you don't it either works or it doesn't so that's not the problem the problem is this other half of that relationship the controller and the problem is fundamentally controllers are not digital entities they're not a nice convenient string of bits that you can just verify they are these squishy things of people and organizations that need to be identified so they need some kind of digital identifier to be captured in this in this milieu and that means that the real PKI trust triangle looks like this it's got this fourth element and and and and what we what we need to relate is the identifier the private game public key all of them to the controller okay so when you see this and you see okay it's actually these four things you can see the problem actually has two parts part one is binding the digital identifier to the controller that's the problem spot number one and part two is you still have to strongly bind the identifier to the public key and that's that second part right there so PKI has shown that both parts of this are hard and and we're going to we're now going to go through the solution that is PKI as we know a conventional public key infrastructure so first part of the problem how do we bind the digital identifier to the controller regardless of what that controller is how do we do that binding well we need an identifier but you know what there is no existing identifier that works particularly well for this class this table caps basically the options were available when x.509 digital certs were being created and they settled on basically these two either a URL or x500 distinguished name in the you know global directory system that is the ex 500 that should say x.509 search down the corner right that's a type of there so anyway those were the two that were were settled on but neither one is perfect but in any case once we have that identifier now how do you strongly bind to the public key well the context of you know public key cryptography well you do it with a digital signature but the challenges whose signature if you just rely on the controller signature then the controller combined their public key and identifier they wanted so who do you trust for that well the answer under conventional PKI is a trusted third party someone who can be trusted to digitally sign that binding between the public key and the ID and that's where we got the role the certificate authority or CAS as they're known that's what they do they come in and they create that red square there which is the the essence of a public key certificate I also got a digital certificate and and they sign it with their own private key and others can verify that that identifier is really bound to that public key so the challenge is there are a bunch of problems with the solution so first of all it does depend on people and people fallible it adds constant friction to every relationship where you need to verify you need to verify will fall by key as we pointed out throughout this it's centralized and that stands for single point of failure which is an issue with security and distributed systems and lastly of course identifiers can change and every time it afire changes you have to redo the whole thing and reissue new public key certificates which actually Keys can change and you have to redo the public key certificate every time keys change as well so all of these issues up to let's see if there's a better solution so part three we're going to talk about a different solution the PKI called self-certifying identifies i want to credit Sam dr. Sam Smith introduced me to that term and it's it's really actually at its core a very very simple idea it's the approaches is doing the binding entirely with cryptography and it works like this if you have a self-certifying identifier you have the same trust triangle only the identifier is actually generated from the public private key process now there are various ways things can work this can work again it's like did methods there's not one way to do it but the bottom line is the identifier is generated on the basis of this and the controller publishes it just like the controller publishes the public key now if we look at this it actually solves both of those core problems for which we invented PKI first the binding of the public key identifier as long as you trust the math it's as strong as the binding of the public heat of the private key and every did method has to show that it's got a way of doing this of showing that that control over the public private key pair equals control over the identifier and then it solves the other problem because binding the identifier the controller works the same when the private key does the the controller is the only one who can generate and publish that public key so as long as they control that private key they can show they can prove control of that identifier so we managed to solve both of those problems the only part of the problem we haven't done solved here is key rotation and recovery and that's why the solution using self-certified identifiers that are public keys this is the limitation they've run into every time we rotate your key you'd have to change your identifier so what happens if you change your keys well that leads us to the dead solution hi so deads and the documents can solve that key rotation problem for self-certifying identifiers so and stepping through it's not complicated first the did controller creates the keeper and the did so we're saying now the self-certifying identifier up here is Adib it has all the properties that Marcus is just finished talking through in detail now that's public/private key pair number one that's your crazy original D ID now what the did controller does is publish original did document containing those that's what this looks like if you look at a dead document its essence from PGI standpoint associates that did is the identifier with that public and again this is did document number one now we're gonna rotate the keys and when it happens that means the controller publishes a new deed document signs it with the original private key and there you have it it is now a new public key signed by the previous public key so you have what is the equivalent of a digital certificate only it's published directly by the controller so it forms a chain of trust across all the did documents all the the key rotations that may take place they can be traced back to the original self certifying identifier essentially you've created digital certificates that are decentralized because they don't require any certificate or other trusted third party they just need a way to get access to that chain of documents that go back to the original self certify identifier to verify it and of course block chains and other mechanisms can be very very handy for that but they're not the only ones all those different types of D ID methods that Marcus talked about except for the static ones can work for this it doesn't require a block J and if your did method can do this just through a series of updates direct them between two peers so it turns out I'll finish up here with there are two other nice benefits of this D ID solution okay neither of which is addressed by conventional PKI the first one is it actually provides a great way to identify something besides the did subject this is why I brought this up early in our presentation here you can now turn around and with this exact setup you can turn around and say the controller creates the key pair crates that did but uses it to identify something else in this particular example one of those common things that comes up is how do you establish a D ID for a newborn newborns obviously not in position to be the controller but the controller presumably one of the parents or a guardian is able to generate the dead identifying the newborn publish that did and maintain this and even do key rotations and everything else until that no born is in a position to take over a control of that and it's actually pretty clear from this how would it do that at that point the the child let's say the agent reached the age of maturity they would generate their own key pair talk to the controller as in you know the Guardian relationship and say here is the new public key that I want you to publish in added document and when the controller does that transfer of control has taken place over to that now grown a young woman or young man so haha again this pattern now can be used for anything any you know person organization thing abstract concept a data structure whatever it is it might need to be identified by I did every control in the world can identify and and and create a cryptographically provable identifier a persistent identifier for whatever it is they want to identify first one go ahead just a small question because I think it's good to bring it up now maybe yeah I'm from Francis he's asking when you do the when you did the rotation example right now then if there's a problem with the previous private key how would you sign a CA or a new pair of keys or a new pair of key to form the previous one if you don't trust it anymore I I love that question it means someone's really paying close attention I don't have a diagram for that but the best answer that I've seen out there and I've been at this a couple years is I call it the the backup key approach it's I actually spent a good hour talking with dr. Sam Smith at the did working group meeting about this last week the the approaches you actually add inception or very quickly you create a cryptographic commitment to the next public/private key pair that you're going to be using and you publish that and you're basically protecting one or a string of other keys that you do not sure you do not expose unless there's been some kind of a compromise and I think you know we started down that path and what's called DKMS design an architecture document you can just google that term DKMS design and architecture at hyper ledger and and find the 70 page document we published on that and we had the notion of that but not the depth that Sam Smith has taken that with what's called carry architecture keer I and just google his name and Karie and you'll get his papers on that Sam's gonna be collaborating with us on the decentralized key management portion of the book and there'll be a lot more detail about how to do those cryptographic commitments to protect basically forward-looking protection on your private keys so it's great question glad I came up are there any others in the queue Alex yeah just just two more like in Francis is also also asking is this coming from the seat and then Michelle he's following up with another question so if you lose that key how do you recover that key so the answer is yes this is coming from initial seed and the second one I want to actually plan to work with Sam to to develop a series of diagrams like this cover the cryptographic commitment approach to protecting those backup so I'm not gonna try and just walk through it right here I think when when we do the probably multiple webinars on the decentralized key management portion of the book we'll cover that so I beg for a little patience on that one because it's it obviously gets fairly complex these are the simplest diagrams I was managing to get the main problem out any other questions in the queue that's it okay all right so anyway this is the first of the additional benefits the other one is oh yeah I point out here it's not just guardianship we talked about but anything that needs to be controlled it's not a person so directorship of organization or what we call controller ship of things they all involve that same pattern so the other benefit is discovering how to interact with the dead subject so it's not just in many cases you don't just need another public key you need to know where and how you can interact in a term that's broadly an SSI being called agents are some cases if it's directly with the data involved with subject might be a Hopf but what you need is URL what we Marx referred to needed document is a service endpoint and as you can see here if you just include that and the document that is signed or otherwise verifiable as being controlled by the control then you know you've got a an interaction point at which you can you can interact and one thing I like to point out is even if you don't trust the did document itself but you have the public key you can challenge the did controller and receive an authentication by whatever that service might be to be sure that you're actually you know dealing with the verifiable controller so I think it's a it's a very it's very powerful pattern and and it's a whole adds the whole discovery dimension to make this decentralized public key infrastructure interactive ah and that's the end of that we have just a couple slides left to go down to the semantic level because we knew that we'd be going over time if we go deep into that we have to hold back a little bit to to entice you to read the chapter but I think what I'll do is are go ahead and finish this and then we'll take any of the questions we have so when we go all the way down we're looking at so what does what did the IDS really mean and that's a that's a very broad question both you know semantically and for the growth of the web but one thing that we thought was fascinating was to put them in the context of the evolution of all types of addresses that we have been using um and I've been meaning to put together a table like this for for a while and I just I just love doing it because it's just it's fast and look at how we have evolved I'm not saying every address we've ever come up with is on this but as a general progression uh Marcus I know when you what was your reaction when you first saw this table you I don't remember what my first reaction was I don't know I didn't the only thing but what I said in the beginning is that we realized early on that we want to build SSI and we system we need to start with the identifiers because to be sure to one another and to have addresses in order to do connections and relationships and anything at all so that's why we believe and you identify I'm not just a new type of protocol a new type of photography yeah yeah it says one of the things that fascinated me was basically the increasing pace of new addresses that evolved as we evolved digital infrastructure right I mean going from a telephone number credit cards and and and and fax numbers and then things really started to speed up but the other point we make in this section is to talk about the evolution new address isn't because somebody needed a new way to necessarily identify something it's because there's a new type of network that needs that address and that's why we've listed each type of network we talked about here or the capability that's needed on that network with the web needed both machine friendly addresses for versus connections like your ends and human friendly addresses for URLs so if you apply that question to D IDs the the real answer comes down to they enable the new kind of network they enable or trust networks and it's where all the relationships can be trusted not just specific oh I need to have a SSL certificate for my website so that people can trust buying something from me in it did network where all the actors be they people or organizations or things or identify with dids you could have trusted relationships of whatever dimension of trust you want everywhere the entire thing is cryptographically trusted but not necessarily just cryptographically so the way we put it this way the new type of communications network functionality here is is did enable both cryptographic trust and then human trust to be layered over that and in the book you know and if you've heard you've listened to earlier webinars on us as I meet up you know that that's the mechanism we call the trust over IP stack and and it looks you know in its full what will do more webinars for other chapters and talk about this in detail but but the technical half of the stack is here the government is half of the stack up so you can see the dudes are the very very you know Bates base layer these these public did registries and we've been talking about pairwise dudes or static dudes are used inherently later to those enable the human trust triangle of verifiable credentials layer three and that it later for governance authorities and governance frameworks will have D IDs and and these different roles we show over here as this trust RP governance TAC evolves every one of those roles well the the the participant playing that role will have a D ID and they will have a verifiable credential that includes that D ID that that asserts their role in a particular governance framework so you'll have a common way of describing no matter what your governance framework is and what your trust network tackles there's a common way to describe it a common way to identify all the actors common way to establish cryptographic trust and then layer on the the human trust a verifiable credentials so that's really when it gets down to the semantic layer what a di D is about is a way of establishing digital trust everywhere and we say everywhere we mean everything that we deal with on the internet everything on the web and things that haven't been invented yet and that's that's as far as we're going to go here there's again a few more fine points in that section at the end but I think we've we've used up our our time here to acquaint with the chapter so questions yeah I mean we have one comment and I might everyone to share the questions now from from from Alan he's saying you missed our GPS coordinates and that's in the page where you had email URL etc so he's suggesting to add that maybe we can update that it's a great suggestion that's I we forgot to mention that because you know the book is still in progress yet please any suggestions gladly we will add GPS coordinates that's perfu cool yeah which is true actually and this chapter can be read online and you can give feedback to the chapter so if you get it online then please give feedback yes that would be awesome and then Francis is saying thanks I get it it is what I thought but there's still an issue with that for scaling and integrating that to full size organization example when you have employees from a government that can produce well our data we need to track this chain of keys if possible I would be interested in connecting with Drummond so he's sharing his email you know all and I'll send it to you via slack ramen that's maybe you want to comment Oh III I strongly agree the the mechanisms for decentralized key management when it comes to organizations and delegation is a wonderfully rich topic I think we're still in the early days and the the underlying primitives that we've covered in in that section I think they they all apply but once the controller is no longer the I'll back up to that as I as we as we talk to it here once the controller is not I'll go to this slide right here what's the controller is not the subject and what you're identifying is for instance organization then the way you set up key management for that organization and for employees and and and and operating units within that organization and even smart contracts that they may be operating is that's the essence of what this new decentralized cryptographic infrastructure we'll look like and I don't as much as we might sort of have got down to the DNA of di DS here I don't want to pretend that we've got all the answers for how this will work we're still at the earliest stages of you know it actually established this operational infrastructure I mean on the on the private key side of things I think there's a lot of innovation that has happened in the in the cryptocurrency space and identities of course something else but probably some lessons to be learned in terms of wallet security and cold storage and air-gapped wallets and politics and some of these things that the cryptocurrency community had had been been working on when it comes to seeds and derived keys and and all of that yeah I think a lot of lot of these concepts would be yeah could be valuable yeah absolutely actually it's one of the things we want to encourage because I think the connection between the cryptocurrency blockchain space and and and as it's high communities and still not as strong as it should be and I think there's a lot of overlap especially when we talk about questions like DKMS and stuff like that and but in reality also many other things for the decentralized economy they want to create so if there no other questions Drummond what I would suggest if you can go to the last slide I have you one more question just came up here from our two more questions came up okay and so doesn't being decentralized semantically depend on a specific resolver method [Music] I'm not sure if it depends necessarily on a specific resolver Noel there's the larger question I sort of hear two questions there is any particular resume when you say resolver method I'm I'm understanding di D method because that's what specifies how it's resolved di D methods themselves have different levels of decentralization in our earlier webinar today we talked about a deliverable of the w3c di D working group is a document called the decentralization rubric which is a whole series of tasks or methods of evaluating how decentralized a particular did method may be according to your criteria of what's important and it's a deep broad topic and I'm certain that there'll be a hopefully a SSI amitabh webinar on that topic once that billable is ready so there's how decentralized is that method and then there's a question of with over 40 methods out there how decentralized is the entire infrastructure and I'm growing increasingly confident that the variety of did methods out there and the variety of block chains or distributed Ledger's or or distributed file systems and other backends that they're being developed for we're going to have a very you know it's like decentralization squared we're gonna have a whole lot of options and they'll be you know competing in a good way you know a survival of fittest for what is most decentralized and you know fit for purpose and Marcus any thoughts on that yeah I agree there are many different types of decentralization obviously the different you can argue whether Bitcoin or sovereign or aetherium or any of these state methods is in itself decentralized that's what this decentralization rubric is is for to try to answer questions related to the centralization about specific did methods but then as you said it method mechanism itself is a form of decentralization because you should be able to you to replace one did method with with another and since it's all if they're all standards compliant everything on top of that the whole stack should still work so you should have some choice there and then there is decentralization of the resolver infrastructure there's this intimation of of agents and and hubs and some of these higher-level components if if we if you register if we have the perfect perfectly decentralized did method but then everybody is hosting their each and with a single provided and again there's a there's a weakness great and then Paulo he's asking a popular question and so he's asking the cryptographic mechanisms that are being considered are the future are they future proof or a quantum proof what can you tell us about this it is a it's a great question it's a common question in fact it's coming up more and more and I I don't blame it there was actually a good discussion of that not in the main line but in one of the breakouts during the did working group meeting in Amsterdam last week I the short answer is in that same vein that we talked about earlier in terms of how you structure the did document and the you know the keys you can put in there one suggestion has been what people call the quantum emergency key which is your publishing a even though it's not attended for use until you you know the quantum emergency happens that you you do publish a key that for which you have you know you keep the private key safe that is quantum proof and obviously it's big and long and we'll take a more more storage space but it's not it's not intended for use until you get to that point at which point you you rotate over to using that and then I've heard of a couple other approaches that are you know coming from experts far far deeper I'm I'm not only not a cryptography expert on nobody's quantum expert so it is but it's very actively being discussed because you know it's it's I think it's as big an issue for decentralized PKI as it is for centralized PKI because you know the attack surface is every place you have a dead document so that but that's that's all I can say on that Marcus you have anything you want to add to that I'm definitely not an expert on that the only thing I comes to mind is that the document concept is is extensible right so just because the current public key algorithms that are being in that are being used if they are not secure anymore and others can be added and that the document can it can be extended actually not just to support different key types in the future but to support different so-called verification mechanisms right so strictly speaking in the entity document public keys are just the type of verification mechanism mechanism or how the controller can prove that they control a certain date but even even that is extensible so perhaps in the future there will be verification mechanisms ways to prove control that are not even key based right a traditional based on traditional asymmetric cryptography so yeah we'd have to work on that and see what is secure and what is not what we don't have we will not have to reinvent did stem service man and we talked on this morning's webinar which about a key mechanism that the did working group has or agreed on last week which is a registry of extensions that will be specifying the did course back and and most likely run by w3c as they move into starting the host registries for different specifications and the nice thing about that is is it's a widely shareable mechanism for publishing extensions such as new cryptographic algorithms or verification methods as Marcus said so as good solutions are developed for quantum proof quantum proofing your dead documents they can be registered there and it just makes it that much easier for them to spread throughout di D infrastructure and and you know get the best of as Marcus said staying it's the we can't design all future proofing in there but we've designed it to be extensible so that it can continue to evolve you excellent yeah I mean I would just add to that I mean like in the in the Bitcoin crypto space it has been an argument for a very long time that what happens when quantum cryptography comes up in computers and everything and and I think like I mean obviously for identity is much more important than for cryptocurrency because I mean if people can see your your identity that's a big deal but at the same time like as quantum computing emerges they're just quantum congress reemerging and there will be changes being made and I think as Raman and Mark is highlighted and it is being made extensible so that these networks can be adapted to those changes I think there are no other questions so as we said this is just an insider presentation about what's upcoming in this chapter about the IDs we will be doing many more about like these and and the for the other chapters that we will be will be working around that will be published just summer you can read this chapter already right now and we would be really happy about any feedback on this as the GPS recommendation that was just made right now and yeah please please have a look with the upcoming webinars we have our 25th of February we have Timberman we'll be talking about money and identity that we have isatis which is a startup in the SSI space from Germany out of 27 on the 28th we have john phillips from australia who will be sharing a very nice method about how to explain to to people that don't know anything about SI about how i work somewhere it's important and this is the stuff we have upcoming many other things also coming up for March and April and if you want to join any of these please join our Telegraph channel you have it on the website of SS I'm a dork you can on the photo on the bottom right you can see the links to Twitter telegram Facebook okay Lincoln and all those channels where we distribute and inform everyone and you can also sign up to the newsletter where we sent out an email every time there's a new upcoming webinar and thank you so much Drummond and Marcus for making time and and and sharing all this with us first in the DAT Working Group webinar we did couple of hours ago and now for this and any final class that you would like to share I not from my part it's I feel did it out for the for the day I hope I just think it's it's we've got as deep into the content and as current is in the earlier one as we can so I look forward to feedback and and helping it improve the chapter and then doing many more of these I think they're literally going to be you know two dozen chapters that are worthy of SSI meet up webinar so thank you Alex yeah thank you thank you my Zetas as well I don't have much great just really nice to be part of this and to be contributing to this very important poke lane I think it's it's great that this is happening yeah wonderful we also people are saying thank you here in the in the questions channel so Michele thank you and they say great job for Michele big thanks to Drummond and Marcus from Pahlavi on and then Nabil he's finally asking can you please add a chapter for using D IDs in IOT I mean maybe you want to comment on that Marcus and Robin but just to say to you that we have a specific chapter we will talk about the use cases of IOT and SSI and maybe how much you want to add anything else Omar Kearse I think that chapter will definitely go you know deep into how DoD's will be used with Si and appoint folks I believe it's in the first the first time webinars that when you did with Myrtle from why is it running up my head but he did a wonderful webinar with you Alex on the ids and IOT yeah I'm just searching for that just give me one leg Arkham is the name of the company oh yeah exactly welcome yeah yeah so yeah but definitely check out that webinar he gave a great great sort of tutorial on on his thinking about the IDS for for IOT yeah if you search for IOT SSI Meetup aw c'mon we know that's his name and you can find you can check out the video and recording with it at a time for that yeah great and I think we covered all the questions all the comments and thank you so much Marcos thank you so much Drummond thank you everyone who joined us today and please check out our telegram Channel and all the other social media channels and check out the book if you have time and interest that would be great we look forward 20 feedback and we will be doing many more of these and or what we hope will be like a really high level but also deep level introduction book to the big world of a society that will be really hopefully I think every shaping the internet thank you so much everyone thank you