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.
This is part one of a two part interview. Part two of the conversation can be found at Rubrik cc.
[00:00:41] Speaker D: Yeah, that's clearly an important public good.
[00:00:48] Speaker E: On the Rubrik.
[00:00:49] Speaker A: 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:06] 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:24] 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:52] Speaker B: Different DID methods use different underlying mechanisms with different performance, security and privacy trade offs.
[00:01:58] 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:09] 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:01] Speaker E: Thanks Will. It was very nice.
[00:03:03] 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:20] Speaker D: Nice to be here. Thanks for the introduction.
[00:03:22] Speaker A: Great. Let's get started.
So, in your own words, what is DID WebVH?
[00:03:29] Speaker E: So DID WebVH is an attempt to provide a DID method that is published on the web, so can be published by an individual entity that has some of the characteristics that say ledger based dids might have. So verifiability and the big thing there is verifiability and survivability. So you can discover the DID by looking up just on on a web server somewhere. But although that's how you find it, the verifiability is built into the cryptography that captures that is encaptured in the encapsulated in the DID log. And that log is from the moment it's created through wherever you are in the history of that did. And you can go back and verify the full history throughout with cryptographic verification.
[00:04:25] Speaker C: Thanks. And will you walk us through the CRUD operations for the DID WebVH method, please?
[00:04:30] Speaker E: Sure. To create a DID, you start, you can DID WebVH can have anything you want in the DID document as long as it has the identifier that says what the DID is. So you start with whatever the DID document is, whatever contents you want in that, whatever keys you want to publish in that DID doc, and then the location where that DID is to be discovered. So the web component of it that then goes through a process to create an entry in the log and that entry will have for the first one during a create will generate a self certified identifier. So the input that you provide as the DID controller will be used to create a unique identifier based on the hash of all of that material in a very specified way as well. So that that creates a component of the DID, the DID identifier, and makes that DID unique across the world. The second part of the entry is it's got a version ID which contains a hash across the entire entry, including in the case of the first entry, the skid. Now you've got a piece of data that you could check, a hash that you could check to make sure nobody has altered it in any way.
Then finally, well, there's a couple more things. There's parameters as part of the entry, and those parameters Tell a resolver how to resolve that did, what version of the spec to use, what cryptography to use, and things like that, and some optional settings you can do.
And finally, that whole thing is signed with a data integrity proof so that there is verification that the DID produced that entry. I would add that the key that they use is stored in the parameters and is independent of the keys that are put into the DID doc. So you've got a separate key or set of keys used for authorization of the did. And then you've got whatever keys you want in the DID doc. Those can be the same if you really want that, but generally you would keep those separate. You'd have keys that you want to use to sign things in the use of the did.
And then there's the key for authorization.
That's the first log entry that gets published to a location on a web server, as indicated in the name of the did, the identifier of the DID to move on to the update. You would then provide an update entry which includes again a copy of the updated diddoc, any parameters you want to change. And then from that the same entry hash is generated into the version ID and data integrity proof is used to sign that, to say this is an authorized change and that gets published. So now you've got two versions of the did. So if they just resolve the did, the DID doc they get back will be the second one. But they can also look back in the history and look at the first version, the first entry, which is the initial DID that was created. So they have that full history contained in that one file that's more or less resolving. It consists of converting the DID string which contains the HTTP location. So converting that into a URL, doing a get to retrieve a file which is the log, and then verifying all of that cryptography that I mentioned to make sure that the log has not been altered in any way that is authorized appropriately according to the spec and things like that, and returns back a diddoc. That's in a nutshell, the pieces.
[00:08:31] Speaker C: Great, thanks. That's great.
[00:08:33] Speaker D: I wonder if I can jump in and add a little bit to the first question on the what is DID webvh? Because Stephen gave a great sort of technical definition, but there's also kind of a business level conversation about DID web VH and what it represents.
Because I work for the Government of British Columbia, so I'm a public servant and I guess you could say I'm the executive sponsor this activity. And so I need to ensure that, you know, the Public good is being served since we're spending public money on its development.
So we were contemplating our verifiable, credential, decentralized identity capabilities in, let's say, 2023 and foreseeing that a ledger based approach that we were using was working.
But it didn't seem like that was going to be a way for us to maximize the inclusion of, for example, private sector organizations, because the ledger technology that we're using is highly governed and we didn't see a way where we could easily allow private sector organizations to participate in that ledger.
So we started talking about is there a way to leverage web technology that could be more low cost, easier to adopt, and yet offer the features that Steven discussed in terms of verifiability and so forth. And so we came up with an idea of extending the DID web method, which is the default easy to do method, but didn't have the security features we felt necessary.
And we came up with this innovation which we'll talk about more further. But there is this vision behind did WebVH that is to expand the ability for public and private sector to work together and create a safer web for as many people as possible and organizations.
[00:10:59] Speaker B: What's new about DID webvh?
[00:11:02] Speaker E: I think there's multiple, as John mentioned, multiple. There's DID Web as a web based DID method. There's several others that are being contemplated.
What's new is with did WebVH is this combination of publication on the DID and being able to easily find it, but removing the trust of a DID from the DNS to the actual verification that's being done through the cryptography. We want the controller of the DID to be able to express, hey, we control this DID and even if you find it somewhere else, you can verify it back through all of the sequence of things we've done in evolving the DID and can trust that it's been done in a way that can be verified throughout the history.
[00:11:55] Speaker D: So that's one feature that, like I mentioned, builds on top of DID Web. And this sort of. There's a backwards capability if you're trying to resolve a DID Web vh, but you don't need to bother, you feel like you don't need to do the verification step. You can resolve the DID simply like you do a DID web method. But we also and the DID Web VH integrity within itself, you know, gives you confidence that the controller is the entity that's updating the DID and so forth. But we also added in a capability that we call model after the soon to be defunct WHOIS capability.
For those of you that are early Internet users, you could issue a WHOIS command to discover the entity behind a domain name. Well, similarly, we've added a capability where if you resolve the DID and add a slash WHOIS to the end of the GET statement, you'll get back a verifiable presentation of credentials that that controller has had issue to it. So the idea is like when you go into a restaurant or a business and you see the business licenses and permits that authorize that business to operate in that jurisdiction and you know that it's safe to eat their food. In the same way, if you receive a credential that's issued by an entity, you can, as a verifier, you can, with one simple GET statement, retrieve this list of credentials that are associated to that DID and verify yourself what that DID represents. And it can actually be sort of a cascading set or recursive set of verifications because you, you might receive a credential that says, yes, this is a legal entity registered by the Government of British Columbia registry. But who's that? And then you do a get on the DID of the registry and you get back, oh, it's a DID that's been listed in the Government of British Columbia set of DIDs Trust Registry, let's call it. And so that sort of at the end of the chain, but it seems to be a very interesting capability and in fact we imagine that it could potentially become its own specification because this capability is not limited to just DID web vh, it could be expanded to any DID method. What else have we done? Stephen, that's fantastic.
[00:14:44] Speaker E: I think the WHOIS is just a huge feature. And again John came up with this at some point and we included it in DID Web eh, And we want to see its use grow, but we really think it should be for all dids. We'd really like to see it become a standard part. Now having said that, it is done with standard DID core compliant approach.
It is using a diff standard called the Linked VP specific. It is using a service that is defined in a standard way in the DID core spec. So we're not doing anything outside of how dids work. But if we can make that convention of/ WHOIs available everywhere and have organizations publish the presentation that that provides credentials about who they are, we could really build up an understanding of what's going on when we get a, you know, for example, as verifier, when we get a verifiable credential from a Holder, we can see who issued that and what authority they have in issuing that credential to a person, for example. So that's the goal of whois. So it's quite a really innovative piece of component of DID Web vh.
[00:16:07] Speaker C: Can you talk to us a bit more about how do you find these linked VPs from the WHOIS capability?
Like, how do you discover them?
[00:16:16] Speaker E: Yeah. So in DID WebVH, we formalize in the specification that there are two implicit services added to every DID WebVH.
One of them is the WHOIS. And it is a service that formalizes that. Here is where if you resolve whois, you, you go to this service, it tells you to grab this file that is in a particular location relative to the HTTP location of the did, and there will be a VP sitting there and you can retrieve it and use it. Because it's a standard service, the DID controller can actually override it by explicitly putting it into the DID doc that they produce. In that case, the the spec says respect what the DID controller did, but if they don't put one in, it's in the default location. So that's one of the two service endpoints that are implicitly added to every did WebVH. The second one, just for completeness, is a path to files.
So if you have a DID with a slash path to Document PDF in the DID in the DID URL that will be found at the corresponding place of the HTTP. So it's to make, since it is a web based did, you want URLs processed more or less as you would expect. And so that's the second one. But those are done through putting into the spec that these specific services will exist. And if you don't add them, we'll add them for you. But if you do add them, you can control what they, what those services do. So that's the mechanism for doing whois.
[00:18:07] Speaker C: I have a small follow up which is are these implicit services included in the DID document when you resolve them?
[00:18:14] Speaker E: So the resolver inserts them into the DID doc. So if, if you for example, go to the universal resolver and you find the example of a DID Web vh, you'll see that those services are always in there.
So if the DIDD doc doesn't provide them. So for example, we have a tutorial on our info site that you can go through and create dids yourself in a 15 minute process and you can resolve those, they get published on GitHub pages and you can resolve them with Universal Resolver. And even though our first example is the absolute minimum of a DIDD doc when you resolve it with universal resolver. You see these two services get added to them automatic, so the resolver is required to insert them in if they don't exist.
[00:19:05] Speaker D: I think since we're talking about resolving, it might be a good opportunity for us to mention that we've also because in British Columbia we're using the hyperledger, a non creds credential format and ARES protocols, we've also created companion specifications that allow organizations to use non creds in conjunction with WebVH.
So we have the specifications and software that allow you to publish all a non creds objects as files On a dibbed WebVH server and resolve them as the way Stephen mentioned.
So credential definitions, schema, revocation, registries.
And so we can continue to use what we feel is, you know, the best privacy preserving, verifiable credential format out there and make it available to folks by simply adding them as signed files, which we think is another powerful feature of this DID web method and a shameless promotion of privacy preserving credentials.
[00:20:21] Speaker A: In addition to the cryptographic providence that lets you verify that the controller has made these series of updates to a DID document, DID WebVH introduces two new ideas that weren't in DID Web, which is watchers and witnesses. Can you tell us how those two things work?
[00:20:41] Speaker E: So the idea witnesses in particular was a way to enable governance and providing a pretty simple mechanism for doing it without being dictatorial about how that governance would work. And so basically the way it works is a DID controller can insert a list of DID keys as a set of witnesses, and when they do so, each update has to be signed by a threshold of those DID keys in a, you know, and it's all outlined in the spec of how you do that. So the mechanism is pretty simple. Now how you decide to use those witnesses in an ecosystem is left as an exercise for the implementer. So for example, in the work we're doing in British Columbia right now, we're transitioning off of or from hyperledger Indie, where there's this concept of an endorser and you have to have an endorser verify that you're allowed to write something, and if you're not an endorser, you have to contact that endorser and get them to do it. Well, we've been using that as a way to allow multiple organizations within the government of British Columbia to have their own dids. But for a central group, the cybersecurity Digital Trust group to be able to verify that they're doing the right things, that the schemas they they are using are appropriate and lets us control those. So we're using DID witnesses in DID Web VH to provide that trust to show that this isn't. Somebody hasn't gone and just created this did and published it in PC's registry, that it actually was approved ahead of time. And that's the governance around it. So we will, just as we've published exactly the governance of how the instance of Hyperledger Indie is used by the B.C. government, we'll publish that same governance document documentation that says here is how it DID gets published to the government of BC DID webdh server. So there's a server component that's out there and we published it. We'll be publishing dids to that.
And this outlines the governance around it. I'll continue on quickly with the Watcher. The Watcher, anyone can watch a did. A watcher is just a thing that grabs a copy of a DID at a certain time and monitors it for. For change. We decided, and for a while we kept that position that, well, we don't need to formalize what a watcher is. We can just let anyone, anyone create one and they're allowed to. There's nothing we can do to stop them. But then we realized it actually would be helpful for the longevity of a DID to have a place that formally collects and watches them. And in particular it allows the DID controller to publish out to the clients, those using the did. Hey, here's other places you can pick this up and allows the controller to ping the watcher and say, hey, we just updated our did. You should go grab the update. And those two allow a watcher to be more efficient and more visible.
But as well, if the DID goes away, if the, you know, the creator of the DID decides I'm not interested anymore, I'm not going to publish this or gets the organization gets dissolved and the website goes away.
The watchers allow a way to resolve them for many years into the future and for a number of use cases, that's very important. So the watcher doesn't have to retain all of the controller and all that. It just keeps a copy of the DID log and any other information, the resources that might be associated with that. And then for as long as that watcher exists, people can resolve the DID itself or the resources associated with that did.
And so that's an important one. I know there's a DID method called DID Web plus that is used by the pharmaceutical industry. And that was one of their key requirements was they have to have a place that they could resolve it did for 30, 40, 50 years in the future. And a watcher enables that in an effort, official type way. Again, we define the mechanism in the spec, but how you want to govern that, how you want to use it, that's totally up to the ecosystem that this DID controller is participating in.
[00:25:21] Speaker B: Is there governance of the DID Web VHSP spec itself beyond diff?
[00:25:26] Speaker E: Well, we'd like there to be. This is one of the bigger challenges with DID methods is and we really appreciate diffusion, Decentralized Identity foundation hosting the incubation of the DID method and allowing us to be very transparent and public in evolving the did, in evolving the implementations, ongoing meetings we hold and things like that. But DIFF is not a standards organization. And so what we're trying to do next is figure out how do we get a standards organization willing to allow us to standardize a DID method. I mean, we've created the SPEC in a way that we think is very friendly toward it becoming a standardized standard.
And so we're working hard to navigate the ins and outs of getting it onto a standards track and through a standards process so that we can declare yay. Verily, did WebVH is a standard, not just a specification.
[00:26:30] Speaker D: Yes. We've had input from a number of other organizations and governments, including Government of Quebec, Swiss government.
So this method isn't just us here in British Columbia, but a number of others around the world that have contributed to the evolution of this and keeping it grounded and is a practical, real world method. You know, we ourselves have, I don't know, eight years experience in the decentralized identity space.
And so we've tried to bring forward the lessons that we've learned both in terms of the kinds of security integrity that we need, as well as being more developer friendly. I think that's overlooked sometimes.
And because this is a situation where it involves security integrity, it needs to also help developers do the right thing with as little decision making as possible.
I think Stephen and the team did things like choosing certain cryptographic suites and so forth that help developers do the right thing. Because there's like one choice.
[00:27:55] Speaker E: Yeah.
[00:27:56] Speaker D: As in no choice, which.
[00:27:58] Speaker E: And yet it can evolve, just to be clear.
[00:28:00] Speaker D: Right, right. There's a path for evolution, but.
[00:28:04] Speaker E: Exactly. Agility.
[00:28:06] Speaker D: Too much choice can lead to, well, fragmentation. That's unhelpful.
[00:28:11] Speaker A: One of the places I have heard DID webvh mentioned is in this effort as a collaboration between the decentralized identity foundation, DIF and the World Wide Web consortium, the W3C, which I think is called the DID Method Working Group, to sort of shepherd some DID methods into sort of into the standards process so we can move downstream. Can you guys speak to that? Can you explain to our audience a little bit sort of what's the idea with that effort?
[00:28:42] Speaker E: Yeah, so the idea is sort of a two step. One is to enable a platform for DID methods to to present attributes of their DID method using the DID rubric, using a thing that DIFF has called DIFF traits, and to propose why and how your DID method, if you will, can become standardized. And then those go through a review process. One step is that they become recognized as DIFF recommended if they go through that process and are, are and if found to be a valid approach and then as well that serves as input into things like the W3C for then putting those DID methods onto a standards track. The trick is in a decentralized world is, you know, how do you please everybody? Everybody has different approaches that they want to do and it makes that navigation tricky and that's what we're trying to get through. We'd love to get through that and figure out how to get to a place where we're actually in a standards working group, not just as we are right now, a work item working group.
[00:29:58] Speaker D: Great.
[00:29:59] Speaker C: You've both mentioned the Government of British Columbia a couple of times. Could you talk a bit more about how the Government of British Columbia plans to use did WebVH?
[00:30:08] Speaker D: Well, I think Stephen mentioned, and we've mentioned a few times that our origins in this space technologically are Hyperledger Indie. Well, that was the origin and over time we've participated in a great open source community to evolve that into Hyperledger, ARES and now Open Wallet, Akapi and Credo and Bifold, which we have in production for our government Wallet and our issuing verifying service that we operate as a enterprise service and we have a ledger which we call sort of Light heartedly Candy, the Canadian Indie Network which we cooperate with a couple of other provinces.
However, the indie community has evolved over time and there isn't the kind of support that we feel is necessary for the long term health and well being of that technology, let's say. And so that was part of what motivated us to look at the web based approach like I mentioned earlier. And so our plan is over the Next, let's say 12 months, 12 plus months is to deploy the WebVH server technology that we mentioned and to begin Issuing credentials against a DID webvh DID for our person credential, which is our identity credential, digital business card which links a real human to a legal entity lawyer credential.
And we have another number of other credentials coming online as well as other organizations like the city of Vancouver which has begun to issue short term rental business licenses and business licenses.
And our land titles organization is going to be publishing property ownership credentials. So we want to use the technology that we think has the longest sustainable capability and that's our plan to work that into our infrastructure. And Steven and others have led great work to get it, you know, resolvers built into Akapi, which is our enterprise capability and credo, which is the engine for mobile and typescript.
[00:32:46] Speaker C: We'd like to change gears now to talk about the people involved in developing and implementing DID WebVH. We'll start with the two of you. How did you get involved in DID WebVH?
[00:32:56] Speaker D: Sure, I think we've already sort of touched on that a little bit. But it was this desire to create a capability to replace hyperledger indie and create it in such a way that it lowered the barrier to entry for developers and digital product owners out there so that they could begin to participate in the decentralized trusted ecosystem landscape or whatever we call this desire to make a better Internet for people. And it was really because of the center of expertise that we've developed in British Columbia with Stephen Curran and Andrew Whitehead and Brian Richter. I think these are the core folks that we got together and said, my experience is that with these kinds of minds is you put them in a room, I guess virtually now and say, here's our problem, go.
And it was a very great experience to watch them take all of that experience that they have and come up with this really, you know, really simple and innovative method. I don't know, Stephen, what your experience was.
[00:34:16] Speaker E: Yeah, I think that covers a lot of it. Andrew and Brian both did an implementation in parallel as we talked about it and really came up with the ways of, of technically I, I would throw it. Well, we want to include witnesses. How do we include witnesses? But we don't want to make it too heavyweight that we, you know, or, or they would say, well that's being too heavyweight if we do it that way. Like what are the, the evolution, for example, that witnesses are simply DID keys was because once you go down the rabbit trail of, of the rabbit hole, I mean, of, of a witness DID being any type of did, well now you've got to, in order to resolve A DID Web VH did you have to go resolve some other DID type that the witness may have. You know, that gets really complicated. So we said, oh, they have to be DID keys and will let the governance determine who the witness actually is and let that be outside the spec.
And so those types of innovations came through from actually implementing and saying, whoa, that's not going to work if we try it that way, because it just makes it impossible for the developer to build a resolver, for example.
So really good specification implementation fix. The specification implementation fix loop really came out very well, I think. And so we got to a point and then through the last couple of versions have had interesting but relatively small changes being added to the spec, which is good. It feels like we've got the big pieces in place in the right way.
[00:35:53] Speaker D: And it's not like these ideas came out of the blue. There's other methods that implement really innovative, thoughtful approaches.
Our take on things was to try and find a way to put together a set of features and capabilities that were as simple as possible for developers and organizations to adopt, yet benefit from the intention of those features and capabilities. So that that feedback loop that Steven mentioned with the developers and organizations like some of the folks from Quebec and Switzerland, you know, we could iterate on that quickly.
And that was a matter of months really, that a lot of these core things got included and then it was refinement from there.
[00:36:49] Speaker B: What's important about decentralized identity work to you personally?
[00:36:54] Speaker D: Sure, I guess I can go first. I mean, creating a safer and more inclusive digital space for people and businesses to go about things is obviously the core motivation behind things. And I can say from a personal point of view, it was almost five years ago, exactly like in June 29, that I was in an accident and my spinal cord was damaged and now I'm paralyzed from the neck down. And so that's made me even more aware that we need to create the capabilities for people to do things digitally that is safe and easy to do. And I think did WebVH helps broaden. It creates the opportunity to broaden the adoption of these kinds of technologies so that folks, whether you're able bodied or not, can get to end of job. You know, practically speaking, you know, the DID Web VH whois capability and that ability to sort of know where a credential comes from I believe is going to be very helpful to know if you can trust a credential because they don't get published out of nowhere. They get published by, you know, issued by something and Is that something trustworthy? Can we create the capability where an organization, for example that helps people with disabilities like I have one that helps me with payroll for my care team and frankly I share a bank account with them so that they can, they can pay my team. But wouldn't it be nicer if there was a credential that they could hold issued by a trusted organization that the bank could recognize them as a legitimate helper to me and so having this web of trust and creating that under pinning carriage. I don't know what to describe it, that infrastructure that credentials ride on.
I think it's really very important my.
[00:39:12] Speaker E: Background in it, apart from the challenge, the use cases that come up, particularly in the organization I've been working with at the government of British Columbia.
My biggest thing is privacy and trying to break surveillance economy and all of the tracking that particularly OpenID connect, OIDC created where not only does Facebook know everything that you voluntarily put in, but it also tracks all the places you go because you use it and trying to come up with tools and techniques that allow for privacy. I don't know if it's possible. It's certainly what I'd love to see, but it's challenging. But that's what keeps me interested in decentralized identity is trying to make it possible that we can operate in the world in a way that is not tracked continuously.
[00:40:10] Speaker D: Yeah, that's clearly an important public good as well as increasingly the need for governments. I see anyways, in my opinion, to be able to establish their digital presence and their digital trust in a sovereign way so that we can manage the technology and the technology stack that establishes our presence on the Internet in a trustworthy way, in a sovereign way, without needing to become dependent on large technology platforms and the like.
That's, you know, we have these lofty goals and there's a lot of forces that are at play.
But we hope that by introducing these capabilities and keeping them safe but as simple to deploy as possible that we have a chance of helping.
[00:41:10] Speaker A: So you've already mentioned a few people who've been involved. Is there anyone else that has helped create did webvh that you'd like to get a shout out to shout out.
[00:41:20] Speaker E: To the folks at Diff?
Kim Hamilton Duffy is always a huge help in getting things going. Dimitri Zagabulin has been very helpful in building the spec out.
Michelle Sally in Switzerland was with the EID team in Switzerland. Martina on that team as well were big helpers in both critiquing the spec and promoting it and helping us collaborate in building it out. Sylvain Martel in Quebec as well built an implementation and showed up one day with it, an implementation done which was exceedingly helpful and getting the feedback on those was so those are a few more names that have come in and then lots of people come in regularly to our bi weekly meetings that anyone is encouraged to join.
[00:42:14] Speaker B: This is the end of Part one and concludes our show today. The conversation continues on our next episode and that will bring us to the end of our show today.
[00:42:25] 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:42:35] 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.
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.
