 Welcome to the ITU studio in Geneva, where we're very pleased to be joined today by Kim Hamilton, who is researcher at the Massachusetts Institute of Technology, MIT. Kim, welcome to the studio. Thanks for having me. Now we're here because we've got the Fiji Security Clinic, which is part of the whole financial inclusion global initiative. And I wanted to talk to you particularly about a subject which I believe you're quite familiar with. It's called the centralized identifiers. And perhaps we could talk about that and what they are and why they are key to identity security. The internet was built without an identity layer. And as a result, it's very hard to know who you're interacting with, making fraud and identity theft very common. So there's an emerging W3C working group called the Decentralized Identifier Working Group, which seeks to address this. So the way that these work, these are globally unique identifiers that can be used without reliance on a centralized authority. And so the thing about them is that I don't have to rely on any one government agency, any company, things like that, to start collecting a series of claims about me. So when I say claims, I'm referring to what another phrase word for it is credentials. So Decentralized Identifiers were developed hand in hand with the verifiable credential specification, also happening at the W3C. And so credentials, they allow you to say any credential, it could be your driver's license, passport, but then also educational records or even informal claims. So Decentralized Identifiers are the subject of these claims. And that means I can take my claims around and prove that they are about me. So this leads to a lot more trustable interaction as opposed to what I say on a resume or in a job profile, I can actually prove that it's about me and that the claim hasn't been tampered with. So the Decentralized Architecture leads to an architecture that doesn't rely on these siloed honeypots of data. So by design, they're meant to improve privacy, reduce risks of data theft. And how do we know that it's authentic? How do we know that your claims about you are authentic? Right, so how do we know it's authentic? The Decentralized Identifier is an identifier string that I offer, and that can be provided in different ways. But effectively, the issuer has already vetted my identity in some way. But I control the identifier that gets embedded in the credential. You scanned your driving license or passport or something like that? Exactly, yes. So it might be a government ID that was issued, but it can also be other forms of identifiers. This gets tied in with self-sovereign identity schemes that you've heard about. So there are a lot of Decentralized Identifier methods that people could create on their own. They could use it in web of trust type scenarios, peer-to-peer claims, things like that. So this identifier, which I can cryptographically prove control over, is embedded in the credential. And then that is signed by the issuer. And so an independent verifier can verify that the credential hasn't been tampered with. They can make sure that the issuer is who they expect it to be. But then also, they could challenge me to prove control over the identifier. I was going to say, how useful is this going to be on day-to-day interactions? Right, so one thing about these, so both the Decentralized Identifier and Verifiable Credentials spec. They're still quite new. And so I think that it's important that we find ways to use them alongside existing authentication methods, such as those described here, specifically FIDO2. So FIDO2 is an emerging set of standards that deal with things like web auth-in, for example. And basically, it's a framework of standards that allow decentralization of authentication materials. So instead of using a username and password, I could rely on biometrics, but these never leave the device. So I think that essentially they can be used in ways to bootstrap off of existing systems that are already used. So one example that I'm fond of in the British Columbia government, there's a group of people that are using Decentralized Identifier as verifiable credentials to improve government processes around, say, business licenses, things like that. So what they've done is they've assigned to each company a Decentralized Identifier, but then claims about those companies are public. So for example, one would be a WorkSafe certification. And so that might be something that would be issued to their Decentralized Identifier. Anyone can inspect and audit it. But then it would make the company eligible for, say, insurance discounts, things like that. So this is all quite new. These are more example scenarios. But I think that relying on first starting in more, how do you say, more public claims type scenarios, and then as we start building up the technologies for individuals to start using these, we'll start seeing them in our day-to-day life more often. OK, you talked about the incentives. What about the standards needed for Decentralized I.T.? Yeah, so the standards needed, there's the foundational layers which are Decentralized Identifiers and Verifiable Credentials. Verifiable Credentials has gone to recommendation mode at W3C. Decentralized Identifiers were developed alongside of it to be the subject to be this thing that a subject could prove control over. So those are in a W3C working group now. And the draft specification is underway. The target, I think, for release is about a year and a half from now. So those are what I call the foundational layers. But there's a lot of other parts we need. And this is where we get into the question you asked about use in your day-to-day life. So those are just two kind of flat specifications on their own. To actually use them, there's a lot of specifications and standards needed around the protocols of exchanging credentials, how I exchange a credential with a relying party, how I request the issuance of one, things around standards to avoid lock-in. Because we still don't know at this point how people might interpret these standards in very locked-down ways. So lastly, there's what I would call not so much standards, but best practices around things like how do we use these in the most privacy-insuring ways? So for example, Decentralized Identifiers, the example that you mentioned was a government-issued one. But the reason I emphasize that they could be unique, they could actually be different for every claim. And you would have a wallet that basically, or some kind of hardware device that is gathering them up and able to prove control over them. But that helps avoid correlation kinds of attacks. So things like, in today's world, we have the problem you have a social security number. And if people know that and they know a few other facts about you, they can try to steal your identity. So Decentralized Identifiers help approach that in several ways. One is that, OK, if your social security number, the equivalent of it, we're not saying that we would build social security numbers that way. But if that's embedded in a claim, the relying party can actually challenge me to prove control over that. But then also, because I can aggregate my claims in different ways, I can build different profiles so that it's not necessarily easy to, knowing one string, gather a whole bunch of data about me. And that's also going to help with regards to privacy as well, which I'm sure will be a major concern. Exactly, yes. Because I mean, I would not necessarily want to share all of these things with everybody. Right, right. And so Decentralized Architecture is really part of the basis of all of these. And so the idea that consent, or that I, the recipient, the idea that my consent is built into the exchange of it, I think it's going to fit very well with privacy regulatory frameworks like GDPR. I think that that's basically what we need to help avoid the need to opt in, opt out, or rather, there's probably going to emerge over time better ways to capture that as a first class notion and not rely on companies to do the right thing. They have to do the right thing. Thank you very much for joining us, Kim, here in the studio and giving us some very valuable insights into what I'm sure is going to be quite a long and winding road to reach the final product there. But I think it certainly sounds like it would be something very valuable for us in the near future anyway. Thank you very much. Thanks for having me. Thanks, Kim.