 And you're good to go. Perfect. Thank you, Sean. I will go ahead and share my screen here. Welcome everybody to the October 5th meeting of the identity special interest group at Hyperledger. Today we've got two things going on, which is first the working group status updates. And then we'll also be seeing a presentation from Carla McKenna from Glyph and Lance Burt. So thank you both for joining us today. To kick us off, just a reminder that we are at the Hyperledger antitrust policy. So basically be nice to each other and don't say anything that you don't want public here. A few announcements. This is a demo recently announced making the areas framework JavaScript a global framework. If you want to learn more, you can find out about that here. And the identity sake has a YouTube playlist. So you can check that out here. And then another announcement that's not here is IW starts next week. So hopefully few of you will be able to attend that as well. Welcome to some working group updates. Looks like the Hyperledger any contributors working group was able to meet on the 26th of September. Was anyone able to attend this session that might be able to give us a quick summary. I'm usually there but I wasn't able to attend that one so don't have too much more to say than what you have already been there. Sounds good. Well, yeah, it looks like they're looking at some network upgrades and the any ecosystem summit meeting. The Hyperledger areas working group met just yesterday, it looks like was anyone able to attend this session about be able to summarize for us. I was. We talked about the process of upgrading to to both did rotate and did pure for as a method of migrating off of the unqualified did that have persisted for a while in the earth's ecosystem. And, and then in also in preparation of migration to do comedy to spend the main topics for the last several weeks. Alright, awesome. Thank you. Moving on to areas bifold looks like they met on the 26th. Was anyone able to attend the users group for areas bifold. All right, looks like they had a couple updates and then we're looking at a machine readable governance presentation. This is cloud agent Python. That's anyone able to attend this one just a couple days ago. Yes, I was there we, we talked about the status of the 0103 release did peer, did peer for, we talked about open ID for VC, VCI to start with, with an occupy the use cases requirements approaches whether it should be a separate service to plug in to act by so interesting discussions there. All right, sounds good. Thank you, sure. Looks like areas cloud agent Python maintainers met 926. Was anyone able to attend this session. Right looks like they are focused on some PRs and plan PRs at the moment you can learn more at the links provided here. Areas framework JavaScript met the last week in September as well. Was anyone able to attend this meeting. All right, looks like they discussed moving to the open wall foundation and did conv2. See hyper ledger a non credits met earlier this week it looks like was anyone able to attend this meeting. All right looks like they're looking at some credits stuff. To IP is not met. Looks like the to IP governance stack met on. That looks like today. Was this earlier today or is this later today, I think it's later it's at two o'clock, two o'clock. All right, we'll move on. Thank you. Technology stack working group met on the third though, was anyone able to attend this session. All right. I think they had quite a few things to follow up on and if you want to learn more you can follow these links. Because there's some foundry has not met concepts and terminology looks like they went on the 25th per to IP. Was anyone able to attend this session. All right. It looks like they're discussing some terminology engine stuff. It looks like did come met on the 2nd of October. Was anyone able to attend this session. I was. We talked about a handful of topics, including I W stuff, but also, and really cool did come demo, by the way, but, but the, the main item for discussion in that group is the potential to advance. The spec to the itf, which was the original plan and was, and was, was stalled briefly into reviving that is, is that our discussion. That's a, that's a meeting that happens once a month. So it's a, it's a location is at this point. All right, fair enough. Thank you, Sam. Appreciate the summary. The did come users group. I believe they've met recently, but was unable to find some info on them. Yeah, we're, we're less, we're less good at agenda items for that meeting. It is, it is recorded. But the we've had under discussion updates to the did come book and also the demo that we had that I mentioned previously was was of excitement there, as well as topics for IW, including a discussion about what's next for did come verify or credential protocols. All right, very cool. Thank you, Sam. I was unable to find anything on the interoperability group either has this group met recently, or is this June 27 their last meeting. So anyone know, if not, we will move along. All right. The users group looks like they haven't met recently and we will call that the, the, sorry, my mind will blink there for a second. That brings us to the end of our updates. I need to, can I add something really quick. Absolutely, then go ahead. It's a important to mention that there have been some discussion maybe you already said it or it was in the notes but I missed it. That there have been some discussions of about joining the diff group with the trust over IP group. The next meeting for the TOIP to discuss this is, is October 18. They kind of put off their next meeting for discussions about that because of IW. And then a few meetings I missed this last several of them. So I don't have a lot more details on how that is going. But as rumors fly around and you've heard the any rumors about it, I don't know that any decisions have been made on that yet, but there are meetings discussing it. All right, good to know. Thank you, Lynn. I can't confirm Lynn, no decisions, but definitely discussions. All right, sounds good. So yeah, look out which meeting again is will have that discussion. Lynn will be at two IP or the diff on the 18th. 18th, the TOIP has invited all of their work group chairs to a meeting. So it's not an I don't believe it's an open meeting. All the TOIP chairs are invited to attend a meeting at TOIP hosted on the 18th of October. All right, sounds good. Well, yeah, I look forward to learning more than on that. Quick announcement as well, if that's okay, Tim. Yeah, go for it. Our next speaker in two weeks will be Darrell O'Connell of Continuum Loop. He'll talk about an update to the wallet report, the emerging trust layer, trust registries and interoperability. So just a note about that for our next meeting. But back to you, Tim. Sounds good. No, be sure to join us for that. That sounds like an exciting conversation. And I'll hand it off to Carla and Lance to take it away on their presentation for today. Hey, thank you, Tim. It's been some time since we last spoke to the group. So thank you again for the invitation. In order to be able to to talk about the progress that we've made with what we're calling the VLEI or verifiable LEI. Our focus, though, has been actually on the usage of the the VLEI in trying to make the link between the LEI, which is the identifier that we we look after as life. So would you be able to make that full screen, Lance? Yeah, there we go. So, first, I wanted to give a brief background on the LEI, of course, which is the reason that that life started to think about the use of the organizational identity that we have in the LEI and its reference data in the area of digital identity. And then we will progress through the presentation of how we've refined the ideas since I last presented to this group and of course definitely since 2020 when we first unveiled plans in order to be able to leverage the LEI in digital credentials. And then we're going to I'll turn it over to Lance. I've asked Lance to join the presentation today because we have some current interoperability work that we've progressed to, which would allow operability between the VLEI and hyper ledger. So, first, just maybe an introduction. Carla McKenna and the head of standards for life and I also manage our U.S. operations are I should say our America's operations located here in the U.S. Lance maybe a brief introduction before we get going on the presentation. Sure. I'm Lance Bird. I'm a software developer for life, specifically working on the VLEI section and implementation. I'm also co-chair of the DidWebS task force with interest over IP. So I will be talking about that. Okay, so the next slide. Thanks. So brief overview of the global LEI system and then a lot of information on the need for secure verifiable organizational identity. And then I'll turn it over to Lance for the interoperability work between the VLEI and hyper ledger, which actually is the DidWebS work that he just referenced. So next slide please. So next one. For anybody who's not familiar, Glyph is a not for profit that was put in place by the G20 and the FSB after the financial crisis, which of course seems like a lifetime ago. So after the 2008 financial crisis where especially the financial regulators were looking for an international level permanent persistent global identifier in order to be able to identify different types of entity legal forms legal entities. And specifically using and leveraging this identifier by being able to track certain activities and transactions by firms in areas that were of concern because of the financial crisis. And so we're under regulatory oversight if we go to the next, the next slide. We see primarily the adoption of the LEI still in mandatory regulation and legislation that involve certain types of financial transactions and financial activity. And there are about 2.5 million LEIs that mostly cover the capital markets that are that have been issued to date. Next slide. Just a little primer on the LEI. It's an ISO standard. That's how I got involved with this whole world on being part of the group that developed the LEI as an ISO standard way back when when the regulators put out that call. And the LEI is a code that is stood up by reference data. And the glyph is responsible for managing the repository that contains these LEI codes and the associated reference data. So that's the background that we come from and why we have an identifier that we thought was useful in order to be able to to start the journey on secure verify and verifiable digital identity for organizations. So the next slide please. No, that's okay. And just continue to go. So organizational identity. We're looking at being able to satisfy the need for a person or a thing to prove their authority to represent an organization in some sort of way, but outside of the boundaries of that organization. And this is based on verifiable authority that the legal entity would be able to communicate within a credential. So if we go to the next slide. And this is the relationship, the representation that is at the core of the the LEI specifically right now. We're looking at a role credential. There are several types of the LEIs, but this is the one that we think really resonates with the, the foundation for organizational identity. If you have an organization, they have people who represent them, either an official or functional or both kinds of roles, whether they are direct employees or whether they're consultants or partners, etc. There are certain kinds of roles, and that's the situation in the real world. What we did was we tried to convert this into a digital representation with the LEI representing the organization, the person being identified. And the, the role also being part of that credential, so that we can cryptographically bind the person in that particular role that's named in the credential to their organization that they're representing in that way. To do this, we start the chain of trust for the VLEI. We go to the next slide. So we've established the chain of trust I think all of you know by now that we decided to employ the newer type of credentials of authentic chain data containers, ACDCs for the VLEI, so that we could, we could put in place a chain of trust, not only logically following the chain of trust where Glyph sits at the top as the governing body for the VLEI ecosystem and infrastructure. And then we can connect and put a program in place in order to be able to qualify external organizations in order to be able to interact with legal entities organizations to be able to issue them VLEIs. To solidify their, the digital equivalent of organizational identity using the LEI, and then to be in place to issue these role credentials that we just looked at the detail of what they would be comprised of. And so we have two types, that's okay, of VLEI role credentials. So the first one is the one that the kind that can be validated to be able to prove that a person is in some sort of official capacity as an officer or some sort of other official role within that organization, whether it is part and parcel of the fact that that that role needed to be part of the organization in order to establish it as an NAD legal form, or whether it was a role that through statutes or board resolutions or other official actions of a company, established that role as an official role for that particular organization. So the important thing here is that we employ that network of qualified issuers of the LEIs to actually validate against independent sources that that person that the organization is asking to be issued this official organizational role credential actually is that person and has that role. So part of the validation of before issuing an official organizational role potential is for the QVI as we call them for short, to go out and to be able to independently verify that I am the registered agent of Glyph Americas. You can do that by means of going to a business registry or to be able to get certified notarized official documentation inside the firm for those kinds of NAD legal forms that don't necessarily need to be listed or not listed in business registries in order to be able to prove that strong foundation that this person is related to this entity in this role and it has been checked. So a good example of an official organizational role credential is a role credential for a CEO. So most of the time the CEO is the role and the person is named in the formation or the documentation that lives in the business registry, or in the case of Glyph, the Swiss foundation actually in our statutes is where the CEO role is created. So an example would be for a CEO to get one of these and be able to perform both official duties and powers and also to execute internal policies. And we've given some examples here so outside facing official roles to be able to sign the annual report and send it on to the auditors. An example to make regulatory filings like Sarbanes Oxley, for example, signing and approving strategic plans internally, or even signing service awards for outstanding employees. As we took this journey, if we go to the next slide, we actually figured out that there was a much broader demand for another type of role credential. A broader role credential that we've decided as a tongue twister to name engagement context role credential, because we create this credential to be able to represent the engagement that that particular person is having with that organization, whether they're an employee in a functional role, head of standards, VLEI software developer, for example, are examples of engagement context roles that Lance and I have with Glyph Americas. Contrasting the official organizational role that I hold on the business registry is registered agent and vice president of Glyph Americas. So that's the difference. These are usually use case specific and would be issued for a certain purpose. And we've given the example here of a company that has an authorized supplier program where a procurement manager is in place, goes through and authorizes certain suppliers in order to be able to deal with that firm, and gives them a credential that they ask that any invoices that's built to the company be signed with, and to try to be able, for example, to cut down on invoice fraud. So this is a use case of functional role credential being used. Let's go to the next slide. We mentioned trust over IP before and I see that you're tracking the, the activities of trust over IP. We not for a moment thought that we would be able to establish the VLEI ecosystem infrastructure without a governance framework, and the meta model that we chose was that of trust over IP. This is a rendering of the documents are actually 24 in total. There are six identifier and credential frameworks, a few three technical specifications, and there are actually eight documents that are in the qualified VLEI issuer establishment the program itself and and appendices that go with the agreement so that's how we get to the 24. It was established on life's website put the link on the bottom, and it pretty much describes how the credentials work how the system, the root of trust was established using our autonomic identifiers with life sitting at the top of the chain of the data that we showed before, and how the various stakeholders users, implementers, etc need to act and the requirements that they must meet in order to be able to continue to interact in the ecosystem and infrastructure for the VLEI. Turn over to the next slide I think I'm coming to the end of mine here. So, I'll briefly stop and ask for questions on my part of the presentation before turning it over to Lance for the more technical part of the discussion and the interoperability work. Yeah, just a comment, but I think the, the concept of the context role actually become pretty popular and hopefully widely used for what it's worth. Looks like Sam has asked a question or made a statement rather. Yes, I see it says for anybody who's not reading the chat I remain disappointed that VLEIs or ACDCs if I could. If I could paraphrase there. And then I see issuing credentials in all popular formats. Well, what we, what we have decided to do is a related path and I think that that will become clear when we will go into Lance's part of the presentation. But we wanted to be able to go into this new world in effect and wanted to take advantage of the chain of chaining the person in those those roles to an organizational level credential that Glyph. I'm sorry that the QVI has issued to that organization. And then that could be verified by a change credential all the way back to the qualified VLE I assure so that you can see that they actually were qualified by Glyph in order to maintain that role and then all the way back to Glyph if the verifier wanted to go all the way back so Glyph also has a role in being able since these are organizational credentials there. They're not to the individual as a as a person, they only make sense in the context of the interaction or engagement or representation that that person has with that organization. It allows the legal entity the ability in order to be able to to make the decision to issue and to authorize that decision and also to decide when that credential should be revoked. So that's why we made the decision in order to issue an ACDC and then do additional work on similar to what Lance is going to present today. Is there anything else before we move on. There was a question about a slide. Yes, we at this particular point in time. This is the validation sources for the official organizational role credentials. Actually our names inside of a business registry for example our names on statutes or names on documents. So, we decided to introduce the person identification as a string. We look forward and we would welcome the the inclusion of a national identification number. Also, to be used inside of a V li role credential, but only if there would be a path for the qualified V li issuer using that based on that identifier that that that they would get the legal entity in order to be able to get back to the person so that they can verify and validate that I'm sorry I shouldn't use verify validate against the the external documentation or independent documentation that that they're looking for. So we introduced it as a string to be able to accommodate both of these at this point. Okay. So hearing no more I guess I'll turn over to Lance. Great. I also see Sam had a comment ACDCs have nice internal credential chaining but chaining is possible using external chains glyphorists losing market leadership in identifying orgs and org representatives to another body that isn't dogmatic about the technology choice. I do think that there is some fairness in that although a lot of as people dive into kind of the V li ecosystem which is built on top of carry and ACDCs and those related technologies. The there there has been a ton of discussion in the community like the BC data model community and things like that. In terms of kind of how these underlying technologies can coexist and a lot of times they're sticking points in the details right I don't say the devil's in the details but I would say just in general this is kind of the broad stroke that I want to paint is that the carry ecosystem is kind of a first principles ecosystem in terms of security. And so, when other formats and things like that, if they hand wave on any of those security aspects, it, it can become a sticking point and it has in the past so as you'll see through my presentation I think that there we there's a very very strong desire within the carry and V li ecosystem to bridge to, you know, other ecosystems, you know, the data ecosystem, BC data model, all those. But at the same time, the, yeah, the details of doing that are can be complicated. I'm sure some of you are aware of kind of the past discussions that have been had. But yeah, I mean, we could maybe talk about some of those aspects but why don't I go ahead and present and then we can discuss more any any kind of high level response for that. You mean for me, or anybody. Yeah, it's more of a discussion than anything. And this might mean not be the right time to have it. I am certainly not in charge of strategy and life. So, but but it's unfortunate, I think there's lots of good that could be done in the world, even with technologies that are not quite as first principles based. And that's, and that's what I lament is that I think there could be a lot more progress that we could have been made in the meantime, had had a strategy allowed for a broader use, even with lower guarantees. I think would have been really nice to have an ecosystem and we don't as a result of that is kind of just what I meant. So, I don't I don't want to derail what you're talking about because I want to hear it. In some ways, I feel like it's a good introduction to kind of what we're about to discuss with did web s, because it kind of is the whole effort is related to this. And I guess, if I were to say simply, I think that, well, I don't want to speak for life in full but I would just say that we would happily support as many formats as would support the requirements. You know, that we have, that's kind of the, that's kind of the goal. So, and, you know, like I kind of mentioned, there has been a ton of engagement between kind of the carry the li community and kind of the, I don't want to call legacy but we'll say that did based and VC data model based and open ID communities so there's no lack of trying is is where I'll say so that. And so did web s is a is a another attempt to try. So, yeah, this this kind of shows the desire here that that the li's want to be interoperable and portable. So, so there has from the beginning been the concept of li being a network of networks. The, the, the kind of core feature if you will within the carry and be li ecosystem is that those identifiers are portable so they don't live on a blockchain in the traditional sense. They are essentially micro ledgers of key state and the things necessary to manage an identifier and then the related information like verifiable credentials. And so the idea is that that doesn't preclude you from using a blockchain. So, the reason that we're here is obviously hyper ledger. Indy would be something that that we would want supported within the VLI ecosystem, Ethereum, other blockchains, but then at the same time be able to be portable and move your identifier. And specifically to have the root of trust of your identifier be essentially residing with you as the primary root of trust using cryptography. So, let's see discoverability and interoperability are achieved through the use of did web s I'll talk more about that in a little bit. Let me close my chat screen it's covering it up. Okay. And so, yeah, we'll get, we'll get more to that. Any question in terms of the network of networks. Okay. So, the VLI approach and our key capabilities security and interoperability of the key event receipt infrastructure so that's carry, which I've mentioned, some of you are probably aware of it. It has implemented carry and the related technical capabilities to support fully decentralized and portable that's one of the big terms, secure key management operations on self certifying identifiers. That means essentially identifiers that you are the root of trust for. The issuance and verification and revocation of VLA VLE eyes do not need to operate on a blockchain we said that. And we could essentially leverage any, any blockchain that we want. The only credentials are chained so we talked about that a little bit. ACDCs are essentially the verifiable credential format that we use, but specifically that stands for authentic chain data containers. And so it provides a cryptographic anchoring of organization identity securely and with certainty to a root of trust the root of trust being very important. In this case, within the glyph ecosystem chains, the ACDCs chain the credentials of the people who represent their organizations cryptographically to the organizational identity. It's similar to the concept of a chain of custody so ACDCs provide a verifiable chain of traceability of the contained data so you should be able to trace always again kind of with this micro ledger concept. So we're going to trace back the, the provenance of the data and cryptographically verify any chain, all the way back to the identifier. There's a chain or tiered proof of authority and this enables delegation of authority and the delegated authorizations so often within the carry ecosystem. What we need to support right is these extremely complex relationships that can occur within any organization across organizations and within a supply chain or whatever it may be. The, some of the core features that are built into carry and ACDCs are things like multi sig. So that's multiple signatures, you know, imagine within a corporation you want to create an identifier for that corporation. It has multiple, you know, board members or executives that have to be able to sign for any action to to be executed by that corporation so you essentially need multiple signatures in order to process an action by the company right now no single member can can execute that action. And so these much more complex relationships, you know, and I had mentioned the devils in the details when you try to bridge between the carry ecosystem and other SSI technologies. So often we find that delegation and multi sig support is, I don't want to say ignored, but we'll say lacking in a lot of places, but in carry because of kind of the first principles and multi sig first approach. And the, yeah, those the, the, that's native to kind of the the ecosystem that that we're building so you'll see and did web s that we had to do some work for instance to be able to represent multi sig. As within a did document, and not only is it multi sig but it's in carry threshold to threshold, thresholded weighted multi sig, meaning that you can have multiple signatures and let's say that it's five possible keys related to a corporate identifier. You could specify that three, as long as you have three of the five signatures, then the action can be completed right so you don't need all five signatures in order to complete an action, if that's how you specify it. And then you could also even put weights on signatures, meaning that, you know, maybe the signature of this CEO and the CTO would be enough for an action but if you have the signatures of the CEO and two others, then that would provide the necessary weighted threshold in order to complete an action so I hope that gives just an idea I'm not trying to kind of bury it in complexity but gives an idea of you know the real world use case of that that Terry's trying to solve. It's probably good for there any any questions so far thoughts. So, Chania just a question around. So, we've got the alley I the alley I talks to the company. The V alley I does that talk to the individual. Yeah, that's a good question so the alley is an identifier that that doesn't have a cryptographic basis. It is just an identifier similar to maybe the identifier you get as a person, you know, from as a citizen, the V alley. Yeah, the V alley is then kind of the digital manifestation of this that ties cryptography to an identifier and then associates essentially your alley I with kind of this digital cryptographic chain of trust. If that makes sense so so it it builds. Well, think of it this way. So if you're, if you're a citizen of a country you're given your, I don't know what you would call a social security number or identification number. Somebody might ask for that and you give it to them. The question is, can do they really know it's yours so then you know they'll ask you for maybe some form of identification so you show them a plastic card or something like that that has that your your picture and your identifier and then maybe your nation did something to try to make it for you to, you know, create a fake form of that identification, kind of that whole manual, you know, physical world process would be kind of where the le I exists. So, so you know there's some level of KYC and things like that but there's no, there's limited amounts of kind of digital verification that can occur. The V li is kind of that whole digital infrastructure so if you're if you're familiar with kind of the, the did ecosystem and verifiable credentials within that ecosystem. The V li is an implementation of that that is that that sits on top of, well, that has a technical stack. That's like Terry and ACDCs and things like that, but then also has a governance stack, which is what Carla was explaining in terms of what life has established and life and their partners have established to to govern the li and the V li system. If, so hopefully that helps. Just sorry about the questions but that's good. The VI li is related to your cryptographically giving a person in inverted commerce like a CEO. So his name and whatever additional attributes you cryptographically give that individual something. Or is the V li the link between that person and the company. That's a really good question. So, because of the stack is an SSI stack. The person retains control of the identifier in the sense that they know the secret for for the cryptography that's that's underlying for that identifier so when the CEO. This only the CEO knows the secrets to their identifier, but the actual credential that's given within the VI li system that that says that they're the CEO. So we would we would call that like a VI li credential and that's why some of the jargon might be a little confusing. You know, the ecosystem is V li but then they get this VI li credential and that V li credential has a special name that that basically indicates that this is the organizational representative. You know, for the company, essentially the CEO. And so that credential is given to them during a KYC process and a process in which they do the the digital steps to create their identifier and to go through challenge response and all these other things in order to receive that credential. From what we call the QVIs who are the ones who who who do the issuance for that credential. So that forms an entire cryptographic chain from the CEO, all the way up to life. And then that's now verifiable to anyone. So if that CEO were to sign a report right, let's say it's the quarterly report for their company. Using their VI li they now have a digital signature. Let's say it's a digital report they they can sign that digital report and maybe submit that to whoever will say the regulator is for for their company. Let's say it's a financial institution. They can now submit that report and it's cryptographically verifiable right with non repudiation and things like that that they the CEO is the one who, you know, signed signed the report for that company. Is that hope Sean. Yeah, thanks. Yeah, good. So, sure. Yeah, can I ask a question or make a comment. Please yes. I see the main problems with most of the approaches that depend on a cryptographic secret to be. You know, impenetrability to the common man, meaning nobody wants to be vulnerable to a private key that is lost, stolen, or has to be kept secure in some environment. And people don't even know about this. Meaning, you know, if it's if it's a common person. Then the other comment that you know so there has to be some alternative methods in order to secure that or to rotate that private key which I know Kerry has forward forward rotation and so on and so forth but it's all based on the private key public key pairs. I mean, it's not based on anything else. I think this is a fairly deep vulnerability in all of the schemes that I've seen so far. It will not fly in the real world. So it is not just securing the secrets, but having the secret be a secret, you know, in the in the sense that. Okay, so that is one thing. The second is CEOs will not get involved in this stuff. Believe me. There has to be some form of, you know, multiple responsible people securing this key for the company. Plus, there has to be a way to do away with, you know, like, for example, if somebody leaves the company then, you know, there has to be a way to say, Okay, now the new person is X. Yeah, so I, what Vipin said, both points are so important that I'll have to interrupt because to throw my 10 cents on top of both of those. So, in the real world when we look at financial systems. We absolutely believe I'll go key management is an insane thought to, in a sense, do verifications in any context, the notion of you holding a wallet with your keys in it is an insane thought. So in the real world, we have actually over the last 50,000 years come up with better models on how to do this. And yet in the technical world, we haven't we haven't actually implemented those patterns. So, a perfect example back to Vipin's point is you have a real wallet that has money in it. If I come along and steal your real wallet, I might get $200, along with unfortunately probably some IDs that shouldn't be in there, but I might get $200 cash from you. But I won't be getting your, your IRA, your 401k, because you don't put that in your real wallet. So in a technical world or digital world, the idea of putting, I'll call it valuable assets in any kind of a, I'll call it a wallet context is insane. Because that's not what we do in the real world. So back to his point about in a sense securing, you can have an identity, the ID, whatever it's going to be. But it literally has to be, in a sense, only accessible through services that you authorize. The actual identity itself can't be present in a sense, in any sense you can't use it directly to sign documents you need in a sense, virtual services that surround it in effect, so that it is in a sense protected. Yes, all the other things about rotating keys and everything else matter using proxy IDs and all that. However, and there are third party products. You know, I'll say, has she got involved in a bunch of other ones trying to do that, but even those need improvement for sure. But that. So there's a lot of missing maturity as vip and pointed out on part one. And I also agree with his second point on, in a sense, using the identities in a sense in a cleaner way, for sure, in the real world. And so it is frustrating to see the lack of maturity. In some of these, I'll put design patterns that are moving forward with identity. For sure, we absolutely don't want to use them. Oh, the other thing is on wallets as an example. Again, following up even Ethereum has figured out that that's the wrong idea is holding in a wallet. So they came up with what I call the wallet service pattern as an EIP. So all of these things need to become in a sense secured services that have controls to vipin's point on signing things yet not only as a CEO, CEO never going to do that. But that means you have to describe to me what your delegation capability is in this framework. So if I have authorities and capabilities, I somehow want to be able to designate or delegate some of those over to vipin. And so so far, I haven't heard anything on that either. So that's not actually what the presentation was supposed to be on today. But if we want to spend the last seven minutes doing that, I would be happy to do that. Because we have thought of those kinds of things. Okay, all right, then the right answer is I don't want to ruin the last couple of minutes. The links in the chat that would help me a lot. I appreciate it. Great. If we could just do the did what we did what I mean, thank you. Yeah, and just since I, I don't have time to address delegation and multi-sig and how that helps for recovery in a cryptographic world in a much easier, safer, more scalable way. Yeah, I just recommend, you know, spending some time with the VLI and carry ecosystem learning about delegation and multi-sig, because I think that at least in part that will we essentially face those same frustrations when we come to other ecosystems is how I'll put it. And the carry ecosystem being first principles and wanting to essentially address exactly what you're talking about is, is why carry is built the way that it is. It has to be much more dynamic for corporations and the interactions between corporations and recovery. Essentially, you can never lose your organizational identity, right? It needs to remain safe at all times. But we can talk about witness networks and all these other things next time, I think, and I'll keep moving. Thank you. I do think that those are really important points. Let's see. So the VLI can be used to sign many things. Carla mentioned that. And based on your role, you could also do login verification, signing of reports, for instance, accountants could sign reports. You know, people who reviewed those could sign the reports and then you could have kind of a whole document signature from, let's say, a manager or a CEO or somebody like that. So there's kind of tiers of signatures you could imagine within a document. And then this is just what I wanted to touch on. And honestly, we do, since we have four minutes, I think it's close enough to give this as an introduction. So right now we're working on a specification. It's just been submitted to the did registry. And so that PR is out there. We call it did web s. And here are the core concepts. Essentially did web is a familiar form of did. And I've put that in yellow just because sometimes people misread did web and did web s. Sorry if you're colorblind. But if you're colorblind, just be careful to look at did web or did web with an S at the end. So did web is familiar and did web trust domains. And if you, you know, we every day trust domains on the web. And so if that level of trust is sufficient for you, then you can both use did web or did web s. So it's important to just understand that did web s is is meant to fully support a did web paradigm. So essentially because did web is familiar than that makes did web s also familiar because essentially those did documents will look very similar to to how I did web did doc looks. The difference is a did web did web s did document is verifiable using carry. So if you want to go to that level of verification and that level of security, you can, if you don't want to, you can just use did web s like did web. So did web s instead of trusting just domains and that level of security and certificate authorities and things like that did web s trusts vanilla vanilla portable cryptography via carry, which we've talked about a bit. Again, if you don't want that level of support in terms of verification and assurance then you can use the did web form, no problem. And the cool thing for us on the carry side and the VLI side is that did web s is a more discoverable did carry or just carry for for our identifier so that that is nice for us right that essentially we can post the did documents for a carry identifier, whether that be an organization person or whatever it may be. We can post those as essentially a did web looking identifier and so it's something familiar for the did community and in a lot of ways that if we use did documents which is you could almost think of it as an interface or an API right in some ways for for key state and for service endpoints and things like that. You can know much less about the carry ecosystem, which you know is is vast in terms of its implementation in order to support multi sig delegation and all these other things. You get this simpler, maybe more familiar did web looking interface, essentially the did document. But at the same time did web s is more secure than did web, it uses carry it has support for multi sig will be working on support for delegation and the other portions of the VLI and carry ecosystems. And so the goal that bottom bullet point that did web s bridges the did ecosystem with the VLI ecosystem so if you if for instance they did come connection, as long as that client supports did web s. And that should be fairly easy given that a lot of them would probably be able to support did web, then you could set up a did come secure channel using did web s or whatever else you might be doing within the did ecosystem. So that's just the high level for did web s. And I know I'm out of time, but yeah, hopefully I'll put links for for the specification and the reference implementation that we're building and we'll be presenting some of that at IW. That's great. Thank you so much, Carla and Lance for for joining us and if you're willing to send along the slides I can add them to the meeting page I think that would be great. So yes and it does look like we are out of time but thanks so much, Carla and Lance did you have any final words you wanted to end with. I did as Lance was finishing his presentation. I, I provided a short explanation of to answer the question of where one finds the requirements of how not to, you know, drag down the CEO of having to be responsible for for doing this instead of their regular job, because the this this way of being able to authorize others within the organization, and to give them credentials and give them requirements in order to be able to make sure that the qualified VLI issuers are hearing from only the people who the legal entity is authorizing to interact with them on a daily basis, and ways to rotate them in and out of those roles are documented in the credential frameworks and so I've given some background in the last posting in the chat. And the link is on the slide that I presented before on the ecosystem governance framework slide so that will lead you on the Glyph website to where you can find those documents. Great thank you so much and I've saved the chat so add that as well to the to the meeting page for anyone who wants to see those links and see see the chat text text so. Great. Well, thank you so much Carla and Lance. Thanks everyone for participating in the conversation and providing working group updates and we look forward to seeing you all in two weeks. Thank you so much. Thanks everyone. Bye. Thank you. Thank you. Thank you.