Verifiable Credentials and Decentralized Identifiers with DIDKit
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Lehner, Charles E.
We present DIDKit, a toolkit for Verifiable Credentials and Decentralized Identifiers, implemented in Rust. This includes an introduction to Verifiable Credentials ("VCs"), a W3C Recommendation; to Decentralized Identifiers ("DIDs"), a Proposed W3C Recommendation; and to the signing formats used with these: JSON Web Signatures (JWS) and Linked Data Proofs. Charles Lehner will demo using DIDKit to issue, present and verify verifiable credentials using DIDs based on cryptographic keypairs. Charles is joined by Juan Caballero for the Q&A.
 Hello and welcome to this presentation of Verifiable Credentials and Decentralized Identifiers with DidKit. I'm Charles E. Lainer, working at Spruce Systems, Inc. and this is FOSSTEM 22-22 Web3 Dev Room. Verifiable Credentials and Decentralized Identifiers are two technology standards being developed at the World Wide Web Consortium, the W3C. Verifiable Credentials are a recommendation of the W3C and this is what the specification looks like. It's for a kind of data model for verifiable information, cryptographically verifiable or otherwise, and it has special formats for indicating specific things. The main data structures are a verifiable credential and a presentation, or a verifiable presentation. Here is an example from the specification of a verifiable credential with comments. You can see the at context for the use of JSON-LD for semantic extensibility, and then there are the required fields and optional fields, ID type, issuer, identifier, issuance date, and the credential subject. The credential subject typically is where an entity is identified that the credential is issued to, and then there are other pieces of information that are called claims that are assertions about reality, about the subject, or about the issuer, or about something else. Then there's the proof property, which is usually a cryptographic signature over the rest of the credential. Here you can see the metadata, the signature proof type, and the signature data. The centralized identifiers are a URI scheme and data model that's a W3C proposed recommendation, and the specification looks like this. A DID is a URI that looks like this, and the first part after the scheme is called the DID method. In this example, this would be the example DID method. The rest of the DID is up to the DID method specification. DID methods did resolve to DID documents, and a DID document example is here. The DID is in the ID, typically, and then the other information is in the rest of the DID document. You can see the use of JSON-LD again, and then this example contains an object for a public key or a verification method, as it's called, for the purposes of authentication. DID, KIT, and SSI are implementations of verifiable credentials and decentralized identifiers and other technologies. These are being developed at Spruce, and that's what I'm working on at Spruce, largely. The structure of this implementation is that SSI contains the core library in Rust for the functionality, and did, KIT embeds the SSI library into various interfaces. There's a command line interface, an HTTP interface, which follows a pre-standard that's being developed at W3C, a credentials community group, and there's interfaces for other languages, C, Java, Python, WebAssembly. There's native libraries for Android and iOS. There's a Node.js module, and a Flutter library, and there's also a GoLine. The did, KIT command line interface looks like this, and here's the links, and the other interfaces, the bindings to other languages, have more or less the same functionality, that is, to issue and verify verifiable credentials and presentations, and resolve dids, and do some key material operations and other utilities. So I'm going to try a demo, did, KIT, now. This demo is a multi-part demo to try to demonstrate the different roles that are involved. In, in verifiable credential issuance and verification. So often, there are considered to be three roles. There's the issuer, who issues a credential, and then there's the holder, who becomes the holder by receiving a credential that they are then holding, and then there's the verifier, who the holder presents their credential to, and then the verifier verifies it. So starting with the issuer, good start. We have a public private key pair here, and we can use didKIT to generate a did that's derived from that key pair. Using key to did for the key method, didKIT and SSI have implementations of various did methods and extensibility to use others, but the key method is built in and allows deriving a key, a did from a key pair, as well as some of the others. So we do that, and we get the did here. Now in the credential that we're issuing, I've started it out here. This one is pretty bare bones. There's, normally you'd have some meaningful information in the credential, but this is trying to be a minimal instance just to demonstrate this functionality. So we put our did in the issuer field, and also I'll note that verifier credentials don't have to be used with dids. You can use HTTP URLs, HTTPS, and other schemes, but when you combine it with dids, you can get some nice properties. So there's the issuer ID. We can put a date in this date field issuance date, and then the credential subject, this signifies, when there's an ID here, it signifies that the credential is about a particular entity, and in this case, it's going to be identified with a did, and then later on, the entity that controls that did will be able to present that credential and prove cryptographically that they possess the key material that is corresponding to that identifier. So we pretend we received this from the subject or the holder already, and it's in there. Now issue this credential, it's did kit, try the command line, passing the credential and standard input and passing the key pair and redirect this to a file. That seems to have worked. Now let's take a look. And you can see that this is a verifiable credential. The information from before is still there. The proof property has been added, which contains this ED255.9 signature over the credential and the metadata. So now we would, as issuer, give this to the subject. In this case, it's a, it may be a person or entity, and they're going to receive this credential. So I'm going to symbolize that by moving it into their directory. Now pretend we're the holder, and we go over there and we've received this credential, and we want to verify it first to make sure it's verified, verifiable, valid, and all that. And we can do that with did kit, and that shows the proof check passed, and there's no errors, so it verified. Now as a holder, we will want to present this credential to another entity who is called the verifier. And to do that, we have to wrap the verifiable credential into a verifiable presentation. So I've started one here, this is an empty verifiable presentation, it's not yet verifiable, it's just a presentation, and it's empty, so I'm going to add the verifiable credential in here, in the verifiable credential property, and then in the holder property, I would put my did as the holder. And in case I didn't have that already, I could use the same command as before passing my key, key, and that's our ID, and I put that in here, the holder property, and now this should be able to be issued, or generated as a presentation, and again using the key pair, and saving that to a file. And that seems to have worked, so we would pass this to the verifier. Now normally there would be an interactive verification process usually, where the verifier might provide a challenge, and a domain property, and then those would be incorporated into the presentation. But for right now, we're not using that in this demo. But we can verify it as the verifier now, by passing it in, similarly to with the credential, and that worked. And then also as the verifier, we would extract the verifiable credential from it, since this is not automatic and did kick currently, and verify that separately. Oops, forgot to pipe it in. And that worked. And then again as the verifier, we would do additional processing to verify that the subject ID is the same as the holder ID, and that the proofs are proofs that we want to allow, and then things like that, and then look at the actual data as well. So that's a verifiable presentation. One more other thing we can look at here is verifying a did, and that would be done with did resolve. Sorry, resolve a did, not verify did. And that returns a did document, looks like this, for did key anyway. Okay, so that's that. Back to the presentation. So I wanted to mention some other implementations of verifiable credentials and decentralized identifiers. These are a few of them, and there are others as well. But Transmute, Digital Bizarre, Denive Tech, Decentralized Identity Foundation, Hyperledger, and Uport have implemented various parts of this technology. And there's test suites and interop activities that make sure that they're interoperable. And I also want to mention some community and working groups. The decentralized identifiers and verifiable credentials have working groups at W3C that standardize them, and these have public mailing lists as well. And then there's the Credentials Community Group at W3C that I want to highlight, which has public meetings and it has an active email mailing list. And often on the meetings there are interesting speakers and discussions that take place. And there are also different work items that happen in there that are pre-standards that later on maybe they'll go into a standards working group. At Decentralized Identity Foundation or DIF there are working groups as well, and also there's Interoperability Open Group, which can be interesting to check out. And for people who want to make sure that their implementations are interoperable and explore different topics and issues. And Identity Workshop is a conference that takes place multiple times a year, and that's a good place for meeting people and working on this kind of technology. And Trust Over IP Foundation is also involved in things, and so is OpenID Foundation. So if you'd like to chat with me or other people at Spruce, we have a matrix room, an IRC channel, you can email here, and there's also a Discord. And if you want to contact me you can find me on Matrix, IRC, email, PGP, secure Scuttlebutt, and on the web. So thank you very much. Great, now we've got 30 seconds while streams catch up. Hello, hello. So the stream's probably caught up now mostly for buffers, so thanks everybody for listening or not, and for being present. And I'm going to mute that. So Juan Caballero is here as a co-presenter, not listed on the page because it was too late of an update, but it was listed in the description. Juan, do you want to say anything? Sure, no, I was just going to say that someone asked in the chat what the best case scenario is and what the primary purpose use cases are. And I think one way of explaining it just as succinctly as possible is that a did is like a universal format or like an envelope or a wrapper for enough PKI information, like the minimum amount of information you need to get and verify someone's PKI. So it's like if it's like a registered entity, it tells you where to go to get the public key, right? So it's a sort of a translation layer for PKI systems, which can be blockchain or not, can be peer-to-peer or not. So really the use case, I think, for dids is that they're just a way to make that stuff travel better. And same with VCs. I think VCs just make an atom of factual information or authoritative information more portable. They're kind of portability-oriented envelopes for data. That was a lot more than 15 words I failed. And as I was saying, as a kind of federation mechanism, I think it could be potentially useful for systems like all the many ones that have been shown today that could use it to interoperate with other systems in certain ways. Does that make any sense? Are there other questions? I think some people are typing in here. Yeah, I mean, I think in some ways portability and translation are assumed to bolt on later. And this is sort of a bolt on for everyone who just built something quickly that just takes advantage of all the built-in PKI and verification of a blockchain system. So a lot of times people building, say, for the purposes of MVP, for the purposes of just building the thing, will just assume every user has an Ethereum account because it's pretty low bar, people can spit up a bit of a mask in five seconds, or just assume, like, just use the central SPKI for now. And I think for, I'm hoping that a lot of open source projects just build against this as a starting point or as a quick way to get from that simplified MVP scope to something that can be a node in the full-stem circuit quickly using this stuff. Like a bridging tool. Right, bridging. It's probably worth mentioning, of course, in regards to the best, I read the question as best use case, but verifiable credentials are maybe probably the main driving one or a big one right now. But best case scenario is, I think that depends on philosophies, but if you think that identifiers that should be decentralized, then it's a good case if it's integrated and adopted into more systems, I would think. And a lot of systems can be using public keys as identifiers, or they're using public key hashes of identifiers. What I did is like a generalization of that into an identifier that resolves to a document that contains verification material, and now I guess to a set of public keys like a PGP key ring. But that's considered the core kernel of what you need to be able to interact in a verifiable way, i.e. through making signatures and interactive cryptographic protocols like secret handshake or libPP handshakes and things like that. And I think in a lot of use cases, in a lot of applications where like content authenticity, for example, if you want metadata to always be linkable, always be findable, right, there's a big problem in content authenticity or big data systems where you can assign metadata to a thing, but you have to make sure that metadata is always findable from the current state of the thing. So dins are a way to do that. You can sort of anchor things in these immutable and or persistent sticky content identifier based mechanisms so that as long as the thing exists, the metadata is findable, the metadata is secure for how to trust it, how to initiate a handshake with it, what languages it speaks, that's a really appealing thing to people who've worked with big data a lot. Well, in the last minute, I just wanted to say great presentations to everyone else. I was watching a lot of them and it's really cool. And I hope these systems succeed and do the best that we can, that anyone can to improve things and all that. Yeah, I hope next full-stim I'm in central European time and not road tripping. Apologies for scheduling it wrong full-stim. I'll see you next time. Yeah, we'll see you all. Everyone's welcome to join the chat.
 Hello and welcome to this presentation of Verifiable Credentials and Decentralized Identifiers  with DidKit.  I'm Charles E. Lainer, working at Spruce Systems, Inc. and this is FOSSTEM 22-22 Web3 Dev Room.  Verifiable Credentials and Decentralized Identifiers are two technology standards being developed  at the World Wide Web Consortium, the W3C.  Verifiable Credentials are a recommendation of the W3C and this is what the specification  looks like.  It's for a kind of data model for verifiable information, cryptographically verifiable  or otherwise, and it has special formats for indicating specific things.  The main data structures are a verifiable credential and a presentation, or a verifiable  presentation.  Here is an example from the specification of a verifiable credential with comments.  You can see the at context for the use of JSON-LD for semantic extensibility, and then  there are the required fields and optional fields, ID type, issuer, identifier, issuance  date, and the credential subject.  The credential subject typically is where an entity is identified that the credential is  issued to, and then there are other pieces of information that are called claims that  are assertions about reality, about the subject, or about the issuer, or about something else.  Then there's the proof property, which is usually a cryptographic signature over the  rest of the credential.  Here you can see the metadata, the signature proof type, and the signature data.  The centralized identifiers are a URI scheme and data model that's a W3C proposed recommendation,  and the specification looks like this.  A DID is a URI that looks like this, and the first part after the scheme is called the  DID method.  In this example, this would be the example DID method.  The rest of the DID is up to the DID method specification.  DID methods did resolve to DID documents, and a DID document example is here.  The DID is in the ID, typically, and then the other information is in the rest of the  DID document.  You can see the use of JSON-LD again, and then this example contains an object for a  public key or a verification method, as it's called, for the purposes of authentication.  DID, KIT, and SSI are implementations of verifiable credentials and decentralized identifiers  and other technologies.  These are being developed at Spruce, and that's what I'm working on at Spruce, largely.  The structure of this implementation is that SSI contains the core library in Rust for  the functionality, and did, KIT embeds the SSI library into various interfaces.  There's a command line interface, an HTTP interface, which follows a pre-standard that's  being developed at W3C, a credentials community group, and there's interfaces for other languages,  C, Java, Python, WebAssembly.  There's native libraries for Android and iOS.  There's a Node.js module, and a Flutter library, and there's also a GoLine.  The did, KIT command line interface looks like this, and here's the links, and the other  interfaces, the bindings to other languages, have more or less the same functionality,  that is, to issue and verify verifiable credentials and presentations, and resolve dids, and do  some key material operations and other utilities.  So I'm going to try a demo, did, KIT, now.  This demo is a multi-part demo to try to demonstrate the different roles that are involved.  In, in verifiable credential issuance and verification.  So often, there are considered to be three roles.  There's the issuer, who issues a credential, and then there's the holder, who becomes the  holder by receiving a credential that they are then holding, and then there's the verifier,  who the holder presents their credential to, and then the verifier verifies it.  So starting with the issuer, good start.  We have a public private key pair here, and we can use didKIT to generate a did that's  derived from that key pair.  Using key to did for the key method, didKIT and SSI have implementations of various did  methods and extensibility to use others, but the key method is built in and allows deriving  a key, a did from a key pair, as well as some of the others.  So we do that, and we get the did here.  Now in the credential that we're issuing, I've started it out here.  This one is pretty bare bones.  There's, normally you'd have some meaningful information in the credential, but this is  trying to be a minimal instance just to demonstrate this functionality.  So we put our did in the issuer field, and also I'll note that verifier credentials don't  have to be used with dids.  You can use HTTP URLs, HTTPS, and other schemes, but when you combine it with dids, you can  get some nice properties.  So there's the issuer ID.  We can put a date in this date field issuance date, and then the credential subject, this  signifies, when there's an ID here, it signifies that the credential is about a particular entity,  and in this case, it's going to be identified with a did, and then later on, the entity that  controls that did will be able to present that credential and prove cryptographically  that they possess the key material that is corresponding to that identifier.  So we pretend we received this from the subject or the holder already, and it's in there.  Now issue this credential, it's did kit, try the command line, passing the credential and  standard input and passing the key pair and redirect this to a file.  That seems to have worked.  Now let's take a look.  And you can see that this is a verifiable credential.  The information from before is still there.  The proof property has been added, which contains this ED255.9 signature over the credential  and the metadata.  So now we would, as issuer, give this to the subject.  In this case, it's a, it may be a person or entity, and they're going to receive this  credential.  So I'm going to symbolize that by moving it into their directory.  Now pretend we're the holder, and we go over there and we've received this credential, and  we want to verify it first to make sure it's verified, verifiable, valid, and all that.  And we can do that with did kit, and that shows the proof check passed, and there's  no errors, so it verified.  Now as a holder, we will want to present this credential to another entity who is called  the verifier.  And to do that, we have to wrap the verifiable credential into a verifiable presentation.  So I've started one here, this is an empty verifiable presentation, it's not yet verifiable,  it's just a presentation, and it's empty, so I'm going to add the verifiable credential  in here, in the verifiable credential property, and then in the holder property, I would put  my did as the holder.  And in case I didn't have that already, I could use the same command as before passing  my key, key, and that's our ID, and I put that in here, the holder property, and now  this should be able to be issued, or generated as a presentation, and again using the key  pair, and saving that to a file.  And that seems to have worked, so we would pass this to the verifier.  Now normally there would be an interactive verification process usually, where the verifier  might provide a challenge, and a domain property, and then those would be incorporated into  the presentation.  But for right now, we're not using that in this demo.  But we can verify it as the verifier now, by passing it in, similarly to with the credential,  and that worked.  And then also as the verifier, we would extract the verifiable credential from it, since this  is not automatic and did kick currently, and verify that separately.  Oops, forgot to pipe it in.  And that worked.  And then again as the verifier, we would do additional processing to verify that the subject  ID is the same as the holder ID, and that the proofs are proofs that we want to allow,  and then things like that, and then look at the actual data as well.  So that's a verifiable presentation.  One more other thing we can look at here is verifying a did, and that would be done with  did resolve.  Sorry, resolve a did, not verify did.  And that returns a did document, looks like this, for did key anyway.  Okay, so that's that.  Back to the presentation.  So I wanted to mention some other implementations of verifiable credentials and decentralized  identifiers.  These are a few of them, and there are others as well.  But Transmute, Digital Bizarre, Denive Tech, Decentralized Identity Foundation, Hyperledger,  and Uport have implemented various parts of this technology.  And there's test suites and interop activities that make sure that they're interoperable.  And I also want to mention some community and working groups.  The decentralized identifiers and verifiable credentials have working groups at W3C that  standardize them, and these have public mailing lists as well.  And then there's the Credentials Community Group at W3C that I want to highlight, which  has public meetings and it has an active email mailing list.  And often on the meetings there are interesting speakers and discussions that take place.  And there are also different work items that happen in there that are pre-standards that  later on maybe they'll go into a standards working group.  At Decentralized Identity Foundation or DIF there are working groups as well, and also  there's Interoperability Open Group, which can be interesting to check out.  And for people who want to make sure that their implementations are interoperable and  explore different topics and issues.  And Identity Workshop is a conference that takes place multiple times a year, and that's  a good place for meeting people and working on this kind of technology.  And Trust Over IP Foundation is also involved in things, and so is OpenID Foundation.  So if you'd like to chat with me or other people at Spruce, we have a matrix room, an  IRC channel, you can email here, and there's also a Discord.  And if you want to contact me you can find me on Matrix, IRC, email, PGP, secure Scuttlebutt,  and on the web.  So thank you very much.  Great, now we've got 30 seconds while streams catch up.  Hello, hello.  So the stream's probably caught up now mostly for buffers, so thanks everybody for listening  or not, and for being present.  And I'm going to mute that.  So Juan Caballero is here as a co-presenter, not listed on the page because it was too  late of an update, but it was listed in the description.  Juan, do you want to say anything?  Sure, no, I was just going to say that someone asked in the chat what the best case scenario  is and what the primary purpose use cases are.  And I think one way of explaining it just as succinctly as possible is that a did is  like a universal format or like an envelope or a wrapper for enough PKI information, like  the minimum amount of information you need to get and verify someone's PKI.  So it's like if it's like a registered entity, it tells you where to go to get the public  key, right?  So it's a sort of a translation layer for PKI systems, which can be blockchain or not,  can be peer-to-peer or not.  So really the use case, I think, for dids is that they're just a way to make that stuff  travel better.  And same with VCs.  I think VCs just make an atom of factual information or authoritative information more  portable.  They're kind of portability-oriented envelopes for data.  That was a lot more than 15 words I failed.  And as I was saying, as a kind of federation mechanism, I think it could be potentially  useful for systems like all the many ones that have been shown today that could use it to  interoperate with other systems in certain ways.  Does that make any sense?  Are there other questions?  I think some people are typing in here.  Yeah, I mean, I think in some ways portability and translation are assumed to bolt on later.  And this is sort of a bolt on for everyone who just built something quickly that just  takes advantage of all the built-in PKI and verification of a blockchain system.  So a lot of times people building, say, for the purposes of MVP, for the purposes of just  building the thing, will just assume every user has an Ethereum account because it's  pretty low bar, people can spit up a bit of a mask in five seconds, or just assume, like,  just use the central SPKI for now.  And I think for, I'm hoping that a lot of open source projects just build against this  as a starting point or as a quick way to get from that simplified MVP scope to something  that can be a node in the full-stem circuit quickly using this stuff.  Like a bridging tool.  Right, bridging.  It's probably worth mentioning, of course, in regards to the best, I read the question  as best use case, but verifiable credentials are maybe probably the main driving one or  a big one right now.  But best case scenario is, I think that depends on philosophies, but if you think that identifiers  that should be decentralized, then it's a good case if it's integrated and adopted into  more systems, I would think.  And a lot of systems can be using public keys as identifiers, or they're using public key  hashes of identifiers.  What I did is like a generalization of that into an identifier that resolves to a document  that contains verification material, and now I guess to a set of public keys like a  PGP key ring.  But that's considered the core kernel of what you need to be able to interact in a verifiable  way, i.e. through making signatures and interactive cryptographic protocols like secret handshake  or libPP handshakes and things like that.  And I think in a lot of use cases, in a lot of applications where like content authenticity,  for example, if you want metadata to always be linkable, always be findable, right, there's  a big problem in content authenticity or big data systems where you can assign metadata  to a thing, but you have to make sure that metadata is always findable from the current  state of the thing.  So dins are a way to do that.  You can sort of anchor things in these immutable and or persistent sticky content identifier  based mechanisms so that as long as the thing exists, the metadata is findable, the metadata  is secure for how to trust it, how to initiate a handshake with it, what languages it speaks,  that's a really appealing thing to people who've worked with big data a lot.  Well, in the last minute, I just wanted to say great presentations to everyone else.  I was watching a lot of them and it's really cool.  And I hope these systems succeed and do the best that we can, that anyone can to improve  things and all that.  Yeah, I hope next full-stim I'm in central European time and not road tripping.  Apologies for scheduling it wrong full-stim.  I'll see you next time.  Yeah, we'll see you all.  Everyone's welcome to join the chat.
didkit_0_923.png didkit_924_1667.png didkit_1668_3719.png didkit_3720_3827.png didkit_3828_4619.png didkit_4620_12227.png didkit_12228_13403.png didkit_13404_15119.png didkit_15120_18251.png didkit_18252_18767.png didkit_18768_22163.png didkit_22164_22967.png didkit_22968_26435.png didkit_26436_26639.png didkit_26640_27479.png didkit_27480_29195.png didkit_29196_30251.png didkit_30252_33107.png didkit_33108_33635.png didkit_33636_34523.png didkit_34524_34751.png didkit_34752_35231.png didkit_35232_35742.png