Speaker 1 00:00:07 Welcome to the rubric. I'm your host, Joe Andrew
Speaker 2 00:00:10 I'm Erica Connell.
Speaker 3 00:00:12 And I'm Eric shoe.
Speaker 2 00:00:14 In this episode, we resume our conversation centered on did pier with Daniel Hardman, one of its creators and drum and re a lead implementer. The first part of the conversation can be found in the previous episode.
Speaker 4 00:00:27 It's unusual, I think to have a spec with this many contributors, but in particular, this many contributors who contributed this much
Speaker 1 00:00:35 On the rubric, we meet the people, making decentralized identity, a reality. We discuss the technologies and motivations behind decentralized identifiers, which encompasses DIDs, did documents and did methods so that you can make better decisions about which did method is appropriate for your use.
Speaker 2 00:00:52 Decentralized identifiers enable robust identity based services without dependence on a trusted third party. Instead of being forced to use centralized identity verification services like Facebook, Google, or the department of motor vehicles, DIDs can be created by anyone anywhere and be used for any purpose.
Speaker 3 00:01:12 Did methods are the magic ingredient that gives, did their flexibility before creating any specific? Did you first choose a did method, which determines how you perform the create read, update, and deactivate operations on a did 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?
Speaker 1 00:01:42 This show the rubric reviews different did methods with their creators and implementers. So you can make better decisions about when and how to use DIDs in your applications.
Speaker 2 00:01:53 Daniel Hardman is a contributor to the verifiable credential and decentralized identifier specs. He helped launch Hyperledger indie and the sovereign foundation and has become fascinated with mesh networking and other decentralized protocols that don't use blockchain. He currently works on digital cash at S PPA
Speaker 3 00:02:12 German Reed is chief trust officer at ever co-author of the book self-sovereign identity from Manning publications co-editor of the w three C decentralized identifiers 1.0 specification and co-chair of the trust over IP foundation governance stack working group, as well as the concepts and terminology working group.
Speaker 1 00:02:33 The did peer method was the first did method I knew of without universal global resolution designed to facilitate direct one to one DDS. Only those parties to the period can resolve the did no one else even knows that did exist much less. How to get to the did document making did appear arguably even more decentralized than ledger based DIDs.
Speaker 2 00:02:56 Here, we resume our conversation.
Speaker 1 00:02:59 So I wanted to, uh, get personal. You may have noticed, we shifted to questions about why you got involved. And so I'm curious, why do you do this work? What, why does this matter to you personally, for both of you? And I'd love to get a sense of, you know, what in your personal background makes you get up at the, the strange times that we need to, to have meetings with these international collaborators and, and the schedule and the travel and all this other stuff. What drives you in this work?
Speaker 5 00:03:29 A number of years ago, uh, my wife and I adopted two children from Haiti and I flew down to Haiti in 2002, and I spent a week at the orphanage where they lived. I went with officials of the orphanage to talk to us officials in Haiti and to Haitian officials. Uh, I went with them on the streets not to get permission or consent, uh, related to my own adoption, but they were in the process of the day, um, getting some consent for some other, um, adoptions that they were facilitating. And I met, um, an, a, uh, a birth grandmother who was giving consent. And I came away from that experience, very moved by the, the profound implications of humans, having control of their own identity. And this was only reinforced, uh, a few years later when the man who ran the orphanage, where we adopted these two orphans, had his own son trafficked, kidnapped, and trafficked.
Speaker 5 00:04:51 He and his wife were at church one day. And at the end of the church meeting, somebody showed up at the door of the Sunday school and picked up his young son before they walked down the hall. And, uh, this man ended up paying, uh, a ransom twice for his son and has never seen him again. So I feel very passionate about how important it is to provide secure identity to everybody who wants one. And I also on that same trip had some funny experiences with government paperwork. I had proof that we were adopting these specific children, but partway through the process, the Haitian government said, wait a minute. We wanna prove that these children are really, uh, the right children to be adopted. So we're gonna do some DNA tests against a living relative. Well, they shipped out, uh, some paperwork and had this living relative provide a sample, but they didn't supervise how the sample was collected. So what ended up happening was they had a thousand dollars worth of DNA tests done that proved that some relative of some, two children actually, uh, would complete their paperwork, but it didn't actually prove that the two children I was adopting were those two children. And, um, so I became very sensitized to how games with identity can be played. And I think I ever since then, I've had a really strong design, wrong desire to see ordinary people empowered more.
Speaker 1 00:06:40 Thank you for sharing that.
Speaker 4 00:06:42 It's quite extraordinary. Uh, <laugh> Daniel, doesn't talk much about his role as a, a father and a family leader, but I, uh, a lot of us look up to him for, uh, what he's he and his wife have done there. And I've, I, I don't have <laugh> as I think as moving of a story, I headed down into this whole thing of what's. Now these, these decentralized identity protocols and standards, trying to solve the problem of, of decentralized data exchange for which there are myriad uses, as it became clear that you couldn't solve that without solving identity. What I found was really moving me, uh, personally, you know, to get up every, every day and, and get motivated to solve this. It fell at two ends of the spectrum at, at one end, it was frustration with what continues to be, and I've been doing this for 25 years now.
Speaker 4 00:07:41 There are still things that we have to, uh, deal with on the internet that are incredibly frustrating. You know, I'm an expert in passwords and I still get tripped up on passwords. You know, I ever was just recently purchased by Avast. That meant going through a corporate merger. I have never gotten so mad at a set of passwords in my life as the set that I had to establish and the different password rules that were involved. And the fact that I couldn't use a password manager, cause I had to set up a new machine to get a password manager. And it was just, oh, meanwhile, my wife who is not, you know, not involved in any way and internet technology or any of that, but I look at her and as her, it support person, you know, it's just it's and, and it's the password managers and it's the forms.
Speaker 4 00:08:33 And it's the, the things that we could and will, will solve with this infrastructure we're putting into place, which multiplied by, you know, literally hundreds of millions of people doing this every day is just gonna have a, a wonderful effect. Now that's just, you know, call it convenience. And maybe you could call that a, a, a first world problem. You go to the other of it, and Daniel's already explained, uh, but what, what also at, at the other end, we talk about the really, really severe stuff. Every time I read another headline about another ransomware, you know, attack and the scale of which is just going up and up and it's turned into an industry. I mean, there are entire companies, uh, consortia of dark web companies set up now to, uh, exploit the ransomware industry. And what they're exploiting is the exact infrastructure that we need to put in place that should put that industry out of business.
Speaker 4 00:09:35 Right. And that's protecting all of our economies everywhere. And then in the middle, since we've been working on this, I'll finish by just saying, I think maybe folks are aware, we've developed a little bit of a trust problem in society in, at large right now. And if the infrastructure we're creating and, and the ability to evolve the, or get beyond some of the harms that social media, which we all thought was gonna be such a panacea for, for, you know, uh, culture and society worldwide, you know, it's some people using the word as become cancerous, and we don't have to debate that here, but we are working on, you know, I, I do believe this infrastructure is going to give us the basis by which we can start to, you know, reintroduce civilization to the wild west of the internet. I'll stop there.
Speaker 3 00:10:34 Great. Thank you. So both of you have mentioned other collaborators on, did pier just wanna give you both a moment to shout out anyone in particular might have made a significant impact on the, the specification would love to hear their names if you're willing to share
Speaker 5 00:10:50 You bet. As I said, a lot of the kind groundbreaking thinking on micro ledgers that turned into the ideas of the peer did spec from Jason law. Uh, he's not an official contributor to the document that is the peer did method spec, but is a very important influence. The authors that are credited in the peer did method spec. Many of them deserve special shoutouts of one kind or another Oscar, uh, inventor at TNO gave some very deep analysis of the use cases and the rationales for, uh, peer DIDs, Christian Luk at consensus analyzed some of the security properties contributed some ideas. Kyle N hark at a matter significant contributions to the thinking. Marcus SBA contributed both to some of the thinking, some of the verbiage in the spec and contributed as well by running the identifiers working group at D where, uh, the peer did spec has incubated for a while.
Speaker 5 00:12:06 Spin Hammond at university in Zurich, did some security analysis with formal proving tools, John Jordan of the BC government tech team, and, uh, trust over IP fame contributed, uh, Vesh Harani, uh, at ever, and M contributed Devin Fisher to bias Looker at matter Brenton Zele Steven Keran, Dennis re bus and Alexander. She Boff in Russia, uh, on the DSR team. Uh, Mike Valey from security key, Dan jaale from IBM lot of really smart people. I'm grateful for all their help. I think I forgot to mention Martin. And this is because I'm not confident of how to pronounce his last name. I've only corresponded with him, but Martin chair, and I I'll try, uh, C S E R N a I another, uh, smart contributor, Sam Curran, who currently works for in DCO and who in past contribution timeframes worked with the sovereign foundation and has also led quite a bit of work at the, at D is also notable contributor because he wrote one of the three methods of generating the name space, specific identifier,
Speaker 3 00:13:27 Drummond, anyone to add to the
Speaker 4 00:13:29 List. Well, since I've, Daniel's just name checked all the, uh, listed, um, authors and also, you know, mentioned Jason law, who's, who's thinking at ever. And I know I, I, I consider, you know, fundamental to the, the whole concept of micro ledgers and, and, and fear DIDs. I, I think I wanna emphasize because Daniels called them out individually, the unique way that collectively this group came together. And it's unusual, I think to have a, a spec with this many contributors, but in particular, this many contributors who contributed this much, it really reflects in my view, some of the best collective thinking and the way that the SSI community decentralized identity community can collaborate when there's a common problem identified. And they all want a solution that in this case, you know, peer bids do not favor anybody, right? They are it's, it's, it's one of the most democratic methods out there because it doesn't, it doesn't favor any particular blockchain or data registry or, you know, existing player ecosystem. It's just there for anyone to use as an implement. And maybe that's why it has as many contributors as it does. And credit to I a w where some of the sort of key steps forward with the spec and the thinking round period, did, uh, took place that's internet identity workshop, which I think is probably gets frequently mentioned on this podcast.
Speaker 3 00:14:56 So those are the people that have already contributed. If anyone listening to this themselves wants to get involved with did pier, where would you appoint them?
Speaker 5 00:15:04 Well, the did pier spec is hosted at a GitHub repo owned by the decentralized identity foundation. It's being incubated in the identifiers working group there. And so I would say go to the get hub repo, and, uh, there's, uh, pretty good Corpus of issues, uh, many closed, but some open discussion going on there. Things have been a little bit quiet lately because here bids turn out. Now that we have the benefit of a couple of years of implementation and hindsight on our design, they turn out to be a special case of some of the techniques that are now well described for Carrie. And I don't know if you've had a podcast about Carrie already, or if it's on your list, but right now, some of the energy that could be going into peer DIDs is being redirected towards Carrie, because we think that eventually pier DIDs will be a special application of Carrie rather than something that remains separate from it.
Speaker 1 00:16:19 Now, I wanna talk about the juicy stuff.
Speaker 5 00:16:23 <laugh>
Speaker 1 00:16:23 About conflict. So as, as this work has come together, were there any particularly difficult technical, political, emotional problems, uh, anything from the whole gamut of, Hey, this crypto was hard to this guy was a jerk.
Speaker 5 00:16:40 I don't think there was a lot of human drama, but there were two kind of notable points of debate that probably are worth mentioning. And there's one outstanding point of dissonance. So let me go through those in order. First of all, early on in the evolution of peer did when it was a fully written spec, but it wasn't very mature, had a conversation with Manus, sporty, and Dave Longley about did key. And we had a debate about whether we should try to bring the two methods together in some way, what we ended up deciding is that the convergence we would target was a simple convergence of similarity. And I had hoped that did key would always be like a subset of did peer. In other words, it would be did peer applied under carefully controlled circumstances with less features than necessary, but Dave and Manu felt like it was better to keep the did key, pure and simple.
Speaker 5 00:17:53 And they may be right in that. I'm no, I'm no longer questioning their judgment, I think did key as many virtues. Um, but anyway, that was a point of deep debate at one juncture. The second kind of key debate was around how you express verification methods did pier was written before some of the final changes were made to the did spec. And at the time I knew that I needed a way to express certain kinds of logic. Like I want an M OFN rule. This key can only be exercised as a group, not in isolation, uh, things like that. And there, there was not a good example of how to do that in the mainstream did documentation. So I invented my own. And later, when the did spec got around to talking about some of these issues, I feel like my hand got slapped a little bit, that I was out of alignment with the thinking of the rest of the community.
Speaker 5 00:19:02 And it's true. I was out of alignment, but I feel like it was revisionist history to accuse me of knowing what everybody else was doing. <laugh> because I was there first and I don't actually love the solution that the finally got adopted in the did spec for verification methods. I think it conceives a verification, a little more narrowly than I'd like, well, actually the word verification itself, I think is, is more narrow than what I would like, but it's okay. We can resolve this, which brings me to my point of dissonance. And that is, there are still several places in the peer did spec where we have to go back and correct something because after the spec was relatively stable and after we had our first implementations, the did spec changed underneath us,
Speaker 1 00:19:53 Right? Yeah. That's a, that's a big challenge. We're we haven't even published 1.0 yet, for those of you who are listening, there is a procedural quandary and, and some interesting stuff going on in the WC organization itself. And so things could still change <laugh> and that's a little bit frustrating to those of us who are working with deployed code and are gonna have to update all that. So I can, I appreciate your pain on that one.
Speaker 3 00:20:18 As I was reading through the SP I did have a question come up about how did peer implement its authorization. Primarily, I noticed that there were two different, I guess, authorization mechanisms called out, which were, uh, trust profiles and SGL, simple grant language. Are these simply two different options for achieving the same authorization, or is there some fundamental difference where you would use one versus the other
Speaker 5 00:20:44 Actually they're intended to be used in combination SGL rules are part of what you can write and profiles reference rules. So an example of a profile is the following statement, a key with identifier, ABC X, Y, Z, in the did document should have a role called cloud. And then you could have a rule that says, when I want to rotate my signing key, I need two cloud keys and one offline key to authorize that action. That's a rule that I just stated. Whereas the first thing was a profile. So, uh, SGL is a very, very simple domain specific language designed to be encoded in JS O and the statements that I just described are examples of the kind of statements you can put in a peer did, did document to announce your intentions about the rules that you want to govern your did.
Speaker 3 00:21:59 So would it be right to use an analogy, think about the profile as similar to like say a Linux group, and then you can apply your rules for what that group is allowed to do, or how many of that group you need to enact any particular operation?
Speaker 5 00:22:15 Yes, that's a pretty good analogy. Actually, the reason why there's this distinction, and it may feel a little bit artificial, but it turns out that in the C R D T logic that expresses deltas, if you can isolate certain subsets of the structure in your JS O document in a very careful way, you can guarantee that you never have merge conflicts, and this was helpful. So the, the profiles and the rules change at different rates and for different reasons. In other words, go back to the example I gave before. If the statement that a follow that the following key has a, a role called cloud, that's probably a long lived statement. That's not gonna change much or ever in the did document, but whether you want that key to be rotated, or you want to use it under certain circumstances, that kind of data changes more often, and it changes with a different authorization.
Speaker 5 00:23:23 So that's why we've, we've got the profiles and the, uh, rules separated, by the way. Let me, let me just comment on this, that this is an example of something where the peer did spec did something that's a little bit of an outlier and where the mainstream, uh, core did thinking has since evolved in a way that I regret, um, I regret the divergence and I'd like to fix it by changing the peer did spec, I'm not expecting the did core spec to change. So this is one of the things on our to-do list is to bring these back into closer harmony.
Speaker 1 00:24:06 Wow, that's a great segue for my next question, which is about a potential conflict with the did core spec. The section on authentication, uh, section 3.5 and the P did peer spec defines authentication as how did core specifies it with a constraint that only references and not inline key definitions are allowed. So two questions about that. One, why that constraint, cuz I'm curious about the technical argument behind it. And two, that term is protected in the Jason LD context. So I'm not sure it's conformant to redefine it that way, except two questions there.
Speaker 5 00:24:48 So first of all, the reason why they're separated gets back to CDTs again, I want, there's a section of a did document where data should be declared once and then possibly deleted, but should never be modified. And so there is no operation in the protocol for peer bids that allows you to change the meaning of a symbol in a did document. All you can do is either bring it into being or remove it from a did document. Once you've removed it, it's permanently gone and can never be used again. And it turns out that if you allow inline references to keys in the authentication section, then the protocol for synchronization gets more complicated. It's still possible, but it felt to me like a desirable simplification to say, keep all of the actual key content in one place and all of the key references in another place I was in, as far as the rule that says, there's a definition of the meaning of authentication in the J LD context for did core and we are possibly violating it. We're adding a constraint, we're not removing a constraint. So we're, we're saying of all the possibilities that JS O LD allows. We're only allowing a subset. I don't know if that is also illegal or not. I'm not a JS O LD expert, but we're not redefining in a more permissive way. We're redefining in a less permissive way. And I think that's at least aligned with the spirit of what you're supposed to be able to do. This may be one of those cases where we need to fix a technicality.
Speaker 1 00:26:44 The did PI spec defines pair wise and N wise DDS in terms of the subject's awareness of the D I D, but isn't it possible for a to create and use DIDs whose subjects are not part of the period?
Speaker 5 00:27:01 Let me make sure I understand the question you're asking if in a peer group, any member of the group could be using a did that has a broader scope,
Speaker 1 00:27:12 For example, using a, a did that doesn't refer to a member of the period, but is used by the periods to refer to Mount Everest.
Speaker 5 00:27:21 Oh sure. Yes, absolutely. That could be the case. As a matter of fact, I think that's quite normal behavior. The members of a nuclear family, you know, have identifiers that they use with one another, but nothing prevents them from talking about a globally known politician in their private conversations. <laugh> right. I know that I've had a few of those conversations, some with more success than others <laugh>
Speaker 1 00:27:49 Okay, great.
Speaker 5 00:27:50 I would expect not a universe that is exclusively a peered universe. Uh, you know, if you're using peer DS, that doesn't mean you're only using peer DIDs, rather. It may mean that you're using peer DIDs, uh, for the relationships that are true peer relationships and then you're using other kinds of DIDs for other stuff.
Speaker 1 00:28:10 Well, that's, that's the protocol cause complications here. It, it seems to me and I'm, you know, I haven't gotten enough in the protocol to understand it fully, but if we have this example where we wanna refer to Mount Everest with a did peer of the period of my nuclear family, how does Mount Everest participate in the protocol? Like is there a way in my did exchange to define a third party, did that is a did peer for Mount Everest.
Speaker 5 00:28:40 So there is a protocol called the introduction protocol that allows you to bring a new party into, uh, a peer group, but Mount Everest, isn't a very good example of that because Mount Everest is not a peer of human beings and probably will never be in a peer relationship with them. But if you said, I wanna introduce you to my new robot, which I'm gonna use as a pet, that might be a little bit closer, kind of an example. And I think it would work there.
Speaker 1 00:29:10 Right. Okay. So would it be fair to say that four did peer to have a subject in the name space of the peerage it has to be able to participate in the protocol.
Speaker 5 00:29:24 The protocol is only required if you're updating a peer did. So if you're just having a static peer did to reference something, you're just creating an identifier essentially, and you're not gonna ever evolve it. Then the subject for that did doesn't have to participate in any protocols.
Speaker 1 00:29:45 Yep. That makes a lot of sense. It's just like did key in that way.
Speaker 5 00:29:48 Can I make a comment about your observation about any wise pair wise and, um, N wise, just, just briefly, I'd like to say that in a many conversations about DIDs we use the term public did and private did, and I believe that public did and private did as it's commonly defined conflates two issues. There's the visibility of the did. And there is the intended scope of the did. And we tend to think those mean the same thing, but I could, if I were, let's say I were I'm deep throat, and I'm trying to inform a reporter about, you know, some skullduggery that's happening in my political circles. I may have a peer relationship with the reporter. And then if the reporter ever gets called to account, the reporter may expose my did publicly the, did it now has a public visibility, but it still had a scope that was intended to be private. And the, the terms anywise and pairwise and N wise are intended to be more precise because I believe they help us understand what the true tradeoffs ought to be for a particular type of public and private conflates, those in a way that causes confusion.
Speaker 3 00:31:17 So that's actually a great segue to what I wanted to ask, cuz we've used this, these terms anywise peer wise and NY a few times now could one of you two, give us a definition for each of these, what, what is meant by them?
Speaker 5 00:31:28 Well, let me start with any wise, essentially, if you think of a relationship in a visual sense as having a left side and a right side, the left side is the, the subject of the did the right side is some assumption about who might be over there. Okay. And, and any wise did says the assumption is anybody, basically, it doesn't matter. Who's over there. I wanna be known with the same identifier, no matter who it is. A pair wise did says whoever's on the other side, it's gonna be a singular party. The pet name that you have for your significant other is a pair name is inherently intended to have the scope of one other party.
Speaker 4 00:32:21 And sometimes when those, we use those pair names, we do so privately because we don't want any other party to be aware of what that bear name is.
Speaker 5 00:32:29 Exactly. And then an N wise did what you're saying is yeah, there is an enumerable, not I numerable, but E numerable I can count them set of parties on the other side, it's all of my business partners and there's three of or whatever,
Speaker 4 00:32:51 Right? Where all the doctors, all the doctors that you want to have access to a particular set of medical records regarding, you know, procedure or a broken leg or something like that.
Speaker 5 00:33:02 Exactly. Or it's all of the teachers that teach me this semester at the university, but it's not random strangers, which is the any wise case. And there are good use cases for every one of these. I'm not saying one better. All three of those are, have legitimate use cases.
Speaker 4 00:33:23 Yeah. I, I just wanna say that since Daniel I'm one of the most frequent users for simplification purposes of public and private, uh, DDS, they ever had slides, but I always put in the caveat that you really need for precision to use those, uh, the, uh, peer wise and wise in anywise when you're talking any, anything about the actual architecture and usage of, of DIDs. Cause Daniel's absolutely right. They are three de you know, different cases, uh, and, and everything about them from the did method involved to the, to the, the verification methods. It might be involved to, you know, the synchronization and, and, uh, discovery of did documents. They just, all they're three different architectures and they all have good use cases.
Speaker 3 00:34:09 So as a quick summary, then, uh, any wise would be like Twitter, where I'm tweeting and broadcasting to anyone, uh, pair wise would be me and you and N wise would be me to a known specific set of people. So maybe your friends,
Speaker 4 00:34:25 For instance, the set of people working together on this podcast,
Speaker 3 00:34:29 The people on this podcast, great example,
Speaker 2 00:34:31 Gentlemen, uh, what's next for did
Speaker 5 00:34:34 Pier. It will eventually evolve into some closer relationship to, uh, carry. We don't know exactly what form that'll take. There will be new implementations. There's currently two mainstream published implementations. Uh, there's one on Maven central for anybody who's using a JVM based language. There's another one on PII. If you're into Python, there's a few other implementations that are less mature and so more might show up at CPA, I'm working on digital cash. And it turns out that many of the use cases for digital cash have some of those any wise and pair wise kinds of characteristics. And we might, um, want to use peer DIDs in some use cases there. And I think some other interesting use cases are bound to show up. I, I know of a few, and I think that the other important evolution is that we need to, uh, reconcile it back to the standard as the standard finishes its journey and gets set in stone.
Speaker 4 00:35:42 And from my standpoint, the, uh, peer DIDs have proved to be so useful in the overall paradigm of, uh, did to did communications and did come, uh, which I'm just a huge proponent of that. I think as it progresses, they will essentially become, uh, part of the, of the protocol of the usage of the protocol, which is where the intersection with Carrie also comes in. So I, I, I think we're looking at another, another evolutionary generation, uh, or another evolutionary step that will, will be another generation of the, that won't really change these sort of atomic elements, but it'll change the way we're putting them together to actually produce real solutions in the market. And whether they're very horizontal or they're vertical, it's just, it will become built in the way. I mean, we could be sitting here talking what, I don't know, maybe 50 years ago about the IP protocol and how, oh, you can set up a peer to peer connection between two devices over, you know, cross internets. What would you use that for? Right. And, uh, I, I think peer tope connections between arbitrary entities on the internet, when you have all the rest of the infrastructure, we're building the decentralized digital trust infrastructure are going to be, you know, similar to the IP connections of of 50 years ago, just at a much higher human level.
Speaker 1 00:37:10 We look forward to seeing that evolution.
Speaker 2 00:37:13 We'll switch gears now to our shameless plug segment, where we take a moment to spread the word about an event, a project or anything that's near and dear to your heart, who has a shameless plug for us today,
Speaker 5 00:37:26 I'll give a shameless plug for, um, a fantasy novel that I wrote, uh, recently that you can look up on Amazon, which happens to have some interesting themes related to identity on it.
Speaker 4 00:37:37 Uh, and I guess I'm gonna give a not so shameless plug for, um, the next internet identity workshop. And, uh, I think we, we continue to need it as badly as ever. And the big difference is it's gonna be in person mountain view, California, back to the computer history museum to see how much has changed in two and a half years.
Speaker 1 00:37:57 I'd like to give a shout out to the XKCD comic number 9 36 on password strength and those misguided requirements of special characters and capitalization. We'll link to it in the show notes. It's on point and it's funny. Check it out.
Speaker 2 00:38:14 We have one more special announcement. Legendary requirements is hiring. We are a small consulting firm focused on requirements engineering for decentralized identity. We are looking for people who can bridge the gap between technology and humanity. If you have a technical background, thrive on attention to detail and are passionate about helping build systems that make the world a better place. We'd like to talk. We are actively looking for remote team members, capable of working flexible hours on a project by project basis. You can drop us a
[email protected], J O
[email protected]. And that will bring us to the end of our show today.
Speaker 1 00:38:58 Daniel, thank you for joining us on the show today. Drumming. Thank you. Thanks also to our staff, our producer, Erica Connell, and my co-host Eric shoe. I'm your host, Joe Andrew,
Speaker 2 00:39:09 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 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 belong solely to the speakers and not necessarily to the speakers, employer, organization, committee, or other group or individual.
