Verifiable Credentials and Decentralized Identifiers with DIDKit
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 287 | |
| Author | ||
| Contributors | ||
| License | 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. | |
| Identifiers | 10.5446/57014 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSDEM 2022179 / 287
2
4
6
8
12
17
21
23
31
35
37
41
44
45
46
47
50
62
65
66
67
68
71
73
81
84
85
86
90
92
94
100
102
105
111
114
115
116
117
118
121
122
124
127
131
133
135
137
139
140
141
142
145
149
150
156
164
165
167
169
170
171
172
174
176
178
180
183
184
189
190
192
194
198
205
206
207
208
210
218
220
224
225
229
230
232
235
236
238
239
240
242
243
244
245
246
249
250
253
260
262
264
267
273
274
277
282
283
287
00:00
Electronic data interchangeSystem programmingData modelAbstractionTable (information)Proof theoryPresentation of a groupTerm (mathematics)Regulärer Ausdruck <Textverarbeitung>InformationType theorySuite (music)Data integrityRevision controlImplementationFeedbackData typeDigital signalSheaf (mathematics)Formal verificationNumbering schemeContext awarenessAuthenticationInformation securityGame controllerCore dumpCommon Language InfrastructureLibrary (computing)Single sign-onCASE <Informatik>IdentifiabilityFormal verificationWeb 2.0World Wide Web ConsortiumStandard deviationPresentation of a groupoutputAndroid (robot)Interface (computing)AeroelasticityLibrary (computing)Single sign-onCore dumpFunctional (mathematics)Data structureImplementationData modelPublic-key cryptographyAuthenticationLatent heatProof theoryElectronic signatureInformationObject (grammar)Numbering schemeContext awarenessComputer configurationField (computer science)Resolvent formalismFile formatSemantics (computer science)MereologyFormal languageKeyboard shortcutType theoryEndliche ModelltheorieLink (knot theory)Data managementCategory of beingState of matterGroup actionBranch (computer science)Food energyBit rateProcess (computing)Boss CorporationWebsitePhysical systemInclined planeEngineering drawingComputer animation
04:41
Demo (music)Proof theoryPresentation of a groupError messageFormal verificationKey (cryptography)Data typeFormal verificationPresentation of a groupProcess (computing)Utility softwareDomain nameIdentifiabilityCategory of beingExtension (kinesiology)ImplementationStandard deviationPublic-key cryptographyProof theoryOperator (mathematics)Interactive televisionDirectory serviceInformationMetadataElectronic signatureKeyboard shortcutCASE <Informatik>Link (knot theory)Resolvent formalismFunctional (mathematics)Key (cryptography)Single sign-onComputer fileDemo (music)Degree (graph theory)FamilyGastropod shellGenetic programmingGame controllerDampingDescriptive statisticsoutputLine (geometry)Metropolitan area networkMultiplication signComputer programmingField (computer science)State of matterTable (information)Instance (computer science)Error messageSource code
12:30
ImplementationWordInternetworkingMatrix (mathematics)Online chatEmailLimit (category theory)MultiplicationIdentifiabilityEmailStandard deviationWeb 2.0Matrix (mathematics)Lattice (order)Electronic mailing listDifferent (Kate Ryan album)Group actionOpen setGoodness of fitMultiplication signComputer programmingSoftware testingMereologyFormal verificationImplementationIdentity managementInformation securitySuite (music)InternetworkingComputer animation
14:51
Buffer solutionDescriptive statisticsWeb pageShooting methodStreaming media2 (number)Computer virusComputer animationMeeting/Interview
16:06
Formal verificationWrapper (data mining)InformationEnvelope (mathematics)CASE <Informatik>Translation (relic)QuicksortMaxima and minimaFile formatGoodness of fitNumberMobile WebPortable communications devicePhysical systemMeeting/Interview
17:38
WordPhysical systemInterrupt <Informatik>1 (number)Mechanism designMeeting/Interview
18:19
Open sourceDigital electronicsPoint (geometry)Projective planeBitPhysical systemQuicksortGroup actionRight angleBuildingCircleMultilaterationTranslation (relic)2 (number)Multiplication signFormal verificationBridging (networking)Portable communications deviceMeeting/Interview
20:10
Interactive televisionKernel (computing)Ring (mathematics)Formal verificationCASE <Informatik>Right angleCrash (computing)Communications protocolPower (physics)CryptographyPhysical systemIdentifiabilityKey (cryptography)UsabilityGoodness of fitCore dumpPublic-key cryptographyHash functionCartesian coordinate systemSet (mathematics)Electronic signatureMeeting/Interview
22:04
Formal languageObservational studyContent (media)State of matterPhysical systemAuthentication1 (number)MetadataMechanism designMeeting/Interview
23:10
Centralizer and normalizerPresentation of a groupMultiplication signMetropolitan area networkMeeting/Interview
23:29
Multiplication signRow (database)Online chatMeeting/InterviewComputer animation
Transcript: English(auto-generated)
00:09
Hello and welcome to this presentation of Verifiable Credentials and Decentralized Identifiers with DigKit. I'm Charles E. Laner, working at Spruce Systems, Inc., and this is FOSSEM 2022 Web 3 Dev Room.
00:26
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.
00:49
It is for a kind of data model for verifiable information, cryptographically verifiable or otherwise, and it has special formats for indicating specific things.
01:09
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.
01:23
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, issuing state, and the credential subject.
01:41
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, about the issuer, about something else.
02:01
And then there's the proof property, which is usually a cryptographic signature over the rest of the credential. And here you can see the metadata, the signature proof type, and the signature data. The centralized identifiers are a URI scheme and a data model that's a W3C proposed recommendation.
02:27
And the specification looks like this. A DID or a DID is a URI that looks like this, and the first part after the scheme is called the DID method.
02:45
So in this example, this would be the example DID method. And then the rest of the DID is up to the DID method specification. DIDs resolve to DID documents, and a DID document example is here.
03:11
So 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.
03:23
And then this example contains an object for a public key or a verification method, as it's called, for the purposes of authentication. So DIDkit and SSI are implementations of verifiable credentials and decentralized identifiers and other technologies.
03:45
And 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.
04:05
And DIDkit 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, Credentials Community Group.
04:23
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 Golang.
04:41
The DIDkit 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.
05:04
So I'm going to try to demo DIDkit now. This demo is a multi-part demo to try to demonstrate the different roles that are involved in verifiable credential issuance and verification.
05:22
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.
05:44
So starting with the issuer, 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.
06:02
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 DID from a key pair, as well as some of the others. So we do that, and we get the DID here.
06:21
Now in the credential that we'll be issuing, I've started it out here. This one is pretty bare bones. 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'd put our DID in the issuer field, and also I'll note that verifiable credentials don't have to be used with DIDs.
06:48
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 issue ID. We can put a date in this date field. Issuance date.
07:09
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.
07:22
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.
07:45
Now issue this credential with DIDkit on the command line, passing the credential as standard input, and passing the key pair, and redirect this to a file.
08:01
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. Only the proof property has been added, which contains this ED25519 signature over the credential and the metadata.
08:29
So now we would, as issuer, give this to the subject. In this case, it may be a person or entity, and they're going to receive this credential.
08:40
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.
09:06
And we can do that with DIDkit, and that shows that 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.
09:26
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
09:45
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.
10:06
And that's our ID, and I put that in here, in the holder property, and now this should be able to be issued, or generated as a presentation.
10:24
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
10:42
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.
11:05
And that worked. And then also as the verifier, we would extract the verifiable credential from it, since this is not automatic and didCIT currently, and verify that separately.
11:23
Whoops, 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,
11:42
and that the proofs are proofs that we want to allow, and things like that, and then look at the actual data as well. So that's a verifiable presentation. One more other thing we could look at here is verifying a did, and that would be done with didCIT didResolve.
12:06
Sorry, resolve a did, not verify did. And that returns a didDocument. It looks like this. For didKey, anyway. Okay, so that's that.
12:21
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.
12:41
But Transmute, Digital Bazaar, Denimtech, 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.
13:04
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.
13:21
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.
13:49
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 for people
14:00
who want to make sure that their implementations are interoperable and explore different topics and issues. Internet 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.
14:29
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.
14:46
So thank you very much.
15:24
Great, now we sit for a few seconds while the streams catch up. Hello, hello.
15:46
Great, now we sit for a few seconds while the streams catch up. So the stream's probably caught up now mostly for buffers, so thanks everybody for listening, or not, and being present. And I'm going to mute that.
16:06
So Juan Caballero is here as a co-presenter, not listed on the page because it was too late of an update, but it 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
16:25
the best case scenario is and what the use, sort of 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.
16:45
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.
17:09
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.
17:30
They're kind of portability-oriented envelopes for data.
17:40
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 many ones that have been shown today that could use it to interoperate with other systems in certain ways.
18:14
Does that make any sense or are there other questions? I think some people are typing in here.
18:51
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
19:06
just takes advantage of all the built-in PKI and verification of like a blockchain system, right? So like a lot of times people building, say for the purposes of MVP, for the purposes of just like building the thing, we'll just assume every user has an Ethereum account because it's pretty low bar.
19:27
People can spin up a bit of ask in five seconds or just assume, like just use a centralized PKI for now. 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
19:47
that like simplified MVP scope to something that can be a node in the full stem circuit quickly using this stuff, like a bridging tool.
20:09
Right, bridging.
20:28
It's probably worth mentioning, of course, in regards to the best, I read the question as best use case, but verifiable credentials are probably the main driving one or a big one right now.
20:42
Best case scenario is, I think that depends on philosophies, but if you think that identifiers that should be decentralized should be, then it's a good case if it's integrated and adopted into more systems, I would think.
21:12
And a lot of systems can be using public keys as identifiers or they're using public key hashes of identifiers.
21:20
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
21:40
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 PGP handshakes and things like that.
22:04
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.
22:25
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
22:44
or persistent, sticky content identifier-based mechanisms so that as long as the thing exists, the metadata is findable. The metadata for how to trust it, how to initiate a handshake with it, what languages
23:00
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 presentation 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.
23:28
Yeah, I hope next full stem, I'm in Central European time and not road tripping. Apologies for scheduling a wrong full stem. I'll see you next time.
23:42
Yeah, I'll see you. Anyone's welcome to join the chat.
Recommendations
Series of 9 media