Episode Transcript
[00:00:05] Speaker A: Welcome to the Rubrik. I'm your host Joe Andrew.
[00:00:08] Speaker B: I'm Erica Connell.
[00:00:10] Speaker C: And I'm Will Abramson.
[00:00:12] Speaker B: Today on the show we talk with Steven Curran and John Jordan, co creators and implementers of the DID webvh DID method. DID webvh adds historical verifiability to DID web using cryptographic provenance to establish that the current DID document is the result of legitimate updates by the DID controller.
[00:00:33] Speaker D: This is part two of our two part episode.
[00:00:36] Speaker B: Part one can be found at Rubrik cc.
[00:00:41] Speaker E: Yeah, that's clearly an important public good.
[00:00:47] Speaker A: On the Rubrik. We talked to the folks making decentralized identity happen. We chat about the technologies and motivations behind decentralized identifiers including dids, DID documents and DID methods so our listeners that's you can make better decisions about which DID method is best for your use.
[00:01:05] Speaker B: Decentralized identifiers enable verifiable interactions without dependence on a trusted third party. So instead of being forced to use centralized verification services like Facebook, Google or the Department of Motor Vehicles, DIDs can be created by anyone, anywhere and be used for any purpose.
[00:01:23] Speaker C: DID methods are the magic ingredient that give DID their flexibility. Before creating any specific did, you first choose a DID method which determines how you perform the Create, read, Update, and activate operations on a DID of that method. Once created, each DID includes the name of its method in the identifier itself. This is so when you use the did, others know how to retrieve the associated DID document that contains the cryptographic material for verifiable interactions.
[00:01:51] Speaker B: Different DID methods use different underlying mechanisms with different performance, security and privacy trade offs.
[00:01:57] Speaker A: 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.
[00:02:08] Speaker C: Stephen Curran of Cloud Compass Computing, Inc. Is A software development DevOps veteran who's been working with DIDs, VCs, ledgers and the Trust over IP stack since 2017.
Consulting for the Government of British Columbia and others, Stephen has helped define, build and launch a variety of proof of concept and production applications based on maximally privacy preserving verifiable credentials. He is actively involved in the Open Wallet foundation, contributing to ACAPI and interoperability testing projects and leading the specification of the DID webvh DID method for high trust survivable decentralized identifiers.
Stephen is also a co author of edX courses on high Indie, Aries and Anon Creds. Please note that Stephen does not speak for the Government of British Columbia and his comments and opinions on this Podcast are purely his own.
Stephen, welcome to the show.
[00:03:00] Speaker F: Thanks, Will. It was very nice.
[00:03:02] Speaker B: John Jordan is the Executive Director Advisor for Inclusive Digital Infrastructure with the Government of British Columbia. He leads efforts in digital trust focusing on secure privacy preserving public services that are inclusive and accessible for all. John, welcome to the show.
[00:03:19] Speaker E: Nice to be here. Thanks for the introduction.
[00:03:22] Speaker B: Here we continue the conversation and next we turn to the juicy segment of the podcast conflict.
What were the political, technical or human challenges you faced developing WebVH?
[00:03:39] Speaker F: I think it's kind of funny. The probably the biggest thing is dids are a low level component and so crucially important, but very low level. And so it is easy to say I've got so many things I got to worry about because I've got to create this thing that citizens can use or a person can use and there's like 14 layers between that person and their phone and, and it did. And so we're just going to use what's out there. We're just going to do something easy. And so getting people interested in that, getting as I have a few times on this discussion, getting deep into the weeds that I'm excited about, but like, who cares? Come on, it's way down there.
But it's crucial to have these pieces in place and that's been a real challenge is getting that interest. So people want to understand, okay, this is what's different about these, we can start to use them now and so on.
It's been kind of fun lately. In the last three weeks we've had at least two fairly significant organizations point out, oh, by the way, we've already got WebVH implementations done and we're using it out in the world. And I'm on Blue sky and just the other day I happened to notice somebody started a conversation, I have no idea who these people are, but they started a conversation about Did WebVH and the pros and cons of using it, things like that. And that's kind of fun to see that out in the world.
Would love to see more and more people come in and say, okay, we're using it, or here's the feedback to it. We're getting some really good feedback from an organization called Affinity in I believe, Singapore. I'm not even sure exactly where they are, but they've done an implementation, they've implemented Witnesses and Watchers, you know, all of it and they've got feedback on it and they're giving it to us. It's awesome. And so that's been certainly a challenge, a technical challenge.
[00:05:42] Speaker E: I think there's the. Yet another DID method which I think you folks would know and appreciate even more.
You know, which probably has a corollary which is like my DID method is better than your DID method type conversations.
You know, I think to a certain extent this, this area of decentralized identity has suffered from a lot of really smart and well intentioned technical people arguing amongst themselves with not always necessarily a strong connection to the real world implementation and use cases that can benefit from this. And perhaps some energy has been spent that could be better spent in different ways.
[00:06:42] Speaker F: John's opinion, and I would add people would say that about us as well.
[00:06:48] Speaker E: Sure, I'm sure.
So what I've tried to do in our, you know, world is because we are actually trying to implement and we are implementing in British Columbia, that feedback loop can happen. You know, it's a fairly small team.
We have specific use cases that we're deploying. We've had experience since we deployed our first live credentials with the Law Society of British Columbia years ago. Now we have 5,000 lawyers that have lawyer credentials and their use is expanding beyond government systems into working with the land title organization and the registries and so forth. That helps us inform technical decisions that we know that we've talked about in this podcast. So I don't know if that's controversy so much as sort of just pointing out how we've tried to learn from the way things have evolved in this industry and try and move or bring in business and inclusion thinking right down to that 14th level that Stephen talks about. Right. Like that's really hard to have that full stack view, if you like, from the cryptographic keys and principles all the way up to what's the user experience of a person trying to actually use a credential?
That's a challenge.
[00:08:36] Speaker A: Okay, next couple of questions. We wanted to talk about witnesses. Our understanding is that witnesses are selected by the DID controller to help them secure their did. And they do this.
The witnesses do this by co signing every DID log entry. And so if an entry isn't signed by the defined threshold of listed witnesses, that associated update is invalid. Does that mean that DID as a whole is invalid? Or can you move past sort of that kind of error?
[00:09:06] Speaker F: So the.
Essentially it can't be updated further in that situation.
So it's valid up till the prior entry, if you will. So we do have wording in the spec to say, you know, if, if the DID is found to be invalid later for whatever reasons, it's valid up till this point. But if You've truly lost control or, you know, your ecosystem has broken such that witnesses will no longer sign your. Your DID log entry, then, yeah, you cannot evolve it further.
[00:09:40] Speaker B: It seems that witnesses make it more complicated for me to update my own dids, so why would I add a dependency on another signer?
[00:09:48] Speaker F: Absolutely, it is more complicated. We've, as I said, we tried to make it very simple in the spec. Here's the mechanism.
Now go do what you want with that mechanism. And our viewpoint is an ecosystem may want that trust, that distributed trust.
Recall that we're coming from places where, oh, we used a ledger and multiple participants in a ledger came to agreement that this transaction would be published on the ledger. So there was consensus.
This is a way that it can still happen with consensus, but the mechanism is relatively straightforward to implement. The governance is much trickier to implement and, and there is that distributed control over it to allow for consensus of an ecosystem to approve DID updates.
Whether you want to use that or not, that's a different question.
[00:10:48] Speaker E: I think that it's a feature, again, that is very technical, but it gives you choice as a DID implementer of how you want to lend trust to your did and therefore the things that you use the DID to sign, like your credentials and so forth. So you have sort of a technological capability, the watchers and the witnesses, but you also have a governance capability that you can, for example, manifest as whois credentials.
So you have multiple vectors with which you can build trust in your DID and therefore your credentials and therefore your business or your government that connect you into your peers, whether it's other government services or public private sector services, or if it's a supply chain transparency use case, you know, I click on or I tap on my phone or use voice control, if it's me, to go into my, you know, settings on my iPhone general about, tell me about the materials in this phone.
And it's able to traverse the supply chain all the way to the point where it can say, yeah, I can see the copper in my phone is sourced from a BC mine which has been verified as a responsible mining organization that respected first nations rights and so forth and so on. I mean, that's the kind of detail that we think is possible. And in fact, we are working on NBC with the UN transparency protocol on supply chain. And did WebvH and WHOIS fit right in there very nicely.
Great.
[00:12:50] Speaker C: It sounds like you're saying there's a lot of value in having an identified set of witnesses, particularly if they're tied with two, like some Governance system that's saying, you know, these three parties are going to sign off on the dids that are part of this ecosystem. I wondered on the flip side if you'd considered using a multisig approach to obfuscate some of the witnesses so such that only a single signature would be required but could be aggregated from multiple parties.
[00:13:18] Speaker F: We did think about it a little bit, decided to go with the simpler mechanism that was based on a didkey specification and the data integrity proof specification, so we didn't have to include any other specifications or standards.
That said, one of the mechanisms we have created was that all keys are so called multi keys, meaning they're self describing so that you can identify from the key what type it is and so on. And then we have each specification by saying this DID aligns with version 1.0 of DID web VH that that enables what types of keys, what types of cryptography, what algorithms can be used. The idea there would be, well, perhaps we'll have a did you know, v1.5 that says oh, we allow multisig did controller keys that use this mechanism, whatever that might be, those would be identifiable by a multi key so that you would know that's being used and then that could be used. So that's the crypto agility and the ability to extend out so that absolutely could be added in the future relatively easily. The mechanisms are built into DID webdh already to enable that type of extension in a fairly rapid manner. If someone comes up with a clean easy way to do that, we would just say, okay, this new version allows for that. A DID that already exists puts a parameter in that says I'm now using DID WebVH 1.5 and from then on it could use that multisig capability if that was allowed in the spec.
That's the approach we've taken is let's get it out there and built on existing, but enable that agility going forward if that makes sense.
[00:15:25] Speaker C: And just quickly, what types of keys are supported today in version 1 ed25519.
[00:15:31] Speaker F: So the authorization key so that remember the DIDD DOC can have anything you want in it. So there's no limitation on what keys you put in the DIDD doc but for the authorization, ED25519 keys are the only ones that can be used to sign the data integrity proof. So it uses a particular ED DSA JCS 2022 I believe is the specification of that spec and it requires an ED259.
So again, I always want to emphasize we only allow that for the authorization of the update. What you put in your DID document, whether you put, you know, any key that supports any particular thing, that's up to you. The DID doc is totally up to you to do. The authorization key is a separate key that you would use.
[00:16:23] Speaker A: Okay, let's move on to watchers. Our understanding is, is that watchers are selected not by the controller, but by relying parties. In other words, those who resolve the DID and use the DID document, they get back to perform some sort of verification.
And the watchers help by maintaining a duplicate of the DID log file whose entries are all signed. So they can't change the DID log file, they're just keeping a copy of it. And that allows the relying party to perhaps evaluate any discrepancies between what the watcher or one or more watchers return and what the primary resolution from the website might return. So this is, as I understand it, a defense against late publishing, which is where a DID controller manipulates the state of the vdr, the verifiable data registry, to change the perceivable history of updates. And so I think this watcher mechanism is primarily to sort of help deal with those kinds of problems. Is that a good framing?
[00:17:23] Speaker F: Not bad, except. So watchers you have in there. What you said was watchers are selected by the relying party, and that's not quite right.
Just like witnesses, the dead controller chooses which watchers to put in.
A relying party is free. Any relying party is free to have any number of other watchers.
So that's there. But an official watcher is one that is notified by the DID controller. Hey, I just updated my this did or hey, I just added this resource file.
So there is an official watcher, if you will. And I've put that in air quotes because it is literally in, in the entry of, of the didlog there. It's in the DD log file listed. Here's the URL that you can find a watcher. And again, any other relying party can have any other number of watchers.
We definitely did it for longevity of the did. So you can now say, oh, I resolved this did and now I have a list of other places I can get the latest version of it. So now if the original location of, of the DID goes away, I have these other places that I can go to.
How again, governance, you know, you started talking about, well, it can be used to mitigate this risk. That's more a governance question, how you would want to use those watchers. Maybe a DID decides I'm going to go to each official watcher and grab copies and make sure there's consistency among them, there's consensus, and that's a viable use case. But we leave that more outside. The spec just simply says, here's what a watcher can do. Here's a watcher gets notified when it comes out, and here's how you can ping a watcher to get back the thing without contacting the original location.
Does that make sense?
[00:19:37] Speaker A: Yeah, it's a great clarification.
[00:19:39] Speaker B: Are watchers a necessary part of the verifiable data registry, or what guarantees are lost without watchers?
[00:19:46] Speaker F: No, they're not required at all. They're only if they choose the biggest thing. We have a concept of portability and it's again an optional feature. And portability says, oh, by the way, the web sometimes is mutable, sometimes a website goes away, sometimes two companies merge and one of the websites goes away. And so portability says, I can take a did that has a specific scid, self certifying identifier, unique identifier embedded within it. And it used to reside on website A and now it resides in website B. So that's technically a completely different did because the DID string is different.
But when using portability, the skid remains the same and the verifiable history remains the same.
With that, the reputation, if you will, of that DID can continue even though it's in a new location.
A watcher can smooth that out by saying, oh, I went to resolve this website and it no longer exists.
Let me go to the watcher query by the skid and I can find out the new location of it.
And so that's a way of making dids last much longer. So we see that as the big purpose of watchers overall is that longevity and consistency over time as the web evolves.
[00:21:22] Speaker E: Great.
[00:21:22] Speaker C: Can you provide some example configurations maybe of watches and witnesses in particular context that you're working in?
[00:21:31] Speaker F: One of the things we discover is, okay, we've created these mechanisms, now how do we use them?
Practical, useful way.
The witnesses, as I mentioned early on in this discussion, was that we use it for authorization or approval. Approval, that's actually the word that's in the spec, although the word, what it means to be approved isn't defined. But the fact is that a witness approves of an update. And so in British Columbia we're using it that this central organization would approve the dids of other entities within other sub entities within British Columbia. So that's how we're using witnesses, we think in the United Nations Transparency Protocol UNTP that could be broadened out to say, oh, we've got this ecosystem of copper producers and here's the whole, here's the witnesses that allow updating of the producers bids.
Certainly that would be in a use of watchers. Oh, copper mines come in and out of, out of existence and so the entities may or may not survive, but we still want to know where they came from or more particularly things like recycling of batteries. So we want to know what were the mines that produced it and what are the recycling capabilities and mechanisms. And we want those to last for 30 years because things might not be a battery might not be recycled for that long.
And so that very much is where a watcher comes into view.
It is.
So we're just starting to get to implement those and do them in a practical way, let alone things like key rotation and organizing that. What are the rules around it?
The fun thing about having a, you know, a centralized identifier that has a set of rules is you follow those rules and you just do it. A decentralized identifier. Somebody's got to make up those rules. And sometimes it's, it's the organization and it and how they will use that, what those mechanisms. And those are hard to come up with. So we're, we, we think we've given enough rope for people to do what they need to do and we think they can then manage it from there.
[00:24:00] Speaker C: Great, thanks. That was really helpful.
[00:24:01] Speaker A: There's an active conversation right now about the no Phone Home statement endorsed by various organizations and leaders in privacy and digital identity, including me. Since resolving a DID WebVH DID requires an ACTP request directly to a website controlled by the D.I.D. controller, do you have any concerns about this being seen as a form of Phone home for credentials that are signed using did WebVH dids?
[00:24:27] Speaker F: Absolutely. And I think there's definitely a perception of it. But, but for phone home to be effective, if you will, it's more at the verifiable credential level. And, and the, the issuer knowing who is either who is contacting it for information or identifying the specific entity that is that that is being verified.
So as a holder, I go to present a verifiable credential and then a verifier receives that verifiable credential, do they have to go in resolving that, in verifying that verifiable credential, they probably need to get a public key. So they need to go to the issuer potentially to pull it in. But Retrieving the DID log file does not tell you why you are doing it. So we think that mitigates that to a great degree. And so we're fairly comfortable that there's not an identification of the individual whose credential is being verified.
That said in an on creds, for example, the holder has to go and receive a more or less real time revocation registry and that will be published on a DID web vh. So now you've got the potential that the holder is retrieving data that is at the time they're doing a verification.
We're doing some things with an on creds to make that non identifiable. We're making, we're making it so that we can have extremely large revocation registries so that in the order of a million credentials so that any holder retrieves the same file as any other holder. So you can't tell who, who is requesting it or why they're requesting it. So that's a mitigation we're working on for that particular issue.
On the verifier side, there isn't the problem. The verifier grabs it no matter who the holder is. So there's no identifying data of whose credential is being verified back to the issuer.
So those are the mitigations we see.
That said, there is a perception that is trouble legged and it is a challenge.
There's other mitigations we can think of things like a verifier not requesting revocation information unless they really need it.
So business case specific of separating out when revocation data is retrieved from when it's being presented.
So standard times where oh, the wallet periodically in the background retrieves revocation data so that it doesn't have to do it when the holder presents the credential. Things like that are mitigations that we're looking towards for dealing with that DIBWebVH, even though it is managed by the issuer, if you will, is not inherently.
It's the verifiable credential mechanism on top of it that would enable the no phone home.
[00:27:58] Speaker A: I think that's a great answer. I mean to me, I think the simplest answer, which isn't as complete as what you just described is that if you're signing a verifiable credential as an issuer, the phone home doesn't include any information about the subject because those are just different things. So for example, if you had a.gov domain name with a did webvh on it and you're signing government issued credentials with that, then the phone home to get the DID document for that government agency doesn't have anything in the loop about who the subject of that credential is. So it is kind of blinded in a certain way.
Even though people are going to think through this process of wait, there's a phone home, isn't there? And so I think we just need to get ahead of the conversation and clarify the extent to which this is not the simplest interpretation of phone home. There's a little bit more nuance and I think for the most part it passes my test about at that level that when I resolve the signers DID documents, I'm not inherently leaking information about the subject.
[00:29:16] Speaker E: Absolutely. Yeah. It's just a, hey, somebody read my file.
Not somebody, actually a, you know, a piece of software out there read, you know, read this file, this public file, this public file and okay, it's like they looked at my sign.
[00:29:35] Speaker A: That's right. It could be a web crawler from Google.
[00:29:37] Speaker E: Exactly. It could be anything.
[00:29:38] Speaker F: Yeah.
[00:29:38] Speaker C: Okay, great. Just a follow up question on that. Does this DID webvh spec place any requirements on like the website platform itself about how it tracks or authorizes access to files required for DID webvh?
[00:29:51] Speaker F: No, no. Everything is published to a web server and is published. So there's nothing in the spec that would provide APIs of how that would be used or how it could be retrieved and so on. We have APIs that we do define for a watcher independent of the DID controller.
That's a mechanism, but no.
[00:30:18] Speaker A: Great. I think that's enough conflict for this podcast. Let's look to the feature what is next for DID webvh?
[00:30:26] Speaker F: The big thing we're doing now is production.
So one of the people I didn't call out in the earlier part of who's contributed was a guy named Patrick St. Louis who has worked in various places in W3C, VCAPI and various things. He's taken a lead in developing did WebVH server, in weighing in and implementing a watcher, and in working with a team member on ours, Jamie Hale, on the Akapi plugin. And we're actively using those to fit all of the things we used to have in supporting and on creds and authorizations in Indy and so on, building it into an implementation that supports, that is based on and enables verifiable credentials rooted in DID Web vh.
Also working hard, Patrick is on the UNTP side of it, which is publishing W3C format credentials with DID WebVH so that's the big thing we're working on right now which is getting it out in the world so that it's. Anyone can. So that a we can use it but doing it in the open. British Columbia does everything in this space in the open and so very much welcome any contributions and taking the code, using it for your own uses. But it really is making it very practical. It's not just this theoretical thing but very practically how you would use did WebVH in a real implementation. And that's what we're doing. A real implementation.
[00:32:16] Speaker E: Yeah. Like Stephen says, we're putting putting this into our public facing app which is currently called the BC Wallet.
We want to implement the WHOIS capability so that people can verify who they're interacting with. Just like signs on a physical door.
We have a fun little phrase, you know who is strengthens trust at a glance so they can understand the origin of a credential in an ecosystem and really just putting things into production and real world use.
Tongue twister.
So yeah, that's our emphasis.
[00:33:03] Speaker C: And how can people get involved? I think earlier you mentioned the bi weekly calls. When and where do they take place and are there other venues that people should participate?
[00:33:10] Speaker F: Yep, every second Thursday, 9 Pacific, 18 Central Europe time. People are welcome to join the DIF website. The DIFF calendar has the information, the agenda and so on. We'll put in the show notes the rolling agenda we have which also contains the zoom link and information and we keep that updated for each one.
Then let us know what implementations are being done. That's the. We'd love to have that questions about how it. How the spec came to be. We're starting to build out. We have a did web vh.info website again in the show notes and it contains FAQs about how we got to putting certain features in and decided not to do others and things like that. So that will help people implement. And then we have a couple of tutorials as well so people can find all the resources, a list of implementations and things like that. So that's ways to get involved.
[00:34:19] Speaker E: We really welcome feedback and knowing who is actually not the who is that we're implementing, but who are the organizations that are implementing this and giving us feedback on how to make it even easier to deploy private sector participation and so forth.
[00:34:41] Speaker B: Wonderful. We'll make sure that we link to those resources in the show notes so our listeners can click through and get involved if that's their desire. Thank you.
And with that we'll turn to our shameless plug segment of the podcast here in wrapping up. So Stephen or John, do either of you have something or someone you'd like to shamelessly plug?
[00:35:09] Speaker E: I think we've done that throughout. So I'll shamelessly plug Stephen and his huge contribution in leading this work. It wouldn't be possible without him.
Also, you know, the fact that the government of British Columbia has created the space for us to do this kind of work is really important and, you know, hopefully that'll continue into the future.
[00:35:36] Speaker F: Yeah, I think I'll talk about the approach that B.C. has taken in doing open source. I keep running into this and I ran into it earlier today, so I'll mention it, of organizations that take an open source project and fork their instance of it and then deploy from their own fork these features and then tell us, yeah, we changed all that and they have no way of contributing it back because they forked the repo and just have their own private fork of it. So really encourage you to organizations and and governments to do the British Columbia approach, which is do it in the open, do the work in the open and do it in a way that you can contribute back to the open source implementation and not just hold the new things that you add that others would be dying to have. But you've got it in your own world. So do the open source in the right way.
Columbia has done.
[00:36:38] Speaker E: We're really friendly, we promise.
[00:36:42] Speaker A: Well, I want to endorse that and celebrate it, you guys, the two of you. And through you, the BC government really has been present and a part of the community from the beginning of when this started. I remember meeting you at both Iaw and early rebootings.
So I would love to see more governments get this engaged and have this much foresight and willingness to invest and have the patience to see it through. So plus one to British Columbia. Let me turn to my shout out, which is I want to mention nophonehome.com I touched on it earlier.
You can go to that URL. It's simple enough, just spell it out and it's basically a statement helping authorities building identity systems understand they don't need to have this phone home mechanism and the phone home mechanism itself cause problems. It enables surveillance in a way that in a free society we would like to avoid.
And part of where that conversation came from was a simple question asked at Iaw about what is the use case that justifies phone home? And we couldn't find one other than convenience because it was easy to use with existing technologies and the surveillance bit. But nobody wanted to say that we put that in there because of surveillance when we were talking about a particular spec. Now the statement is not about any particular spec, so I'm not going to mention the one that has caught the fire because they're not the only ones that need improvement. All of these specifications are making engineering trade offs and in some context it may be appropriate to do a phone home, but in my opinion most of the time you can do it through another mechanism rather than embedding this sort of surveillance friendly mechanism at the platform level itself. So check out nophonehome.com it's been great to see how this conversation has already shifted how industry standards bodies are engaging with this privacy risk. So nophonehome.com check it out.
[00:38:50] Speaker E: Great.
[00:38:51] Speaker C: Okay, my quick plug is for a book I just recently finished reading called Tiny Experiments. It's a great book. It's all about how you can lean into uncertainty and treat your life as a series of tiny experiments instead of a fixed path to some far off goal, you can sense and react and do more of what you love. It was really a great read, so I recommend it.
[00:39:13] Speaker B: Awesome. We'll conclude the link in the show notes and my shameless plug is for a short attention span theater, a live production that I'm working on. If you're in Southern California, you can look it up in Ventura at the end of August and we'll be having some wacky summer fun with good theater happening here locally and that will bring us to the end of our show today.
[00:39:40] Speaker A: Stephen, thank you for joining us on the show. John, thank you. Thanks also to our staff, our producer Eric o' Connell, and my co host Will Abramson. I'm your host, Joe Andrew.
[00:39:51] Speaker B: You can find all of our episodes at Rubrik cc. Consider subscribing so you'll be notified when our next episode is released.
We look forward to you joining us next time.
[00:40:02] Speaker D: 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 speaker's employer, organization, committee, or other group or individual.
