Great. Welcome everyone to the Identity Implementers Working Group call for May 5th, 2022. Thank you for joining us today. My name is Shar Haaland and I'm a co-moderator of this group with Heather Dahl. Today we will plan to cover working group status updates and in the second half of the call, we will hear presentation on the new did Indie method from Daniel Bloom and Stephen Curran. With time for questions at the end. And I'll work through the status updates slightly more quickly than usual to make sure we have plenty of time for the presentation. We also probably do have fewer updates than usual because of IAW, but I'll ask in a few minutes, if anyone on the call attended IAW and would like to share about their experience as well. As usual, this is a hyperledger call so we are following the antitrust policy and the hyperledger code of conduct. We are collaborators in this space and anything confidential or proprietary is not discussed in this call. And of course, as usual, let me know if you do have an interesting project able to be publicly shared that you'd like to talk about and you're very encouraged to reach out and give a presentation we'll just schedule schedule you in for a future call. This call is being recorded and it will be posted on the meeting page later today. And with that we can move on to introductions. What anyone like to introduce yourself yourself if you are new or rejoining or just would like to say hi and a few words about what you're involved in in this space. I'll also send out the wiki link again, if you're willing to put your name under attendees that would be great. Moving on to announcements in three weeks in DCO is hosting a meetup call that is very relevant to our presentation presentation today it is on the did Indie method. This meetup will be longer than today's talk so there will be an opportunity to go deeper and learn more so if you are interested in what you learned today from Daniel and Stephen you should definitely sign up for this meetup. The link is there to register. And then we've been announcing IW for the past several weeks it is now in the past it happened last week and sounds like it was a great success. Did anybody who's on this call attend and would like to share a bit about their experience. I had a lot of FOMO. Yes, missing out. Sadness. I can give like a quick overview of some of my experiences that I have you if that would be helpful. Thank you. So I had the privilege of attending IW it was great to be back in person. Virtual IW was it was great to have. And it was great to continue the momentum of the community even while we were unable to meet in person. But there's just something about meeting in person. It's just really difficult to replicate in a virtual setting. I think it must be just the bandwidth that which we're able to communicate and just the opportunity for the side conversations or the impromptu discussions just is greater than we had the opportunity for it and virtual IW. That being said, some of the big things that stood out to me participating in IW this year. There were some common themes that just kept on coming up. One of those being machine readable governance frameworks, which is something that in DCOs had a lot of opportunity to participate in. So it was interesting to show up and have that be organically a topic that a lot of different organizations were talking about. So as the community is maturing, we're all kind of reaching a point that at more or less the same time where we're realizing that decentralized identity gives us a cryptographic foundation of trust, but doesn't communicate real world trust doesn't help us to identify that this the ID is this organization that is a valid issuer of driver's licenses, passports or whatever. In the community we're all kind of hitting the same point of we need to be able to define what an ecosystem what the participants in an ecosystem are and and what they're trusted for and what roles they're expected to play. So that was a really common topic throughout IW. And then we also of course had the common threads of interoperability, how we reconcile quote unquote competing standards in the verifiable credential space. Highlight from a lot of those interrupt conversations is an acknowledgement from the community that we're not yet at a point where we feel it's appropriate to really rally behind one single implementation. We're at we're at a stage in interrupt where there's still we're learning what different solutions are appropriate for different use cases. There was an analogy to the browser interrupt days. I wasn't around for that. So I can't really communicate the analogy well enough to communicate the same meaning so I'll just leave it there for now I guess. But lots of conversations about that and how we can do better at interoperating with one of kind of the cool things that came out of that is a plan to do a bit of dog fooding. And for next IW just have everybody come with their credential systems in tow and be able to use verifiable credentials at the door to present our ticket to IW and kind of use that as interopathon so to speak on decentralized identity and verifiable credentials. That's probably enough waffle for me so I'll leave it there is really good really glad to be able to participate and get back together in person. Great thanks thanks for sharing about your experiences and calling out those common themes sounds like it was a great success. Anybody else on the call attend would like to share about it. All right. Are there any other announcements that anybody would like to give. All right, we can move on to working group status updates with that. The main identity working group. We reported on their last meeting in our last meeting two weeks ago so I'll leave those links up until we report on their next meeting, unless anybody's involved in that meeting would like to say a few words. Indy contributors. Steven since you're on the call do you want to give a brief update on what we talked about in the Indy contributors call last week. You got to remember okay. Marco did his presentation. I was hoping to hear see exact examples and I was disappointed that we didn't have exact exact examples of what it would be like to put other objects and did docs and that's, I'm still looking for that. We also got more queries out into the community to see what that looks like if you're referencing a, an object, a piece of data via a did what does that look like and has anyone actually done that so we're looking for that. We also talked about this proposal for DNS for a did Indy namespace and well we thought it's a reasonable idea it's still is just an alternative to the one we have and we think it's not that strong an alternative or not that beneficial over the approach we're already taking so we. I don't think there's any a lot of further action going to happen with that so that's where we are with. That's what we talked about on the Indy contributors call. Great thank you for that update. I did Indy method just to reiterate that this call has been merged back into the Indy contributors call which has moved back to its regular time. Now that the work is done and I've left off the demo, the links to the demos from previous calls but I don't think we need to say too much more about this here because we will hear plenty about it in the second half. Let's see the areas working group meeting it did anyone attend these latest calls would like to give an update areas working group. We met yesterday continues to you know lots of lots of interesting things going on. Unqualified did we're looking at a. Timo has done an RFC or a proposal for an RFC on on adapt adoption of dealing with unqualified did for how we will do that in the community community coordinated update. And we do have some information provided on the, the problem of how you deal with present proof when you have when you're willing to accept a bunch of different present verifiable credentials presentations from different verifiable credentials that's the one in any problem. More progress on all of those things. There was a whole bunch of topics and I can't cover all of them that we talked about on the areas working group call but it was very good. Sam, as Daniel did an excellent recap of IW.  I don't have further details on to what other than what you have written there. But I think there was a few more topics on the one yesterday. Okay. Yeah, thank you and there are links here to those meeting notes for more information so thank you. All right areas by fold user group. They didn't meet last week because of IW so we reported on their latest progress last time. So let's move on to Acapai. Stephen, I'm calling you out a lot. Would you like to jump in again. Sure. This one we have good conversations on release 074 with people volunteering and being assigned a few more things to verify and then we'll get the release out. So that's the final of the documentation now. I expect it will be out by the end of the week so that's the final of release 074 we've had RC0 and RC1 release now this will be the final. Ian Costanza from BCGov gave a presentation on the Aries Endorser service and that is analogous to the Aries mediator service that we put out recently which is. Basically a repo that wraps a, you know, provides a configuration of Aries CloudAge and Python, in this case to do endorsing of transactions for indie ledgers. So this makes it much easier to deploy an indie ledger where, or sorry, and Aries CloudAge. An Aries client basically an agent that's perhaps an issuer or is an issuer and needs to have their transactions endorsed by a third party whether it be an internal third party within the organization or an external third party. And so this will spin up an endorser service that accepts connections. We will extend that capability over time to include things like a user interface so the endorser service might get a request from somebody they'd never heard of so that'll go to a human to look at and decide whether they want to allow that the endorser service to endorse the transactions for that new connection. So that's where we're going with that so we had a presentation and there's a repo and a HackMD document sort of describes the direction and we're looking for input and contributions to that one. And that will eventually go into Hyperledger. Currently it's a BCGov repo. Yeah, and I've linked the repo there if you want to drop the HackMD document in the chat you're welcome to and I can add it in here. You have a shot at that, yeah. Great, thank you. All right, let's see areas framework go they've been they've been meeting mainly going over work updates but not too many notes from them. Let's see areas framework JavaScripts. And is anybody involved in this group would like to report. Looks like in the last couple of meetings they've been mainly talking about supporting did come be to an AFJ. I've linked a HackMD and Google Doc with more information on that. Then Hyperledger Ursa down here. Don't believe they've met. Since we last met, are there other Hyperledger working groups or status updates that I'm missing that anybody would like to call out. One thing I wanted to call out that I realized in I did the Aries quarterly report and one of the things I wanted to report on was a comparison between the performance of Indie SDK as underlying and in this API agent, and Ascar, the, what is seen as the successor and found there's pretty amazing difference between the two so a contributor in the community in, in, in Germany, Paul Wenzel and team, I think, working with IBM I think he works. I'm not sure where he's, he is I think he's with Lissy worked with IBM to create a load test generator so a whole environment where you can just create define a load to run and run, you know, 100,000 issuances in an environment and it collects statistics on it and displays it and I've got a couple of links that I provided in the Aries quarterly report to the to the Hyperledger technical steering committee and I just hadn't realized the scope of the difference so basically what you see is that double the performance in using the latest Ascar the 025 which we just added to Acapai, but more importantly, performance is consistent across the entire test whereas with the Indie SDK performance it rates over time. So basically the interactions get slower and slower on versus Ascar which is absolutely constant across the entire test and, and as I say runs at twice the speed so pretty impressive and very start to see that to report inside. It's very impressive. So that's that is an basically a way of saying the 025 version of Ascar is out Aries Ascar which is the storage component of Aries agent that is the alternative to using the SDK at the Indie SDK and it's looking really good and now we're certainly going to push more and more to putting our implementations on top of that certainly all our new implementations will go on top of that. Thanks for going that out that's that does sound very impressive and again if you want to send out any of those links you mentioned, you're very welcome to if people want to learn more so thank you for that update. All right. At the trust over IP foundation they had their all members meeting the day before our last meeting Kyle reported on that meeting in our last session and was one of the presenters. Let's see steering committee. As far as I can tell they haven't met since our last meeting is anybody involved in the steering committee that would like to share about it, or have additional information. Sure with trust over IP. Oh, you have it listed. I see gain below that, but that was a topic of the steering committee, kind of as a result of, I guess discussions at IIW which I couldn't attend. But yeah, along with so gain and oh IDC where we're both there and both interested in, I guess in discussing further with trust over IP. I don't want to say ways of working together but yeah, interaction points let's say something like that and, and I think part of it was when Wenjing was presenting the trust over IP architecture stack that we've been working on that he's been spearheading. So, anyhow, so the steering committee was, I guess one of the action items is to follow up with both gain and open ID connect and figure out how and how the architectures overlap and things like that. Thank you for that update. Let's see and in the communications committee, it looks like they're mainly talking about an SSI adoption blog. Dana you're also involved in that would you like to say a few words. Yeah, I'm definitely involved in the communications committee. The SSI adoption. It's not ringing a bell. Where's the line I'm here though, sorry. Just, yeah, just has a link. Yeah, I, there's there's so many things going on with SSI adoption. So, I know one of the things we're working on is, you're comparing it with MDL and things like that. I don't. Sorry, I'm having a senior moment here. I don't remember exactly there was a series of blogs. We were going to do a neitis comparison, an MDL comparison. So I'm not, I'm not sure if this line item SSI adoption blog is an overarching for those for those more particular ones, but I know that that those are in the works the itis and MDL. Great, great. Thank you for that update. Yeah, it sounds like there's a lot going on. And we already heard about a bit about gain, which it sounds like the technology stack working group is working on as well. Let's see utility foundry group. Lynn, would you like to talk about what they're working on. Yeah, so we didn't have a meeting for the, the usual reason I guess IW this last time and so there's nothing really new to say but I'll remind everybody that we're working on a document that everyone's so welcome to look at or review the document is nearing completion I think and we're it's essentially a most of the guts of the document are a rubric for determining whether a layer one public utility or a an indie network essentially or whatever other kind of network you want to use is suitable for your purposes. So we're trying to help to to set the stage for helping people to determine which network they should join or whether you know in the end if they don't want to join anyone to build their own so and that building your own is not covered in the document but it will be in the next phase so that's where we're at. Great. Thank you for that update. The ecosystem foundry group. Let's see in the last video they had a presentation on check D from Tobias Holler and for these last few to IP groups, does anybody have any updates or anything they want to call out in general. I'm looking at the time to I might breeze a little bit more quickly through these last several working groups. The diff did come working group. Anybody attend this group would like to report. It's like they, as many of our groups have been reporting on IAW going through PRs. Okay, how about the unsync did come users group meeting. And then. So these I don't think have met since we last met sovereign foundation W3 C standard. I think yeah, a lot of a lot of groups have skipped a meeting because of IW but does anybody have any updates and missing on these last few groups in general, or any any other status updates you'd like to jump in with. I don't have a ton of detail on this personally but one of the sessions that was held at IAW was actually on a V2 of the W3 C verifiable credentials data model, which is seeking to overcome some of the shortcomings that were discovered in the V1 particularly as it comes to just being too open to permissive. So it was difficult to actually produce things that are interoperable. So it was discussed, I believe, print Zundell and others are working on putting together a charter to actually continue working on a V2 for the verifiable credentials data model. Cool. Yeah, thanks for that update. All right, any last other working group updates or related matters. Anybody who jumped in with updates, it is very much appreciated. I think we are ready to move on to the presentation portion of the call. We will hear from Daniel Bloom, who is a lead software engineer and team lead at DCO. He's a veteran of the community who started at the sovereign foundation in 2018 and joined DCO from its founding in 2008. He's a regular contributor on the Aries and Indie projects and spearheaded the implementation of the Indie did method that we're going to hear about in a moment. And Daniel also at one point led the identity implementers working group call so it's great to have you back. And we'll also hear from Steven Curran of Cloud Compass Computing. Also a veteran of open source software and facilitating working groups in this space. Who dove full on into what has become the trust of IP foundation in 2017. He works with the government of British Columbia and has helped define build and launch a variety of proof of concept and production applications built on verifiable credentials. He's also a regular contributor in the Indie and Aries communities, facilitating collaborations and driving interoperability. Also is the co author of EDX courses on hyper ledger Indie Aries and Ursa, and is the current share of the sovereign foundation. So with that, I will pass it over to you two. All right, do you want me to start Daniel. I'm going to share some slides that you'd like to share. I can share a couple of slides but I'm going to be really short because you've got the good stuff so all I'm going to do is put a bit of foundation on it to say, you know what BC guy was looking for when we put this out what overall the did any method is so just to provide that background. So did any method. One of the advantages I want to be able to receive credentials from issuers using different indie networks and be able to construct a single and on creds verifiable credential that uses all of those credentials so that's a pretty straightforward thing issuers are going to be on different networks. I want to be able to use any of their credentials that they give me in a presentation that I give to a verifier. Anyone that we added into the did any discussion was being able to do publish a did doc, such that I can have other information in it than the core information on Indie such as a BLS key so that I can issue a W3C standard verifiable Jason LD credential using SS plus signatures don't you love how long these user stories can get in when you talk cryptography and verifiable credentials. Yeah, just adding here or anything else that goes in a standard did doc so part of the issue was so the core problems were indie identifiers don't reference what indie network you're actually talking to you're actually dealing with so you get an indie identifier and identifier for a did or identifier for a schema, and, and by looking at the identifier you can't tell what ledger it's on. And so you get an awkward user interface like you see at the side here, where you have to as a user pick which network you think the issuer is using so that everything will work. And you see develop the parcel partial solution which has been adopted by a number of stacks which is, they just check all of them they just say oh we're going to deal with all of these networks. And when you send us an identifier we'll just check all of them now of course that's slow and subject to collision where you wind up with the same identifier on two networks, and you have to figure out what to do with that collision. But that's the core user experience probably want to get rid of, and then as well in the does not have a native concept of did docs in the predates the did spec and therefore, you know, has conventions for generating a did, and a did or a did doc that is standard to the or meets the standard but but predates it. So here are the five goals and and what we're going to talk about namespace did useful across all instances so when you look at it did. There's a component in there that says oh this is on the DCO network. And, and you know to go there rather than trying a bunch of them and discovering that it's on and in the DCO network so in the network discovery and embedded in the did itself as the namespace. So full did doc support, we want to be able to provide a allow a client to publish a did doc that meets the, the specifications of the did spec, and can put as much or as little into that as they want. So we're coming back to the namespace piece. And non credit uses a bunch of other objects beyond did's not just did but schemas and credential deaths and revocation registries we want those also to be namespaced. And then, there's several really important resolution parameters that are important for SSI things like version time version ID and resource basically being able to look at history and say, yes we know that did exists but what did it look like on June 12 2021. You're able to with those requirements go back and see what they did look like at that time not just the current version of it. And finally we wanted to create a way to enforce or or or demonstrate that it did is self certifying self certifying basically means there is a direct tie a, a, a calculable tie between the did and the public key for which it derived. I, I create a key pair, a private key and a public key pair. I derive the did from the public key, and then I publish that and anyone can checking that can verify that the, the, the initial did itself derives from that first public key that was used for it and this is an important property to proving that you control the did. Or that, or that you're not just creating a did for confusion purposes or things like that that you actually created it from the beginning, even, even after you rotate it this this property can be verified. This was an important capability that was was somewhat in the original in the implementation and definitely a core element of the carry protocol that's being used so those were the goals. And with that Daniel now you got to, you did all the real stuff. And I should mention one more thing sorry BC gov put out a coat what's called a code with us which is we said, hey we need these things community can you do this and we put, and the government put a sum of money for it and that's how this work came about so huge who knows to BC gov for creating a program that allows for open source challenges to be put forward and basically the way it works is the government defines a goal that it wants people or organizations apply and and in order to be paid, they need to do a merge that that we agree meets the intent the goal of that of that. And so it's a very low, low overhead program, fantastic and has really worked well in this space for BC gov to get to get done. In this case, in DCO and Dominic burner, one it, and Daniel will talk about what came from winning that. And Lynn's got a question. And add on maybe you mentioned this but there's a place where the sorry the Genesis files are being stored for networks and so the screen you showed were currently that you have to, you know, each app would have to contain, you know, whatever networks they trusted or listed or whatever that is is not going to have to happen in the future. If you get a new name, you can go look in a common place and grab the Genesis file and make it work because there's the gold there. Yeah, yeah, that's the discovery so not only do you have the namespace the ledger in the identifier itself, but there's a mechanism defined that the community agrees to, to say, Oh, I can go look up this name find the Genesis file and use it dynamically. So that's another feature that's been implemented. That was in the work in DVD our work that Dominic did. And with that, go. Cool. Yeah, thank you, Stephen for kind of leading into it that was a really good introduction to all of what we've been working on recently I'd say and then thank you for the addendum there as well. I'm going to talk about the India did method getting a little deeper than Steven did. And yeah, I think I'll just go ahead and hop right into it. So a lot of this background, Steven's already covered so I won't spend too much time on it, but Andy was around before. So we had names and attributes versus this and did documents and there's been this dissonance between what indies doing and what the W3C did course specification has been working on. And then we of course have the this the assumption that there would be only ever a single indie network just didn't occur. And so being able to work with multiple indie networks and you know issue from one network verify from another, and use a variety of networks to accomplish our goals and decentralized identity is something that is both really valuable for interoperability but just also allows us to use networks for what they're specialized to do, I guess, what framework or jurisdiction that they reside in, and kind of use that to help bring verifiable credentials and interoperable decentralized identity to a larger audience. So these are almost exactly the points that Steven brought up as well I'm going to dig into each from one at a time here and talk about some of what we have done with the Andy did method and in implementation, man, get those words out to accomplish it. So first up, natively supporting dids and did documents mantis as defined by the W3C did course specification. So we now explicitly have within the did Indie method rules for transforming the core NEM information into a base the ID document. So inside of a NEM transaction. This is very much shortened just for brevity. There are multiple attributes inside of a NEM transaction but the key ones for this purpose being the test or the method specific identifier value that you would include inside of a fully qualified DID. And then the very key, which is the public key currently associated with that NEM or that destination identifier here. So did Indie method defines that these values, this destiny becomes a DID document that looks like this so we've got the ID of did Indie and the namespace of the network that we're resolving the did from, and then that destination value. And then a verification method. A single verification method just included by default. So associated with that destination with the fragment of a very key as the ID. This is an ED 25519 verification key with the public key base 58 value corresponding to that original very key value here. And then the controller as defined by the did and then also an authentication block which references that verification of it. So this is the base DID document that can be constructed from all NEM transactions on any on an Indie network. We also have defined rules for merging in a new attribute associated with NEM transactions that did content that is merged with that base DID document. And as before we've still got that test and very key attributes inside of the NEM transaction but we've also added this did content attribute, which contains a serialized JSON value, which might look something like this. Particularly did content is saying add on these JSON of the contexts, or, you know, just the did core context and then a did come messaging service endpoint context, and also include a service endpoint for did communication, which has a recipient key pointing to the very key that is contained in the core did document and no routing keys in the same point and so on. So the rules as defined by the Indie did method outline that the base did document and that did content get merged into this value here this is a little small this is an image of an example taken directly from the Indie did method specification. But if we inspect it here briefly we should see all of those pieces that we saw in both the base and the did content merge together into a single value. So the ID, of course the did Indie namespace and then that method specific identifier, the verification method, which has that fragment of Burr key and the base 58 encoded value for that key that authentication hasn't gone anywhere and now we have also this service block, which includes that recipient key service endpoint and all those values that were defined inside of the did content. And then of course also the did context that was included in the content. So this has a number of other really useful characteristics. And it means that we can fully resolve the did document from an Indie network with just a single transaction, as opposed to doing a nim followed by an atrib which is the previous mechanism for resolving endpoint information associated with a did on an Indie network. So we've more or less deprecated this usage of atribs, but we are continuing to support the ability to look up the atrib transaction on Indie networks this is a fully backwards compatible change has taken place. In the content attribute we can write any arbitrary did doc value into an Indie network. Did so like Steven was mentioning, we can now include BLS keys. So we can include bbs plus signatures from Indie based the IDs also allows us to use other key types as well not necessarily BLS things that were previously not really added into an Indie network. Okay, so next on the list of things was supporting those key resolution parameters. We've got version ID version time and resource. And as Steven mentioned these allow us to look up a value of a DID at some point in the past so what did document values were associated with the DID on June 12 2021. At a specific ID so the did Indie method specifies version ideas relating to a sequence number, which is in a unique incrementing integer that is a reference to a transaction on an Indie network. So version ID in the W3C did core specification gets mapped to a sequence number, which is included in a get them transaction so under the covers when we do the reference, or resolve. This did Indie sovereign ABC 123 with version ID 789. The resolver is transforming this into a get them request with a sequence number of 789. In a similar manner, we have a version time. This. Oh, I've actually got a typo here, the version time is actually an ISO formatted date time. And then the resolver takes that value, and then transforms it into a POSIX time stamp which is what is natively supported by Indie networks and then does a similar get them transaction to the network to retrieve the DID document at that point in time. And then that resource parameter is mapped to a get transaction request on the networks. So next on the list we've got to find did URLs to dereference non-crit objects in a ledger agnostic way. This is of course only defined for the Indie did method but it leaves the door open for other did methods to resolve these sorts of objects in a similar manner, just by defining the semantics of dereferencing one of these did URLs. So this did URL looks something like this in a very abstract form we have the did, followed by a slash, followed by the object family, the object family version, the objects type and then an object type identifier. If you're familiar with the did come spaces might look familiar, I guess. We followed a similar set of motivations to arrive at a namespace and then versioned object that allows us to, you know, at some point down the line, define a different version or whatever for resolving a non-crit object. So as an example of what these did URLs look like. Obviously, when resolving a schema from an Indie network. This is what the identifier would look like. This corresponds to the author of the schema to represents that this is a schema. The NPDV is the schema name and four out three out four is the schema version. And we've also got a similar mapping that takes place for credential definitions or claim definitions. We have did colon Indie colon sovereign colon the did followed by slash followed by a non creds V zero schema, where scheme is the object type NPDV, which is again the schema name and four dot three dot four as the schema version. And we've also got a similar mapping that takes place for credential definitions or claim definitions and read revocation registry definitions as well. Just again, same pattern of did author. This represents a claim def. This represents the signature type CL is the only signature type currently supported by non creds so this is actually omitted in this specific version to non creds. The sequence number corresponds to the sequence number of the schema on the network, and then a tag for the credential definition. This is a good time to call out that in this V zero non creds did URL reference format that we've established. We are looking forward to a time where we can reference schemas for a credential definition that resides on a ledger separate from the one where the credential definition is defined. So suppose we have a schema on sovereign main net for a driver's license schema. We could use that schema on an in DCO network to define a credential definition for my issuer which is anchored to an in DCO network. We're not yet to that point. That kind of has some tie in with the non cred standardization efforts which are occurring in parallel. Again, by versioning these did URLs we leave the door open for down the line saying in a V one, rather than doing a sequence number referencing a transaction on the same ledger. We can have another identifier which points to another network for that schema. Let's see. So, at IW actually as a brief tie in the semantics of did URLs were were discussed briefly with Marcus Salvador who's been kind of the pioneer in the did resolution and URL the referencing space. And it was really interesting having conversations with him about the did Indie method and the example of using pads and did URLs as a mechanism to reference objects on a ledger associated with the DID that isn't a DID document. To my knowledge I think we're the only did method that is currently doing this. But using Marcus's words here just to brag a little bit he said this was a very appropriate usage for the path of a did URL even though it's not widely used yet and he expects that this could be a very clean mechanism for referencing these sorts of objects on other did methods as well. So one day down the line a you know did BTCR could reference a non creds objects written to that ledger using a similar path mechanism. And then it's just up to the de-referencer to use whatever mechanism specific to BTCR to resolve in a non cred schema or credential definition. So then the final bit to talk about here defining unambiguous network identifiers Steven covered this and Flynn did some covering of this as well. We want to be able to say which networks were aware of and have the opportunity to dynamically discover new networks. So a particular client of any networks can use a static definition where the client is just configured to quote unquote know about a set of any networks. You might consider this as being part of a machine readable governance framework, as an example, or it could just be built into an app directly where it just says I know about in DCO I know about sovereign I know about ID Union. And this would just be lumped in as a static definition of the networks that and namespaces that we're aware of. Then we can also do dynamic discovery of new networks. So the best example we've got of this right now is the indie did networks we get a repo, which is just a really lightweight way of essentially having a registry of these network namespaces and associated with these transactions so we can interact with those networks. Yeah, I don't think I have too much more to say on that. So we don't necessarily see indie networks being as frequent as hundreds or thousands. So having a lightweight mechanisms such as this get a repo to discover new networks for the hundred or so that we anticipate is a, at the least favorable solution for this dynamic discovery. So to briefly talk about what what's been going on on the did method work. So, as Steven mentioned, we did the BCF code with us in DCO and Dominic Werner were awarded the code with us. And we add in DCO worked on the indie note side of things to the network side to add support for the needed method and Dominic worked on the indie VDR or the resolver side to support any did method and providing that kind of generic resolver interface. I don't have enough time to really get into exactly what those changes look like so I've just got a brief overview here. There were additions to the nim transactions as I previously described we added that did content. We added a version, which ties into the self certification feature that Steven described as well. So we had the ability to do that sequence number and timestamp resolution for get them as well as get a trip for that legacy support on the indie VDR side. Those additional optional parameters for the content version sequence number and such were added to the requests and builders for those requests. So we added some changes to the databases. So taking a did indie did and turning that into a document that all took place inside of the indie VDR as well as updating the proxy service that's in the indie VDR repo, which provides a web service that can be used to resolve these ideas and then updates to the Python record. And then a high level overview of the Indian method the current work that's been going on. So what comes next. First, we'll need a release of any node and any VDR that includes all these changes that we've made. And then after we have a release ledgers will need to be updated to run this new software. And after that we need agents as well to be updated to support these unambiguous identifiers within a non creds objects. So we anticipate that work will take place inside of it the indie credits libraries and other shared libraries to add that support to agents at a lower layer so everybody can benefit from it. So the engagement implementations can also work directly with whatever libraries they choose to add support for that. At this time, we currently don't have scheduled any changes for the indie SDK. If you're interested in getting involved on that front we can certainly help guide that effort, but we and currently really only have scheduled the shared library work for these updates. Let's see, I've included some links here I'll make sure a link to this presentation is available. I've also got more content after what I planned to present today if you'd like to dig in a little bit more on your own time. And yeah I think that about covers what we're able to cover for today. Thank you for that presentation Daniel and Steven that was a great overview. What, what would you say the implications of this project for scalability? I'm really interested to get your input and feedback and participation in that meetup. But aside from that I'm, I think I'll leave it there and see if anybody has any questions for the last few minutes. Thank you for that presentation Daniel and Steven that was a great overview. What, what would you say the implications of this project for scalability and interoperability of Indian networks. Incredibly important. It's scalability, and I think as well governance I think that's the important thing is issuers different different categories of issuers will want different. Guarantees if you will from from their layer one utility, as it's called in trust over IP for where they put their information. And this allows them a whole lot more control to be able to do that and that's, that's really important. From a scale perspective, it allows us to easily use, you know, spin up networks or use networks and not force the, the, the holder or the verifier to have to pre pre load everything. So that gives a scale it gives us more capacity on the networks. And then as I say this governance factor as well, all important. Second, but Steven said there, the interesting thing to me. As well with the dead and you work is that kind of paradoxically by improving the Indian networks, we've almost in a sense made it easier not to use Indian networks and still maintain the same privacy preserving nature of an on credits. In the future, it'll be a bit before we're really at that reality. But at the same time, by making an on credits more interoperable by making it more accessible we're also strengthening the case for any networks themselves as a really good solution for your jurisdiction, jurisdiction, your private network that meets your governance use cases and needs. So that's part of what gets me really excited about the Indian method. It's definitely a significant update. So thank you. Yeah, I'm going to second that what Daniel said and highlight that that pathing that was mentioned about how you reference other objects. I think Daniel put it well in the presentation and people should highlight that that that's really important now. Now we have a way to reference these objects that are that are in the specific right now but could be put on other networks and and that work was was pretty crucial and as you mentioned. Marcus is blessing of it if you will. Great. Are there any other questions for Daniel and Steven before we wrap it up. All right, I will make sure that the link to these slides get goes into the meeting page. Looks like we are at the top of the hour so thank you so much everyone for joining thanks to everybody who jumped in to give updates from working groups and thanks again to Daniel and Steven for their presentation. Thank you.