Speaker 0 00:00:05 Welcome to the rubric. I'm your host, Joe Andrew I'm Erica Connell.
Speaker 1 00:00:10 And I'm Eric today on the rubric. We interviewed the co-chairs of the working group, Dan Burnett and Brent Sandel deserve magic.
Speaker 0 00:00:21 The rubric helps you understand the technologies behind decentralized identity, including decentralized identifiers, also known as DIDs or did, did documents and did methods. Decentralize identity enables robust identity services without dependence on a trusted third party. Instead of being tied to a central service like Facebook or Google, or the department of motor vehicles, DIDs can be created by anyone anywhere and be used for any purpose. Did methods are the magic ingredient that gives dibs their flexibility before creating any specific debut first choose a did method, which determines how you create read, update, and deactivate. A date of that method once created each did includes the name of its method in the identifier itself, so that when you use the, did others know how to retrieve the associated did document that contains the cryptographic material for secure interactions, different did methods use different underlying mechanisms with different performance security and privacy? Trade-offs this show, the rubric reviews different did methods using a common set of criteria, comparing apples to apples. So you can make better decisions about which did method is appropriate for your needs.
Speaker 2 00:01:35 And now these announcements, our announcement for today is that we don't have any announcements, but if you have an announcement, you would like us to include in the podcast, email it to
[email protected] that's
[email protected].
Speaker 0 00:01:59 Today, we're talking with the folks making decentralized identifiers. Our reality. We have the co-chairs of the worldwide web consortium's decentralized identifier working group, Dan Burnett and Brent Dell to give us their perspective on DVDs and did methods.
Speaker 2 00:02:16 Dr. Burnett has over 20 years of experience in web and internet standards, having authored and edited more than a dozen standards as principal for standards play his consulting firm. Dan helped a variety of companies play the standards game, both advising clients and how they could strengthen their brand and market positions through standards, leadership, and representing them directly in organizations, such as W3C and the I E T F in the Pegasus standards group at consensus. Dan began his journey in the blockchain space that led him to his current role as the executive director of the enterprise Ethereum Alliance, the industry association for organizations in the Ethereum blockchain space, Brenton Sandell is a crypto engineered Evernham who also works on open standards. He likes to run, spend time with his family and cook, especially baking, especially pie. He's the co-chair of the dig working group co-chair of the BC working group and editor of the presentation exchange spec. Welcome to the show. Co-chairing
Speaker 0 00:03:21 A standards group is often a hard and thankless job. So I want to start by thanking you both Dan Brent, for your leadership as we turn this idea of decentralized identity in a rally. Thank you. Definitely. Dan you've been in the standards game for a long time. You recently changed jobs through consensus of some definition of recent to this new role at the enterprise Ethereum Alliance. So, uh, tell us a little bit about yourself and your own aspiration for DIDs.
Speaker 3 00:03:50 Sure. Um, so I, as it, you know, as, as we heard in the bio I've, I've been doing standards for awhile. I, gosh, let's see, uh, should probably say that, um, I was working, uh, before VCs and DIDs. I was working on web RTC, which I'm very pleased to talk about nowadays because we're, we're all depending on that technology today in the pandemic as we, uh, as we communicate with each other. Um, but it was while working on that, that was attending a W3C meeting, happened to wander by another standard session that was going on when I had a spare moment and I heard Manu, Sporney talking about verifiable credentials and I stopped outside the room and listened to him talk, and afterwards went in and said, I'm interested in this. And I'd like to get involved. And that was in probably gosh, 2013, 2014, something like that.
Speaker 3 00:04:46 Wow. And so that was the beginning for me. Uh, I realized that, uh, this was the beginning of a, uh, of a change in the world. Uh, and it was a positive change in the world that if it verifiable credentials and DS and eventually decentralized identifiers, we weren't talking about them yet. If they actually replaced what people used for identity in the world today that, uh, that the world would become more of a place that I wanted to live in. And so I got involved out of personal interest before I had any, uh, any corporate commitments of any sort. And from there went on to beginning to write the verifiable credentials specification, uh, as the first as its first editor. And then, uh, co-chairing the verifiable credentials working group. And so on, it was I think, a natural outgrowth of the VC work, uh, that we started talking about bids. And I don't know how much you want to go into that yet. We can talk about it a little bit more later. Um, but to me, I always associate decentralized identifiers with verifiable credentials. And every time I explain the technology to people, I explain it in the context of verifiable credentials, because I've found that get it in that context. So again, if that's relevant, we can come back to that.
Speaker 0 00:06:03 So turning to you, Brent, uh, I believe this is your first time sharing an open standards group. You are doing a great job. You work with acronym, one of the leaders in the decentralized identity ecosystem. Tell us a little about yourself, your role at Evernote and why you're excited about dates.
Speaker 3 00:06:21 I, uh, I came to standards in a, in a rather roundabout way. I am an engineer. I, I got a computer science degree, um, at Fresno state university go bulldogs. Uh, my focus there was, uh, cryptography engineering. And with my newly minted degree, I immediately got a job doing systems integration for irrigation systems in the central valley, um, which really had nothing to do with cryptography or anything. Interesting at all. Um, luck brought me to Utah of all places, um, where I eventually got a job with Evernham. They, they recruited me specifically to work on cryptographic engineering. They had this notion for a verifiable credential that would allow the holder to remain as, as anonymous, as possible to avoid correlation. And they use some, some pretty fancy crypto to do it. As part of that work. We were attempting to pay attention to what was going on with the standards development.
Speaker 3 00:07:28 The verifiable credentials working group was, was already underway in defining the standard. And I was tasked with paying attention to it and make sure we're going to be able to use it so that someday we can use it. And that was, that was my intro to the world of standards. I found myself sitting at a table in Leone, France, um, across from a number of people who had literally been working on this standard for years and just kind of demanding that they change a bunch of stuff. And you, anyone who's done standards knows about how well that went over. Um, luckily they saw, I guess they saw promise in what I was able to contribute and coached me toward contributing to that standard. And from then I was, I was hooked standards. Development is a lot of fun. Uh, it allows me to interact with a whole bunch of interesting people and do things that as a crypto engineer, I don't get an opportunity to do, which is interact with people,
Speaker 1 00:08:34 Always the struggle of engineering. So I guess to focus a little bit on DIDs, um, could you both maybe give us, uh, an overview of what art DIDs and, um, I guess we've got into a little bit, but, um, why do you two, both care about them so much that you are willing to put your time into a organization like this? Um,
Speaker 3 00:08:59 Um, Brent, do you want to go first this time? Okay. The, the example that I like to share about, uh, when I explained DIDs and how they're useful, his email address, I have an email address. I use it all over the place as my username to log into websites. Email is really, really handy and, and everybody has an email address. So it's a very common thing, but if my email provider wanted to, they could take away my email address, which would make this nearly insurmountable problem in my life of how do I then log into all of these different websites that you use that, you know, control of that identifier, as opposed to control of that identifier as proof of my identity, as proof of my, my capability to be the person that I am. Uh, so a decentralized identifier would allow me to not depend on anyone else I can prove control of the identifier without a third party.
Speaker 3 00:10:01 Also being able to take away my, my ownership and control of that identifier. Yeah, absolutely. Um, that's a great example. So I remember when, uh, when we were working on VCs, um, I remember actually when this came up, we had, we had developed the structure for the verifiable credentials data model. There were a couple of places that ID showed up the issuer ID and the subject ID. It was the subject ID in particular where we were somebody asked, okay, what's the syntax of that identifier. And I remember the conversations in the group where we thought, oh, well, we want to allow a variety of identifiers. So we should probably allow email addresses. And then someone said, yeah, okay. That that's, that's cool. Um, why don't we also allow, um, URLs okay. Just arbitrary HTTP URLs. So we thought that sounded pretty good, but in further discussion, particularly around privacy, it became apparent that we didn't trust any of those existing identifiers.
Speaker 3 00:11:04 Everything that we could think of, where there was an email address or a domain name or whatever was, as Brent said, it's essentially an identifier that someone else can administratively take away from you or just be you that's actually almost even scarier. It's not just they could take away your access. Okay. But for example, if you're Google in China, you do not control google.com. It's whatever China wants it to be. Okay. And so this is, um, this is true for a lot of identifiers in the world. Essentially every identifier we were aware of, and that led us to the need for something, an identifier that you yourself could own. That's how we talked about it at the time was it would be your identifier on you owned it. Now we've moved away from the terminology of owning because that has its own problems. And we talk now more about controlling, and I think Brent did an excellent job just now of explaining it a little bit in a little bit better way.
Speaker 3 00:12:06 Um, a little bit more detail, how it is that you control a dead. And, um, and I'm sure Brent will talk about that more or Joe well or others on this podcast. Um, but the driver for me has always been that need with a verifiable credential, for an identifier, particularly a subject identifier that you could control. No one else could take it away from you. And in fact, you could mint as many of them as you want it. That was actually also very important, right? So one of the reasons, and I'm getting a little bit on my soap box, so feel free to pull me off, uh, Joe or Eric or Eric here, but, uh, with respect to decentralized identity, I hate the term identity. Joe knows that I have fought against the use of that term for a long time. And it's because I believe that many people in the world, well, actually everyone means something different when they use the term identity.
Speaker 3 00:13:00 That's one of the reasons I hate it. And often commercial entities believe that they, their definition of identity is the one that should matter. They get to define it, they get to control it. They get to control the information. And that has never seemed right to me. I really liked the focus on identifiers with DIDs, because identifiers are something that I can get many of and then I can choose where I use those identifiers. Now, obviously we know that correlations can occur in the world. And so there's only so much, um, there's, there's only so much we can do to prevent that. And that's something that may come up in our conversation, but it was just critically important that I could create one or more identifiers. And I could decide when I wanted this subject identifier to be used. And when I wanted this other one. So that's a long-winded way of saying that this was a critical need for VCs. And to me, that is still essentially the fundamental need for this technology. Even though now the world is realizing that this, this identifier is useful in, um, in a much larger variety of contexts.
Speaker 0 00:14:11 I love that you brought up identity. It was something that I was going to touch on next. You've always had that sensibility that I really appreciate as a chair, that identity is something that lots of people can fight over and never get any progress on. And so, as a chair, you've definitely navigated. Let's not get into that rat hole. I've made the other choice and published several papers about how other people should think about identity. Um, and of course, I'm just adding to the noise. So I appreciate how you've helped navigate, you know, the standards process to say, okay, all you guys have different notions of identity, but that doesn't mean we can't have a common standard in these identifiers. So that's been really awesome before
Speaker 1 00:14:51 We move. We move on though. Dan, I did want to ask you a follow up. Um, you've mentioned, uh, verifiable credentials, a number of times so far. So just for any listeners out there who don't know, could you maybe give us your one or two minute spiel on what verifiable credentials are and how they fit into this space, along with it?
Speaker 3 00:15:09 Sure. Uh, verifiable credentials, in a nutshell, they are a data structure in which there is an issuer who makes claims about a subject. The issuer is represented by an identifier and the subject is represented by an identifier. The other thing that's in this though, and this is important is that there is a, essentially a signature by that issuer over the content. So what this, what this gets you very simply is the ability to be sure that that issue or ID issued those claims about the subject identifier. Now, those claims can be anything, right? It can be that the sky is purple and the, you know, in the grass is pink or whatever. That's fine. We actually say nothing about the truth or falsity of the specific claims. All we always say is that you can be sure that this issue or identifier is the one that made these assertions about this subject identifier.
Speaker 3 00:16:12 That turns out that that is the fundamental piece that the cryptography of the math can do for you. What has often happened with, uh, identity solutions is, uh, I always, and I get this question all the time, but, but who is the authority? Who's I want to know who I can trust. So in the end, it's always your decision who you trust. That's why it was structured this way. Okay. There's an issue. Or who does that? Who, who makes these, uh, who makes these claims? And it's up to you as the verifier who receives a verifiable credential, continuing this information to decide which issuers you trust to make the claims that have been made. And I think every other identity system out there, um, tries to put a trusted party in there. And that is the mistake. That is the trap of identity systems, because what do you do when that trusted party gets hacked, uh, or there's some other kinds of fraud, or they do something that you personally disagree with. That is, that is precisely the problem. So what we did is we define the smallest data structure, the most compact data structure we could that captured the pieces that the math could give you. And then the rest is really a human decision. And anyone who tells you otherwise is lying. I'm sorry, they're misleading you. Um, and taking away a decision that ultimately is yours to make about who you trust to make those claims.
Speaker 1 00:17:42 Great. Thank you, Brent,
Speaker 0 00:17:44 What's your take on, what is our, how would you frame it?
Speaker 3 00:17:49 DIDs are magical. They, uh, they were, they really are. There were amazing creations that the association of an identifier with, um, provably chosen public key cryptographic material is enabling of so many use cases. The, the more people I talked to about decentralized identifiers, the more people kind of grasp onto them and get kind of excited about them. The notion of an identifier that a user can create and control without some third party being involved. It really solves a lot of issues. There are, there are a lot of, there are a lot of folks who have to deal with digital identity systems who don't like that they have to deal with digital identity systems partially because they have to create and assign identifiers to their customers, to their users or anything like that. Um, a system that comes along that allows them to not have to get into that business at all is, is fantastic news.
Speaker 0 00:18:59 Awesome. Thanks, Brent. So far, we've been mostly talking about DIDs, but did methods are core component of how DIDs have their flexibility? I'm curious how the two of you think about did methods in their relationship to the standard and how your advice for how people should think about did methods when evaluating their own options.
Speaker 3 00:19:24 Uh, um, I probably have the least to say here, so I'll just go first. You know, I actually have really not focused very much myself on the variety of good methods or exactly how they're evaluated. I think my, my concern and I, and I know that this is important to get to that. Um, but my primary concern is that there's more than one. There's more than two there's more than three in short that the world ends up using a variety of them. I think all of the great work that we've done on dets still face a risk. If in the end, there are only one or two or three did methods that get used. And in particular, if those did methods are ones that are primarily driven by commercial entities, that, that try to capture that control again in some way that that is the risk right there.
Speaker 3 00:20:19 Thankfully we've developed them in a way where it's possible to create, did methods that don't have those problems, or at least not as badly as some of the traditional identifiers, the domain name, system based ones and so on. Um, so for me, that's my overriding concern is, and it's just something I watch, uh, in, in both hope and, and trepidation actual light to, to see where we're going to end up. Brent did methods on first glance. And at first read, some people feel like they're a complication of the standard, in my opinion, it's the did method construct that really allows us to claim the title of decentralized identifier. It's not only that a good method itself may be decentralized it's that there could be any number of did methods. And the, like Dan said, the creation of them is not dependent on some central party.
Speaker 3 00:21:15 It, it really hearkens back to the, the ideals of the early days of the web, when, you know, the notion that anyone could host a server in their front room, um, and thereby create this worldwide connection between a bunch of different people that was built into the Fs of the early web. It's not that way. Now, there are a few walled gardens that we all like to play in. And occasionally we toss things over the wall to one another, but for the most part, this idea of something that is self controlled and self-initiated, uh, there's, there's little of that in today's internet, in my opinion. And so having this enormous choice of did methods so that I can choose an identifier who, which has the security characteristics that I care about. Uh, it's really important to me, uh, bringing some of that choice back and
Speaker 1 00:22:15 To tie that into some of the previous points, it would be security characteristics that you care about in the particular use case you are currently using the identifier. And I think that's one thing I've gotten out of being in this space now for about a year, is that conceptually, I think we all would hope that DIDs are very contextualized and you want to use them in very specific, specific circumstances. And so different did methods might fall into different use cases where one of them you use to sign in for a general account as you would today. And another one, a different did method you would use for say your accounting, something a little bit more personal.
Speaker 0 00:22:56 Yeah. I love that use case focus. There are several classes of methods that do things fundamentally different, for example, did QI, which has effectively the verifiable data registries in the DIT itself. So you can extract the did documents directly from information in the identifier. And there are a couple of, of methods that have that kind of characteristics, others like the BTCR 1.0, which is a Bitcoin reference, did method. You have to have an on chain transaction, which costs quite a bit, and it can have a latency and a delay. So these are just some of the examples of different kinds and families have did methods. I'm curious, and I'm going to put you both on the spot. You don't have to answer, but Dan what's, your favorite did method.
Speaker 3 00:23:45 Okay. All right. Um, you know, um, so I'm going to cheat. I actually have to, and, but I'll tell you why they're my favorites. Okay. So did QI and did BTCR. Okay. All right. The reason, so the reason did key is one of my favorites is because it captures the absolute ultimate essence of what must exist. And I think that's extremely, extremely important, um, whether it gets used or what it gets used for, you know, I, I, I don't know that that matters a lot, but I think it is, uh, a fabulous example to those who wish to design their own, did methods to understand what really is kind of at the core of a did method. Now, the, the BGC R one is interesting because it was the first and, uh, it is far from, um, you know, what, I'm not going to put a value judgment on it.
Speaker 3 00:24:50 I could just say that, uh, even the, even its creators knew that it was, it was far from perfect, but, but being the first was important, it was a proof, it was a proof that it could occur and it could be done without having to go and create new, uh, new DLTs, new blockchains. Okay. New decentralized frameworks. I think that's really, really important. Okay. Because when we created this, that's what we had in mind. I think it's easy to forget that. But when we first talked about this blockchains were becoming popular, and that was the only reason that we actually even thought of doing this was because they existed. We knew that there was this ability to separate control, uh, and make sure that, so there was no centralized, uh, party that could administratively take it away from you. And in fact, in all of our early conversations, we talked about, this was a blockchain based identifier.
Speaker 3 00:25:47 Obviously we've gone beyond that in a number of cases, but I just love that, that BTCR showed what could be done without creating a fit for purpose chain or any of the custom work that has happened since then. Brent, what's your favorite? My very favorite did method as did pier and the, when I first got started in the decentralized identity space, uh, self-sovereign identity and all of that at Evernham, we were backing. We still are big fans of the sovereign ledger, which is a Hyperledger Indy based, uh, public permissioned ledger, where, um, anyone can create and store an identifier. And, um, we were building solutions around this, this distributed ledger when one day the, the CTO into the room where we ruined some planning and he went, did, you don't have to be on the ledger. We went, what are you talking about? We're putting everything on the ledger.
Speaker 3 00:26:52 Well, not the credentials. He's like, no people don't need dibs on the ledger. They just need a DIT. They need some way of passing keys back and forth. They don't need it universally verifiable. It only needs to be verifiable among the people they've shared them with and the people that they're using with the different entities that they're interacting with. And so did peer kind of grew out of that. Daniel Hartman took that notion and created an initial spec. And now it's at diff being agreed upon by, by a whole group of people. But this idea that I want an identifier, I want it to prove that I can control it. I want to be able to rotate my keys so that I'm not locked into a certain, certain key. And I can share it with whomever. I like it's, it's uh, yeah, thumbs up in my book. All
Speaker 2 00:27:43 Right. And, uh, let's change gears a little bit here. Tell us where our DIDs in the standardization process. We're so close
Speaker 3 00:27:54 At version. One of the spec is in a candidate. Recommendation means we are, we think we're done. And we're looking for implementations and feedback from implementers to show us that we're not quite done yet, but hopefully they don't. They don't do that. Hopefully they show us that we've done a good job. Right. So, so just to explain a little bit for some viewers who may not, uh, understand the process, the first stage of the process where we're at the working draft stage is where we're trying to develop the technical content. Once we move to the candidate recommendation stage, we were effectively saying, we believe that it's done. We believe it's technically complete, but now we need sufficient implementation experience to confirm that it actually is implementable the way we think it is. And so that's a big step, right? It's a big step to say, uh, you know, we're beyond feature complete, right?
Speaker 3 00:28:46 We're actually at the point where we say we would be done, if everyone was able to implement this, uh, and it worked. And if that happens, then we are done. If that doesn't happen, then we just, we clean some things up as we need to. We, we don't think it's likely at this point that there are going to be any major problems because we've, we've gotten enough, uh, sort of informal implementation, uh, comments back. Uh, but now we're going through the formal process and there are some minor things here and there that, that do need to be cleaned up. And that's what we're doing.
Speaker 2 00:29:20 And so I, uh, I'm not, um, uh, involved with the standards world. When you say like we're inches away and it's so close, what does that mean in, in standards? Like timing does that mean like you have six months or a year or a timeline when, um, when things will be complete
Speaker 3 00:29:39 Six months away, we're so close. So I should put the chicken back in the fridge. How long have you been working on it? Working group? What we're a year and a half in about, correct. Uh, but the, the initial draft of the spec was in the CCG for the credentials community group at W3C for a long time. And even before that, there was a lot of discussion amongst, uh, a lot of people trying to get this thing worked out. Okay.
Speaker 0 00:30:14 It seems from my experience that the fast track from concept to realization for a standard like this rule of thumb feels like five years, which before I got involved in any of this work, that felt like forever. It didn't make any sense as a Silicon valley kind of startup entrepreneur kind of guy. That was the culture I grew up with five years. I should be having an IPO by then. Um, does that, Dan, has that been your experience? It really is. I mean, I think it's about, we've had about five years,
Speaker 3 00:30:46 The faster specification I ever worked on in my career took four years from beginning to end and that was version two of a specification. Okay. So we already had the basis of it. Um, web RTC when I started working in 2011. Okay. 2011 is when I started working on web RTC. They just published the candidate recommendation last year and a recommendation this year. Okay. 10 years. Um, it is normal. Okay. So five to six years is fast. So I don't usually tell people this. Okay. When people come in and they're like, we got to stand up, we got to, we're going to have it done next year. And I go, sure. Let's get started. I just don't have that enthusiasm. Great, great. You know what, we'll do it into your shirt. Let's put those dates down, let's write them down, you know, and I really do.
Speaker 3 00:31:36 We write them down and we use them to threaten people with, so that they'll actually do work because that's the other thing that people don't realize with standards is that there is no day with standards. There is no, you, you should do this. You should do that. That's not how it works. It's the people who actually submit the content, the actual real content that make the standard. And until they do it doesn't happen. So sometimes the chairs have to, uh, you know, threaten control, cajole, wheedle, whatever. Um, we're not allowed to bribe, but we can, we can do everything else, you know, but, but essentially this is pretty quick. It absolutely is. I'm thinking about, you know, like I mentioned VCs when I first heard about it in 2013. Right. And so that spec was not done until, uh, what was it? 2019. Yeah. Um, so yes, it's five to six years. That's quick for a standard. In fact, this one, this has come together much more rapidly than I expected. I thought for sure, we would have to extend the group, uh, in order to even, even to be where we are right now. So fingers crossed. We are doing very, very well. I really
Speaker 0 00:32:44 Liked Dan, what you said about doing the work that there no day that this, this is about people stepping up and I liked it because it echoed my own experience. I got involved because I went to a rebuilding of the web of trust and Manny Sporney and others who were working on VCs with the VC task force at the time were having some conversations. And I, and there was a use case document that had been drafted and we had an open hour to have a conversation. And I said, oh, I'm kind of interested in reviewing that use case document. So I did, I sat down with a couple of other technically minded, sophisticated professionals. We read it and we said, oh, well, this isn't clear. Maybe you could do this. And we just provided some feedback and it was absolutely welcomed. It was stunning to me the first time that, oh, I showed up and I did some work and people were like, that's great. Thank you. And that was the beginning. So, so a message to those listeners who are curious about the standard process, although it might take five years or 10 years, and although it may be something you're totally not familiar with, you will be welcomed if you show up to the meetings and, uh, chime in and help out and actually do work, contribute, pull requests, make suggestions, contribute ideas that can help move towards consensus. That is always welcome. And so I love that you touched on that, Dan.
Speaker 3 00:33:58 Yeah, actually, um, I'm going to embarrass Brent just a little bit here and say that during the VC world, which I was one of the chairs of, um, one of our struggles was getting input. We actually had, there were some communities we reached out to and had not gotten input from them, but we knew we needed it as shares. We knew it was very important for the success, the eventual success of this to have broader input than we'd had. And I'm just immensely grateful to Brent. Brent came in and Brent actually provided that input in one of the two, two areas that we needed input. And it was honestly not until then that we were able to begin moving towards a candidate recommendation. And so I will forever be grateful to Brent and others who stepped in to do that work. You know, it's funny, we had like a year and a half where everything seemed done, except that we knew that there was this big piece, right.
Speaker 3 00:34:53 If we didn't have the input on and it just made me horrendous, you know, just terribly nervous as a chair. Um, so even though it took a little longer than we had originally anticipated the getting that input allowed us to produce a specification, which was the first, it was the first in what may be a long line of, of pieces of really good standards work. Uh, that is, that is really going to change. I think the identity landscape, and yes, I use that word. I think it's really, I am hearing people from all kinds of places, people who will talk to me about something else and they'll mention VCs and dev like, Hey, you know, I had something to do with that. This is cool that I'm hearing from somebody else. That's great. Okay. So, so anyway, thank you. Thank you, Brent. And you're absolutely right, Joe. It is, it is the people who come in and are willing to contribute, uh, that make it what it is. The only thing that chairs don't like is when people disappear and then come back and say what you didn't do, what I wanted while I was gone. That's the one thing that is honestly a nightmare for a chair, um, because you know, you have to be there and do the work. And that's, that's how it works.
Speaker 1 00:36:07 Given where both of you are with the work in this home stretch. Are there any implementation that you have your eye on as far as, uh, using ditz
Speaker 3 00:36:19 A couple that, um, Evernham is working on right now that I'm particularly excited about, there's a group called <inaudible>. They do, um, blockchain stuff with credit unions and banks, and they had, they'd been using, you know, decentralized identifiers, uh, as a means of bootstrapping secure communication and authenticated communication between credit unions and banks and their customers. And it's been, it's been really fun watching the rollout of this because I, I, I don't, I think many of us are familiar with the process of calling the bank. You call the bank and they go, who are you? What's your account number? What's your date of birth? What's your mother's maiden name? Uh, there, there may be, you know, security questions. What was the name of your first pet? And, uh, you know, there are all these, all these things that have to all this friction to getting to the point where I shouldn't actually do some banking, um, what the proof of control of an identifier allows these, you know, this customer story to turn into is, oh, hi, I recognize that, oh, and you're talking on the phone that has the private keys in, okay.
Speaker 3 00:37:40 We know who you are. As soon as they pick up the phone at the call center, they know who they're talking to. Um, and they have authenticated communication back and forth, um, on a side channel that allows them to be so assured as to the identity of the person they're speaking with. They don't have to ask anything at all. All they have to say is what can I help you with today? Oh, you want to send a wire transfer? No problem. Anything else? And by the time the first conversation is, you know, gearing up towards mother's maiden name, reveal the, you know, the second conversation is already over the other use case that, um, we're pretty excited about is, um, the international airline transportation association is creating a travel pass. Um, a lot of people want to travel. A lot of those people want to travel safely and a lot of airlines want to make it possible for people to travel safely. And in, in this time of pandemic traveling safely means I can show that I've been vaccinated or I can show that I've tested negative. And being able to do that in a verifiable way is, is really, really powerful. Yeah. Those are the, that's what I'm excited about. Yeah.
Speaker 1 00:38:57 Thanks for that.
Speaker 3 00:38:59 I think what's most interesting to me of the ones that I've heard about, and this is not going to be a surprise to those of, you know, everyone who's been in this space is the work that the us customs and border protection is using for, for customs tracking of goods from, from the beginning to the end. And I think this sort of cross border, you know, tracking of, of information about goods is really, is really fabulous. It's just been an absolute nightmare for governments around the world to know what is ha where did goods come from? It's, it's essentially the whole, the whole Providence thing, right? Um, what happened, when did it happen? Where did it happen? And the reason that this is to me, so, so interesting is because it is taking advantage properly of the chain of verifiable credentials. It is the chain of usage of DIDs that makes this work okay, where you do not have to prove everything from beginning to end.
Speaker 3 00:39:59 You only have to prove your part here, but because of the way these tools are designed to operate, you get an end to end connection. I think that is immensely valuable where you lose privacy in the identity space is when each individual entity believes that they must themselves see all of the private information to verify themselves every time, because there is no ability to trust what someone else has done. So I, I like the fact that there is now a set of tools for that. And so I'm just using the supply chain one as an example, or the, or the customs chain as an example of that. Um, but I think it can apply more genetically as well. What
Speaker 0 00:40:46 I love about the customs and border protection is, um, they are dealing with fundamentally transnational interactions. So there are going to be people in the supply chain who own a shipping business and they're Chinese, and they don't want to have anything to do with registering with the U S government and CBP with using DIDs has a technical architecture that will allow us to have tracking with those parties. And they in fact, do not need to yield any of their authority to the U S government, just like our shippers or manufacturers won't have to yield any authority to the Chinese government in, in return. So it's a, it's a wonderful cross jurisdictional, uh, use case where it feels like dibs perfectly made for it. Yeah, that's a good one. We got the sense a few minutes ago that we are inches away, which apparently means six months. So what's happening in that six months. What's next to what can people expect to see if they are watching this space? What should they be looking for
Speaker 3 00:41:49 To be fair? Six months is we should have a, an officially published W3C recommendation in six months. There is a whole lot of work that is happening right now that has been happening for awhile. And that will continue to happen, uh, in the next six months, year, five years. So what's next for, for DIDs is we're getting implementation feedback. We're responding to that feedback. We're getting the test suite written and finalized, and we're doing the nuts and bolts, uh, editorial work that is required to put the final Polish on it before it rolls out the door. Yeah. What I would add to that is that this is version one and it's very important to understand everyone wants to get everything into version one. Okay. Always, always. They want to get everything into version one, but you actually don't need to. What you need from a standard is enough agreement that the world can begin using it.
Speaker 3 00:42:54 And then you will learn and you will make, you will likely make a version two. So there may well be at some point a version, two of DIDs, I believe there'll be a version two, a verifiable credentials. People have been learning and they've been, they've been experimenting with, with, uh, modifications that could be made down the road. So I think, you know, I used to tell people when they'd ask, when is the standard going to be done? When can I use it? And those are different questions. Okay. When can I use it begins with the candidate recommendation, believe it or not now that's for early adopters. Okay. If you're an early adopter, then the candidate candidate recommendation stage is exactly the right time to be using it because we don't believe it's going to change fundamentally at this point, but it might change a little bit.
Speaker 3 00:43:42 Okay. As we tweak a few things by the time it's a recommendation. Yes, you should absolutely be using it. Um, but that's not the end. That's kinda, that's the beginning of the story. That's, that's now the point when you can tell all of your customers, we have implemented the standard because there's a document with a fixed date on it, and you can point to that thing and say, that is what we implemented, that's immensely valuable for, for the community. And so what comes after that? You know, it's interesting. I actually just asked someone, uh, in this space today, you know, where do you think things are going to go, where, where what's going to happen next? And I think no one knows exactly what's going to happen next. There are a lot of interesting pieces of work aside from dads that could happen. And, um, and Brent is actually more involved in them than I am. So he probably would give a better idea of some, some of the work happening in the CCG that could turn into something, you know, turn into a piece of, uh, you know, sort of formal standards work. But I think that's what I would say. We're, we're close. Like we expect to be done currently by the end of September, but don't wait. You don't have to wait. You, you know, use it. Now.
Speaker 0 00:44:51 One of the things that I like about how the DIDs and feces are architected was a separation of concerns. And there are several pieces of the architecture that are still pre standards track. Like they're still early, like the presentation requests standard. And I don't, I don't know the names of all these things, but I want to get your sense of what are the pre standards work that you know of that people might want to pay attention to so that they can contribute to how we, how we layer on new functionality or additional functionality on top of DIDs.
Speaker 3 00:45:27 One of the things that's happening right now is folks want to develop protocols that they can use to pass these data models back and forth. Uh, one of the protocols that's being developed is a presentation request. What are, what are we calling it? Wallet and credential interaction, presentation exchange protocol is of mouthful. Um, I'm sure it'll be, I'm sure that the name will change. Naming things is hard, but we have a large group of very interested folks from all sides of the ecosystem, working together, parts of the ecosystem that traditionally haven't worked together are now actively trying to work together. There are a lot of different viewpoints from the outside in, it might seem like there's this kind of homogenous group think happening inside of the decentralized identity space. It's really, really not that way for, for folks who dive in. So to have a project.
Speaker 3 00:46:33 So right now it's at the decentralized identity foundation is doing some pre standards work, trying to figure out what's the best way for a verifier to ask for information from a holder. And it seems like a simple proposition, but a lot of different people have proposed a lot of different ways to do it. And this is one of the first opportunities that proponents of those different ways have actually come together to say, okay, now how could we all do this the same way? How can we all take the good ideas that we've all come up with and bring them together into something that we can all try to use? This is really important, and I'm glad you brought this up, right? When the verifiable credentials work started, there was no unity that I could see in HII in the different communities, you know, doing identity work and particularly in a decentralized way, right?
Speaker 3 00:47:23 What we're talking about here. And even when we started the good work, there were some strongly disagreeing camps, right? When we began the work. So this, the, one of the big benefits of the work is that we now have people trying to work together. That doesn't mean that they're not innovating. And it doesn't mean that they're not coming up with alternatives, alternative ways to do things. But there is, I think, a greater realization now through, through the evidence that we've created by creating the specifications that the world benefits. And that means you will too, if we all use the same thing. And sometimes that means that your thing that you think is ideal might not be the end result, but it's okay because we're all going to end up using the same thing in the end. And that will be more valuable to all of us.
Speaker 3 00:48:15 Uh, possibly example is screws. Imagine going to the hardware store and having to choose a particular screwdriver to work with the brand of screw that you want to use, oh, you can't use a Phillips screwdriver that doesn't exist. Imagine a world where every screw manufacturer says, here's our screw, and here's the thing you need to use to screw it in. That's like we've designed the screw with VCs and we're designing, you know, w decentralized identifiers, what folks are now trying to decide on is what does the screwdriver supposed to look like? Because right now there's a whole bunch of different screwdrivers and some of them have different privacy characteristics than others to completely stretch the metaphor. But, um, we, we do recognize the usefulness and the need to come together on something we can all agree to share.
Speaker 2 00:49:13 How can people get involved? Where do they go to plug in or to show up and do the work? We talked a little bit about that earlier, how great it is when people are excited and enthusiastic and want to get involved, where do they look first? Or where do they turn? Well,
Speaker 3 00:49:28 I know what my answer would be on this. I usually tell people to start with the credentials community group and, and it, it sorta depends on their knowledge and skill level in this space already. But if you start in the credentials community group, you will hear about the different things that are going on. So that's what makes it a really good place to begin. The challenge with the did work is that we are wrapping up now. So if you're just getting started and you show up on our meetings, you'll be welcome to, uh, you know, if you're a W3C member, you can, you can join in the meetings, but you may be lost because we're discussing things at a level of detail that, uh, even, even people who are there may not even fully comprehend. Okay, is it depending on the topic, there might be a small number of people there who do understand it in depth.
Speaker 3 00:50:14 So, anyway, my recommendation is credentials community group. Um, I, I'm not personally involved in, um, most of the work at diff, but there are a lot of great groups there, I think for beginning. And so, I don't know, Brent, you may disagree with me, or you may have some other, those are, those are two that I would name it. It would depend on the interests of the entity getting involved. If the interest is in, I want to learn about this space and I want to meet some of the players and I want to contribute on an individual level. The CCG is fantastic. The decentralized identity foundation is fantastic. The there's a group at Hyperledger Aires. That's fantastic. All of these have slightly different flavors and, and slightly different groups of people. There are, there are a whole bunch of people who are in all three or are in two of the three, but any of those would be a good place to go and find out more. Great. Thank you.
Speaker 0 00:51:09 So we want to move towards wrapping up. This is the rubric. And so my question for you too, is what do you think are the most important questions that someone should ask about a method when they're considering whether or not it's a good fit for their application?
Speaker 3 00:51:27 Well, as I said earlier, I don't have a strong opinion on that one. Um, I'm going to plant so over to you, right? But the, the first question is, does it do what I need it to do? If all you're needing to do is exchange keys then did key, might be what you need, if you want the ability to rotate those keys over time, but remain as private as possible then than did peer might be for you. If you really like the distributed notions of blockchain, then BTCR, or one of the methods that's built on top of Ethereum, did I on, uh, is another one might be right up your alley if you're a government or a business, and you're concerned about a trust model or governance around a ledger and the whole Bitcoin thing kind of scares you then a public permissioned ledger, like one of the indie ledgers might be more your style.
Speaker 3 00:52:19 There, there are a lot of options. And I think it's actually really good at this point that we have actually, I love that answer because, um, I I'm sure you're probably going to bring it up at some point, but if you don't, the rubric document that is being that is, that has been developed and will, uh, be worked on in our working group that did work in group, I think will be quite helpful. That's a dig method, rubric document, whose goal is to actually lay out a set of questions, the considerations for people to, to take, uh, when doing their own evaluation of good methods.
Speaker 0 00:52:56 Thanks for that endorsement.
Speaker 2 00:52:57 Yeah, we, yeah. We'll have the link in the show notes for sure. And that sound brings us to our shameless plug segment. Do either of you have something that you'd like to give a shameless plug to?
Speaker 3 00:53:10 I do. I have a shameless plug. Evernham has been building products that allow for enterprise level use of verifiable credentials and decentralized identifiers. And one of the challenges in the space has often been, how do I try it out? How do I evaluate the software? How do I evaluate this whole idea without needing to attend a lot of meetings to try to figure it out. We have a developer sandbox it's really, really easy for anyone to go to go to our website. It's evernham.com/developer. You can create a developer account and you can use all of our software. We've, uh, open-sourced our software. Um, it's a business source license. So we guarantee that every feature that we develop is in code that you can read, uh, within two years, it's going to be, um, I think on Apache two license, so open, open source, and until then, it's a, we want you to be able to use it, but if you're going to use it a lot, please pay us for it.
Speaker 3 00:54:19 Um, but the developer sandbox is the place to go and try that out. And I would encourage anybody who is curious about verifiable credentials and kind of wants to play with some tools to use them, to check it out. Yes. Um, so this is something I didn't make clear at the beginning. I am, and I am acting as an invited expert in the decentralized identifier working group and in my role as chair there. So I am not officially representing the enterprise Ethereum Alliance. However, since I'm here, I am going to give a shameless plug. And that is actually, I should say, in my role as chair of the dead working group, I'm, uh, I actually very neutral, right. And I won't, I won't talk about one particular blockchain or another, but of course in my day job, uh, with the enterprise Ethereum Alliance, uh, Hey, Ethereum, Ethereum, Ethereum, and all of you are crazy if you're not using a theme for everyday.
Speaker 3 00:55:13 Okay. So look, the shameless plug I have is that we had, we had one of our, uh, big conferences last week, Ethereum in the enterprise. And so if you go to our website and the link will be provided here, we are going to be having recordings up from all of those presentations shortly. And I do encourage you to check them out. Uh, the, the focus of this last event was on the Ethereum main net, the art of the possible. So what is it that you can do today, uh, without waiting for a theory to there's an awful lot and let's face it. If there yum is the, um, is the biggest Mo longest running most stable, uh, largest number of developers, et cetera, chain out there. So, um, you know, we all think it has a really good potential to be the trust anchor or the internet. So, uh, if you want to learn more about that, if you want to get involved, if, if a theory is important to your business, if the existence of a theory is important to your business, then you should be a member of EEA and we would love to have you.
Speaker 2 00:56:12 Excellent. Thank you both for all of that. And that brings us to the end of our show today.
Speaker 0 00:56:18 We'd like to thank our guests, Dan Burnett and Brent Sandel, especially you are a first outside guests on this podcast. So thank you for putting up with a technical snafoos and then figuring out our process. This has been fun and interesting. I hope you enjoyed it. I also want to thank our staff, uh, our producer, Erica cuddle, and my co-host Eric Chu. Thank you.
Speaker 2 00:56:40 And wherever you find the rubric podcast, please take a moment to subscribe to our feed. So you'll be notified when our next episode is released. We look forward to you joining us next time. The
Speaker 4 00:56:51 Information opinions and recommendations presented in this podcast are for general information only. And any reliance on the information provided in this podcast is done at your own risk. The views, thoughts, and opinions expressed by the speakers in this podcast belongs solely to the speakers and not necessarily to the speakers, employer, organization, committee, or other group or individual <inaudible>.
