Understanding and Using Verifiable Credentials

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments
Captions
hey everyone in this video I want to talk about a verifiable credentials the ability that I can maintain control of various identifiers that represent me or some other entity in the real world but still have them trusted by relying parties that I want to present them to if I think about me as a human being my human identity so I have me I have John what is my identity in the real world is it things I say about myself well the reality is things I just say about myself some receiver of those things um who cares I could be making things up they're not going to trust the things that I just say about myself I could be a mad person people would probably assert that I am doesn't matter what we say about ourselves in most circumstances now sometimes we can hey what's your shoe size fine people will take that it doesn't matter but the things that really are important really our identity in the real world is the sum of what trusted or the majority will attest about me I could think about saying well okay my citizenship people don't care what I say people would care about some institution that institutions have columns always some institution would create some credential for me hey a driving license that give me this driving license that they have created with various claims about me my name my date of birth whatever they issue this to me I store it I have a wallet hey I have a wallet and governments would issue me a certain credential and it has claims about me in that credential and when I give it to someone they can verify it's authentic they have Holograms and watermarks and all different things in those that I could then put in my wallet and I could then use this to go to another company Say Hey I want to get a job so they check my driving license and then they give me a credential from them and I can get these whole sets of different credentials including a Blockbuster video card which is super useful but I get these verifiable credentials of the real world that I can put in my wallet and I can present to people and I can give it to this person they do not have to directly communicate to the government there's no direct communication required because this credential it is able to be proved because those Holograms because of those artifacts of the actual credential so it could be hey John is a certain citizen of a country John works for certain company John eats a lot of pizza um the pizza restaurant would attest to that so it has a YouTube channel with over a hundred thousand subscribers these are all artifacts that help me prove things to others without the person I'm trying to prove it to the verifier of this proof having to have a direct relationship with that issuing party and again all those different credentials fit in my wallet they adhere to a certain standard I could have any wallet I want this one just happens to be a Minecraft wallet it doesn't matter they have a certain they follow a certain set of standards for the credentials of the real world I could put in there and even if the government was shut down this still works I can still give it to people and it would be trusted and usable so there's a certain isolation protection once I've been given that I can carry on using it now to think about my digital life so my digital self okay so now we'll have a digital John do I have my own identity in the real world well no I really don't what happens here is in the virtual world there are various identity providers now this could be a Google it could be a Facebook it could be a Microsoft there are many of these organizations out there and in some way I'm able to prove to them hey I'm I own this identity they essentially are leasing to me it's not really mine in a lot of ways they could absolutely go and give it to someone else so they hold a digital identity and I have to go and prove hey yes here's my username Maybe here's my password maybe I'm using MFA whatever that is to be able to then go and use their identity phone number it's not really mine it's a telephone company it says an area code they have it a website there's a central Authority that give out the domain names but there's ways to go and challenge that and so I have many different accounts I have a work account I have social accounts um there are bank accounts I have educational institutions so what I do is for these various identity providers I might use there are apps out there that I can tie that Federate to particular identity providers now I may have different islands of security world for example I might have a work Persona that my work apps tie to that certain identity but then I might use a completely different identity provider for apps that may be more social that are more personal in nature so it could absolutely end up with these different identity providers but all of those they really own that identity and you see this all the time now if I go to almost any site so I'm just going to pick a sales site over here oh it's offering me good sales I'm not interested in this but if I was to say hey I want to sign in and I don't have an account notice we have this option I could create a local account or hey look do you want to sign in with one of these identity providers over here it's a very common thing we see all of the time and so what those are really doing is they're federating to those particular identity providers so over time more and more of the applications are used the data I have is tied to some identity that's centralized we have these Central identity providers they are holding and really own that identity where a best case leasing it from them so we're making a trust decision in those identity providers that they're going to do their due diligence they're going to make sure it really is me but there's challenges with that I am trusting them this IDP really has all of the control I don't really have control of these identities so the IDP has control of what I consider my identity I could lose the identity foreign terms of use they may go out of business now the big identity providers that's very very unlikely but I could happen I could lose that identity so this identity I have well it's not portable it's really tied to that particular identity provider and as I add more and more apps to be trusting well one of the things I'm going to be concerned about is data breaches foreign happens now everything that I tie to this identity could be exposed my privacy if I use this one identity over many sites can they start to track and correlate what's happening and do I really have well data shared how do I have confidence but they're not over sharing I give some app access to some particular aspect of my digital identity do I trust that do I trust the Google or Facebook or Microsoft isn't maybe over sharing or has some problem or it's over sharing my data maybe even these relying parties if I keep using the same identity could start to correlate and work things about so really there's a lot of risk with this I've seen the net with Sandra Bullock um they deleted all of identities she ceased to exist even in the real world pretty much so there's challenges with this Central approach I do not really have fine-grained control of what people want to see and think about who's really in the center of this picture you've got the various apps there's me but it's the identity provider they are at the center of this all up picture and that's really not what I want if I think about this is my digital self and as we think more and more important about those digital identifiers that represent entities in the real world I want to be in control of that I do not want all of these concerns so if I could start fresh what would the solution be well the ultimate solution would be me as John I would actually be my own identity provider the identity provider of now I'm saying John But realize this could also be organizations when we talk about these concerns about the identity it's not just human beings have that concern it could be entire organizations it could be I want some identifier for my dog it could be an identifier for a building it might be an identifier for a child who's not yet able to self govern self-control and identity for them but I would want this ability ideally that I am my own identity provider I create my own identifier and I'm in control of it that's that's all nice and ideal except we come back to that same problem as the real world identity real world identity hey I can make claims about who I am they don't care self-attestation is generally not that useful for many things so absolutely hey I'm My Own identity provider I could make up some Claim about myself some digital claim and I could do some self attestation but most of the time that person I'm sending to it that organization that I'm sending it to we call this a relying party or in this case they're going to verify that attestation I'm doing do they care about a self attestation they they really don't what they really want more the idea is someone else who's more trusted will issue some kind of verifiable identifier some verifiable credential for me that they would trust just like I was given a driving license but I want it decentralized that's really one of the key points about this so instead of having this idea of hey I just create all my own things what I really want ideally is for some other party again if we think about this idea of what we had in the real world but some other trusted party some issuer would be able to populate something with claims about me give it to me and I would store it I would store it in this whole same idea of a digital wallet so it conforms to certain standards and then I could present this to them and there would be some way they can verify without having to have a direct relationship to say oh actually yeah this is good I'm gonna trust this I'm gonna enable this to work now when I think about this type of verifiable credential think about the part is involved in this the issuer well this company still has the right to issue it they have the risk because they're making claims about you so they want to be confident about that what I disclose though so the claims in this what I disclose and who I disclose to that should be my decision so the issuer hey they make the claims about me and give me and that's the key Point me the subject or at least the controller of that identifier it goes to me and then I have the control of who I deem I want to present that to now there's even things around the idea that maybe it's selective disclosure I don't want to give the whole set of claims to someone maybe just want one claim out of that or maybe it's zero proof so I have zero knowledge proof I want to be able to attest to this party hey I'm over 21. but I don't want to share my birth date with them and those things get very difficult when we start talking about computers and signing things and proof because of the way this is all going to work and we'll see that but they're challenges that are being looked at they're challenges that are being worked on so over time I think we're going to get these today there's not I don't think a standard way about that selective uh disclosure or that zero knowledge proof but the thing that's being worked on but think how interesting that is hey yes um I have my covid vaccine but I don't have to share details beyond that that maybe could then track other things I'm doing so there's a lot of real world ideas that really come into play here who's in the center it's not the identity provider anymore but it's not a external Central identity provider anymore it's me as the user the control of this that's the huge shift so when you think about this model here so I can think about this is centralized identity in these models I'm shifting to a decentralized there is no external IDP in this picture and we're talking about verifiable credentials and all of these Concepts this is the key point I the controller of these identifiers I have control I hold the verifiable credentials I choose who I want to give them out about so if we really break it down there's a series of different trusts that have to occur so remember me I'm the holder so I'm going to hold these credentials that are going to be given to me then we have the idea of this issuer so then there's the issuer foreign and then there's going to be this verifier now the whole point in the decentralization I don't want there to have to be a direct relationship between the issuer and the verifier it's all kind of going through me now before the issuer is going to give me a verifiable credential well they have to trust me they're not just going to make claims and give it to me without some proof they could be giving pii in this verifiable credential so it very well could be some pre-step that I've logged into a site maybe there's some in-person meeting I'm going to an office I'm doing something to really give certain levels of proof now the levels of trust is going to depend on how important this credential is if it's a government ID I want a lot of trust that issuer has to really know that is me if it's a pizza frequent buyer card they don't care at all I have to then trust the verifier to give them present these credentials I'm going to get but also the verifier has to trust the issuer in some indirect way because I have to know hey these claims they're creating really came from those and they've not been tampered with so what we have to have is this idea of some kind a verifiable data registry and what's going to have to happen is I'm going to is the issuer right some cryptographic material that I can then sign things with we're going to talk about this that the verifier could then read whatever that gets written or the verifier could then read that and use it as part of that all up and what that essentially enables to happen is indirectly the verifier can now trust things coming from the issuer so we have these different sets of things that have to come into play and this this all gets fairly complicated and the reality is when I use both fiber credentials I don't need to know any of this it's just nice to understand some of the things that are happening behind the scenes to really make all of this work because this is key we have to break this down and understand all of these components to have trust that I want to use this that I as an individual want to use this I as a company want to use this so it's really important to understand how this really can all work together so I keep using the word proof I have to be able to prove and I have to feel confident that these things that have been given to me really came from the issuer and have not been tampered with in some way now remember in the real world how do we do that proof well the real world proof was hey there's funny Holograms in things and my original Microsoft certified card as a as a hologram on it my driving license has hologram things and Watermark things there's a huge market for a falsified official documents because hey they're certifying some fairly important things so in the digital world I need to be able to do the same thing I need to be able to prove so in the real world how do we prove things well this is not a new problem and we've had the solution for a really really long time and I do actually as I wrote these different terms I should know in the terminology we have been using remember this is the holder the person holding these credentials I'm the holder this was the issuer and this is the verifiers there's three key roles involved in all of this so let's let's think how could this actually work so I want to issue something so I'm the issuer I want to be able to create some digital thing say verifiable credential that can be authenticated and proved that it really did come from me then it's not been tampered with I have some payload that needs proof well in computers we use cryptography that's really the the key part of everything we do and so what we use is asymmetric encryption or public key encryption so is the issuer here I have a private key foreign and I also have a public key now the key Point around these private public Keys is if I think about what shared the private key is never shared I keep hold of that private key above all else I have to keep that secure because what we're going to be able to do is to prove ownership of things why can do certain cryptographic operations on a payload using my private key that the public key could decode and assuming it's the same value it proves I had the private key and so by having the control of the private key I prove hey I am whatever entity is related to this so the people I wish to communicate with have access to this public key now the way we essentially use this is I have a I have a certain payload so what I'm going to do is there's some payload and in this case what we're really talking about are claims I want to make claims about something and then what we can do is I can generate a hash so a hash is just a mathematical um operation that's guaranteed to produce the same hash value if it's the same input so guaranteed hey if this input goes in it will always generate the same hash value so I create these claims in a certain format I generate the hash value and then what I can do is with my private key I can encrypt that hash so I can take that hash value encrypt it with my private key and that becomes my signature because I'm encrypting it I'm encrypting the hash with my private key so at this point if I just looked at those things this is the proof so I attach this to the oval document so now my document becomes this and the signature is the proof that hey it really came from this issuer because only this issuer has the private key and I can prove it's not been tampered with because when they receive it or they can decrypt this so if I now think of this picture and the issuer well now if we have over here the verifier well I send this to them I send this payload to the verifier and what they can do is they can run the body of the work through the same mathematical they will get a hash value so they will calculate the hash and then all they have to do is take this signature block so they take the signature block and with the public key so if they take the the signature if they take my signature and then they decrypt it with what I publishes my public key equipped as long as they're equal so what's that result of the decrypted signature equals the hash they generate they know it came from me they know it's not been tampered with because if it's been tampered with the content it would be a different hash it would prove it's been tampered with so through this this is how I can do cryptographic proof that hey it really came from this issuer because only they control the private key and it's not been tampered with so this is how in computers we do proof of things so that's Fair but there's a huge problem with public key cryptography how does the verifier know that that's the right public key for that issuer especially in a decentralized world how do I know that is the public key for the issuer that's a huge problem with this the way we solve it in regular pki is we have high level certificate authorities that everyone trusts and they sign things on behalf of companies who do some out of band or whatever trust with them so it's an external Central party is certifying yes this is the public key for this issuer and I trust that higher up certificate Authority but that will be centralized I don't want to do that I want a decentralized model and so I have to have some way to accomplish this how do I as the verifier know and here's the true problem that's correct I need to know that it's really this issuer and this is the right public key so how do we solve that I have to have some kind of identifier and I have to have some way to tie identifier to the public key that they can look up so I need to identify that they could resolve to find a public key and have strong confidence that it's the right one so how do we do this one is an identifier I need some set of identifiers again they were things like X top 500 names there were DNS names there's URLs there's different types of identifier out there in the world but we can have a new type so we're going to have this idea of a did a decentralized identifier it is identifier not identity so it's a decentralized identifier and this is not just people yes people would want a decentralized identifier but organization my pets my kids maybe a building many different types of real world entity will want decentralized identifiers and sometimes the controller will be the same as The Entity of that decentralized identifier I as an adult hey I'll be the controller of my decentralized identity but for my kids I would be the controller for them for my pets and their vaccination records I would be the controller for their decentralized identity but if I think about this decentralized identity remember we're coming at this brand new set of requirements we want what are those requirements that I want in this brand new type of decentralized identifier what needs to be some core fundamentals to make this workable it needs to be permanent it never needs to change potentially I I might want a different identifier in the future maybe I might have actual multiple identifiers there could still be concerns I have about parties tracking my use for the same identifier but it's my choice but the key thing is it never needs to change foreign I have an identifier but I need to be able to find the public key and maybe other things other ways to communicate with me so I need to be able to resolve it to some kind of metadata that's a key point I need it to be cryptographically verifiable foreign control of that identifier I don't want someone else to be able to use it so it has to be a way using these public and private keys that if I am the controller of that identifier and I would be the controller because only I would have the private key I can prove it so through some cryptographic operation using those cryptographic materials I can prove it and it must be decentralized I don't want some Central party giving these things out there's no Central registration Authority that allocates these now once again just to use verifiable credentials you don't need to care about any of this but I do think to get confidence in this and it's workings it's nice to understand what's kind of happening behind the scenes to actually be able to use this so those are our requirements I must have these things so we're going to have this new decentralized identifier that we know fundamentally has to be able to tie to some public and private keys so let's think about that for a second so I'm going to have my dead and there's really going to be two sets of Worlds I could think about for a second there's going to be stuff that I share so on this side of the line and then stuff I'm not willing to share it's going to be a very important point of what we talk about now we already know when I think about this distributed identifier there's going to be someone in control of it it might be the holder The Entity that this decentralized identifier is in the real world so there's going to be this idea of my controller and then we know we're going to have these public and private keys so then we have the idea of okay great there's the public key and then we know there's going to be the private key and actually I should make sure I draw this on the right side so that the did actually I'm going to move this line This shared the did can be shared I'm going to actually draw the line over there so this is the split my did and my public key obviously I'm going to be willing to share those things the controller no not necessarily and the private key definitely not at all now think about the various bindings we might have the private key and the public key are bound together they are mathematically bound together there's no splitting those things up only the controller knows the private key so they they're the things that just where we are right now verifiers can know the public key verifiers can know the Dead but now what I need is for those verifiers well I need them to know this identifier uses a specific public key because only if the verifier knows will this identifier uses this public key can I prove I am the identifier because I have the private key and I could respond to various challenges hey sign this not use more than once with the private key I can do that well that proves I have the private key which proves I am this identity how do I do this and this is the really tricky part so how do I have the identifier bound to the controller so I want to be able to prove this I want these bound and then what I also need is how do I have the identifier bound to the public key I need to solve these two problems once I can solve that I'm good to go now as we talked about with regular pki they solve this by certificate authorities there's a higher level sets typical authorities that can sign things that will basically with their private Keys sign digital certificates that are your keys and the public keys and I can have an Xbox 500 name or DNS name whatever that might be they're providing that proof but I don't want that I don't want any essential Authority so what I need to be able to do is use that same cryptography that is used to bind these public private Keys together my solution needs that did that decentralized identifier to be generated from the public key if the public key generates the distributed identifier they're mathematically bound together as long as I trust math I'm good to go this there's nothing that could actually break that and if mathematically the public key is now bound to the distribute decentralized identifier well if I'm the controller if these two things are bound together I can prove I'm the controller of this decentralized identifier because only I have access to the private key so I can respond to challenges for the corresponding private key to the public key that's bound to the decentralized identifier so I can prove that as well so that's the solution we're done I use math and cryptography to generate that decentralized identifier from the public key so I can self-generate private public keys anyone can do that I use an algorithm to from the public key generate the decentralized identifier that's just math I have the private key I can prove all of these things well I'm not quite done because there's a problem what are some of those key features of that decentralized identifier I wanted permanent what's one of the good practices we want with public private keys oh I want to be able to rotate them well that that's a problem because right now my decentralized identifier was generated from the public key so if I think about versionings okay private key one public key one I'm happy at this point but now I have to do a key rotation so now it's been six months or whatever that might be I need to rotate the keys so now I get a new private key and a new public key that doesn't work anymore I have to change my decentralized identifier every single time I do a key rotation I don't want that so what I need is a way for initially the Genesis so the first public private key I mean it's a publicly that Genesis the first public key yes that can mathematically be bound to the decentralized identifier but then I need a way that after that I can rotate the key but have some trusted means to go back through history and say oh from the Genesis that first one yes that did mathematically tie to this decentralized identifier so yes even though the keys have rotated I'm still good to go now one of the requirements we had also remember was resolvable to metadata and this is why we need that because I can't long term rely on math to just say hey this public key mathematically ties in through cryptography to the decentralized identifier because it won't as soon as I rotate the keys I've broken that link between them this is where we have something called the did document and this is what the did will resolve to so now we add in this layer of the colors we use we use orange now we have the idea of did documents and what they did document is going to contain well contains the public key and the key point is the did can always resolve to the did document if I should even draw the arrow there because we're going to see there's going to be different versions really what it always responds resolves to two the document of that did but over time it's going to change now I've that metadata I said is a public key that's probably the most important part but there are other things it kind of things like service endpoints a service endpoint could be some um address but if I was receiving this maybe I can go and communicate to get maybe other information some ongoing set of requirements some interactions imagine the issue was a university and they give me a certain type of verified credential we're going to talk about but as the receiver the verifier I'm like well how do I know you're legitimate University for the service endpoint I'd have a way to communicate with you I could say hey give me your official government University sanctioned ID you could give it to me and then I could go and do various checks on that so I can also have things like these service endpoints as part of that metadata so I can have other things but the key point now is so this did document well initially I signed it with the private key so remember that proof so it's signed with the private key one I narrow tape my key I update my did document from I did document now actually I'll change the color now has public key two how do I establish that chain of trust well I sign it still with private key one oh okay so now there's this chain that can actually go back and then if I rotate it again well the next did document with public key three or I would sign with the private key to so I can always go through the chain of trust if needed when it will be needed I can go all the way back through the various chains over time saying now I've got public key three but I would have signed it with private key to there's a link I can look at the late this did document and I can validate all the way back to hey now it cryptographically would resolve to that initial one and that's really the the important point when I think about the whole point it has to be resolvable the reason it did has to be resolvable is I want to be able to rotate the keys I mean it really boils down to that something where I couldn't rotate the key is actually pretty useless if I think of any kind of public key cryptography things get broken over time I have to be able to rotate the key foreign so yes initially the identifier mathematically cryptographically is tied to the first public private key or the public key but by being able to resolve to this did document it lets me update the public key so I can rotate the keys but through this chain I can still go back and validate or yes it does tie into this now it gets more complicated than this and it's always gets simpler than this because I really don't have to care about these things the whole point of this did is that hey it is resolvable it's cryptographically verifiable it is decentralized it is permanent but these things are going to be taken care for me this is not saying I'm actually going to have to manually go and worry about about what is it did let's break it down into a bit more detail it did it's a URI which means just like HTTP send to mail to whatever that might be well it starts with did colon so HTTP colon did colon and then we're going to have a method and there are many different methods this is an open standard there's going to be different methods to be able to facilitate this decentralized this resolution um this cryptographically verifiable there's different ways we can anchor and Trust in this and then whatever the method is there is some unique identifier within that method it's guaranteed to be unique within that specific method now remember that did represent some specific entity some specific subject saying in the real world me a company my dog my kids whatever that might be and we can actually go and look at the spec so if we look at the specs so the specs are actually fantastic sometimes you go oh spec yuck so this is talking for example about did syntax so it's got method syntax so a method must have exactly one but you can say hey the specific ID must be unique within the did method maybe it's globally unique as well to reduce the chances there's a whole set of different things I have to do to make this happen but the key part is I did is really just resolving to a did document that's fundamentally the point is the Dead is going to be able to resolve to a dead document in a secure trusted way that's the ultimate goal of all this I want it to be able to resolve to that document because that's what's got the metadata the public key and those other things I want I have the controller the controller is the one that can make changes to the document they can update those keys they have the private key they also a lot of times in our scenarios the controller will be the same as the subject who's the same as the holder of they're all going to be the same thing so they did in the document are very very tightly coupled together but there are a huge number of methods if we go and look right now it says look at the current methods and these are I don't think all of them but if we look at the dead methods available to us there's a lot now one of the things you've probably heard about decentralized identifiers and decentralized identity is Bitcoin and blockchain and absolutely there are methods that use those you can see here look Bitcoin okay I can go and look at the Bitcoin method and if we look at the Bitcoin format that unique identifier part is basically by nature of hey I'm writing some transaction and those transaction identifiers will become part of that did see it goes through the entire spec of what it's doing but what you're going to end up with is it did notice the method is btcr for Bitcoin and then it's going to have something based on some transaction that it made to the blockchain it could be a smart contract address as many different methods available to us there's things that don't use blockchain maybe it's based on a web address there are many things there are ones that are layered approaches where maybe hey the method initially writes to some interplanetary file system like ion interplanetary there's copies of your data on Mars which then takes the hash of the right to the interplanetary file system batches them up so I can have thousands in one transaction which then does a Bitcoin to the blockchain to really anchor it so it's immutable so it can never be changed so I some of them are multiple layers to enable this functionality because there's different things I think about for those methods because they have different environmental intra environmental impact they have different levels of trust they have different levels of cost of performance of scalability so there's not one method because different organizations priorities and goals will differ and so these different methods use as the name suggests different ways and methods under the covers to achieve these things to make this identifier permanent to make it resolvable to the document to make it cryptographically verifiable and make it decentralized but there's different ways you can achieve that but they all doesn't matter what the method is resolves to a new document and that's really that the key part some of them are doing proof of work some are proof of stakes some of proof of hey I own this domain it really doesn't matter there's some Genesis public key some Genesis transaction that's rooted in something we trust that I I can then build off of and we can look at some examples if we look at some of these so there is key so if we look at the key method well it's exactly what the name says the unique identifier is the public key so that's that most pure form we talked about but if we actually go and look at some of the security and privacy considerations what don't we like about this key rotation is not supported because it's purely generative method you can't change the key well that's really not very useful and so the ultimate result is long-term use is discouraged now if you had some short-term use maybe it's fine I don't need to rotate the key so this becomes super super simple in a way I could do this but because I can't rotate it I'm not going to use that long long term we already saw the Bitcoin there's a web method so if I think as an organization I already own a domain name I already have an SSL certificate so what I can actually do my method to resolve to my did document I could actually just root in my domain name and this is actually very attractive for a lot of organizations I'm using this for mine like I could actually go and if I look at my service I'm offering this is my did document so if I look at my did what my did is did web and it's just by Nature that I own onboard to azure.com and what I can do is there are certain well-known locations that you have to be able to place a document on so in this case the way this works is it has to be present in dot well-known and that the document has to be called did.json so as an organization this isn't using blockchain this is simply I as a company already own this domain what is the goal of this I need to be able to securely share my public key and prove it really is tied to my identifier and prove that I'm the controller of it well it's got my domain name in it so it's got my domain name in it I'm hosting it under my domain so my identifier actually becomes my domain and within here you can actually see I've got my cryptographic material so my verification method I'm telling it the key I'm going to use I'm going to different versions I tell it the type of key and then I actually have the keys so I'm making my did document available just through the web that's that meets my requirements I'm totally good with doing this approach so again the key point in all of this is hey look yeah I can see I've got my dead is within the document I can see the verification method I can see my ID and then I can see the type and I can even actually go and see the keys so all of that is just there in so that's that's one option that's one method so as a company that that's pretty attractive to me this means I ion so ion is another big one Microsoft in its services so that there's a huge number of options you have here but Microsoft is really focusing on web and ion right now and ion is actually built on top of the side tree protocol so if I can look at the side tree protocol it shows me those layers so yes initially I go and communicate with an ion node which goes and write something maybe a database which then writes this interplanetary file system when I do the right I get a hash value I batch those hash values up and then I write it to a decentralized ledger like Bitcoin by writing it's a ledger it becomes immutable so I can track back okay the hash value is written to this Bitcoin transaction which cannot be changed so I can go back and get those different levels of trust and because it's batching them up it's not some Bitcoin transaction every time I do anything which again we think about the environment we think about the impact of these methods that's one of our considerations it's like oh okay if I wrote to a blockchain every time it's a proof of work I'm heating up the planet so one of the benefits ion and the layers which batches up maybe thousands of those into planetary file system hashes and just as a transaction so there's still a proof of work there but it's not per action I'm doing but some of them like the web doesn't use it at all go and look at the specs they're pretty cool but as an organization I I can pick and it doesn't matter and that's going to be one of the key things we're going to see it doesn't matter which one any particular company uses the way I resolve it is going to be exactly the same I don't have to care I don't have to do different things if they used ion they use Bitcoin they use web they use it's the same thing doesn't matter what I do it's all abstracted from me and if you look at the specs the key point of all of this is whatever the method I give it a did it has to respond to a did document it has to be able to create it has to be able to resolve and then read be able to read it I have to be able to update and I have to deactivate so those crud operations that's the key point of the methods and again as the verifier I do not care at all I really don't care what particular method they use it's transparent to me I'm going to use this ability to resolve it that takes care of whatever method they happen to use so there's a lot ultimately a couple of them will Bubble Up and become the most used so right now I think there's a hundred odd there'll probably be a few key ones so I think web would probably be very popular things like this ion will be popular the ones where it's a certain maybe Bitcoin transaction for everyone uh there's probably some issues but come and take a look it's it will evolve over time now one thing you probably noticed when looked at the Bitcoin one or the the key one and most of them if it's using ethereum it's a smart contract uh they're really hard to read only that web one is actually fairly friendly because it's a domain name so as a human being when I go and look at a did it's Ugg it's horrible it hurts my brain why why are the dead so ugly and it turns out like most things in life um I can pick two out of three things I can have it done fast I can have it done cheap I can have it done right pick any two well in this case um I can have it human meaningful I can have it decentralized or I can have it secure foreign that's what really matters this tough can't have it so we pick two we pick the two that really matter I am not going to see these dids to all intents and purposes I'm never going to see them anyway the point is it needs to be decentralized it needs to be secure technically you you can cure all three but it's very hard to do and there's just no point so this is the whole idea now I'm two-thirds of the way you're probably through this presentation and I've still not really talked about a verifiable credential um I probably should fix that but it builds on this the whole point is we need these decentralized identifiers and we need to be able to prove that hey we are or it was issued by really this particular decentralized identifier to be able to issue any verifiable credentials that have claims that are meaningful so this part is really really important to all of this so when we come to why have we spent so much time on this it really boils down to the fact that well I have some controller that controller remember they own and keep secure their private key what they're making available well they're going to make a did document available so there's going to be some ability to have a did Universal resolver doesn't matter what the method I'm going to be able to go and query this did resolver and it's going to give me back when I give it a did a did document and that the document is going to have the corresponding public key and the key part is even if the part of the method and this is where the trust comes in even if I've rotated the key that underlying method when it resolves is resolving that in a trusted cryptographically verifiable way that I know hey this really is the did document for this particular decentralized identity so now what I can do as a controller is hey I can create something I can say hey the issuer is me this is my did and I can make a bunch of claims I can use my private key to sign it remember I take the message hash sign up my private key attach it I can now give it to a verifier I can look inside oh it was issued by this did hey I'll go to my Universal verifier whose whole job is to resolve that to the document which I can now read oh hey that public key I'm going to use that to decrypt the signature I'm going to generate my own hash hey they match important point we're done so this is the whole key part this is what we've now allowed through the did and the did document without any direct communication remember it's just whatever method be it the Bitcoin or key or web whatever that is doesn't matter this did resolver I could write my own there's ones out there again it's a standard there's a spec for this whatever the method this one resolver will ultimately give me the did document in a cryptographically provable trusted way that that's what all of this boils down to so let's actually think about a verifiable credential in practice how would this actually work so we have to start off with again this idea of the issuer so I have the issuer remember the whole point of the issuer has their own did and let's I guess we'll draw down the bottom this idea we'll do it in the Universal pen we have some trust system whatever one that is I do not care be it blockchain or ion or web I do not care at all but there's some underlying trust system that fundamentally what this is going to give me is this did Is Anchored in that trust system and what it's ultimately going to be able to give me is their public key through that document and maybe service endpoints and all that other stuff but all of this gets wrapped up in this nice did document so in a trusted way I'm going to be able to take this issue as did and get that did document fantastic now we also have a holder nobody spoke much about the holder but the holder me me I actually want to get these verifiable credentials and then be able to give them to various people so I want to be able to request from the issuer a verifiable credential now to be able to do this the first thing I need is obviously I've got my device I phone a computer whatever that is on that device so I'll do a little box around this I've got some kind of user agent uh think of it as a wallet now in the Microsoft world for an example it doesn't have to be an at all but this could be the Authenticator so I open up the authenticator app initially my authenticator app has nothing on its own I'll walk through this in a second it doesn't have a did of its own it has nothing initially first time I actually go to request hey I would like a verifiable credential please it Springs to life so what it's going to do is it's going to go and create my private key that it's going to store in a secure Enclave so that's my private key obviously it's also going to then generate a public key that's paired with that and then it has to create that decentralized identifier now the way we're doing this is Ion remember there's different methods available and so it's going to generate my did now I didn't go into the detail of it but if you actually go back and look at this ion spec for a second there's something interesting about ion we can see if I can actually find it um it talks about different structures of its actual did one of the interesting things we have is remember this is multi-layered trying to find the straw okay file structures so let's see if I find it moment has multiple layers so you have this idea of hey it goes to some database and then it goes to some into Factory file system and then eventually it goes to a ledger so if you think about those layers there's time involved in that it's not going to instantly especially if it's batching up those various hashes it wouldn't instantly be available so one of the things it does is its format is you have this short form did so it there's this side tree but again ion is built on side tree dead side tree and then this short form URI great but it also generates a long form did because there is a period of time between the generation of a deed and it properly being anchored Etc and so the long form did well the long form did actually contains the did document which actually contains the public key and again this is a huge amount of detail you really don't need to know but it's important to understand so this is what authenticator is doing it's using ion but it's using the ion long form and what that means is it doesn't actually have to really anchor it in in the battery file system or Bitcoin Ledger or anything else it's used in the long form so it did actually contains the did document which contains the public key because really for this identifier this is just my wallet in a way I want to be able to generate a decentralized identifier for me but what's going to count is not what I say about myself no one cares it's going to be what other people say about me so the whole point is now I've got this identifier that contains that public key as part of it it is not published to any Ledger it's just bound to me as that subject and if I give this to someone they can still run it through the resolver the resolver will try to get a newer version of the document if it doesn't work we can't find it then it will just use the version that's in that encoded long form state so now I have a single did in my wallet that represents me okay so now I'm requesting a verifiable credential as part of the the protocol that goes through this it's part of the protocol of issuance it's going to request me to sign something my private key and my data will be included in that signed payload the Json web token the jot will have that in it now important thing when I'm doing this request remember they might want some evidence I I this did really is this real world identity this reward entity of John Savile or this company or this dog or whatever so it might be as part of the request I have to give it a verified credential I already had from someone they trust or I've had to go to a site where I've had to authenticate first which then lets me go and do this request or I'm standing in an office so there might be an idea of a bootstrapping to get the initial set of permissions but let's say in this case this is the first one so maybe I have done some other authentication through some other method that's going to allow them to trust to say hey okay the dead is John's have all I'm going to give them some credential so I may have to go and log on first to then go and request this so now what they will do remember this they did is anchored in that trust chain so I'm requesting a verifiable credential so they are now going to go and create one they're going to create a verifiable credential for John well for that decentralized identifier more specifically they're going to say the issuer well is them the subject so who this is about oh that's this state the whole in this case and in many cases the subject and the holder and the controller of this data all the same thing again it could be different the controller could be a parent or the owner of a pet or the owner of a building but let's say this is for me as a person the whole of the controller did the subject of all the same thing and then they make a bunch of claims about me I was a citizen he earns this amount he was born on this date whatever remember they have their private key then as the proof they sign it and they give it to me and at this point I store it in my wallet so it's just stored in my wallet okay great so it's stored important point this verifiable credential is not written to some Ledger somewhere this might have pii in it the only place this is stored is my wallet this is not stored on a ledger it's not stored on a site I don't want that it's got pii in it this is generated and the proof is anchored in some trust system but the verifiable credential itself is not it's given to me I store it in my wallet now there is a long-term concept maybe of an identity Hub where instead of this just being in my local wallet there could be some cloud-based service that's secure where I could store these and share them between different things but those things are all being built up you have to think over time when this takes off I'm going to have a lot of verifiable credentials okay so now I want to use it I want to use it with a verifier whoever that may be I'm going to get a presentation request via oidc siteop so open ID connect is highly used already what they have done is there's an additional spec built on this so I can still use open ID connect so most of the web already speaks openid connect the protocol I'm talking to leverage this is just a modification of that and there's going to be a challenge to hey signs saying with my private key that matches the public key found in the resolution of my did so what's going to happen is they're going to have a request so this verifier has some request we request and now what I've got remember I've got this verifiable credential so I've got it in my wallet and I might want to send it multiple verifiable credentials but remember the issue of the point here is there did and the subject was my did and it's got a bunch of claims about me and then they signed it great I might put multiple virtual credentials in one verifiable presentation so I am now going to create what happened now a verifiable presentation in response I am going to sign it and then I send it to them one or more verified potentials unpacking them together in a verifiable presentation I'm signing it with my private key and sending it to them now this point is the verifier I might well okay I need to look those things up so how do I do this well we have the did resolver foreign they can be using different methods this did could be web this did could be ion it doesn't it's imp they do not care they don't even have to look at what the method is of the Dead all they're going to do is they're going to say okay um wrong color why don't they not change it they're going to say hey what I need to know I need to dig documents for um well there's two dates right I want to know the holder did oh and I also need it for the issuer did Too Many Colors and it's the resolver's job to go to whatever trust system that method particularly uses I don't need to care but what it will ultimately return to me foreign documents which is going to have the public keys of each of the entities and then with those public keys I can validate I could say okay that's good the dead in the verifiable credential does match the date of the person presenting it to me so it's really them okay this credential is for this holder and it really did come from this issuer because I can validate the signature on it matches that one through the trust system I'm happy so the end result is we're done they never spoke directly I have complete control when they sent the request I'm prompted for hate what do you want to share I get to pick which verifiable credentials in my wallet I want to share with that verify and again in the future the path will kind of evolve to maybe it's selective presentation maybe only show one claim out of this maybe it's zero knowledge proof yes I'm employed by a company without having to send you the actual so it will prove it without having to send the verified credential directly it's got too much information I don't want to share my salary or my start date with you I just need to prove I am employed so those things are all coming so what is this really look like and again in the real world I would start off with an empty wallet and often I have to bootstrap my wallet initially in the real world who sang from the government for example so I get some government ID and once I've got a government ID I can then show it to other issuers so I can then go and get important things like oh an employment card I can put in my wallet um I can get other important things like my Blockbuster video card but that's the process I would go through so if we think about that same process let's do exactly the same thing so I want to bring up let's just open this up over here let's switch over so here is my authenticator app and right now you can see it's completely empty so what I could do is I could jump over to a site now let's assume I've already authenticated to this site let's actually move this over for a second so I've already authenticated to this site and with my name blah blah maybe I have to upload a picture this is a true identity I verified it I go through some set of processes I upload a picture of myself I maybe have to upload some other government ID again it's all about that bootstrapping initially but it's verifying my information it's doing checks and when it's going to end up is it's going to give me a verifiable credential it has now added that to my wallet I now have a verifiable credential from true identity in my wallet I can go and look at it I can see oh yeah it's my name I can see the issuance I can see expiration um I now have an identity what if I now carry on with that life I can now maybe go back to my next stage okay I've identified my identity now I want to get a work card so it's asking me hey can you share your kind of true identity so I want to share and now it's telling me hey the company is asking to see this verifiable credential do you want to share this I'll say sure I'm going to share it with them it was approved and now I can go back continue on boarding and now I could retrieve my verified ID for my company yep I like that as well oh okay fantastic so now I've got another identity and if I went back and looked at my initial I can see how it was used and say oh yeah I use this verifiable credential and I actually shared it with all this other company and you can set up your own ones so a little bit of fun uh just while we're doing this so on board to Azure super follower credential I could say hey I want to get a credential and it's going to show me a code now it also could have linked directly for example but what I'll do now is actually let's just open up so you can see this again I'll go back to my site I want to add a new one we'll add in that code it has a pin so I'm entering in that PIN and now I've got another verified ID oh yes please on board to Azure super follower very useful credential so now I have yet another credential in my environment now the way this was and again this is Open Standards the way I've done this is I'm using enter so that little silly super follower I'm using the verified ID functionality of intron it took a really a few minutes to get stood up now by default it's using web so what it would basically give me is it generated the public private key the private key it stores in Azure key vault it gave me this document and it told me hey make this available on that website you own in this folder and it needs this name so it went and checked I put it where it was because I'm using web it's a little bit funny but you also have to prove domain ownership so it gives you another file that you have to put in another well-known location that basically just says hey is the link did I'm actually using for that domain and that was it and then you just go and create your credentials so I created an onboard to Azure super follower and you can see the credential preview you can modify the look The feel the logos all of these different things around it and then you just write a little app to issue you write an active verify there's samples on the portal for how you do this but it's it's actually very easy to get up and running with so one of the key things is if you want to go and start trying this stuff out you absolutely can the sample you can just download and there's samples in different languages you can go and use these things an entry is just one example of a service that helps you be an issuer and helps you be a verifier but it's going to interoperate with whoever whatever service you use the issue you can write your own you absolutely could it's just hey there's things that are out there that help you do it now with all of this well one question that comes up well if I lose my wallet what if I lost that app and as I mentioned there are things for example in authenticator you can back up so ways to protect that now I think things in the future around are webs where you can actually have an identity Hub where I could then share it between different devices but ultimately if I lost my wallet the same way if I lost my physical wallet I had to start again I'd have to start fresh so I maybe have to go and re-request a verifiable credential from some government agency to put in my digital wallet then I'd have to go and re-request my employee so just like a physical wallet if I lost I can start again it's a pain and it will be painful like in the digital world as well but you could do it and that's what would be required for that now ultimately why do I care like why why do I want this now we did talk about all the centralized there's a lot of challenges with not owning my identity both for as a company both as a user so this decentralized approach is benefits to everyone its benefits for issuers its benefits for the holders its benefits for the verifiers everyone gets better security better privacy better protection better portability they're all standards so certainly I'm not worrying about some particular implementation that this person has done it doesn't matter remember as long as they're following the standard that did follows the standard that did method they choose is one of the standards well that did verifier is gonna work that did resolver which is going to give them the document which is going to give me all of this proof the method you choose they all have different considerations hey the environmental impact if it's maybe um proof of work maybe it's proof of stake well then it costs me money um there's different options there I'm going to pick the one that best aligns with my principles maybe around hey that environmental impact based around its trust status based around the Security based around the stability based around the scalability I have choices I as an organization I'm going to look at those things but everyone gets benefits When I think about that idea of hey the the security the Privacy the protection the portability the control as a company well when I suddenly can support these verifiable credentials I now have less concerns about storing people's personal data I don't want to store that gdpr then I have to somehow prove and give it away if there was a breach I've got all this stuff well in this world hey give me your verifiable potential approach over 21 give me this verifiable credential that proves you've had a covered shot that proves you're employed that proves you're a citizen I don't have to store it next time you do some other interaction I just request it again it's a verifiable credential it's super super easy to do those things so I want some way to identify my customers super super easy the wallets have standard features which makes interoperability really easy hey maybe it's an NFC um maybe it's just hey it's some some scanning thing whatever it is there's standards around that hey I buy something hey they they issue you a verified potential you're going to take it to the Fulfillment and they give it to you could be a train pass a concert ticket it's going to help produce fraud for again these standards things it's going to help as a company my life be much much easier I'm not having to store a whole bunch of stuff and if I do need information there's certain types of verifiable credentials hey give me an ID give me whatever that is as a user I'm control of my digital those decentralized identifiers I control them I consent what I want to share again in the future we'll have that selective presentation maybe zero knowledge proof it's even better but I have a consistent experience I can think of two good YouTube once I hit 100 000 subscribers I could get verified that proves I'm a real person it proves hey I own that channel that's not available to someone who has less than a hundred thousand subscribers because there's a burden of work on YouTube to go through that verification so it's not available to everyone some might have a load of bots they're not real subscribers Twitter they did Proof of stake give me money and we kind of saw how that went well verifiable credentials would solve both of those things it democratizes the requirements to go and get verified hey give me your government a verified credential maybe it's zero knowledge proof that you're an actual real citizen here you go okay Twitter give me your verified credential that proves you're John Savile here you go done it democratizes the whole idea of identity by democratizing the whole idea of that cryptography the public private kit makes it available to anyone which makes the identity available to anyone so now everyone in the world can have an identity not just those people that can maybe buy a URL or or buy an email or have a phone number whatever that might be it starts to make it far more available I don't there's no Financial there's no popularity none of that applies anymore so it's a very very attractive thing I think for everyone long long term now with everything there's considerations if I think of my wallet for a second today if someone asked me for proof I'm kind of skeptical when someone asks to see my driving license I'm like why do you want to see my driving license as more and more things become these verifiable credentials whereas attackers today might Target an IDP was the information shifts from an IDP to the individual people makes it harder for the attacker now they have to Target thousands of wallets instead of some big Central Target but they'll set up spoof sites that will if you're not paying attention say hey give me all your verifiable credentials if you're not looking oh here you go and suddenly you've given away a whole bunch of pii so I think what will happen is a certain amount of education but the wallets the wallets and their user interfaces will help protect the user saying hey wait a minute uh is this requester is this verify really someone you should be giving this stuff to do you want to give all of these because it shifts the responsibility a little bit now to you and picking who you want to give it to But ultimately if you think about this decentralized identifier these verifiable credentials when the internet started out it's a mesh and it still is the internet's a mesh yeah it's just networks connected together that have IP routing between them there's not really a central point you could argue DNS is there's there is a hierarchy DNS but identity has become very centralized it almost goes against the goal of the internet the identity providers have become the Hub whereas really when I think about identity it should be the entity of the real world is at the center and these decentralized identifiers take us back to that world if you look at all the pictures I drew it's the holder is in the middle so it puts it back to this idea that it's a mesh it's a mesh of entities it's a mesh of decentralized identifiers and through these means we can still have trust in that system so I hope this helped um there's a whole bunch of Standards around this really if you're interested there's this great Knowledge Tree that goes through all of the different standards and I'll put it in the description I definitely recommend going and have a look at this but they're actually very readable they're actually pretty cool to go and look at and it can help understand what's happening so I went in a ton of detail the reality is you don't need to understand almost any of this if you just want to use verifiable credentials I install an app and a user agent whatever you choose and I go and request it you saw the interaction oh here we go here you go I'm consenting give you this that that's it but if you have concerns maybe about the use of those and the security hopefully what I've shown you here is they can be trusted they are rooted in these very secure trusted systems and that have this Central um set of specifications that they're going to behave the same way but you as a company can choose what method do I feel most comfortable with what I want to use and you can go and play as always I hope that was useful this was actually the most work I've had to put into a video for a really long time the research for this was crazy I don't have ever read so many specs in a one week period but it's fascinating this is a really interesting I think this is the future in many ways of the internet if you think at the core of everything is identity and identifiers for our entities this this I think is the future so it's cool to actually uh understand and start playing with this so the next video take care
Info
Channel: John Savill's Technical Training
Views: 23,920
Rating: undefined out of 5
Keywords: azure, azure cloud, microsoft azure, microsoft, cloud, azure ad, identity, decentralized identity, verifiable credentials, did, public key, private keyde, centralized identifier, identity provider, real world, cryptographically verifiable, verified credential, service endpoints, identity hub, selective presentation, certificate authorities, openid connect, sidetree, distributed identifier, verifiable presentation, cryptographic material, key rotation
Id: BxLSSH_EHjo
Channel Id: undefined
Length: 92min 23sec (5543 seconds)
Published: Tue Nov 22 2022
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.