Episode Transcript
[00:00:06] Speaker A: Welcome to the rubric. I'm your host, Jo Andrew.
[00:00:10] Speaker B: I'm Erica Connell.
[00:00:11] Speaker C: And I'm Will Abramson.
[00:00:13] Speaker B: Today on the show we talk with Marcus Sabadello and Lance Byrd, contributors to and implementers of the Didwebs specification.
This is part one of a two part interview with Marcus Sabadello and Lance Byrd about Didweb S. The continuation of the conversation can be found in part two.
[00:00:36] Speaker D: Can you tell that I'm passionate about that one?
[00:00:42] Speaker A: On the rubric, we talk 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:00] 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:19] Speaker C: Did methods are the magic ingredient that give dids their flexibility. Before creating any specific did, first choose a did method, which determines how you perform the create, read, update, and deactivate operations on a bid 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:49] Speaker B: Different did methods use different underlying mechanisms with different performance, security, and privacy trade offs.
[00:01:56] 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:07] Speaker C: Marcus Tabadello has been a pioneer and leader in the field of digital identity for many years and has contributed to cutting edge technologies that have emerged in this space.
He is the co editor of the decentralized identifier specification at the W three C, co chair of the Identifiers and Discovery Working Group at the Decentralized Identity foundation, and a member of the Technical Governance board at the Sovereign Foundation.
Marcus has spoken at many conferences and published papers about both the politics and technologies of digital identity.
He is the founder of Danube Tech, a consulting and development company that worked on decentralized identity infrastructure products. Marcus, welcome to the show.
[00:02:49] Speaker D: Thanks.
[00:02:50] Speaker E: It's really nice to be here on your great podcast.
[00:02:53] Speaker B: Lance Byrd is a secure organizational identity developer at Glyfe and co founder of Roots ID. He's been working on secure global scale data systems for over 20 years. He's helping to build a verifiable legal entity identifier ecosystem to facilitate trusted interactions between legal entities around the globe. He is the co chair of the Trust over IP Didwebs Task Force, which is an effort to secure didweb and bridge the did based ecosystem with the VLEI ecosystem. He participates in many open source and specification efforts with trust over IP, Cary, decentralized identity foundation, Hyperledger and W three C, and has given public talks on SSI, carry, the v lei ecosystem, identity wallets, Didcom and more. Lance, welcome to the show.
[00:03:51] Speaker D: Erika, thank you so much.
It's a pleasure to be here. Longtime listener to the podcast, and yeah, dream come true to be able to talk with you now about didwebs.
[00:04:04] Speaker A: We are thrilled to have you.
Let's get started. Didwebs is an interoperable, more secure version of did web, applying the principles of carry to layer on additional security while retaining usability.
So let's hear from our guest. In your words, what is didwebs?
[00:04:26] Speaker E: So I would say it's definitely inspired and based in some ways on date web, which you mentioned. But I remember when the Didweb method came out, there was a lot of discussion whether that was a real did method, whether it was really decentralized and persistent and cryptographically verifiable, all these properties that deeds were supposed to have. And some people thought that it's possible to improve on deed web by adding some of these original properties and aspects of deeds into dead web. So to make dead web more secure, cryptographically verifiable, independent of central authorities, of third parties. And that's what did web S is achieving.
[00:05:17] Speaker D: Said another way, DidWeb S is a compromise between did web, which is highly discoverable and did carry, which is highly secure. And it's hopefully capturing the best of both of those worlds in a way that's more approachable for people who are familiar with the web and with dids, and then also provides a bit of a bridge, if you will, for people in the cary ecosystem as well to the did ecosystem.
[00:05:56] Speaker C: Great.
Could you walk us through the current lifecycle of a did Web s identifier? How do we create, read, update, and deactivate the Didweb s did?
[00:06:07] Speaker E: So to create a did web, as you really need, two things you need, first of all, what you also need for Didweb, which is a domain name, a place on the web, a place where you can serve resources on the web, you need that. The second thing you need comes from the carry world, right? The second thing you need is an aid, an autonomous identifier that can be created using cryptography without dependency on a third party, using all the mechanisms of carry. So creating keys that only you control, creating a so called inception event, working with witnesses and watchers. There is a very secure, very advanced infrastructure behind Carrie that makes it possible to create these types of identifiers that are called aids and to take these two things together, the place on the web and an aid.
Then you get a dead web s.
[00:07:13] Speaker C: Identifier and to update the Didweb s. How do you do that?
[00:07:19] Speaker E: So to update it, you again use the mechanisms of query.
In query, there's a concept of a key event log which updates what is called the key state. So that enables you to rotate keys to update other aspects of your identifier. That all happens on the layer of carry and what carry enables. And this is reflected in the did document when the did is resolved and the document is actually constructed directly from the carry key state. So by updating your carry keyevent log, by adding new events to your keystate, you're effectively also updating the did document that's associated with the diddeene.
[00:08:08] Speaker A: And how about deactivate?
[00:08:11] Speaker E: To deactivate the did, you rotate your key state to a situation where you have a null key, basically that controls the identifier? So once you do that, once you update to a null key that cannot be controlled anymore, then you effectively deactivate the identifier.
[00:08:35] Speaker D: Yeah, I'll add to that.
We also have a concept in didwebs of the designated aliases for an aid. So because didwebs is controlled cryptographically by the carry aid, it's this cryptographic string that is the identifier, but that's tied to this key state that Marcus is talking about, it's cryptographically bound to essentially those key events.
There's a way to specify within, from your kel where it is that you are designating for valid did webess and other did identifiers that are cryptographically controlled by this aid, you can specify that. And why is that helpful? Because the ability to say I had a did that was hosted at a particular domain. But maybe that domain, you've lost some form of control or you no longer want to host it there.
You can essentially designate that domain is no longer a didweb s identifier that you have designated. So in a way, that's a way to transition away from a previously hosted web s to possibly new one. So if you had a company or something like that, and you wanted to essentially show that you are aware of a didweb s that was controlled by your cryptographic identifier. Before, at this company that was bought and now has merged with another company, there's a new domain, and you can transition to that. So that's not deactivation, but that's another way of kind of evolving over time from previous didwebs identifiers to new ones.
[00:10:52] Speaker B: Okay, you've mentioned Carrie a little bit already, and Carrie famously is a bit overwhelming to newcomers with a 141 page introductory white paper. So for someone new to dids, what do they need to know about Carrie to understand Didweb S?
[00:11:11] Speaker E: I think you can answer that maybe better.
[00:11:13] Speaker D: Sure.
Yeah. So carry uses cryptographic identifiers and verifiable data structures, which you can kind of think of as micro ledgers that are hash linked. So cryptographically linked events. And so this means that the infrastructure that's serving up information about this identifier, you're not dependent on that infrastructure for providing the verifiability of the information. The information is. And verifiable meaning no matter where you discover it, you can verify whether it's cryptographically correct.
And so that is an important property for Carry that introduces all kinds of important security characteristics and is the reason that Didweb s is considered secure. The s, you know, should remind people of HTTPs, right? The idea of securing on the web.
And so this aspect of being and verifiable and being persistent. So these aids that we're talking about, carry, provides the mechanisms for transitioning the key state of an identifier over time. That is huge, right? Because this isn't just a session based token or something that is cryptographic, but only lasts for the purpose of encryption and confidentiality on a secure channel or something like that. These identifiers are meant to be able to persist over many generations of humans, even because they were literally built. Kerry was literally built for the use case of secure organizational identity. So the idea that a Coca Cola or a chase bank or some other institution could have identifiers that are cryptographically verifiable, that can last through key compromises and post quantum, a post quantum future and all of these things, that is literally what Kerry was built to solve is that problem. And so introducing that into a web based did method is quite novel, quite innovative, and really a game changer.
We believe in the did ecosystem.
[00:14:16] Speaker B: So in that framing, is it not designed for people?
[00:14:21] Speaker D: That's a good question. I think that it is quite capable of being part of the human world, and for people particularly, and in fact, carry identifiers can even be ephemeral, like did key is used for these ephemeral, temporary, secure channels and things like that. Kerry supports all of those things as well and has mechanisms to be quite efficient for short lived identifiers. But the point is that it is also rich enough to really express a rich form of identity. So even in personal identity, I had mentioned secure organizational identity, but maybe if we start there really quickly, we can kind of show the analogy. Insecure organizational identity.
A company, for instance, a legal entity, can have a CEO and multiple board members and representatives that have to be involved for an identifier. They can all contribute, if you will, cryptographic signatures. They can use their cryptographic keys as part of that identifier. So we would consider that like a multisig identifier. Well, a person needs the same thing. For instance, if you could think of a person who's aging and has children and is doing power of attorney and things like that, how do you essentially express that this identifier is not just controlled by one set of keys, or even if it's just a single person with multiple devices?
How do you express that a single device doesn't control this personal identifier. In fact, it's been secured with, with a multisig across devices, so that a person who has multiple devices is protected against the loss of one device, et cetera. So these problems that are often, I'll say, ignored in some of the did methods that I've come in contact with over time, multisig being a big one, that is, these considerations are first class citizens within Didweb s because in carry, it was literally built for these very complex use cases. And identity is complex, and life is complex. It is also legal. Maybe we'll touch on some of the kind of legal tie ins to these things. So I think it's appropriate. In all of those use cases, you.
[00:17:07] Speaker A: Had described Didweb s as a marriage between the web and its technologies and carry, and it's a cryptographic security.
If my, my reading of the specification suggests that the only interactions beyond my website and my keys and sort of my files that I'm managing would be for witnesses or watchers, is that correct? If I have my cryptographic key material and I have a wallet, I'm on my server, do I have to interact with anyone else, as I work with did webass modular witnesses? Like, we can talk about witnesses and watchers in a few minutes, but can I just update my website and everything's good.
[00:17:54] Speaker E: So that's right, you don't have to interact with anything else. You interact with the web server initially when you resolve the did, but that's really only a discovery mechanism. And other than that, there's no built in dependency or anything like that on any predefined or static service like blockchains or ipfs or distributed hash tables. This did method is quite different from a lot of other did methods insofar as this underlying infrastructure is so very flexible and doesn't assume any single specific point or directory or network where you have to go and look things up.
[00:18:43] Speaker C: The spec states unlike did web, this method's trust is not rooted in DNS, webmasters x 509 and certificate authorities. We've talked about did web in the past on the show and how the current status and availability of history of a did is entirely at the discretion of the owner of a given domain. So what have you introduced into Didweb s that changes this property of did Webd?
[00:19:06] Speaker E: So this is one of the main advantages of did web s, I would say, compared to did web that it really has a fully transparent and auditable and discoverable history. This is something that comes directly from the underlying query technology, which has this concept of a key event log where every update to your key state and therefore every update to your identifier is recorded and verifiable and can be looked up and queried by anyone. So these features of going back in time, looking up an earlier version of the did document is a feature that we have in the did core specification, but it aligns really nicely with the architecture of Kerry, where you simply have this access at all times to the history of an identify. And therefore it was actually pretty straightforward for us to define how deep web s can support this versioning and this feature of looking up earlier states of the identifier.
[00:20:21] Speaker D: The concept of the root of trust of web based technologies is that they have an administrative root of trust, right? Certificate authorities have their admins and we've seen essentially that play out in terms of providing secure mechanisms via the web and there's things left to be desired. So the concept of carry having this cryptographic root of trust rather than the administrative root of trust essentially builds a foundation for security that's just unmatched compared to what's on the web.
That's a large driving force for this did method.
[00:21:12] Speaker A: So we've mentioned the carry event stream a couple of times.
Could you talk a little bit about what goes in it, how it's used to verify the current state in particular I'd like to highlight for our listeners, there are two files that go on the website. A Caesar file and a did document.
I believe as JSON did. JSON, that Caesar file includes the cal, which is a key event log. Could you just unpack what are these artifacts and how are they managed to do the securing of the document?
[00:21:49] Speaker D: Okay, yeah. So what we call the carry event stream within the spec, it is a Caesar encoded file. When you look at it, it will look a lot like JSON, usually with these cryptographic lines in between each event.
And so you're kind of visualizing at that point this JSON block. That's an event that might say something. It'll always start with an inception event. That event is essentially establishing for your identifier the current pair of keys that you're going to use.
This is probably a good time just to mention the idea of pre rotation that Kerry provides.
So in this inception event, it's not just listing your current public key, it is listing your current public key. And it is listing a hash that is a commitment to your future public key. And this is something that's very novel. Within Carrie, it essentially was Doctor Sam Smith who created the Carrie spec. This is one of the first problems that needed to be solved. How do you essentially recover from a key compromise?
What is the mechanisms to use for this? And so an inception event has this pre rotation mechanism. And all future rotation events also have this pre rotation mechanism.
Why is it called pre rotation? Because you have that current public key and you have a commitment. I keep saying a commitment because it's just a hash of the future public key, meaning that that future public key isn't exposed yet.
And by the way, making that commitment as a hash also makes that commitment post quantum secure. So pre rotation in an inception event, which is the first event of an identifier, it's literally how the cryptographic identifier was created from that information plus some other information.
If you're well, to just tie the bow on pre rotation, this post quantum mechanism and this ability to essentially transfer from a current public key that could eventually be compromised to a future public key has to be expressed to you in a file in what we call the carry event stream. And that's essentially the Caesar encoded file. And so you'll see something like the t field, for instance, in this JSON, we'll say ICP, because ICP stands for inception. So that's how you know it's an inception event. And then the other fields are essentially linking to future or I'm sorry. Providing your key information, that's the pre rotation stuff that I talked about. And then providing other things like your witness information, which we will talk about later.
Essentially, that inception event has a configuration. Then we'll call it all those fields being the configuration.
All future events, whether they're key related events, like a rotation event where you've moved from your current public key to the committed to future public key. Or if it's a, what we call a non establishment event, meaning it's, you know, you're anchoring something, some information, like a verifiable credential or something like that to your Kel. All of these things, when you look at it, look like JSON, but then have all of these cryptographic signature looking things in between the events. And that's essentially you viewing this hash link chained micro ledger, if you will.
This is essentially how we express and transmit the KEL information. The key event log for an identifier.
Replaying that information is essentially you walking the verifiable data structure of the identifier so that you can determine if that cryptographic identifier is truly the one that's bound to this information.
And so that's hopefully gives a sense of why you kind of have these JSON data structures plus this cryptographic material. But the Caesar encoding, just to, you know, give a quick touch on that.
Doctor Sam Smith and also Phil Fairheller from Glyfe have done quite a bit of work on the Caesar spec, which is essentially this incredibly performant encoding for information that goes from text to binary. So the text being kind of that JSON stuff, although it supports JSON, Seabor and message pack, this is an extremely efficient way of providing information that is text based, but also has cryptographic material in it. And so that's why Caesar is important. There's a whole spec for that that people are welcome to read. I won't really get into it beyond that and probably shouldn't anyways, to be honest. But yeah, this file that we're talking about for Didweb s is essentially the mechanism by which we provide the verifiability for what you eventually see in your did document. Great.
[00:28:02] Speaker A: So we maintain as the control of the did document, both the current did document and this historical log of all of the changes which is in the Caesar file, which has the, I'm guessing you append your next events as you keep changing things. And that Caesar file is just going to get longer and longer and it keeps referencing itself in a cryptographic way. Right? So you're signing it as you go in the way that a blockchain does. But it's just your file that you're appending, is that right?
[00:28:31] Speaker D: Yes, that's correct.
[00:28:34] Speaker C: Can you explain how witnesses and watches are used in Didweb s?
[00:28:38] Speaker D: Yeah, great question.
So we kind of covered pre rotation in kind of the previous section. Another really important thing is duplicity detection because if anyone's, you know, a lot of people are familiar with kind of blockchain theory, if you will. The question is, how do you detect when someone has forked a cryptographic chain of events? Meaning we want to be able to recover from a key compromise. So the current. I talked about your current key and your future key that you've committed to. If your current key is compromised, how do you find out that it's been compromised? Well, part of the cryptographic chain of events in Kerry is you defining what your witnesses are. You can think of witnesses as a notary in real life. When I sign a document, that's very important. It's very important that people know that I was the one who signed it. We tend to have another party, a third party, if you will, who is your notary, who also provides a signature and probably a stamp on a piece of paper, for instance. Essentially, that's what witnesses do.
An aid controller, a carry identifier controller. They define who their witnesses are. That's their notaries who exist in a network addressable way. Uh, that. That people, when they, um, uh, you know, receive information, uh, they can essentially go to those witnesses. Uh, and those witnesses have signed each event, uh, uh, cryptographically signed each event to essentially notarize that they have seen, um, this information from. From. From the controller of the aid. So how does that help us with duplicity detection? It is impossible for the key, the current public key or set of public keys for an identifier to be compromised without and then a change to the kell to occur without essentially posting that information to a witness. And so if a witness witnesses a event on my key, event log, if you will, that I didn't put there. This is a strong sign that my identifier, my current set of keys or key has been.
Yeah, has been owned, if you will, has been compromised. And so the witnesses are meant for me. This is why I define it in my.
In my establishment events. Those are all the events, either the inception or rotation events, all those events. I list my witnesses. And so that's my way of saying these are my representatives that will notarize my events. And as soon as I see an event that I didn't send and they get notarized by the witnesses, then I am aware that it's time for me to rotate. If I rotate now to the public key or keys that I committed to now, I can reestablish control over that identifier because the identifier doesn't change. As each establishment event, like inception and rotation events, the identifier doesn't change. And so I reestablish control once I see that. So that's the point of witnesses is for duplicity detection. And then watchers seem very similar. They are, but they are now on the verifier or validator, whichever word you like to use. They use by verifiers and validators to watch witnesses and watch the state of the key event logs for an identifier. And that's important because they shouldn't trust witnesses. The witnesses are defined by the controller of an identifier. It's important to have watchers as essentially the advocates, if you will, the infrastructure for a verifier or validator to watch the key state over time and to essentially provide a key event log that is consistent with what the witnesses have, have been displaying. So yeah, they have similar roles, although the watchers literally are watching the witnesses for that aid.
[00:33:39] Speaker A: So you said something that gave me pause.
You mentioned that the witness knows that it's not you. In this use case where you've lost control of the private key and you're going to use this pre rotation mechanism to regain control. How does a witness know it's not you? Or is it just that the witness is notifying you through a channel that you can sense, check your own sense of edits? Because I think that was the use case. He walks through like, oh, my key changed, I didn't do that. And then you can take an action. Am I understanding that right?
[00:34:16] Speaker D: Yeah, no, that's a perfect question, actually.
I hand waved this a little bit, but I.
You define witnesses in your key event log, but as a controller for an identifier, you also have watchers that you are using to monitor your witnesses. So really the witnesses are meant to act as the notary. There are other aspects of the infrastructure that are meant to help identify duplicity right across witnesses.
And so watchers are not the only thing. There's actually other roles within the infrastructure that kind of play a similar role. Those can be considered jurors or judges.
But the point is, you are absolutely correct that witnesses are more for the notarization, if you will, of the key event logs and then the watchers are the ones who are monitoring the witnesses. So yes, even me as a controller, I don't just have witnesses, I also have watchers watching my witnesses, if that helps. Did I? Hopefully I answered sure.
[00:35:31] Speaker A: It was pretty good.
[00:35:32] Speaker D: Yeah, yeah. I mean, I don't, I don't know.
The truth is for people who are used to blockchains, especially like global permissionless blockchains or. Yeah, even like organizational private blockchains and things like that, there's always this consensus mechanism in carry that the cost of doing, of determining the ordering for a particular person is far lower. The ordering events. This micro ledger, if you will, the cost of essentially processing that micro ledger and validating that microledger is much lower cost relative to like a global permissionless blockchain that essentially has to do a global total order consensus for every transaction, if you will, that occurs on the blockchain. And so that's one of the features of essentially decentralization to the maximum. Right, Kerry? Being far more decentralized in the sense that a person's identity really only needs to be maintained by them and the infrastructure that they need in order to serve it up, rather than an infrastructure that has to be able to do a total order consensus of all transactions by all people in all times.
Yeah. This is something that I think is much more web like in terms of its distribution and decentralization.
[00:37:20] Speaker E: Yeah.
When we talk about that part, I always find that this extreme decentralization or a very radical way of avoiding dependencies on specific parties is often what's hardest to understand about Carrie, because there is not one place where you can go to look up the identifier. Right?
This is how it's different, how Carrie is different from many did methods because most of most bid methods have one well defined place, whether it's a server or a blockchain or something else. But, you know, you can go there and look up the identifier. And with Kerry you don't really have that because you can choose your own witnesses and your own way of publishing and managing the key event log. And this part that's sometimes hard to understand.
What do you do with the identifier? How do you look it up? This is what we're trying to make easier with Didweb s, right? Because with Dead Web s now there is one place where you can go and look up the event log. Just like with Dead Web, you just go to the web server, but you still have all the features and advantages and security architecture of.
Because the security aspects have nothing to do with the domain name or the web server, and have everything to do with the aid and the key events.
[00:39:00] Speaker B: Can the carry event stream be used to verify historical versions, for example, with a vc issued at a particular point in time?
[00:39:09] Speaker E: I think we talked about that already a little bit with did Web s. Since it's based on carry, it's always possible to look at previous versions of a did document. So if a verifiable credential was issued at an earlier point in time, let's say a few months ago, then you could point to a specific version of the Didweb s identifiers. You could use the right public keys, basically from the, from the key state to try and verify the credential.
However, my understanding is that related to what Lanz described about having a consensus algorithm and total ordering with carrier don't necessarily have a global, globally consistent view of time and timestamps. So it may be hard to point to a specific version of the identifier at a specific timestamp, but it's easy to reference specific versions, versions of the identifier. And therefore you can also then verify credentials, for example, that were issued at a point in time where you had a specific version of the identifier when it was issued.
[00:40:40] Speaker A: I see, so you can look up and verify particular versions. It's the linking of those versions to a point in time that might be contestable, but I think your watchers or witnesses might be able to provide trustable timestamps in that case. Is that right?
[00:41:00] Speaker D: Yeah, at least close enough that, you know, most important things can be complete. Yeah, there's, there's no doubt that carry and the infrastructure provided, the infrastructure defined, are not meant to be a world clock, right? That's an extremely hard problem to solve, but yeah, absolutely. It provides all the history necessary to be able to say that this identifier received this credential at this key state.
And so you're right that the infrastructure can help with that.
There are date times within many types of events, and often a verifiable credential will have a time with it. But solving the exact time problem is not something that Kerry's approaching.
[00:42:02] Speaker E: I think in many situations where you might think you want to point at the state with a specific timestamp, I think you could, in most of the cases also solve that by just pointing to a specific version, like a sequence number of the history. And in many cases where you think you need to identify a specific time, it's actually sufficient to just be able to point to a specific version number as opposed to a version timestamp.
In the did core standard, there are two different dit parameters which are meant for this. There's the version id parameter, and then there's the version time parameter, and in many cases version id is good enough. And this is perfectly supported and aligned with carrier.
[00:43:02] Speaker C: Perspect claims that Didweb S is easy to implement. Does that assertion include the implementation of the associated carry component?
[00:43:11] Speaker E: Well, I think the answer to this question, as so often, has to do with tooling and the kinds of libraries and SDKs and so on that are available. It's true that when you're new to it is not that easy to understand in its entirety. If you read through all the papers and documents, it can be a little bit intimidating, of course. But I think the tools of the tutorials and the documentation are just getting better all the time. And DEET webass is also again a step towards making it easier to use.
[00:43:56] Speaker D: Yeah, you know, I've had many discussions about Kerry with technologists and security engineers, and what we often see is, for those who are jumping into it from a first principles point of view, understand why it has such a rich ecosystem of features, if you will.
But I do think that it's really important to note that you can approach Didweb s as someone who is familiar with did and with a small set of carry commands, if you will, operations, events, really you can begin to use Didweb as. So I think that if you were just approaching carry by itself, coming from a did based history, that might be a little more complicated. But by seeing your actions as a did document, I think that that helps, and especially for it to be essentially did web based. I think that a lot of people within the did web, or I'm sorry, within the did community are familiar with did web and kind of how it works. And so I think this is a great way for them to be able to approach Kerry without having to know everything about it.
[00:45:45] Speaker B: Here ends part one of our episode on Didwebs and concludes our show today. The conversation continues in part two.
[00:45:55] Speaker A: Marcus, thank you for joining us on the show. Lance 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:46:07] Speaker B: 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 speaker's employer, organization, committee, or other group or individual.
