 All right, I'm going to do the backup recording now. You're good to go Tim and Shar and Vivin. All right. Thank you, Sean. Good morning everyone and welcome to the identity special interest group on September 7. Today we'll be doing some working group status updates and then a presentation from German read on trust spreading protocol. So thank you all for coming. As a quick reminder, we are under the hyperledger community and the Linux foundation anti trust policy. So that's right there if you'd like to read that. A few announcements before we get going. It looks like there's some IW planning happening. There's a thread in discord if you'd like to jump in on that. We recently announced making areas framework JavaScript global framework. If you want to learn more about that you can find out that here. BC gov announced a new hyperledger areas related code with us program to do deadline applies Wednesday, so for 13th, so you can find that here. And the ID sig has a YouTube playlist, including presentations from previous calls and you can find that here. So if anyone else has a quick announcement, feel free to jump in here, but if not, we will jump into some working group updates. All right. The hyperledger indie contributors working group met on the 29th of August. Was anyone able to attend this session. Yes. And I think the biggest news on the indie front is that this morning just before this meeting we had the second hyperledger indie summit this was a continuation of the first hyperledger indie summit at the end of June this year. And so Steven current talked about outcomes and realizations from the first summit is continued interest and activity around indie but we're largely working on independent activities. So the goal was to create an environment for meaningful collaboration amongst all these groups that are using indie as utility but don't have too much interaction. And so this, this second summit was because we ran out of time last time for the, here's what we need to do part. That's mainly about actions around technology marketing and regulation on the technology side talked about a plan for what's next with indie and ideas for improvements on the funding side talked about a funding model based on regular contributions to support indie development. And then as well, a non creds in WCC VC data model standard format. So, yeah, lots, lots of great conversations. I think it was a good success on that summit this morning. All right, awesome. Thank you, sure. Appreciate it. Looks like the hyperledger areas working group met just yesterday. Was anyone able to attend this session. All right, looks like they were discussing unqualified did and did come v2. If you'd like more info you can of course all these links. They'll take you right to the page in there. bifold users group hasn't met in a little bit areas cloud agent Python user group was anyone able to attend this meeting. Okay, looks like they're discussing a release and some did peer discussion. Did you do that hasn't met for a while looks like the areas framework JavaScript met the last day of August here was anyone able to attend the areas framework JavaScript discussion. Looks like they had a new release and discussed some open ID for vcs VCI and si op stuff. versus not for a while. Let's see. Looks like the two IP governance stack group met on the 24th of August. Was anyone able to attend this session. Yes, this is drumming. I was there. We have some several very active topics on the governance side. I don't know what what depth to go into but we are off just say at a high level. Our first generation, you know governance framework specifications came out December 2021. We're recognizing that we'll be doing a second generation in conjunction with the maturity of the of the technical stack which is we'll talk about later in this call so it's not going to happen, you know right away but it will be an ongoing project over I'd say the next six months roughly to get to a second generation of those specs and those tools. All right, very cool thank you German. And then it looks like the technology of stock working group met just on the fifth here. Were you at that session as well or will your, your presentation kind of cover a lot of this stuff. Yeah, I, I'm the coach here or one of now three co chairs we have a new coach here Kevin Griffin from glyph this joined Darrell Donnell and I, and what you see here is all the, the six active and there's about to be a seventh active task force. The seventh one is going to be on the new did method called did web as a safe or secure method of do of using did web, which is turning out to be a fairly popular did method so I don't want to take the time here to go over there's there's However, just putting together these notes is pretty amazing because I mean there's a whole whole notes page on a report out from all of these meat was just copied over I'm not sure but in any case I could find the link for it. All of these task forces are active and cranking along I'm mostly going to be reporting on the third one down the trust banding protocol task force. I'm going to take the rest of this call to summarize what all the other working task forces are doing. Fair enough well no we will we'll move it along to to get to your presentation but yeah if anyone like more information click the links they are copied and pasted driven so we have. Yeah that is how we got all that info in there so cool. I do. Think. Sure that if as the diff did come user group or work or working group met is anyone attended a session from these. I wasn't able to find anything when I was looking to update the page, but I think they're supposed to meet every week or every other week. Once a month. It's over the user group meets three times a month. As I understand it basically three weeks user group and then one week of working group. I, I try to tend those I maybe make it to half of them. And they're, you know, I like to say is that they're moving along nicely. There is a big intersection between where they come is going and what we're tackling with trust banding protocol talk about that more when I present. All right, awesome. Thank you. And then W3C standard doesn't look like there's anything new for them so so yeah unless there's any other updates I think we will hand it off to you drugs. All right, I was going to say I, although the dead working group is going to have a meeting that so next week in Seville, Spain. This is W3C to pack the dead working group will it's been on I had a since we finished 1.0 there will be a meeting there about the the Charter for the maintenance working group. And they continue to accept dead methods. I think it's over 160 now. And that doesn't yet include did web s which they said is going to be new task force and trust over IP. The credentials community group as always, they're just constantly doing new stuff so that's what I can say about what's going on over there. Oh, you don't have the verified credentials working group listed. Getting close to their what's called candidate recommendation stage for BC 2.0. That will also be an in person meeting in Seville I'm not going to that Brent Zundell that works for Jen is co chairs that and as I understand it they're, you know they're pretty confident they're going to get out a candidate request, I mean a CR. But they were not able to resolve the tension between Jason LD and and other formats like Jots. So it's going to be a very Jason LD centric specification. All right, good to know. Thanks, John. And I will look at the verifiable credentials working group and see if we can get them out to this list here. Daniel I see your hand is up. Did you have an additional updates? Yeah, just real quickly, NIST. It's a kind of US centric but NIST SP 800 that's 63 there. They had a public draft on rev for Dave just today was giving an update on that. They had 800 comments. One of them. And the reason why I'm bringing up here is, they were very centralized focus so what some of the comments including mine where why don't you cover decentralized like verifiable credentials and MDL. They added that so when when they publish the final version of dashboard, special publication 863-4 it will include some level of verifiable credentials in that NIST specification. That was it. All right, no, I appreciate you share. I think that does bring us to the end of our working group updates for the day so I'll hand it off to you, Drummond, if you'd like to take it away with your presentation. You betcha. And my presentation is going to consist of just one webpage. So what I'm going to do is just walk through and give you a talk track to the blog post that was just just published earlier this week on the trustworthy site. I guess if it's helpful, I can. For those who like to read ahead I'll just put the link in the chat. There we go. And we call it the mid-year progress report because when we formed the trust spending protocol task force at I trust RP actually I guess to give you a little bit this background I'll pop open quickly this one and give you a little background so when we started the work this task force we wrote this blog post as you can see in January first week in January. And we started out providing this context that in the development of the trust over P stack at at trust over P. And most folks may be generally aware of this but for anyone who's who's, you know, new to this whole thing. We knew we were playing, you know, quote the long game that it was going to take us a while to do you know to design a protocol stack to really tackle the problem of decentralized digital trust infrastructure in a highly interoperable way and when we say highly interoperable we're talking about interoperable like the internet's interoperable it works everywhere it's as seamless as it can get it's it's huge task. So we developed this this diagram which is in our technical architecture stack we have a page on the website that's devoted to the evolution the trust RP stack we said hey. First we got to tackle, you know, design principles based on the core, you know, four level model. Then we have to develop a technical architecture then we can finally concentrate on any component specifications that don't already exist things like decentralized identifiers or verifiable credentials we don't have to. We don't have to invent those are already there but there are other components that will be needed we're only going to do it trust or P what no one else is tackling a lot of what is being tackling. A lot of the other components are coming from from diff or from hyper ledger things like the non creds. As well as of course other standards bodies like w3c or ISO itf. So, hang on just a second. I need to my boss just sent me a text and I said, yes, I just need to answer this. Just quickly. So, So what we will want to establish in January was we have completed what we call design principles for the trust review stack and since I have macros and all these and I will take advantage I mentioned them. Do you think there is the link to that. And the next one I'm going to mention is called our technical architect respect. Let's see. No, it's that is the page we have on our website that actually has linked them with a PDF and the markdown version of the technical architecture spec. So, this effort here took about nine months and 20 during 2021 this one took a good part of last year, but by last fall I w last fall we said okay we've got a technical architecture spec. It's pretty mature has been in public review we're still going to make some minor revisions we decided we would want to tackle a few of the component specs to provide feedback on that so, but we're we're pretty happy with the first two stages so what that laid the ground for you to say all right, what component specifications in the stack. You know need to be done that no one else is doing and we've identified two of them. One is work on trust registries which we've been working on since the good health password in spring of 2021. The other one is the core of the stack, which is the trust spending protocol so this we wrote this to announce the start of the work on the trust spending protocol. And, and why is it called the trust spending protocol, because the model that you know the internet pioneered turns out it's not the first hour glass model but it's just the largest and most successful. It's been extensively studied why did the internet succeed versus other architectures for a global network. And this is a simple rendering of what the hourglass model looks like for the internet. And the core of it is the idea of a spanning protocol spanning protocol is the one common protocol that is supported by all the protocols below it and supports all the protocols above it. And that's what gives you the global interoperability everyone can use the internet even if you they're using, you know, email on top of it using one, you know, a transport and HTTP is different or to be you know all that stuff so that's the whole idea of a, an hourglass model and and a spanning protocol at the center. The whole reason for being of the trustworthy foundation is to say, we need to apply that same model to the problem of interoperable trust, not just sharing data across domains but establishing trust across domains, any two domains anywhere just like the internet. We need to apply the same. It's in the design principles, the whole point of the hourglass model is one of the 17 design principles. And that means we need, you know, we need the proper support but we need this protocol right the center, the trust spanning protocol and that will support a whole family of trust has protocols that been support applications. And so that's that's the overall rationale we had this is a diagram from the more detailed diagram from the technical architecture spec that sort of breaks this out and says hey at layer one you have to do you know an endpoint that's going to speak trust over IP and use it for interoperability. The endpoint is going to have to support whether it's a mobile phone, or, you know, tablet or laptop a server IoT device. If it's going to speak this protocol it's going to have to have some form trusted computing, whether it's a secure enclave or HSM or whatever it is, because it's going to have to do cryptographic operations, it's going to need secure storage for what it's going to keep on that endpoint. It's going to have to use transport protocols to move around the the trust spending protocol is not is bound to transport protocol. The default one is of course going to be TCP IP via one or more of the other protocols like htp or htps but or quick or whatever the whole point is it is transport independent can be bound to any transport protocol. And they're really good use cases, especially offline use for for using other things besides TCP IP so even though we're called trust over IP trust spending protocols protocols actually transport independent. And this protocol is the groundwork for all kinds as I said we've got much larger list but this just gives you a sense and I want to emphasize, even though, you know, over hyper ledger and the and the current state of the industry were very focused on credential verifiable credentials, you know, digital credentials, whatever you want to call them, and the whole trust triangle of issue hold and verify that is fantastic super cool it's only one use of the trustworthy P stack. Second thing, you know, digital wallets are there's a whole nother class of course digital wallets that are all about payment, especially, you know, Web three crypto currency exchange. But those are maturing and adding additional forms of payment we absolutely believe both of those are going to be covered, but secure messaging right did come. I think many folks are familiar with deep in areas projects, then all the things you can build on top of did come and did come protocols and belong at our trust has layer. And it's important to point out it's not just messaging streaming data can also use the stack we're designing it for that so you want your security centralized Netflix, that's something else so there are many examples what can be used up here. I'll get to a couple more specific ones when we get to the spanning protocol but all those try the whole idea is try these trust as protocols now can be called by applications and the developers of the applications. Not only do they not need to worry about how authenticity and confidentiality and correlation privacy are handled at this layer. They have all of the power of one of these trust as protocols that they can just plug into an application it will make building trusted applications just I mean, enormously easier. I sometimes I'm not a developer myself but I compare it to what some of the UX frameworks do they just they just handle so much of the jobs of the developer can can focus just on what they actually need to do. That's unique for their, their application. So, anyway, I went back to this one to just say this, we have a whole set of requirements in the technical architecture spec for layer to the trust spending layer. I'm not going to go through them here but as you can see they're 18 of them. And, and, and the whole starting point, I'm going to talk more about this in a minute is what we're called in the spec trust of our p identifiers we're actually going to change that to just talk about these verifiable identifiers. I'll cover that in a minute. Anyway, so we just basically said hey and by the way this trust spending protocol, because it does connect. It uses. You know what we all recognize as dids, we're generalizing that to verifiable identity identifiers or vids. There are three protocols out there today they're all designed with that same architecture that it's it's obviously did calm his name because it's did did. And a lot of folks may be familiar with carry and Caesar is also it's actually you can think of a very specialized kind of did called an AID autonomic identifier. That's all what what the carry stack is about and then another diff project decentralized Web node also is based on did to did communications. So there are three, you know, protocols out there and and all of them are sort of stacks they're all what we call for runners to what we're trying to do with a trust spending protocol. And then we just said okay so and there's a bunch of other protocols out there that today are filling little niches in the stack. Because there isn't anything that is comprehensive and complete and if we're wondering why is interoperability so hard in the world of, you know, call it decentralized identity or SSI verifiable credentials today. It's because of this it's because of all these options that folks have to choose from to be very specific, you know, if you're the European Union and you want the ideas to to work. You're going to have to make choices from among the things that are already there that are reasonably mature enough, and we recognize that we can't do anything about that. Other than to stick at trust and very peace stick to our knitting and say, this isn't really going to work for interoperability at internet scale. Right, we're not going to get there by continuing to use and I don't want to, I don't want to cast, you know, aspersions on any particular protocols out there they're all doing the best they can to solve the problem today. What we're tackling with the trust spending protocol is to say, All right, let's really solve the problem at a very, very wide level. And that's so that's the introduction to why we established trust spending protocol task force which as I said, kicked off in late January. Now, move forward. I actually I'm going to stop there for a second if there are any questions about, you know, the, I guess I never turned my video on. Happy to do that. Any questions before I then dive into. I have a question. Go ahead. If you look at the initial our glass model, which is the IP model. Yes, everything below it is shown as basically, I mean, not in this particular diagram. Yeah, so most of them. The layered model you already have, but the layer just below the IP is basically all different kinds of protocols that allow communication and create local area networks. Yes. So, in other words, it's translating those into a standard canonical form. The IP protocol. And then everything just links to that IP protocol IP protocol. But in your diagram. There is a whole bunch of things that are a mish mash up different kinds of kinds of technology there, meaning the storage layer is not the same as you know some other thing. So, there might be a paradigm mismatch here but, you know, I'm willing to accept that, but that complicates matters quite a bit for your trust panning protocol. I would agree I think if we're talking about this diagram. Yes, and and you see here at layer one where we're going to talk about trust support if we're talking about strictly a protocol stack. Then the only thing at layer one that that matters is that you have the whatever the necessary transport protocol that you're going to be using for the. Yes, because, because the only thing that trust panning protocol should know about are those network network transport protocols as long as they can support the capabilities that are the trusted computing services and the secure storage services. Yeah, that would be a fine thing but if you start mixing and matching layers then you know I don't know I mean maybe there is a reason why you do that, but So vivid are you saying that of these three boxes down here, these other two don't really belong here because from a protocol stack standpoint it's really just a network transport protocols that are. And then those others should be below that because they have those have to be supported using. Yes, the transport protocols because otherwise. You know transport protocol is the only thing that you're going to connect to in a certain sense. Yes, you're you're saying that those transport protocols have to support those basic capabilities that you're talking about which is just started out by talking about the IDs, but then. Yes, there are the channel stuff and everything else but everything has to come through those. Those network transport protocols. I 100% agree with you in fact we just had a good conversation yesterday on two different trust European meetings, we are revising this diagram is definitely out of date at this point. Again it's in the curve version of the technical architecture spec but we knew and we even put in the current public review draft that we know this diagram needed to evolve it's going to evolve and you're absolutely right. I think you should continue because you know this can go down a rabbit hole shirt probably nobody else wants to talk about you know I'm just bringing that bubbling that to the front. Yep, no it's it is a very good point and so that no one is confused. In terms of a protocol stack from the hourglass standpoint it is these network transfer protocols that the trust spending protocol runs over. So, I don't have that diagram right here but it ends out being an hourglass on top of an hourglass with some sometimes called the waste in the neck model. And the lower hourglass when you're building on top of TCP IP is the TCP IP stack. So that's that's how it stacks up together. Right so now I'll switch over to our progress report and and I'll just go down through and I'll touch on that there's seven will call cover seven pillars of the design that we've worked out over the first seven months of this year. And we publish this blog post because we want to basically just not go silent till we're all done. We wanted to document the milestones we're going through as a task force, and we were particularly excited because as we cover here. We, we actually identified for various reasons we created a. Actually, it's useful enough I might just bring it over here right now and show you know, I skipped that there are basically 10 stages that are working with some task forces go through and preparing things and the proposal stage is is in many ways one of the most exciting which is okay we've outlined the problem we've got we know what the sort of the scope and the constraints are. Now how do you solve it and we spent three months going to that stage and had for sort of complete proposals as to how to solve the problem from these four gentlemen you see listed here. And so, once we had that then we entered what we call the consolidation stage and that's the hardest part. Can you take the proposal to figure out and bring them together into you know one overall coherent design and sometimes you can't do it and you can't solve the problem or you can't be successful. And believe me there was some we had to have a lot of long in depth discussions you know as you hash that out. What I was particularly excited about is that it did come together in a way where. Mr. Herman is no longer active but where everyone else said hey, this really is, you know, we're excited we think this is going to work. It's a combination of the ideas that were brought from those proposals and the other task force members. It boils down to these seven what we just call pillars of the design. They're all different aspects and I'm just going to cover them for the quickly as I take a sip of water. Sorry I've been talking since 630 this morning. So, I will just quickly step through them you can see all seven listed here and I'll just step through and stop me at any point if you have a question about a particular one I just want to sort of hit the main points. The starting point is really easy as I said we we've decided the term we want to just standardize on the term verifiable identifiers, because that diagram I showed you earlier. Obviously the one that we said the most attention is the IDs, and they are decentralized verifiable identifiers. The reason for this term is that we did not want to exclude identifiers used on the web today that are cryptographically available like HTTP addresses URLs. The challenge from a security standpoint is there are several holes one on holes in terms of relying on DNS and not not throwing shade at the SSL or TLS protocols, you know, pretty good stuff but they don't, they don't provide the same characteristics out of the box as the IDs where you can rotate keys and you can rotate endpoints network endpoints and maintain continuity of a relationship. There are ways to address those and those end up being dead methods like did web or did web s. And there are other ways to do it so we wanted to say hey, we're just going to talk about any form of verifiable identifier. On the other end, there is a subset of you call it did methods or the carry community calls them a IDs autonomous identifiers that are even more secure and more decentralized and have more capabilities non-AID methods. So we're just lumping them all together and saying our starting point is verifiable identifiers. And you can see the three key things that any verifiable identifier needs to be able to do. You can resolve the firm public keys cryptographly verify that they are valid. You can obtain the current network endpoints for speaking this protocol for establishing a TOIP connection. And the identifier does not need to change when the keys or the endpoints are rotated or updated. That's the essence. That's our starting point. We've also, because there's such a variation in the kind of identifier and the strength of that identifier, we've identified that we also need to design what we call an appraisability framework a way that you can a machine, ideally, maybe in combination with a human can actually when presented with a particular VID get and verify the description of that so they can make a trust decision. Do I trust the underlying infrastructure, the governance framework associated with whatever there's a surprising number of factors that go into making that decision about whether you trust that VID and what it's based on. So anyway, that's all I think I want to say about that because as we say here in this paragraph, all the VID based protocols also rely when you need to initially form a connection. You got to have some way of discovering and verifying the VID of the other party, what we often call a public VID if you're exchanging it publicly, or if you're even if you're doing it like phone to phone. And that of course can be QR codes, it can be a bunch of other ways. Those methods, UBs, we call them are just part of what you need to do. So that's pillar number one, it all starts with verifiable identifiers. Pillar number two, end to end, authenticity and confidentiality. We all know, we all hear about, hey, you know, what's that Facebook Messenger, iMessage, telegram signal, they're all end to end encrypted. That's wonderful, that is confidentiality. They also do address, okay, do I know this is really from, you know, the other endpoint, that's the authenticity part about it. I was not aware that the combination of what you need for signing and encryption, that there are a bunch of different ways to put those two together, and a bunch of cryptographers have argued for a long time about what is actually the most secure way to do it. And we refer here, and I learned all about this, that the pattern that actually results in the greatest, the greatest security, the hardest to break in any way is called ESSR, encrypt senders key and sign receivers key. You know, follow up on the links, dive deeper into it, but the task force, once we got educated on that, we just said, ah, we need to apply that pattern to every, to all the protocols and channels in the overall design, and we have 100% consensus on that. So I'm just going to refer to that ESSR pattern is used in every one of these channels that we're going to talk about. So pillar number three, and this is the first one I've got a nice little diagram to go with, there it is, direct connections. So if you have, again, you've got verifyable identifier so you can sign in encrypt every message, you can deal with them with authenticity and confidentiality requirements for any trustworthy connection. The third area is what we call correlation privacy. If you're going to share data that in the end the other party can decrypt and they've got the data, then the usage privacy of that data is not something you can control with technology. You can do it with governance, you can do it with contracts, you can do it with other non technological means. The other part though is correlation privacy, often called the metadata observability. If you can see everything that's going on in the network, you can learn an awful lot, even though you can't decrypt the messages. And so what can we do technologically about correlation privacy? And there are two steps and the first one is remarkably simple, shown in this diagram here. You can have a public channel between two vids of their publicly observable like over the Internet if you've got a publicly observable network. But what you can do is then you can tunnel another channel inside of that with two vids that are not publicly observable. So A1 and B1 are only known to A and B and you can't see those over the network. Now you're going, well, I know A and B0 and I know they're talking to each other, you're absolutely right. However, one thing that A0 and B0 can do there is turn around and say, all right, if we want to change our public channel, change our public observable identifiers, we can do that and not have to change A1 and B1 because they're hidden and they can stay hidden. And so it's one simple way you can, it's one step towards correlation privacy. It's not a complete solution, but it turns out this pattern, as you'll see, is actually very useful in a number of other ways. So we call this just very simply the inner channel and the outer channel. So that's our third pillar, and I got about 17 minutes left, so we're going to make a good progress here. Now, if you want full correlation privacy, it turns out what you need to do is nest one level further. And I won't take a bunch of time, you can read through this, but the basic idea is you need to add one or more intermediaries. This one shows two, but you can have the more intermediaries you add, you get both scalability and the idea is no intermediary actually knows the full path. The only one's knowing the full path between A1 and B1 or A and B. And actually all they need to know is their intermediaries. It could go through other intermediaries and the intermediaries can connect just like routers do today, but none of them know the full path. What they do have is connections with each other. That's the outer, that's the red. And then what they're running between, they're putting the inner channel through the blue is a routing protocol. So they are, it's three layers of nesting. A1 and B1 have the direct connection that no one else knows about their identifiers and this path. Each of the A1 has a connection with its intermediary. You think of like, you know, if you use an email server style analogy, and over that publicly observable connection, you have this routing protocol. So you know that this is A's intermediary, but you don't know who A is talking to. You don't even know the other intermediaries that you can come and say, ah, well, there's a connection between these two intermediaries. And I can publicly observe that, but you don't know which of the endpoints are using that connection. And again, neither of these intermediaries knows the full path. So this is a, you look at it, you go, oh, it's sort of like what onion routing accomplishes, but it's simpler. And it is, you know, it doesn't require all the infrastructure. It does require intermediaries that know how to speak this routing protocol. And that's, you know, that's going to be a requirement of broadly deployed trustworthy infrastructure. All right, taking breath at each one of these to see, but I might as well plow through and then we'll see if there are any, any more questions. So that's number four. Now, number five, once we've established this channel infrastructure, this is where it really gets pretty cool in terms of now we're getting into capabilities of the spanning later what you can do with it to set up for trust tasks. And the this one is once we've got these, you know, nesting of channels. And you've got this default channel they want to be one will always have between them. They can now use that channel as a control channel to set up other channels as needed for as many different, what we call relationship context as those two parties. And don't think just person to person thing person to business, you know, person to device device device business whatever it is right. And these relationship context channels, there's all kinds of uses for them. I think we listed up here you can, you can instantiate a new channel to add a new set of parameters for stepping up identity assurance, right. Okay, you want to use a high value payment. Okay, we're going to establish a channel that requires a liveness detection, or a certain set of a trust tasks like verifiable connection exchange has to take place. You want to have a group messaging channel or or institute something like ML asks for group messaging. You want to have a streaming channel, you want to, you know, instantiate you want to switch to a different pair of vids for a particular transaction that again are only one time use. So you keep that you want to, you know, present private they're all kinds of any particular trust task a layer three might say hey I would need to instantiate a new channel with these parameters and the two, you can use the control channel to do that. And you don't need any other infrastructure to do that. So, that's number five. Now, the last two are fairly easy to explain any, you know, protocols around say what's encoding, how do we do it. This is incredibly contentious topic. When it comes to cryptographic protocols. They're, they're very heavyweight with cryptographic data structure signatures and hashes and and commitments and all that. And I don't know forever going to agree who wants to use Jason who wants to see more who wants to use message pack. You want to text you want to binary Caesar is a one of the specifications in the carry family. It's, it's now in the AC DC task force at trust over IP Caesar was developed to tackle this problem and say hey we can have a encoding that's optimized for cryptography that can carry Jason Seabor or message pack and it can can exchange the data and either text or binary or a combination in the same message or stream. It's also designed for pipelining. Again, I'm not an expert down at that level, but I've watched architect after architect be very skeptical about last thing we need is another, you know, serialization and coding format. And then come out the other end with enough experience to go Oh wow, I don't know how we're going to do it without this. So, we're we've we've we've also got the consensus about using Caesar, even though it's fairly new. And the last thing I'll cover and we'll have good 10 minutes here for questions is, once we have all those other pillars. What we need a layer to is just the framework for trust as protocols that they go above and that's that's the thing we least have to invent because did come carry and DWM all have established those frameworks are all designed with the same basic idea we get the base protocol and now you can build what what trust or P calls trust hash protocols on top of that. And they all follow the same basic thing you have a protocol identifier which of course could be a V ID. And, you know, that defines the message family is what they come, or at least used to call it I'm not sure what they call it now. And, and in that family you have to have definitions of the packets or messages and in each one and then of course the protocol logic business logic of the protocol. We don't need to reinvent any of that section nine the did come a v2 spec is a perfect example. We also agree, and the did come folks that are participating and pointed out there's some handful of standardized trust tasks that we also want they probably will be separate specs, but that we think need to be defined to use with a trust spanning layer, just like I mean the easiest one to example just like we use King, the very simple pink protocol with TCP IP just to check a connection. And they call it trust ping, and it makes a lot of sense. So anyway that framework is then what will set up a you know the ability to define standardized, you know whether they're narrowly designed or broadly designed, you know, very horizontal or very vertical it doesn't matter all the trust tasks that we need. We provide a small example. I'm going to point out, I guess, actually no I won't take time we have finally develop a list we're adding to the technology architecture respect 27 of what we call canonical use cases for the trust or IP stack. We wanted to do it not to say you can do. They're just examples but we wanted a bunch of examples that were not just verifiable credential exchange I think there's of those 27 I think seven of them are verifiable and there's a bunch of others. And so this is over here. And that's it. We are now in the working draft stage we just had our first meeting yours first step on the working graphs yesterday we meet Wednesdays. It's 8am Pacific and 6pm Pacific for the two time zones and if anyone's interested we'd love to have you and with that, I think there's about 10 minutes left for questions. Go ahead right. So with regards to iot. I saw that in the, you know, at the beginning. Yeah, is there is there is there a focus on that with regards to what is being presented here. I dance I'm going to give you is the trust of IP architecture is designed very much like the internet to connect any two entities. And I mean that in the very you know, in the very precise term entity that need to have a trusted connection engage in some kind of trusted interaction. And so we don't distinguish whether that entity, the communicating entity is a person, it's an organization, it's a iot device, it's a AI, a bot, it's whatever, right. We absolutely have said from the outset that the protocol must be designed so it can be used by, you know, the thinnest iot device or sensor that can actually handle cryptographic operations because that's the only way we can secure that end point. But as long as it can do that, it's absolutely and one of our one of my colleagues that my two colleagues of the task force are Wenjing Chu from future way and Sam Smith from digital trust ventures and you know the carry stack. Sam is a huge iot guy and and everything like even Caesar is designed so it's it's it can support, you know, the thinnest iot device that can do cryptography is the way I will put it. So I won't say it's a special focus but it's absolutely a requirement that we're not designing something that, you know, could not be used for iot. And so that architecture is that available or are we still. Well, so where we are as I said the, the specs you can look at now you can look at the design principles you can look at the technical architecture spec you can't implement any of those they are, you know, design principles and then the technical architecture is requirements that the component specs have to do the two component specs we're working on a trust over IP are this one for the trust banning protocol which is you can see is going to end up being a little sweet. Okay, and then one of the trust task protocols is a trust registry protocol how do you talk to a trust registry, and there's a separate task force that meets Thursday's two meetings every week. They just had their meeting in the last hour. And, and that's going in parallel with our work on this. Our goal is to have, you know, specs. Well we want to basically complete the specs this fall together with implementations we want to have implementations of both. With the trust banning protocol the initial implementation being rust. It will probably be at contributed to open wallet foundation. But, you know, collaborate the same. Can you send me the link so I can put my email. I get notifications. Yeah, yeah, well, sure. I tell you what, let me put my email address. Maybe the easiest thing is the, well, the easiest thing are you a member of trust over P because that's the easiest thing to do if you join trust or P, then you can pick the mailing list you want to be on and groups you want to be notified by. And that's just just right on the trust or P website check and put in chat. Oh, the trust I was on my phone and then I came on here so I lost the ability to grab that link. Thank you. No problem. Yeah, it's right there just contact page. I don't have to have Judith. I think it's that you can also just email Judith. She's our director and she can set you up with with that right away. Okay, thank you. Any other questions I can answer. Come on. Yeah. For the channels that you talked about. What metadata can be observed, even after wrapping them. Um, the whole idea that pen is the only not not that one. I mean, you know, the earlier one. This is the control versus others right. Yes, exactly. So you're talking about going all the way back to that one. Yeah, because that is the basis of all the rest of the channel wrapping stuff, right? Yes. So the, the idea is what you can observe publicly by assuming this is like to see that be used to be transferred so it's the internet you're observing. You'll be able to see a zero and B zero, and that there is traffic going between them. Um, gauge the level of traffic. Can you look at get any other piece of metadata. We have been discussing that one thing that can you do traffic analysis. Yes. As you can do it on on any protocol, but it does and we're going to discuss there. They're basically if you want to defeat things like traffic analysis, then what you do is you start sending messages that are yes. Fake messages or patting or whatever, you know, you, you start exactly you start doing all kinds of crazy things like drop this message, you know, it's it's only to spoof. I mean, it's only to help. Defeat traffic analysis. The other the other protocol that comes to mind is dandelion in lightning. Which, which, you know, for the next few, like, for example, when you have intermediaries. That's when dandelion up. That's the context in which dandelion operates. And there's some usefulness in looking at that. I mean, I know that you already said you looked at the onion stuff. But this is, you know, this is a different problem being solved in lightning. Again, you know, it is to obscure the path and the and the level of messages being sent. And then to the original comment, which is, you know, sometimes get the feeling that you're stuffing in too many things into the trespassing protocol. If, you know, all these things have to be supported by the underlying transport layers that you're supporting, then, then you can do this, but if not, you cannot write. Well, I think just to make sure I'm being clear. In classic layering that transport protocols don't have to know anything about what will happen is trust over IP. You know, the trust spending protocol will just be from the standpoint of the T scrap B stack another protocol above the IP layer. Right. And in fact, we're, we're looking closely at binding to UDP for various reasons. I mean, you can bind either one, but UDP has certain advantages that. Yes. Yeah. So, you know, so we have to have the protocol to. Yeah, exactly. And so, you know, we don't want to, we basically want to keep the trust spending protocols light as we possibly can to get to cover authenticity, confidentiality and correlation privacy. And if we can do those things, then the trust tax protocols don't have to worry about any of those. They can constrain just what they need to add. And we'll get a really nice stack. I'm not, no one said it was easy. If it was, it wouldn't. I know. But anyway, this is, this is, this is where we are at with the design. And will you be at IW Vippen? No, I'm, you know, I'm anchoring down in New York City. That's a good place to be doing it though. Well, anyway, so I will follow and contribute as needed because what's happening with me is that I have experience actually coding many of these things. This is New York City after all. Yes. You know, time is coming on, but yeah, so basically I have experience with the actual development in protocol development and also in binary and text format, you know, streaming and, and at rest and cryptography of course, but we'll see. I'll try to engage. Okay, sounds good. All right, I know we're over time so. Yeah, we really appreciate you joining. Appreciate the great session. So thank you all for your time and we'll we'll close the meeting out. Have a good one. Thank you so much. Thank you all. We'll see you at the next meeting if not IW. You bet. Very much Helsinki. Oh, thanks, Bo. Good to talk to you. You bet. Talk soon. Going very strong you are and thank you very much. Good. Well, we want to solve the problem, you know.