Decentralized ID Technical Mastery Sprint for IT Architects and Project Managers

Welcome to this second pre-Conference Workshop of the day. It's Tuesday, it's EIC 2024. Really looking forward to that event. Really looking forward to this workshop. And first of all, I want to introduce you to two, actually three people that will actually make the workshop today. First I start with Kim Duffy Hamilton. I have Steve Mcow. They will introduce themselves, I think, a bit more in detail later on. And we have Sam Curran over there who will do a demo later on. So really looking forward to that. I did the house cow keeping already, so still some seats left.

So if you want to sit rather than stand in the background for two hours, that should be doable. And yeah, without further ado, I would like to hand over the microphone to Kim first and then to Steve. I think you, you're playing back and forth and please welcome Kim Duffy Hamilton, Steve McOwen. Hello. It does seem to be working.

Hi, I am Kim Hamilton Duffy. I'm just introducing myself for now. We'll have Steve McOwen kick us off. I'm executive director of the Decentralized Identity Foundation and I've been involved in decentralized identity for about seven years. I first started becoming interested in it when trying to solve the problem of how do you make learning and working credentials that, that you've earned throughout your life, continuing to be usable, accessible, and manageable by you. And so that took me a bit down this rabbit hole of decentralized identity.

And yeah, so here I am. And Steve, yeah, Thank you. I'm Steve McCown and I work with Kim as a member of the steering committee. And are we good? I can talk loud.

Otherwise, I'm also a chief architect at Anatomy Labs where we make software to help you manage your various identity segments. So Maybe just to interrupt, I've opened the first poll. The question is, so please, please go ahead. Okay. The question is, how familiar are you, you, and you remotely available in that call as well with the concept of decentralized identity.

And you can answer between very familiar, somewhat familiar, have heard of it, but don't know much and not familiar at all just to lay the ground for this workshop and to understand where we are also for this, for this crowd today, which is great. Thank you. So I will close down the, the poll in some five minutes and then we can use the results whenever you want. Thank you.

Okay, thank you very much. Are we on now? Is this good? Okay. I like my presentations to be interactive, so if you have questions, feel free to just interrupt and raise your hand. They'll bring you a microphone and I would enjoy that. So it's a pleasure to be here my first time to Berlin. And so thank you all for coming. Let's go ahead and get started. So we also have a spacing problem. So we have a security problem and we all know that that's why, kind of why we're here.

We also have a privacy problem and that's becoming more and more apparent and we're seeing governments get involved and, and helping us out in that regard, helping us move forward. So part of my background is I worked for, you don't have a lot of years as a red team researcher, so think hacker. And so a lot of what I do takes on kind of that motif. So our security problem, there was a report that came out a couple of years ago called Account Takeover in 2002.

And what this report demonstrated was there have been 25 billion login credentials leaked to the dark web over time, and that that was a 65% increase over 2020. So this is the world we're living in where our login credentials get get leaked and they're just out there. But the thing that should scare you and all of your companies is that 98% of organizations have vendor relationships with at least one party that has experienced a breach in the last two years. So you are inheriting that association. So that's part of our security problem. Now that lead leads to privacy problems.

So the odd hard card from India, not to pick on them, but it's just a really good example. In 2023, 815 million cards with all their associated card data ha were leaked and they were posted out on the dark web for sale. And that's what that little black square, it's hard to see. That was the hacker advertising all of that for sale. So that had personal data. Think everything that goes into your passport, everything that goes into your national ID or driver's license along with biometric data. So the data related to fingerprints and IRIS scans and all of that was leaked and for sale.

So the privacy problem comes in when that card is used for all your government services. It's used for voting for passports, for KYC payments, banking, cell phones. It kind of cascades into, into everything. So the security problem we started with now led to a tremendous privacy problem. And what do you do when your biometric data has already been leaked and associated with you? So that is a huge problem. All of that happened on the heels of a 2018 attack where 1.1 billion cards were also disclosed and made for sale. That was basically the whole network.

And so this is, this is the world we live in and as we saw in the previous slide, it's increasing year over year. I really liked this. It leads into why we're all here. Identities are the true hackers objective. That's what hackers are after getting your identity data because of what they can do with it. They can use it for identity theft, they can use it for getting, getting loans and voting and all the, all the things that, all the, all the things that we do in everyday life. So what I'm gonna do now is I'm gonna walk you through all the aspects of decentralized identity.

We're gonna do it kind of quickly, but this hopefully will get us all on the same page about what is decentralized identity and how can you put it to use. So most of us, when we think of our d our identity, our decentral, our digital identity to start with, what it is is it's our email address I'm Steve at. Otherwise we think of what's our phone number, our credit card number, some handle we have on a social network. And that's what identity has meant to us so far. And so there's a couple of problems with that. Get that email address that seemed just so neat to get.

You're kind of locked into that email provider. Changing emails is, it's a hard thing giving out the new address. So part of what happens is they give you that email for free so that they can monetize you, they can watch your data, watch your actions, watch your communications, and that feeds into AI algorithms. That creates a profile about you. And so privacy is not so strong in places where you get that handle, you get that identifier and you get it for free. That's it's all, it's all monetized. Your data is sold for ads.

So the question that we wanna ask now, especially when we see these attacks happening, can you upgrade that security? Can you upgrade the security of quote unquote your email address? The answer's no, not really. Can you control your private data? Nope. That's part of the terms of service and privacy agreement that you signed.

When, when you accepted that email address or that Facebook handle or the Twitter handle or whatever it is, whatever network can you interoperate with others outside of the network, that's often not true either that you can't do that, you operate within the parameters of whatever the terms of service are. So currently, hopefully that's readable. Our current trust architectures, they're, they're pretty good in a lot of ways, but they have a few problems. So we're working to secure our interactions to secure our connections.

We have H-T-T-P-S and Secure Socket layer and every year those standards advance. So some of the questions I have is, do you feel secure in that relationship right now? Do you feel secure logging into your email provider, sending an email to someone and receiving an answer?

Are you, are you secure in that you are in the back? Let me, let me ask you a question. Most of us are from out of town, so we're staying at hotels. We get onto the hotel wifi. Do you feel secure on the hotel wifi? See a lot of no, and that's a good answer. That is the right answer. So we think we're making these big security advances and we are secure socket layer today is stronger than it was 10 years ago. The problem is we're also setting ourselves up to do different things than we did 10 years ago as well.

So this little thing that's hard to read, but you'll be able to pick that up in the slides I was reading through Broadcom's. It's called the SSL Proxy Deployment Guide. Page eight to 2020 edition updated 2024. Here's what it allows you to do. It says you can determine what H-T-T-P-S traffic to intercept through existing policy conditions.

You know, that's what I just said. They can intercept H-T-T-P-S by design, break the connection, break that encrypted route relationship, scan your data for whatever it is they're scanning for. And you don't know that that's happening. And there's a whole section in, in that manual that describes how that's going on. And so the world we live in, we have these security problems, we have these privacy problems, and now we're seeing that while they're getting solved, they're also being a little bit broken at the same time because analytics and, and data monitoring has become a, a focal point.

The other question I always ask in any of these systems, whenever you see, whenever you see someone say, we use a ES 2 56, we use elliptic curve, whatever we use post quantum, it is gonna keep happening. The question you need to ask in every one of those situations, the algo algorithms are awesome. The question you need to ask is where do the keys go? You have cloud services, oftentimes those keys are stored in the cloud and they're stored in these systems that often, often get get breached. So this is the world we live in.

We're we're working to make things better, but we've got these competing interests when it comes to analytics gathering and data monetization. So now we've got this thing called decentralized identity, and I'm probably who's working with specifically with decentralized identity, okay, quite a few. This changes things a little bit. So this is a little bit of an advertisement slide. So decentralized identity tries to put you back into control and it lets you do things like creating your own identifier. And we'll talk about what that means.

And it, it promises end to insecurity and we'll talk about that. That means, and you can choose your own email provi or your own providers of whatever, whether it's email or texting or whatever. There are revocable connections you're in charge of, of those connections and those relationships. Break those when you want to, and then you can share data. And hopefully what this all gives us is, is increased privacy. All right? So decentralized identity is enhancing trust. So trust today is kind of this diagram right here.

You have party A and party B, they can trust each other because they trust a third party. Now that's important if as long as we have this third party trust, there's opportunities for problems, for issues. Who remembers the digi note or attack from a number of years ago?

Okay, so what happened there? So we have a certification authority.

It's, it's meeting all the requirements, it's using the right crypto algorithms and what happens, they get hacked. And so then their service that everyone is set up to trust starts issuing certificates, web certificates. And so you think you're logging into one website and that web certificate is supposed to help you cryptographically verify that connection, but it was issued fraudulently. So now you're trusting something that isn't trustworthy. And so things like this can happen under current paradigms. And that's what decentralized is trying to, to overcome.

It's not a bad model, but there are some fringe cases where that does become a problem. So decentralized identity di changes how that trust is done. And we're gonna talk about things in the next few slides. What's a decentralized identifier? What's a did document? What's a verifiable data registry credentials And also zero knowledge proofs. So we're gonna walk through those quick.

Again, if any of you have any questions, please just shout 'em out or raise your hand, Give quickly to, for, for the poll results. So if you can bring up the poll.

Yes, of course. If you can bring up the poll results, that would be nice. So at least that you know that the work was not in vain for, for answering the, the poll. And it's quite a, a heterogeneous group of people. If this doesn't work out, I I can just read it out. That's no problem.

Oh, here we go. Oh, even in a diagram. So we have somewhat familiar, it's leading, so 49%. So there is a group of almost experts here. We have experts, but we've also people that are eager to learn more from what, what Steve and Kim will be talking about. That's a great group for of, of people. Thank you very much. I will open another a poll later on if you have a look at it. Otherwise I don't interrupt more back to you. So if you go back to the slides that, that Steve is presenting, that would be great. Am I supposed to do that?

Okay, there we go. Thank you.

All right, so now let's dig into the individual components of di. So the first one is what's a did? So you'll hear that name throw thrown around a lot. It's a URI think like URL, it's very similar.

So I've, I've illustrated a comparison. So with regular web URLs, you have the scheme, which is H-T-T-P-S, and you have part of the address, which is a website, and then you have a, a little designator for the webpage. And we use those all the time. So it should be very familiar with DIDs. It's kind of the same thing. We have a scheme, it's called dead. And then we have what's called a dead method. And we'll talk more about that. And that's very kind of similar to what would we would call a website and IT and on the regular internet. And then we have a did specific message string.

We'll talk about what that does. So this is your identity, this becomes your identity. We'll talk about what the DID method does and why that's a little bit different than an say an email address with ds. There's two, basically two types. One is a D that's based in a verifiable data registry, think ledger, think blockchain, think whatever. And we'll talk about that.

There's a, a variety of ways to do that. And then you also have DIDs that are peer DIDs. So between me and you, between you and you direct to another party, not through a third party. And you can create those and it will inherit a lot of these cryptographic protections as well. And so the purpose of this is that your did will be resolved by a DID method and that will point to a DID document, A did doc we call that, that has a lot of things in there. I have another slide, we'll talk about what that means.

But what's neat about this is there's lots of DID providers and the core component of all of this is they become interoperable. So if you want to go to a DID provider and of your choice and pick one, and I go to another of my choice and I pick that one, the protocols of decentralized identity allow you to be interoperable even though with your, you're with different providers. And so if you think of your favorite cryptographic Chat app today, that's not the case. You get that cryptographic chat app and if you want to communicate securely with someone else, they have to get the same app.

And that's a little bit of a problem because there's so many apps out there, we can't all use everything. But what one of the main promises of decentralized identity is EmPro interoperability between these secure sites, between these secure walled gardens. All right, so let's talk about a dead doc. What goes in there? This is an example. It's meant to be an eye chart, so don't worry about rating it. I I pulled that out of one of our standards documents, things that go in there.

Well, what you wanna do when you exchange DS with someone as you want to communicate with them. And so the communication aspects of the DID doc will specify what the service endpoints are, where you need to go to communicate with them. They'll tell, they'll have basic protocols, how you need to communicate with them, and then there'll be security stuff in there. So there'll be public keys will be in there as well. And so you'll know now where to communicate, how to communicate, and then you'll have the cryptographic public keys necessary to do that communication.

And so, so what makes these secure and how you trust them. So think back to the website model where you trust the website is the correct one because you trust the the certification authority. There's a something simple similar here, but there's a variety of ways to do that. And we call that a verifiable data registry. And it's used to securely correlate these did identifiers with these did docs so that you can download that and then communicate with whatever party. There's a variety of ways to do this. So there's a decentralized ledger, sovereigns a pretty good example of how that's done.

There's a centralized ledger. You might find a service that offers a ledger, but they manage the whole thing instead of it being decentralized and and replicated across parties. And that's a valid way to do it. Blockchain, Bitcoin, Ethereum, those are all good ways to do it. Others have implemented their verifiable data registry as a secure cloud storage. Others put those DIDs and did docs on regular websites and that's another way to do it. There's yet another way that uses transaction receipts.

So I talked to you a couple of times, talked to you a couple of times, now you can both trust each other if you trust me. And so there's a variety of ways to put these together. But the idea is that a verifiable data registry, it's immutable, can't be changed. It's decentralized. So we tried not to want things stored in one single location. It needs to be privacy preserving. So most if not all of these VDR methods will, you don't wanna put personal information on there so you don't put your name, correlate that with a dead doc. That's a big no-no. And all of these need to be be secure.

So you have your, your verifiable data registry, you have what interfaces with that for you is a did, did method. Okay? So I've listed over here a number of DID methods, think back to that scheme and did method and and data specific or did specific string. So did methods can be anything. So sovereign was one example here in Europe, there's the EBSI platform, jcom, polygon, Bitcoin, Ethereum. There's a whole bunch of different ways and that's one of the benefits is you don't have to just go to one provider, they're all interoperable. And that's the goal.

So you can pick one of these because of reasons that are purely your own. Do you like Bitcoin? I've had people say yes and people say no. Well pick one or don't based on on your preference. But following the standard protocols, you'll be able to interoperate with others even if you choose a different DID method than they do. So there's just lots to choose from. Now some are more secure and some are less secure.

I, I mentioned a minute ago that you can take a did and a did doc and correlate them and put them on a website. We call that dead web, dead colon web. Is that secure?

Well, it's not really any more secure than things we have today. So there's some issues with that. But it's easy to test with, it's easy to set up and you can interoperate with that as well. So the trust comes based on what you trust. You don't trust dead web to be secure. Don't talk to someone with a dead web address. You trust it. That's great. And in either case, all interoperable. So you get the choice of what you trust.

All right, so resolving did, so right now, if you wanna resolve a web URL, you go out to the DNS, right? And so it's this central, central site where it links engli or, well not English, but human readable names with IP addresses essentially. And so you can go there and you can look up and figure out what address you want to go to. DIDs do the same thing. There's something that we at diff have called the universal Resolver.

And so there's a whole bunch of these different DID methods, and you can use that to look up things about that, that VDR registry where how to, how to get from a did to that did doc. Now you don't have to just use ours again, DI is about choices. So Checked is another company and they've provided one. There's a number of out there and you can even host your own if, if you would like to.

Again, it comes back to trust. If you're hosting your own, do you trust that?

Well, maybe, probably do others. Well that's up for them to decide as well.

But again, all this is interoperable. All right, so now we're gonna store this.

We, we get a, did we download all this information? We're gonna do verifiable credentials in here at some point, and we're gonna need to store this. So we need a wallet.

And I, I tend to laugh at this term, it's, it's, everybody wants to be the wallet provider. There's a million wallets out there. And what they do is they, it's a secure local database and it's often embodied in an app.

So I, I tend to view wallets as more like apps. And you get them from whatever provider you would like. It might be your government, it might be your bank, it might be a club you'd be able belong to. It might be whatever you want. And it will store all of that information. And that's really what it is.

Now, again, you get to choose the wallet you use. Does it store it as a, as a little database on the device? Does it use the secure element? All these wallets will have different pros and cons that you'll get to, to choose from.

All right, now verifiable credentials, this is kind of the big thing we're all talking about. Yes, Go ahead. Just one question that came in from, from the audience, don't did automatically lead to a linkability problem. That's a question that arose from the, from the audience, a linkability problem that comes through dds with the use of dds, what would be your answer? Do they have a linkability problem? Right? I what is meant by that? I'm not Sure.

Yeah, my impression that they mean correl relatability. So I think that's what is meant. I think so. I think so. So is this merit's problem? Is is the dealt with or Okay, that's a, that's a good question. So one of the things I kind of skipped over, if we go back a couple of slides, a lot of slides, let's see, let's see, where was it? So there's right here. So there's two types of ds. One is we anchor it in a verifiable data registry, it becomes very public. So this goes back to your correl correl relatability problem.

So if you are a website provider, if you're Microsoft, if you're Yahoo, if you're Amazon, you want your dead to be as public as possible. And is there a correl relatability issue with that?

Oh, absolutely. But you want it. So the thing about pure DIDs is if I create a relationship with any one of you, this dead relationship, will it be embodied in a peer did. So a peer did is strictly between two parties. I guess it can be multiple parties, but it's intended to not be this public correlatable identifier. And that's what's really neat.

So each, each did relationship will have have its own set of keys, all the information that's in a did doc that will be duplicated on a person by person basis. So if, if I connect with any one of you and we establish each our peer DIDs that are now communicating, and then I go to someone else and do the same thing, different DIDs. So it solves the linkability correl relatability problem by having a different cryptographic relationship with everyone you come in contact with.

Now, if you go to somebody who does want a, a public VDR anchored did, you can also use that to spawn off a peer did relationship that is unique to them. And so in, in doing that, there's not gonna be this, you know, steve@gmail.com type address that everybody uses and everybody can correlate and track against instead these cryptographic relationships or DS will be unique to each connection.

Hey, thank you. There is one other angle I wanted to add, and this is jumping ahead a little bit, but we'll talk about credentials and verifiable credentials. So one question that comes up is, yeah, this is way ahead, but, so within a credential there can be a did, did can be used as the issuer and the subject and how do you bind that subject to a person? And we call that holder binding. And so some of the concerns that have come up, say for example, in the EU wallet was the idea that that would, you know, lead to unintended disclosure. And that's not necessarily the case.

There are opportunities to do private holder binding, but again, that's several steps ahead from where we are right now. So it's probably best to just resume with the flow. Absolutely. Thank you very much. And so if you have to click all these slides forward again.

Yeah, so, but thank you for answering that question because it was did, did related. Okay, so verifiable credentials. So that correl relatability problem is, is a, is a good issue to be aware of and always keep that in mind because one of the promises of decentralized identity is we enhance your privacy by letting you maintain separate relationships. So if you come across something that seems to be contrary to that pay, pay close attention and you can do things differently. A lot of what you can do in this environment is it's up to individual discretion.

So now with verifiable credentials, these follow, so you have your did and you know how to resolve it, you can create one between parties, the verifiable credentials or digital credentials, sometimes we refer to them as reusable credentials. They come under a variety of names. The idea is that they will embody the same data that you find in traditional credentials. Your driver's license, your passport. They may also incorporate biometrics. Hopefully we don't link actual biometric data to these credentials.

What we want is a representation, a cryptographic representation, the ideas for these to be electronically issuable and presentable and go through cryptographic processing to verify these credentials as they're requested and proven. One of the big things about this is selective disclosure. So if you hand someone, maybe it's the hotel, maybe it's whatever your passport or you need to show your driver's license for something, usually what they do is they can scan or read and make a note of any or all of the information on there.

What's your home address, what's your height, what's your weight, what's your eye color? Are you a donor? They have all these kinds of bits of information that when you present that credential, you're presenting all of it. One of the things about DEI verifiable credentials is what we call selective disclosure. So if somebody says, what's your home address? You can decide first of all, but you can give that home address and you don't have to give your height and your weight and your eye color and everything else that's in the credential.

And so selective disclosure means someone can ask for one element of your credential and you can decide whether to give that Yes, a bit closer to the microphone, please. Oh, sorry, sorry, my hand gets tired. Verifiable credentials kind of work the same way they're issued by an issuer and they're often anchored at some point in a verifiable data registry. Not so much each individual credential, but the issuer's ability to issue and prove.

And then later you can prove that that credential came from that issuer verifiers will be able to also reference that verifiable data registry to be able to prove that that credential was accurate and authorized. And notice there's no line between verifier and issuer. And that's an important point. A lot of times today, if you're issued a driver's license and you prove that digitally somewhere, that wherever you prove that, that's verifying your credential jumps back to the issuer to say, is this still valid?

And what that does is it creates what we call a phone home scenario, which is really kind of a privacy challenge because if the issuer gets no notified every time you use their credential, then all of that creates more tracking than we had before. And so in the decentralized identity approach, cryptography is employed in such a way that the credential can be issued by an issuer and later verified by a verifier without either of the two communicating together. And that's very important because that maintains your privacy. Another aspect that that we've created is what we call dicom.

And together with Sam Curran, I'm one of the co-chairs of the DICOM working group over at diff think of this like a message passing paradigm where the messages are secured with dead based keys in cryptography. And so it's very much a message passing paradigm, but the design of each message is cryptographically authenticate or it can be private as in encrypted. And so it's, it's really easy to use, it's a standard with lots of providers and that's how we can communicate securely, both in terms of encryption and in terms of authenticating each party of the communication.

So back to where I mentioned the hotel wifi, if you're connecting with a DICOM connection over the hotel wifi that we talked about being insecure and subject to man in the middle, if you connect from your computer to somebody's computer somewhere else, that encryption is, is totally separate from whatever the hotel might be doing. So you might be running on an insecure network and still be able to have secure communications because the cryptography is separate from the transport protocol. And that's a real quick overview. There's a whole lot more to that.

But that capability exists to message between clients wherever they happen to be. Since it's did based, we're back to the same thing. What you have DIDs, you have did methods, that is the basis of the did come communication protocol. So you're not just limited to somebody who chose your same provider. You can choose different providers and then they'll work together. All right, one of the things, and I'm setting this up for Sam, who's gonna give a demo here in a few minutes.

One of the things we looked at with this, with decentralized identity, with the standards we've been creating and any other system out there, the question comes up, this is awesome, I want to adopt this. I I wanna put this whole thing in place, but the company I work for just spent $10 million to put in another IM system. Are you telling me I have an either or alternative? And the answer's no. One of the things that we're pushing with DI is interoperability between systems.

And so in this case, what will be demonstrated here in a minute is taking an open ID system and being able to do an open ID authentication that spawns off a did based, did com connection. So now what does that give you? You don't have to leave the security identity system you're using in order to take advantage of some of these new advancements that we're presenting. And so that's really neat. It changes the value proposition when you don't have to tell your employer, yeah, we shouldn't have spent that $10 million, let's use this better thing because they don't like carrying that.

And so this way you can piggyback the two and couple these systems. So that's what we'll demonstrate here is doing a a, an open idea authentication followed by spawning a DICOM connection. I'm Sam Curran.

I am, i I I work, I'm employed by in dio, we are adopt open source stuff and, and, and provide solutions for them. The okay, so, but the work that I'm presenting here is actually not mine ID union began a project that they've asked me to present a up here today. This is ongoing work, but, but with some good initial success. And here's the repository if you're interested in looking at it. This is here on GitHub and it, there's some, some background that I won't read all the way through here, but it, it has some background on the open ID for for VCI and VP protocols.

Those are of course lots of interest to the folks here in the European Union and, and the ID Union project needs to adopt those protocols because of the, of the designs that have been created here in Europe. But they also had some use cases that were not met purely by the Open ID protocols and they were already accomplishing those with DICOM and they needed a way to put these together. And so what they have done, there's more background here.

What they've demonstrated here is some minor additions that don't invalidate in any way the use of of the Open I protocols, but that can allow or facilitate the, the, the coordination of a, of a DICOM relationship at the, during the process of an issuance or a presentation of a verifiable credential. And so I won't go into too technical detail here, but there's some additional information included in the issuer metadata that that can be used to make that happen.

There is a, there's an additional scope included during, during a, an access token request, and then there's a, there's a DICOM protocol that is used to present that token and therefore correlate the session. And so that's here and it's available for reading, but everyone loves a demo, so let's hope the demo behaves with the wifi. What I'm gonna do here is I'm gonna run, and this is of course both running on a, on a local environment here, but there is software that uses the, that supports both the open ID for VCI protocol that we're using here and supports DICOM running together.

These are, it uses Vemo and the FERION libraries in order to, to produce the demo here that's in the same repository. And so what I'm going to do is I'm going to run an issuer here and create an offer. And so this is all open id, I will then take this open ID credential offer and I'll pass it to the other party. And then a lot of stuff's gonna happen here in quick order.

Ping, this was working earlier, but with more folks on the wifi, we'll see how, how, how it does. All right, there we go. So a handful of things happened and the, the first thing that happened was that the, the client on the right hand side here retrieved the, the issuer metadata noticed that, that the issuer had specified that, that they required a DICOM connection in order to issue the credential. The credential is still issued over open id, but they wanted to make sure that they had a DICOM connection before they issued that credential. In this case, they can also be stated as optional.

That's just the way the, the protocol was designed to, to handle both of those. Then the, the access token was requested and received w with a DICOM scope attached. It then uses a DICOM protocol to communicate back and forth between the two parties to present that token, thereby correlating, you know, by permission of the, of the scope on the access token, the open ID interaction with the DICOM relationship. And then after that's done, then the actual credential, the, the actual credential presentation actually happens.

So all of the credential stuff happened with the open ID for VCI protocol and then the did come relationship was, was either created or an existing one correlated as in the same part of the process. The Oh, nice. The the end result of this is that you can, I'm gonna have to re restart the, that piece of the demo here. The end result is that you end up with a DICOM connection at the end of that exchange. There's lots of things you can do, you can exchange credentials over over dicom, but that's not the point of the demonstration here.

The point is that you can, is that you can exchange other things. One of the things that it's used for is that you can send messages that are intended to be presented to the user in order to give them a, to, to smooth over a user experience or explain something as part of the process. One of the other advantages of, one of the other advantages of doing this is that you can actually have multiple interactions that you have with the other party in OpenID, you typically have one sort of exchange that you're going back and forth with.

And so if you're going to issue them a credential and then you want to issue them another one, you need to be able to present, you know, another sort of beginning part of the process in order to make that occur with a, with the a DICOM connection, you can facilitate fu future interactions, like for example, passing an open ID credential offer at over a DICOM message, and then the creden, the issuance of that credential can actually happen over the same open ID protocols themselves.

And so as a quick example in the, in the demo here, you can then use this active real DICOM connection between the, the client, you know, the, the issuer and the, and the, and the typically the credential holder in order to send these bi-directional messages. And this is of course just a really quick example of what DICOM can do, but all sorts of interactions are possible here in order to make that happen. And this solves the, the ID union problem where they needed to support the Open ID protocols, but they had use cases that went beyond the capabilities of the OpenID for VCI and VP specs.

And this allows them to both be used together. And the, the point here is that you can combine these technologies and, and, and, and make them work together instead of having to wholesale swap from one to another in order to, to implement this, this stuff and make it happen. So there's kind of a lot here, any questions that I can answer about what happened or what or what's happening here. So everyone's totally satisfied or, or lost somewhere in there.

All right, thank you. Okay. Yeah. Well thank you. Thank you Sam, very much for demonstrating that. So what you just saw was adding DI capabilities to an existing system, in this case open id.

What I, what we want you to take away from that is you can add using the same type of meth methodology, you can add DI capabilities to the systems you currently have. It's not an either or proposition. You can do this incrementally. Actually we have a few questions from the audience.

If, and you maybe you can have a seat, we can sit down and answer them, right? Some of the ones we'll be getting to shortly, but I can read out some that would be good.

Now, so does, did web have the phone home issue is one question? I can take that or you can. Okay. So did web and phone home. When we're talking about the phone home issue, a common scenario of that would be you have a credential, so let's stick with the mobile, the driver's license use case. And so you're going to use your credential somewhere. And the question is, does the verifier go directly contact the issuer? So ignore the fact that we're talking about driver's licenses because that pulls in a whole bunch of implementation details.

But say if you were just using verifiable credentials, in theory it would not, even if you're using DID web, it would not have to incorporate this phone home. So what would be happening is that there's a, a query on the the website, which you know, is, is being used to resolve the did the DID keys. It's not necessarily tracing it to you though as a person. So another aspect where phone home comes up though is so verifiable data registries are used to anchor identities. They're also used to anchor credential status. So issuers wanna issue credentials.

They, you know, they're portable with decentralized identity, but they issuers still wanna be able to control the, the state of the credential. They wanna be able to revoke it if it later turns out they were issued an error. So did web has no bearing on the credential status part as well. And credential status registries can be implemented in a privacy preserving way. Is there anything you wanna add to the DID web question specifically? Yes. One of the things to be concerned about with did web, first of all, let me just say that it's, it's quick and it's easy for testing it.

It's, it's excellent. The complexity is fairly low. The question is how much do you trust your website not to get defaced? And that's the trust question that when it comes to DIDs being anchored on, on did web is how much do you trust the attackers not to be able to modify something on a website? There was a famous hack a number of years ago when ICOs were a good thing where a company put their wallet address on a webpage and you were supposed to send them money and they would send you cryptocurrency.

Well, right as the ICO was launching a hacker hacked in and changed the address to their wallet and many millions of dollars were stolen in the first two minutes. So how much do you trust your, your website to remain secure and unmodified when it comes to did web? That's the question you need to ask. Yes. So Sorry, because of the online audience, we have to pick it up with the microphone. Thank you So much.

This has been so interesting and I want to follow on the previous question about security, but how can you, how do you address the correl correlation problem with the verifiable registry? So I think, okay, there's several concerns with correlation and I'm trying to think of which one is most relevant here.

So okay, say when, when someone is using a credential, someone, Mike's happening, oh, oh, it's you, okay. When you're, when you're using a credential, right? So there there's several, several forms of correl relatability that we might worry about. So one would be, for example, can the, can the issuer learn that I used this credential somewhere that solved more through the, the status verification. And there are privacy preserving ways of doing that, even just using web-based techniques so that for example, the, the verifier doesn't have to query the status of a credential for me.

They're querying, they can effectively get the whole set and then pick out what they want of it, but the issuer doesn't learn who was doing that. And there are even more privacy preserving waves involving advanced cryptography. Another concern with correl relatability would be across verifiers or relying parties. And that touches on some of the first approaches that we talked about.

So the idea of every time you use a credential using, you know, revealing slightly different bits of information about that so that two relying parties can't work together to find out a more rich amount of information about you. And that, that happens in several ways effectively at issuance time.

The, the DIDs that they're issued to would be unique DIDs or you don't have to reveal that did you can sort of, it's through zero knowledge type proofs you can reveal that that is bound to you, but that it's, you're not revealing that in the clear so that people can work together to reveal information. Yeah. Thank you Linda. Great question. We have a couple more that I'll try to get through quickly. The rest that I see so far I think are covered in our subsequent questions. So is it just for customer identity? What about other types of identity?

This seems to be about identity verification and not just authentication and authorization. So organizational identity, what do you, do you have anything you wanted to add on? Is it just for customer identity? This can be used in a B2B a B2C, C two C kind of format?

Well, what we're talking about with decentralized identity is the ability to cryptographically prove that the party you're intending to communicate with is the intended party. And that when you talk to them yesterday and now you talk to them to, you're talking to the same party. It doesn't matter what the parties do, whether it's a business to customer relationship or two individuals communicating the protocols that we're talking about in this type of architecture applies evenly to all scenarios. Thank you.

And we have one more spicy question, which is great and I'll I'll I'll make you answer it. Oh, thanks. Okay. Decentralized identity puts all your identity keys, proofs and secrets into your mobile phone. Okay. But now when you integrate government issued strong identity and proofs to the mix, isn't that a bit too much in Apple, Google, Samsung, et cetera? So maybe first we want to detangle the, the, the first part of it. So the first claim was that decentralized identity puts all your identity keys, proofs and secrets into your mobile phone.

The phone is certainly a very convenient mechanism to store these, to host your wallet, to store the keys. Modern phones come with a secure element that has a whole bunch of hardware security options available to it. But it does, none of this needs to, it's not inherently phone specific. You could put this on, on your, on your computer.

You, it needs to be on some computing device, but you could put this on your laptop, on your desktop. Doesn't necessarily need to be in the phone.

Okay, we'll we'll leave it at that. That's a good point. And so yeah, the rest will, I think we'll get to any extra at the end and now it's my turn, So in the next part of it. Great.

Yeah, we'll stick on slides. The next part of it we're getting to some more questions about implementing these in real systems. So some of the questions in the chat had to do with how do you pick a did method, how do you make sense of all this, how do you get started? And we actually have a demo at the end that we'll get to as well. But we'll start first with some practical considerations. So we call this architectural patterns in best practices. I don't know why I put this slide in here.

I, this is just to, I shouldn't start by overwhelming you, but there's a lot of different ways to think about the landscape of SSI standards and protocols. We'll be getting into a bit, well actually Steve covered a survey of these. We talked about digs and signatures, verifiable credentials in frameworks. We touch briefly about verifiable data registries and in that are the sort of like, how do you establish trust in this verifiable credentials?

So the, the great benefit of decentralized identity is anyone can issue any claim about anyone, right? So do I take Judith Fleener issuance of a credential that I can drive a car who well, so can I get someone to accept that? And so trust registries are really the framework around, you know, how can you establish trust in a given credential. And so there's a lot of great ongoing work there, product offerings. So that's one way to think about it. How people are rolling out decentralized identity and then industry service, there's some really exciting work going around.

Some of the most fascinating work in my opinion is happening in diffs travel and hospitality group. Mainly because it takes in the full range of identity claims. It might involve your government ID if you're crossing a border, but also it could include simple preferences or self attested claims that no one has any right, but you to to state. So I prefer a window or aisle seat and everything in between to loyalty points, things like that. And a range of business models.

So in terms of architectural patterns, some aspects start out with, okay, so how do credentials get into wallets and how do issuers obtain a did from a subject or holder? And then also how does a verifier or relying party describe the information or the types of credentials that they need from a holder. So we've seen a lot of patterns emerge over time.

The, the fact is that decentralized identity methods are, are unique in that if you're issuing a credential, then the credential is issued to someone's did, then how do you get that did in the first place? So that's either a first step where the, the individual, you know, sort of entered it directly, which is not very feasible.

Typically what happens is a combination of deep, deep links or QR codes or even DICOM methods might be used to kick off the process and establish something where say I the user am, am scanning a QR code with my mobile app that kicks off the flow where the, the did generated by my wallet gets sent to the issuer, then they issue the credential, which gets sent back, sent back to me. Let's see, then a similar thing happens on the verifier or relying party side. So the verifier wants one to many of my credentials or they may want just parts of it.

They may be able to express that I just need these types of information and maybe the set of tools I'm using supports zero knowledge proofs or selected disclosure. So what happens in this case is the holder will similarly scan a QR code, deep link, et cetera, and the verifier will end up exchanging information to my wallet, which will package up the information that it needs in whole or in part sign it and pass it on to the verifier. So as you can see, you know, when you, when you think about it, one or two credentials, it doesn't sound all that hard, right?

You know, you're used to using your maybe your, your mobile phone manually selecting your boarding pass and presenting that. But in the future when you have a a lot of credentials, there's some real usbi UX and privacy concerns that come in there. So you don't want to overwhelm people by saying select manually select all the credentials that apply. So at scale manual selection is not an option, but consent is key.

So there's a lot of work happening around how do you pack, how do you get the usability aspects, but then forward onto the user, you know, here is the key actionable data you need to know, here's the the risks, right? So maybe it will flag specifically if date of birth or any other sensitive information is being forwarded.

One thing I do wanna call out with did come and just to circle back to the, the DICOM demo that we just saw, DICOM is really compelling in that it addresses some of the security concerns that we're most facing right now through a combination of, you know, deep fakes, voice messages, things like that. So a lot of the enterprise considerations for security that are happening right now don't have to do with this nice clean boundary of you're already browsing a website, things like that. It can be initiated by a call.

It sounds like your CEO who's telling you to do something, a unique advantage of DID com is that it allows this peer-to-peer connection and all the benefits of DIDs and the ability to prove that I control this did and I know that you control A did. So I call that mutual authentication. One benefit of DICOM is it really restores this ability to know that you, who you're acting, interacting with is who you expect that to be. And so it really restores that trust.

And so, you know, just to contrast a lot of the sorts of identity challenge we we talk about right now would be effectively you as an individual sharing all of your information to an organization and this allows the organization to trust you. You do not get that in return. So I think that's one of the key benefits of dicom. Let's see. So actually I think I, I jumped the gun on this.

So yeah, direct messaging communication, DICOM is a, a diff standard and we're looking to, we'll be promoting it to IETF. So some use cases for that of course as Sam and Steve mentioned would be secure messaging, initiating credential exchange so you know who you're talking to and, and this can be used in a wide range of use cases. You'll be hearing more from diff about this over time. One thing we've been talking about wallets, and I think this came up in the question from the audience as well.

So wallet, there's, there's kind of a fine line between wallets and agents and this gets sort of confused. There's been a lot of focus on wallets recently and so there are some commonalities, you know, and actually first I should define what I mean by agent. So in the decentralized identity world, we tend to use these two terms and, and we don't really define it that well and I'm not gonna define it that well. And there's fuzzy boundaries between what they're doing.

Wallets though tend to keep with the form factor that you would expect from your digital wallet right now where, you know, it's, it's a, you scanning a QR code or manually selecting kick you off a flow and there's a lot of things that can be done through protocols and you know, standards that your wallet knows how to implement that can make it easier for you. Agents, we tend to think of them as more, you know, like a service endpoint running in a cloud that still you own and you control. And so this can be appealing because it supports more automated flows.

Like say you don't, if you don't necessarily want to be notified for every interaction, if there's some, you know, say the equivalent of data that you're happy to store on LinkedIn, that you're okay sharing to whoever asks. Maybe you have something that is happy to share that claim more broadly, but you wanna be notified if something is requesting more sensitive data. So in general with wallets we think of those as more human initiated flows and there's a lot of focus on that.

Now agents is something that can work really well with the DICOM kind of flows as well for whether it's general messaging and communications or you know, the sort of filtering to find out if it's something that needs a human to interact with. So there was a question on considerations in choosing D methods. This is sort of surprising to me, but it's still one of the most common questions we get at diff when people are, you know, they have even good familiarity with the space, but they're wondering how to use it in their company.

And sometimes it's seen as a barrier that you know, and a mis misconception is that there's a ton of DID methods and you have to support any one of them as a business. If you support did methods, then you have to support all, I don't know how many we're at now, 200, I mean there's, it's way more than 200 I'm sure. But the good news is that you get to pick and there are common patterns in terms of how people go about assessing and choosing did methods.

So back to what Steve was talking about, the core data type is, is a URI and really when you are picking a, a did method on top of that, you're picking things like use case fit compliance. So some, in some jurisdictions you may not be able to anchor it to a blockchain. So maybe a blockchain based methods are out. But privacy, durability, interoperability, and of course costs are considerations. So one common thing that we're seeing in government backed pilots, if they're using DIDs, would be to use DID web.

So the reasoning there being that they're already comfortable, you know, securing their web domain for their website, so they're comfortable putting the DID documents on on their website and securing that. And there a new range of methods like did web coming out TDW, which I still don't remember what that stands for, but keep your eye on that one. Someone had it. Thank you.

Okay, perfect. So for organizations that's a common pattern that you see it's in, it's kind of nice because it's saying you don't have to install all this fancy new infrastructure. You can just get started and maybe over time you decide that you wanna evolve to something else. For individuals, a lot of the big concerns would be around having something that's cost effective. It would be real anti-pattern if you're saying, okay, individuals get to this nice new feature of self-sovereign ness, but you're only supporting a few DID methods and it, it's very expensive.

So I'll pick on my own, did Method BTCR, the one that we implemented, it's, it was meant as sort of a educational exercise. Very easy did method to get started, but very costly because it's anchored to Bitcoin transactions.

There are, you know, so that would be an example of saying like, do not use BTTR for individuals unless they choose to, you know, maybe that, maybe they're comfortable with that, but there are layer two solutions on top of Bitcoin and there's all kinds of ones like based on did DHT, for example, that that would not involve the same sort of costs. The other example would be purely generative methods, and we didn't touch on those yet, but did Key is a popular one that you see there, or did PKH. And what that means is that there's no DID documents stored anywhere. It's generated on the fly.

And so that's, we see that very commonly for say, pilots getting started. And it's equivalent to, well there's also did JWK, so that's equivalent to using A JWK key. And so again, that's free to get started, but it doesn't have the features of DIDs like the ability to update. So you know that that limits the long-term use of it. So in general, the evaluation criteria might include the technical feasibility availability of mature and open source implementation. So that's one thing you might wanna keep an eye out for.

And it also depends on, you know, is it a consumer product or is it, is it a platform play that you're doing? In which case you'll wanna make sure that the data is implemented in a variety of languages. So cost effectiveness, we touched on that and, and you know, is there some sort of dependence or lock in on network and or, or a certain blockchain? And not to pick on Dogecoin, but that would be an example of something where you know, that your users may not be happy to, you know, have their ident identifiers bound to certain blockchains.

And there's some great work on the, did you know how you go about evaluating these different DID methods? How, what different security characteristics they might have. That's the D method rubric. And we're gonna give these slides out so that you can see where this links to. That's a very comprehensive evaluation framework. What I've done here is list sort of over time the criteria that I've used in a lot of projects.

One other sort of misconception that was really challenging, I would say specifically around like maybe 20 19, 20 20 was, you know, a lot of our earlier messaging on self-sovereign identity. And, you know, there's a lot of really, so to back up decentralized identity, self-sovereign identity, yes, it's a set of technologies and standards, but it's also a set of principles that can't quite be encoded in the standards that we're developing.

So it's, it's a work in progress. And part of that is that we actually do care about regulations and integrating with f data protection frameworks like GDPR and things like that.

And when, when we started doing, you know, when SSI really started to become more popular in rollout, we would get a lot of say, government groups that would say, okay, this doesn't make sense because if a person is fully managing their own data, this interferes with this regulation that says the organization has to retain the information. And so I think there was a bit of, you know, softening of, of the language that happened around the transition from SSI to decentralized identity. But SSI decentralized identity is not advocating violent overthrows of ex you know, governments I guess.

So, you know, we're, we need to work in existing regulatory frameworks. And so yes, in some cases organizations are required to store information. One thing about decentralized identity though is that it, you know, it, it helps clarify, it has done a lot of thinking around how we exist alongside GDPR in similar data, data protection frameworks, but then also things like in verifiable credentials, the data model themselves, they have a terms of use that help people understand and, and be very explicit with the data coming in about how it's meant to be used.

And again, we have to rely for a large part on, on regulations for enforcement. Yeah, I'm gonna move past this.

Okay, one other way you might think about DS and VCs as providing an on-ramp across web architectures. We see a lot of interest in DS and VCs.

You know, a lot of my experience in, in Web3 for example, is if you're wanting to do cross chain or off chain onboarding from web two to Web3 kinds of use cases, then DIDs and VCs provide a nice way to facilitate that, that don't involve a proprietary protocol. So that's another use case that we're seeing. And then if you're familiar with Web five, DVC is very commonly used there. So that's another area where we're starting to see a lot of rollout in. This can be a good, very good use of decentralized identity.

So yeah, I think this is close to rounding out the part of, you know, the best practices design patterns. So these are general best practices, not specific to SSI, but you worth reemphasizing, which is that, you know, tracking user consent and informed consent, making sure you're managing, responding to that recovery of credentials. So that might range from, you know, so if you're issuing these portable credentials, making sure that people are not left in the lurch if they lose their credentials. So these are thinking about the full life cycle of the credential on issuance.

And this could be maybe you're storing a, a backup if you know, if, if that's consistent with the consent model. Designing for availability and resilience is key. So if any part of this, you know, the credential verification relies on some sort of online service, you need to make sure it's available. That's something that came out.

You know, a lot of my work with originally blockchain based anchoring of, of credentials had to do with the, we were trying to solve problems in open badges that relied heavily on hosted verification of credentials. And so what would happen is issuers would issue these credentials, but then they'd conveniently forget that they put them in a certain location. Now with SSI, we solve some parts of that, but for, there's all kinds of things you might worry about. Like say if your revocation technique relies on some kind of web endpoints, you need to make sure that's available.

So there's a lot of permanent, permanent designs for permanence that you're thinking through. And generally zero trust architecture, resilience planning, making sure that people can opt out of, of this new way of doing things. And so with SSI particularly, some things to keep in mind, we talked heavily about reducing potential for correlation and minimizing disclosure. So you know, it's a balance here. So a lot of the selected disclosure data minimization cryptographic suites are fairly new in standardization.

So that sometimes you may not be able to use that, but what you can do in some cases is issue multiple claims, different levels of granularity so that people can choose to use the appropriate one depending on the context. And then we talked heavily about phone home and so you wanna avoid leaking unintentionally leaking information.

And of course, you know, as you're rolling out things with all these new concepts like wallets and you know, you wanna educate users on the benefits of benefits and usage of decentralized identity to help drive that adoption and really increase their confidence in it. So actually this is probably a good time to check in on, on questions. I think that, yeah, we, we've covered a lot of stuff here and I'd sort of like to just check in with the audience and see where we're doing. Right. So can you put up the microphone again?

Oh great, thank you. A lot of very different questions but interesting questions and they're all a bit apart from the traditional joiner process, so requesting an an an, an identity authenticating, verifying it using it. So apart from that, so one question is what about recovery of identities of even whole wallets, a mobile wallet is stolen, phone is lost, the recovery process, this is a question that comes up. How can we deal with that? Are they lost? Can is is the recovery?

Yeah, so there's several there, there's a whole range of options with that. I think that, you know, we're getting better over time with the kind of mnemonic seed approach to things. So I think a lot of early SSI kind of approaches would be similar to managing crypto data.

So you, you know, relying on people to store this mnemonic seed and you know, write it down somewhere and that's not really reliable. I think over time we're getting a lot better with providing different alternatives for that and so it does make it easier to recover the data. I think in terms of the credential, so there's several things that you might worry about recovering. It would be, you know, is it your key material that allows you to prove that that's you, that the did mention in the credential is yours.

So if the issuer of it is allowing you to get a backup of it, then as long as you are using some method to back up the cryptographic keys, you can just get a new copy of it, continue to retain control over it. You can even store your own backups. There was another aspect that I was gonna touch on, but yeah, so yeah, I guess one other aspect though is it is best for you as an issuer to design for the idea that everything gets lost.

And so in the verifiable credential data model itself, there's something called a refresh service, which can be used for things like, you know, say a credential, it has a expiration date or you need to go request a new one. So that's, that's a approach that is sort of a standard type of approach to convey to the user and to their wallet or whatever devices they're using that they can get a new copy. Right. Okay. Other questions are around the topic of, of trust and verification. One question is, what happens if an issuer is explicitly not trusted by some verifier?

So your middle earth verifier and you don't want to verify mod or issued identity. So how can that be dealt with? So not to drive it? I'm Sure I get it. What was that r May maybe the stretch was too large. Sorry about that. So that's an interesting question.

What I, what I heard at the onset of that question was what if you don't trust a credentials issuer? True. Well it's game over at that point. If you don't trust the issuer, all the cryptographic integrity along the way doesn't really matter. Right? And so with all of this architect, so Kim mentioned we have kind of somewhere north of 200 dead methods that are out there. You might not trust some of them and that's fine if you don't trust them. There's not a cryptographic process that is going to give you that trust. And so that's just something that you, you need to keep in mind.

But there's, there's so many combinations, there's so many providers, you will have those that you trust and those that you don't trust. For example, if I give you a dark web address that says this is a virus scan, install it on your computer, would you do that? Everybody shake your head now then you don't trust that. So no matter if they used a secure socket layer or any of that, that none of that matters at that point. And so that's an kind of an extreme example, but if you don't start with trust, you need to keep that in mind. Right?

Is is there some kind of level of assurance, so for different types of issuers that you can say I trust them for something, but not for everything but that's it. Yeah, I think, I think that's a good, a good point. It's like meeting people, right? Over time as you interact with people, you'll come to trust them more. Hopefully when you meet somebody new, you have a certain level of of trust and as you get to know that person and you have good interactions, that increases. It's kind of the same way with verifiable credential providers.

You'll have, if it comes from your government, then you will have a level of trust and then over time that might go up or down. If you get it from a commercial vendor, the same type of thing. If you keep having good experiences, your level of trust goes up. But trust is a little bit parallel to everything that we're talking about. That's something that you, you have in a, in another party and then all the processes we're talking about will help you do verifications in light of that trust you have or don't have at that point. Right.

So another question, different use case delegates, parents acting on identities issued for their kids. Is that a use case that you're thinking of that's implemented that's available? Yes. And that's one of the design goals of decentralized identity core types. And so for example, verifiable credentials have a separate notion of subject in holders. So the subject of the credential may be the, the child, but the holder of it and the the person authorized to act on behalf of that is the the parent.

And I think that, you know, there, there's a lot of different, you know, I think that touches on a lot of different issues around how the specific use case, you know, whether it's a educational environment, something like that, what sort of patterns would be expected. But that is one of the design goals. Right. And another use case of course, apart from the usual joiner stuff is a revocation. How is that dealt with and is there a a scalability a scalability problem when it comes to revoking identities that have been leaked, broken, whatever?

Yeah, so revoking wait is this revoking credentials or I or, or can you read it Again? That's a check the question. So it says revocation, so you can choose Revocation. Okay.

Yeah, so there's several things with revoking credentials and scalability there. There are several just very easy to implement approaches to credential revocation and it's called the bit stringing status list. I think it's gone through a lot of rebrandings, but it's basically just a big string and then you know, just a zero one at each position and corresponding to, you know, whether someone in the batches credential was revoked or not. And so that's a very, very scalable way to do it. I think early more naive implementations would have be more like a revocation list.

So maybe this is what we're getting at 'cause rev pure revocation list where it's like, you know, something that you're listing identifiers for each credential that did have scalability concerns, but these bit vector types approaches, you know, make that a lot more scalable. Right. Just one question that goes back to what Steven mentioned regarding the, the digi notar.

What, what happens or is there a risk at all even of an issuer getting compromised? Can that happen? Can that be prevented? That's a good question. So the question is security ever 100%? That's a different way to phrase that kind of question. The answer's no, the cybersecurity is never 100%, we never say a system is totally secure or a hundred percent secure.

What what we're finding is that security is best deployed in lots of different layers where we can detect things like are there too many credentials being issued from an issuer at any given time or can we detect what was issued when and can we react to that appropriately? And so kind of the neat thing is with bearer credentials, like a driver's license, you know, you can go to some back alley and buy a driver's license and and use it. The thing with, with these verifiable credentials is they can be remotely digitally revoked.

And so if a problem like that were to happen, there are security response methods in place that we could recover. So nothing's ever a hundred percent, but recovery can become easier, Right? So it's at least partially security by design.

That's, I think that was the question behind that to say okay, it cannot even happen because of, and there are mechanisms if it happens, I think that is the main, main aim of the question. Yeah, As a security professional, I find it difficult to say compromises cannot happen, fill in the blank of whatever reason. I feel uncomfortable saying that, but being able to detect when compromises occur and have mitigations in place response methods, that's what we need to rely on, Right? So now I have to choose between very philosophical questions, very technical questions.

So I take the technical question first and I I really read it out for p ds, where does the data get stored, if not a verifiable database and if it is a verifiable database, isn't it still public and correlatable? So did they say PP Peer DS peer, sorry, sorry, my my English. So Peer DIDs are created to through two parties, right? And there are exchange methods and the standards we can talk about how to exchange peer DIDs, but once those are exchanged, the keys will rely, my side of the keys will rely with me on my device and the other person on their device and that's it.

There's, there's no third party and if that's the only place that that did is used, it's not gonna be a very good correlatable identifier because if the only things that are linked to it are between the two parties that already know what's going on, then yeah, that's why we don't worry about that. But the, it is important to note as part of that question that peer DIDs are not anchored on a verifiable data registry. They're literally just created and shared between two parties.

Right, okay. Also, good one, how can we uniquely identify someone if the laws, for example, money laundering require it, even if you verified your customer once one institution, but you merge with another bank institute, how can you recognize that two identities are actually the same legal person? So this merging of accounts or at least making sure that these are linked. I mean I think with this that's it, it depends on what is being asked. So is it saying through is what are the unique problems with SSI kinds of approaches or I I think it's the identity verification part.

Identity, okay. I, I'm, I'm still thinking about the Question. I have an account with bank A I'm verified in there, right?

Bank, I have an account in in bank B and this works fine for that bank as well. And then they merge both banks and then you have two accounts with different provenance and then you need to make sure that it's still materials with these two identities, Right? So I mean there's, there's a lot of questions around there. So I think that one, if the, if the question is, if the, if thought is more around sort of like the method at which the person got onboarded and you know, is, is there uniquely a way within decentralized identity to make that harder?

I think we're running a, a state where you have to, there's a legal obligation to know your customer and so there's additional diligence involved. One thing if you're talking about DIDs specifically, one advantage of DIDs is that, you know, from an identifier perspective, there is this sort of, you know, uniqueness across its scope. I think that that's, there wouldn't really be a use case where the did would be the sort of core thing that gets you in the door identifying you, there would be all this other information binding it to your real identity.

And so in fact a lot of these flows when you're talking about using SSI in practice, the way, you know, no company I've worked with sort of just starts from scratch. The initial id, you know, the additional exchange of DIDs, things like that all start from an authenticated session. So those are using the authenticated session currently in use. So no one's just throwing out their current security measures. So I think maybe that is sort of the, a possible angle on the question as well. So I think that that's one way you can think about it.

Like the, the bank, like say if they open you account and then they're issuing you some sort of credential that's like a portable KYC credential, there would be sort of no new sort of identity verification issues happening there. Okay, this is a difficult one. Even I don't get it by reading it out.

I try it, hopefully my English doesn't butcher it too much. How can a verifier be notified immediately in case the verified credential of a user gets revoked or issued with a new VC by the issuer? Is there a notification mechanism? How can that take place?

Yeah, that's one of the benefits of verifiable credentials and decentralized identifiers is that lifecycle is a first class concern. So starting with with DIDs, you know, there are these strings that you can prove control over. Part of using it is resolving it. And so that means that when you resolve it, you can get the UpToDate version of it. So in contrast to normal cryptographic keys where there's this problem of how do you know it's not revoked and you know, there are approaches, certificate revocation list, but there's a lot of risk with that.

In contrast, DIDs, you're always update resolving to the latest updated version similarly with credentials. So they're not called verified credentials, they're called verifiable credentials. Every time you use it you wanna verify it and part of that includes checking that it's not revoked. And so that's part of the, you know, sort of a, a standard of just the standard things that you would check. It's not been tampered with things like that. But another layer of that is checking, its its current status.

And so if the credential has a status list that you need to check or a status registry that is listed in the verifiable credential and it's up to the verifier to check that. So it's just baked into the, into the flow. Okay. Now I get the question and the answer Trust is related to, or even based on governance, is there governance in some parts of, of the DID ecosystem? Is there governance baked into it?

Yes, governance is a, is a huge aspect. It's, it's starting to emerge and be more defined than it, than it has been. But whenever you create your part of the ecosystem, if you're a credential issuer, if you're some sort of environment operator, you're going to have rules of those operations.

And we, we call that governance and it might be accepting different kinds of credentials or DIDs or a variety of things. It, it can really be defined however you want and there are, there are ways to codify that and then people operate within that environment according to that governance document. There's a couple of ways that that's put together right now.

Trust over IP has what they call trust registries, where the, those government governance rules are, are, are located in, in a, a repository and they can be pulled in queried upon requests at diff we're creating trust establishment documents where all those aspects of governance are in a particular document that's signed that can be downloaded and, and used by all the participants. Governance is a real, is a real issue. And so yeah we're we're seeing those, those are two good examples of of governance standards that are emerging that we like. Okay.

I skipped the questions which require, re require the, the crystal ball, how future will evolve and it comes to how issuers will look like one big one, many, many small ones and all that kind, that kind of stuff. Before we continue other questions here in the room, I think I covered most of the important questions. Is there any question in the room where I should bring over my, the microphone and that you can discuss? Maybe I can just hand it over like this. Thank you. So I guess I'm curious about it.

It seems to me within the category of employee ID type use cases there, there are situations where seems to be cutting out on me there a bit. There seems to be situations where it's neither sort of necessary or desirable to have it be decentralized so much as you still want that information about the employee and you want to be able to change it a lot. Are you guys working on models for how the verifiable credentials themselves can be applied to centralized directories?

Yeah, I think one of the benefits of the verifiable credential data model is, so we, we were talking about how there are this, this, the core type is a URI and it can be a did but it doesn't have to be a did, it can be any identifier, any URI.

And so yeah, I've, I've certainly seen examples where verifiable credentials are, are used for just centralized flows and, and I think the benefit of it is, you know, so my entry point into verifiable credentials and all that, we were using open badges, which was for educational accomplishments and it works really well for certain types of educational accomplishments, but when you, we started being in the position of then people wanna do transcripts so they wanna do this and that and so the nice thing about verifiable credentials specifically is you can think of it as just this really flexible envelope structure that also describes how to verify the contents within it.

And so you can put any claim in there and so, you know, and then similarly you can issue it to any IDENTI identifier. So that's one of the big benefits. And also one of the confusing parts of it is people, you know, how do you know what to put in a verifiable credential? And so that's another area that diff is working on quite heavily is sort of what are these reusable schemas that you, you know, to sort of help discovery, ease of implementation and kind of, you know, of help prevent further fragmentation from everyone having their own different type of credential. Right.

Any other questions in the room? Otherwise I think we are through with the questions and you would like to continue with the integration challenges and solutions. Great.

Yeah, that sounds good. Okay.

So yeah, I think one thing, I'm probably gonna be briefer about these so we can get to the demo, but deploying decentralized identity within your organization, it ends up looking not too different from anything you're doing right now. Pretty much. So you know, there's, you will end up having some kind of, you know, if if you're issuing credentials you'll end up having some kind of service or library or something like that that's, that's actually printing out these credentials. So we talked about the first part of collecting that did.

So say you're standing up some sort of endpoint to collect these DIDs and then issue a verifiable credential in response. There are standardized APIs for these sort of back office issuance kind of flows. I think that's really the main place where I've seen that sort of work happening, which is really kind of nice work. So DHSS Department of Homeland Security in the US who's backed a lot of decentralized identity efforts promoted that because they had the experience of, you know, vendor lock-in or API lock-in.

So they wanted to make it a commodity so that people couldn't, you know, force them to use one particular vendor. So that's one nice thing that's happening in the decentralized identity ecosystem is that you're seeing standards all the way down so that you know, whether you're a a vendor or you know a consumer, you have options. And then, so we, we talked about the idea of interoperability.

So say, you know, you're wanting to use DICOM to for more secure communication, there's the open I DICOM approach that's rolling out now. There's a lot of approaches on the DID side that are anchoring to existing sources of trust. So deploying decentralized identity doesn't mean you're necessarily rolling out a whole bunch of new resources with distributed ledger if you are using distributed ledgers or blockchain specifically.

You know, there's a lot of different considerations there. You know, if you're using some kind of, you know, like say you're anchoring to Ethereum and there's a whole bunch of of considerations about, you know, accessing the network, any sort of latency, maybe you're using some kind of API that accesses it. One thing that people do is, you know, try to rely on multiple APIs that would stand it up, maybe stand up their own node that's that's, you know, receiving the current state for if they want that extra assurance.

So there's a lot of different considerations you might think of there, authentication and authorization. I'm sort of dividing it into what's generally the same and what's different. So a key thing is that the usual levels of assurance still apply. So the NIST levels of assurance that you would make in terms of, you know, how many different forms of identity used for identity proofing, you know, nothing new here. And you can also reuse existing methods to establish trust in the trusted channel.

So say you are issuing a verifiable credential and you as an issuer standing up this QR code or some kind of deep link you might initiate that from, so say you've, you've already have some sort of authentication method you might ask the person to authenticate in the usual way before initiating this. I think the thing that's different is with individuals there's a option for did authentication. So that's very commonly used whenever someone uses a did in some way, whether it's in a credential or through DICOM mess messaging. Part of the flow is generally then proving that they control that did.

So that gives an an extra level of, of assurance holder binding is what's typically referred to as saying that this, you know, this did corresponds to you the person. And so there are a lot of, there are a range of different work happening on that now. So I think we don't have a lot of time to get into holder binding that's more of a watch the space but that's the, the term that you need to to know of there.

In terms of credentials, I think that sometimes people use more of it, you know, sometimes you use, people use credentials to express a wide range of you know, sort of capability like this person is authorized to do this or that. Another pattern that you see is people relying on O caps or Z caps technically for expressing those types of capabilities.

And then also I think that in the current model, a lot of these sort of organizations or you know the sort of, you know in terms of knowing which organizations that you're interacting with, they may follow existing trust structures, implicit patterns. But in SSI it tends to be a lot more explicit in terms of governance frameworks, trust frameworks, and this ends up being one of the areas where there's the most work happening. So I took this list from the last IAW where there was a trust establishment face off kind of thing.

I don't remember it was called SmackDown and I think that we made it through about three of the approaches before we ran out of time. But so there's a lot of approaches to trust establishment and a lot of them are are you know, sort of operating on different levels. Some are more API focused others more data driven or focus on, you know, just more declarative expressive model.

And then there's also just custom a approaches or conventions where, you know, say you know pilots I've done maybe in the early stages where there was a hardcoded list of issuers that you might want to accept like so certain educational institutions and there DIDs. So you would just say then at verification time the issue, the verifier is checking that registry, making sure that the issuer is in that list. So those types of methods, those were more of a function of being kind of too early before a lot of more mature trust approaches have gone.

So there's a range of ones in terms of their implementation and how they relate to existing trust methods. And yeah this is the most critical piece to really moving the ecosystem forward and really having these take off at scale some case studies or examples where, you know, these have been successfully used. So supply chain, this is a good example. We talked about how V VCs and digs can be used in these, how do you say relationships, capturing relationships between parent and child types of relationships. It can also be used to express things.

So decentralized identifier can correspond to a non-person entity. And so we've seen a lot of pilots successfully based in supply chain DI mentioned US Department of Homeland Security, Silicon Valley innovation program. They're using it for basically green cards in a variety of of government credentials. I am still really actively involved in the educational lifelong learning space. So in the as Arizona State University in the US trusted learner network, they're doing a lot of pilots with educational and workforce credentials.

So one of the examples that we're using is a local kind of ice cream shop and there's frontline workers that are working there and so we're issuing credentials for one of them is a bit kind of on the nose certified ice cream scooper. But so for example the idea that that could be some sort of portable claim that you use elsewhere. And so that one's a bit of a, we, we picked it as a very kind of relatable kind of fun example. But the idea is that we're targeting these frontline worker scenarios to really en enable job mobility in a much faster way.

Related to that is a Walmart foundation in the US is also heavily backing these sorts of frontline worker and worker mobility. And those are really key for examples where maybe a person has collected all these types of skills in the course of their work and then they could be eligible for a management type of position because they've learned a lot over time. So we're seeing people get a lot more access to Im improved, you know, how do you say benefits and and opportunities.

I mentioned IOT as being one of the compelling use cases and I think in general we're seeing that for IO ot, the sort of flexible nature of decentralized identity does really well for the flexible adaptation to these different, you know, sort of resource constrained, you know, deployments. So that's another area that we're worth paying attention to. We talked about, we talked about choices of using DIDs, like how do you know which did method to use and, and this is true for DIDs, it's true for a lot of the decisions you make along the way.

So a lot of the questions around use of DIDs and this sort of technology would be like, well there's so many choices, how do I get started? And I think that that, there's a lot of questions there. I think that in some cases that really touched on how we need to be doing better at, you know, diff related orgs to to really get across like how do you get started because it's really easier than it may seem. But in general you can think about it as different, you know, it's not that you need to have everyone in the organization being aware of did methods.

I think like 0.1 is the choice of using DIDs because of the benefits that it provides and you know it's really lightweight lift and interoperable with existing methods. So you know, you might have a case where the product manager is, or you know, the system architects are saying yes we wanna use DIDs. So they're not really concerned about which specific did method project manager would be more in the role of saying, okay, these are in my jurisdiction or with these regulatory requirements I cannot use a blockchain or this and that.

So they might be making those kind kinds of requirement considerations, but then the architects developers may be choosing the appropriate DID methods based on all of those requirements and other considerations. So stakeholders, users, usability is, is incredibly key to this. And the issuers and relying parties need easy integration points. So that's one thing that I would say early decentralized identity approaches maybe tended to scare people a bit more if it was, especially if it relied on a, a custom bespoke blockchain, things like that.

We're seeing a lot less of that interoperability and portability, more lightweight adoption and you know, these patterns that we're seeing like open, I did come open, ID did come or whatever, I'll get the name right at some point. So lots of improvement there. If we have time, if there's not many more eight minutes, seven minutes. Okay. And if everything works okay, we can see just a quick demonstration. Good. So I was gonna build an ICUI but then I didn't So you get command line. I'm sorry about that. Is it working out? Yeah.

Okay, sorry about this. So what I'm showing right now is basically just the toolkit. So it's a nice easy way to show how to get started. So I think we actually wanted to make this interactive. So let's see we, okay, I want to get a verifiable credential and I want it to be issued to my did what's my first step? Everyone all at once. First step is, is getting a did. So let's see, I lost my screen.

Sorry, just one second. Okay, so we'll create a did and then with the Ram CLI is Ram's open source set that we toolkit that we host at diff. So it's giving me a set of DID methods, hopefully one of these will work. So let's see, I'll pick did Ether, oh it's not updating.

Okay, you may have a problem with it. It updating.

Okay, so I think we'll we'll bail on the demo. That's it happens. Oh okay. Okay.

So, oh I got my, I got my did. So then we'll look at what it's like to resolve A did so then if I resolve this I may have to use did key. It may be a network connection problem.

Let's, let's go back to did key, let's not over complicate it. Okay. So we'll create a did key did, okay so I have my DID key and then if I wanna resolve that, did this really should work.

Okay, good. So this, I think it's, it's probably offline again. Oh okay. I think you see it. So this is the DID document that corresponds to the DID key as I mentioned did key is generative only. So this did document doesn't live in a persisted form somewhere it's, it's generative. So it's basically saying part of did keys resolution instructions say, you know, map it to this key information and then so that's what gets displayed here.

So that's one of the other neat things about decentralized identity or did resolution is that each method can say its own set, it could a set of instructions, it could say look at this ledger, find this document. It could also just say perform these magical steps.

1, 2, 3, make this document on the fly and then there you go. So the issue though, when they're not persisted tends to be that you also don't get the update methods. So let's now create a credential and this is, this shows a few different credential proof formats. I don't think we really touched on proof formats that much, but Jot is a, you know, it just uses the standard old jots that you're used to. There's some linked data types of approaches and we'll just use a a jot to start with. Okay so now I can issu, I can pick my issuer did and my subject did.

So again because I'm in the demo worried about network considerations, I'm just going to pick did key and so note that it's a self issued claim, so Wow. Oh okay. So yeah I have a credential. You don't see it though so that's good. It's my business and not yours so yeah, you somehow see it. Yeah. Okay.

So, but I have my credential so VMO is a nice way working with I I think it's gonna display. Yeah, VMO is a nice way if you're wanting to just experiment with these core concepts, it's a good way to see how it all works. And I'm just using the standard VMO CLI toolkit and yeah, it has things that we are showing around DICOM messaging. It also has command line options for that as well. So it's a really good way to experiment. There's a lot of really useful did SSI sorts of toolkits of many of which of you can get as well. So if there's any shout outs you wanna make specifically to. Okay.

So yeah, any other questions before we sign off? There are a few questions, but I think you will be around, I think so when maybe people can reach out, reach out to you after this session as well. So especially there's a question around assurance levels, where to apply them, et cetera. But I think we should close down. Thank you very much, Kim. Thank you very much Sam, thank you very much Steve for presenting this great workshop to us. Thank you. Thank you. Thank you for hanging Out two hours. That's really impressive.