 Hey good day folks. Hello. Good morning. Hey Hakkan. Happy new year. How are you? Yeah, happy new year. I'm doing well. It's been super busy even before the new year and now now coming back into it but yeah busy is good. How about for you? Yeah, same with me as well. So yeah, I will be changing my organization by the end of this month but I will be in the area of South Sovereign Identities and will probably continue with this working group as well. Oh, great. When do we get to hear the details? That sounds exciting. The beginning of February, I would say. Once I switch, I think I would be able to officially announce it. Since there's a recording, I don't want to. Yeah, fair. Discloses at this point. Yeah, that's great. Well, thanks for the heads up and yeah, I hope we can continue. That would be great. Yeah, absolutely. But by the way, just one more information. The next two weeks, I will be on vacations, rest vacations, so I will not be attending these calls for the next weeks. Yeah, thanks for letting us know. Yeah, of course. All right, let's see here. And yeah, how's that look? Let's see, that should be our meeting. And did comm is highlighted because well, there we go. Okay, let's see. Does that look all right? It should be our meeting page. Yep. Great. Okay. Hello, everybody. Welcome to the January 16, 2023 meeting of the areas did come v2 working group. Our mission is essentially to accelerate the adoption of did come v2 within areas and beyond. And I just have to remind everybody about the hyper ledger code of conduct. And I'm forgetting the term the hyper ledger anti trust policy. So please feel free to let me post the link in our comments here. Please feel free to add yourself to the attendees list on that document. And is there anyone new here who would like to introduce themselves to the group? Yeah, sure. Hi, my name is Simon. I'm here with Philip. We're both from hyphen, a Danish startup that are building a commerce focused side wallet. And we're super interested in in did come and what it can enable for the user and brand company interactions in the future. So we're just listening in and learning more. Great, Simon. Yeah, glad to have you. So the wallet is a web wallet or a mobile wallet or it will be a mobile wallet to begin with. But that's probably going to be like multiple agents. Yeah, good. Very good. And yeah, I think I saw that you guys said signed up recently with Aries. So so you're fairly new to the whole Aries ecosystem. Yeah, we have really been diving down the SSI rabbit hole past six months, I would say. And we come basically from from the web three blockchain space. And then, like our eyes were opened up to the whole as I think, and just been diving into that and learning a lot about the different, let's say communities that are within the SSI space. And trying to figure out which holes to bet on is the areas is it more the verbamo, you know, way of doing things. And yeah, but it, I think we've been convinced by the hyperlature in the Aries community, especially now with the adoption of the B3C, where five of credentials and kind of moving. It seems like the different spaces are converging and areas really has a lot of fuel behind it. Yeah, for sure. It's a great community that's been around for quite a while. And in a lot of ways has defined a lot of what SSI is, I think. And it's helping that that open standards are becoming more well known. And yeah, we can kind of all hang on to the, yeah, to the same standard. So I think that's that's helping the convergence a ton. But yeah, this is a pretty exceptional community in the sense of just how well they work together. And, you know, it's a it's a good group. So glad to have you. Glad that you found found us. Did you want to say anything about, you know, real quick, just the blockchain world that you're coming from? Or you don't know, I mean, we've just been looking into the space between, let's say, consumers and brands, and how that relationship is evolving. And, you know, last year, we saw a lot of stuff in the word three space with NFTs and, and identity on the blockchain. But it seems like there's a really nice overlap between the whole SSI idea and some of the technologies that we do have been in where three that can enable some super interesting and new ways of interaction. And that's that's kind of what we're looking at. Great. Awesome. Thank you. Okay, let's see. Any other anyone else want to say hi or introduce themselves? Yeah, I'm, I'm also here from high fun. My name is Philip. I work together with Simon as a developer, but I will mostly listen in today. But I'm happy to be here. Yeah, great. Great to have you, Philip. Thank you. Thanks. Thanks. Very cool. All right, so let's see. We have our welcome section. Let me edit. Okay, good. Aries agent test harness. Let's we're just going through the updates from from the different groups that we might have some information about. We had talked some about Aries agent test harness last week. Thomas was here from from Apache camel. And he had done, if I can, he had done this report. Yeah, for just support for didcom across the different AIPs. Sorry for all the scrolling. I'm trying to find that thing. Yeah. So he was just trying to update himself on Aries agent test harness, which is the test harness and Aries for agents to connect to and find out how get score for how interoperable they are. And part of this group is, we think part of our work will be to kind of improve the amount of testing and simplify as well some of the testing within Aries agent test harness for didcom v2 specifically because didcom v2 isn't part of an AIP yet. So we've been talking a bunch about AIP 3.0, which would be didcom v2 focused AIP. But the previous two AIPs one and two, Thomas was going through and just looking at support for those and the types of tests. So we've essentially been talking about Aries agent test harness a little bit more here in 2023. And that'll be a focus of some of the work that roots ID that I work for. That'll be some of our focus as well. So I don't think that they had their monthly yet. So I don't know if we have any meeting updates, but anybody else want to say anything about Aries agent test harness or ask any questions? Okay. And then Aries ask our secure storage. I did see an update that I think Ariel from the AFJ group, I think he just did a pull request for some Aries ask our support in AFJ. So that's good. Yeah, if anybody wants to mention anything on that, feel free to jump in. And then our frameworks. So Hakan, I don't know if your group has anything for ACAPI updates? Yes, I think you were in the call as well, but I will give a recap from the last ACAPI meeting regarding how we will be proceeding for the Aries cloud agent Python and did conv2 implementation. Basically, we had a question mark related to the encryption envelope, which one we wanted to use. There is an ask our implementation. However, it is not fully developed yet. It is still missing some components, some features for it to be a fully viable encryption envelope for Aries cloud agent Python. But currently, what we can use is different libraries for the did conv2 encryption envelope. And there were a couple of options like rust implementation. There is one that has been created by SIGPA. And after talking to the ACAPI community, we have decided for the time being to roll with the SIGPA implementation of did conv2 encryption envelope, because it has a full future set. And it can also resolve peer that's natively. It does come with a couple of, let's say disadvantages in comparison to a native ask our implementation. For example, the key management so that the keys are actually leaving ask our itself. However, as long as we are not really considering using your hardware sqq module for connections, basically the ED or x25 519 keys. This is not a large problem. And at this point, it is also not planned to do so, like at least not on the next viable short to midterm. And that's why, like as a pet of least resistance, we will be using the SIGPA libraries for did conv2 encryption envelope. Great. Then, yeah, go ahead. No, if there are any questions or remarks related to the encryption envelope, we can, I think, talk about it right now. Yeah, sure. So no, one question. So you're going to use the SIGPA library for did it come and the SIGPA library for did it here? Both the libraries or did it here? Are you going to be handling that with your own version or different I thought the encryption envelope library is supporting did peer resolving on a native level? I did not know that there are two different libraries for it, but I might be wrong on this one. Well, you mean the SIGPA library? Yeah, this compitons, I'm going to post the link. Did come to Python, right? Yeah, yeah, because I implement a mediator using did come Python from SIGPA and great. Yeah, you're right. But did it be a library in Python? It's a different library. So I think you can use whatever you want for the PR, but the examples on demo are using the same, right? Okay, that's that's very good to know. Yeah, it wasn't very clear to me. Yeah, so in that case, I think we will also be using the did peer libraries from SIGPA, because currently the way it is implemented in ACAPI is. Yeah, it's there is a special treatment for peer that's or you don't even really exchange peer that's on ACAPI at this point, you just exchange a key recipient key and an endpoint and from the recipient key appeared it is generated on the site that is actually receiving the message, the out of band message at this point. So we will be using these libraries from SIGPA to resolve the period. Yeah, that's really great. Just for others to tie it kind of together. If we go to which I should have had, let me just pull up the hack MD for AIP. Yeah, so the this is kind of why AIP three is important, because this instead of just saying, well, why don't you know, why don't all agents just use did com v two? There's a lot of nuance to that, which kind of Hakan is exposing, you know, with with deciding which libraries to use and how each agent supports specific did methods, specifically did peer is is being put forward as kind of this base did method that that we need to support. And did com v two doesn't necessarily, you know, levy that on an agent, right? You can use any did method. So that's why having this interop profile is important in order to help people to kind of know this, the kind of most basic path towards being able to interrupt, including with did com did com v two. So that's really good info. That's a good update. And the SIPA libraries, they keep showing up everywhere, essentially, because they've they're kind of the most used at this point, especially when within the areas community, but Veramo, I think also has leveraged a bunch of the SIPA stuff. And if anybody else knows other other usages, but yeah, so so I think it sounds like a good decision. Yeah, I had a quick question. What's the time line for the asker implementation? I was curious to see like another did come implementation that's not from SIPA? Or like, is that do you think that's gonna happen since we're gonna like to use SIPA? I don't think we will have an ask implementation for encryption envelope in the next three to six, well, at least three months. Let's put it that way. So there is a pull request that has been created by Andrew Whitehead on the Acapai repository, I will find it and send the link. And yeah, somebody would have to continue on that work to have a full feature. Yeah, did conv2 support and the encryption envelope side? Yeah, I guess like what I was curious about, like, it wasn't just the encryption envelope, because the conv2 also has like a couple of like core protocols. And right now, as, as you guys were speaking, like it came to me that we only think of the conv2 as an encryption envelope. But I think we should also think about having like a core set of protocols that I think like, stay like the big time library should come with like the routing protocols, sometimes becomes an issue, like how do you display the keys is like your eyes, like the ID, that kind of things. But yeah, excited. It's close. Yeah, that sounds. Yeah, it will need to be implemented, I think at this point, still. So if there are no more discussions for the encryption envelope, we do have a bit of update coming from the protocols as well, not the protocols that Alex, you were mentioning, but rather the protocols related to credential exchange and connection establishment. And Judith is working right now on the out of band V2 implementation on areas cloud agent Python. So that we will be able to have, we will be able to have a flag for the conv2 for the connection. So the areas can differentiate between whether a connection is based on the conv1 or v2 and from that point on to use the protocols accordingly, including the issue credential v3 and present proof v3. Yeah, very good. Just for those who might be newer for did come, did come v1 and did come v2 are significantly and enough different that it's, yeah, there's a wide enough gap between them that did come v1 agent can't really do can't communicate with a did come v2 agent. And so, you know, occupy has support for did did come v1s. And so Hakan and Judith have done a ton of work to try to adapt what already exists in occupy so that it can do both distinguish between did come v1 and v2 and then act appropriately. So that's great. Anything else on that? Sorry, Hakan, if I was No, no, you wrapped up really well. And I do not have any other updates from the occupy side. Great. Yeah, one question to Hakan. You mentioned the connection, like protocol, are you gonna be developing a connection protocol, or maybe adapting the exchange, the exchange protocols on that? Yeah, not using any protocol at all. So we will adapt the did exchange, I don't know if it will be the on the time of Judith's master thesis, depending on how far she can come. But it is planned to have did exchange for did come v2, like in terms of message structure. However, right now, the main focus is really out of band protocol. So that, yeah, well, one party can actually broadcast an unencrypted message that can be fetched by a somebody who wants to connect to and then start the protocol exchange, basically. Yeah, great. Yeah, okay. And also maybe one more topic like your talk, you guys were talking about the test harness. I think also it's going to be very important. And one part that we will be making a lot of thought about and also probably a bit of development work is the extending the area's test agents has tarnished. Yeah, very good. Okay, great. If anybody wants to join that work, you're more than welcome. Otherwise, we would come up with something and then discuss with you guys. Yeah, good. Well, yeah, we plan, I keep saying this, you know, I'm probably three weeks behind where where I wanted to be. But we plan to do some work related to areas agent test harness to essentially make that make the did come v2 related tests and really AIP three related tests. Just kind of a richer set there so that that someone can specify. Because currently, with the areas agent test harness, let me see if I can. Yeah, so so this would be areas agent test harness, a particular feature it's tagged with what has tags so that you can essentially run these feature sets based on what it is that you're trying to show interrupt for. And so you can see there are some tests that are tagged with did come v2. And then of course, this one's also wacky related and issue credential v three related. And so we would want to also have on this something like AIP 3.0. And then we had also talked about, let's see, last week, we talked about having maybe a simpler tag than even AIP 3.0, because AIP 3.0 kind of is basically saying that you can do credential exchange since Aries mission seems to be mostly bent towards, you know, the presentation and exchange of credentials. And so can we have essentially a tag that's something like, yeah, did Tom v2, but even something like did Tom v2 or messaging or something, maybe? Yeah, or messaging or yes, some way of basically saying, I can do AIP 3.0, but without credentials, because maybe I don't care about being able to exchange credentials, I just want to be able to be able to do safe, secure communications with a did, and I'm willing to use did peer and things like that. So that seemed to that seemed to be a nice concession that we told the Aries working group on Wednesday, they meet on Wednesdays. And that's always helpful because Sam's in there. And we basically told him that idea. And when, you know, when we say, Oh, well, Aries is mostly focused on, you know, verifiable credentials, you know, Sam says, Well, you know, we make this what we want to make it and, you know, Aries kind of has expanded over time to be more of like open source SSI related things. But anyways, I think I think that's kind of a good concession to basically have AIP 3.0 include verifiable credentials, and then still be able to do some kind of, you know, base did come interop for Aries. Yeah, sounds good. Good. Okay. So then Aries framework JavaScript, I'm just going to look real quick and see if I can pull up the pull request that aerial head. Yeah, here we go. Let me bring that up. Yeah, so let's see. Initial implementation of Aries ask our module for AFJ, including interfaces for storage and wallet. So that's only kind of tangentially related to this stuff, because we're talking about ask our but I thought that was worth being aware of. I'll just throw that under here. And ah, but the bigger news, which I should have let off with this. The pull request for did com v2 support is basically getting delayed. So Sikpa was attending the AFJ meeting last week, and they basically said, we don't have any more cycles to continue to work on this pull request. Essentially, the Sikpa had submitted the their pull request for did come v2 in AFJ, while AFJ was in this big transition between zero dot two and zero dot three, zero dot three being much more modular version that's, there's this movement of indie pendants, right? So moving away from having Aries agents focused on indie ledger and being more ledger agnostic, and then also just being modular in general to yeah, for plugins and things like that. And so that pull request has been going through this long process, you can see November 10th. And somewhere else on here is a date, I'm sure. But yeah, the point is, it's ongoing. And it's not complete. And Sikpa is basically saying they're, they've run out of cycles to work on it. So any thoughts on that? Anybody? Yeah, it's it's hard to imagine. Most of the most of the people who would pick up that work are or the AFJ, you know, related people like animal or aerial has done a ton of work, I think with the time v2. So I would imagine he's interested in it. Route ID certainly is interested in seeing that work move forward. But at the same time, we aren't using AFJ right now. So Yeah, the thing I think with this PR is that anyone new to the library, and to that need to decide we want to start digging into this PR that is, you say, like, 3048 files, or you start a new one. Yeah, if you're new, don't note all the details on that, because also, you this PR is way ahead of the main branch. So you not only need to understand what is in there, but you need to add up to the to the latest call. So probably I think it's going to be better to start from scratch, probably. But I don't know. That's it. That's a feeling. Yeah. Any other any other thoughts? Yeah, I mean, certainly we want to see if AFJ did come v2, you know, as soon as possible. We were hoping that this work was would be completed. I think animal and and and sick will have gone back and forth on it. And I truly believe everyone's, you know, making the best effort to kind of make it happen. But it's really hard when a framework is experiencing a massive shift. And then this did come v2 pull requests. It's just so big, that then kind of going through and refactoring it so that it's it's ready for for AFJ 0.3. I mean, yeah, maybe Roto's right that maybe just use the pull request as a as a guide of or for lessons learned and then maybe do something new. But it's a little bit sad to see because yeah, it's like if you can just get through then, well, we've got it now in AFJ so but it's not there. So okay, and then I don't see. Oh, yeah, I do see Bruce. We talked about the Pico's work. Is there anything Bruce that you want to give us an update? Yes, our students have just returned from their end of year break. And we'll have the first meeting in the new year tomorrow. Good. Early and they are using the sick libraries for encryption. That's what they're working on right now. Great. I saw that it's a new working group from IoT devices that may be related to the Pico. I don't know if you're aware Bruce on that. I think it's going to be it's a new working group that I think they're trying to to raise people to to show them that. Yes, thanks. Thanks, Roto. That's the one sponsored by Diff. Yeah, I think it is right. I've been a member of that group for a few years. It used to be a sovereign foundation. Let me find it. Yes. If there's another one, I would like to know about it. Yes. I saw the message last week. So let me I'm gonna try to find it and write that. Thank you. Yes, Pico's are work very well with IoT. And yeah, having IoT devices, either be agents or be closely associated with agents is is very powerful. So yeah, maybe while Roto's looking that up, I think the by fold group, the areas by fold group has I can't remember if they've already had their summit, but if anybody knows kind of what their plans are with kind of a more modular component breakdown of their work. I haven't been keeping up on it, but I've heard about it and they just for anybody who doesn't know they use AFJ as their as their agent framework. And so yeah, we were hoping again that if did come V2 was supported in AFJ, then you know, areas by fold would have it and now you have an identity wallet that's become V2 and you know, we could do all kinds of nice collaborations. All right. There's also one more framework that I saw by the end of last year. It is the native framework for iOS Swift. Does anyone know anybody who was working there, but I think it's coming from South Korea, if I remember correctly. Right. Yes. Yes. I attended the presentation from I think he calls himself Conan or I could be wrong about that, but you know, he says his name is difficult in English and even in Korean. So he calls himself Conan and I do see updates, but I don't think I asked him about did Tom V2 support and I think he said that that was not on his radar. He's essentially developing that framework. Solo himself and so he's it's taking quite a while for him to just get kind of through the AAP 1.0. I think. And maybe 2.0 work, but yeah, I recall him saying that did Tom V2 wasn't on his shortlist. I see. But I'll throw this one here just we could keep up with it in case. I did see a pull request from him recently, but I don't think it was for did Tom V2. All right. Good. Okay, so yeah, Aries agent test harness we kind of already talked about, but just to remind everybody that yeah, we had kind of come up with this idea for a new tag in Aries agent test harness. It would essentially be two new ones. There would be the AIP 3.0 tag as we define that. And then something simpler. That's not not credential focused. And yeah, maybe we call it something like just did Tom V2 peer and in which case, you know, that's telling people, yeah, you need to support the peer did method. But yeah, so I think that that is a great idea. It seems like the Aries working group folks think it's a great idea. And, you know, I'd like to continue to report back more on this as I get into it. But like I said, I thought I was going to be starting about three weeks ago and I haven't started yet. So hopefully this week. Anything else we want to say about Aries agent test harness or ideas about the about, you know, how these features are put together and tagged. Okay. And then, yeah, AIP 3.0. I'd like to see this move forward. Faster. If I'm honest, I'd like to actually see AIPs. Iterated on more often within Aries. It seems like they're, you know, it's maybe like a year long process, but I don't, I don't see, you know, a reason for it to be right. If an agent supports one and two and then three comes out and let's say they don't even, you know, Want to implement three. I don't want to implement three. I don't want to implement three. I don't want to implement three. I don't want to implement three or just, you know, have, don't have time or, you know, whatever it is. And even an AIP four could come out. And to me, that seems okay. That's the reason we have versions. So anyways, I'd like to push this process forward. More. So any thoughts on, you know, accelerating AIP 3.0 or things that, that we think we need there. One common lens is that. I think last, last week when Daniel present this grand unified theory. Yes. Yeah. Trust, I think they call it that way. They mentioned. To use. Did it carry as a kind of replacement of did it peer? Yes. As a, as a goal to have that. I think some current grab that and say, okay, this is a good timing to put that on AIP three. Right. Okay. And that was last week. Yeah. Sure. That adding that on. AIP three is a good timing right now because this is nothing ready and it's more complex and need to be developed. So this is something that probably I wouldn't put in the IP. 3.0, maybe 3.1 or as a, or optional, something like that, but not as a main component of AIP three because that's what we're going to do. We'll delay that. Yeah, I'm so glad that you mentioned that. That kind of that. I think that is what triggered my. Intuition that. Yeah, these things need to be much more fluid. You know, it's, it's, I get it that because Aries has been used in production that, that changes are not, you know, not so simple. And, you know, and we've seen with the work that Hakan and Judith, they're doing with, with Akapai, for instance, you know, you have to do some adaption. You can't just throw did come V2 implementation in there and, and, you know, forget about the legacy, but at the same time, this, this gut alliance, the grand unified theory, maybe we should. This grand unified theory is something that I don't think anybody should be afraid of. You know, we should applaud that Daniel Hardman is trying to get these communities, you know, the Kerry community, the Aries community, the diff community, trust over IP community to continue to converge. And so I see AIP 3.0 really as a stepping stone because we've asked Daniel Hardman directly, you know, there's been mentions of did come V3. And, and again, some people get nervous about that, right? Like, oh, you know, everyone hasn't accepted did come V2 yet. And so we can't start talking about did come V3. And I just don't agree with that as a technologist. Oh, yeah. Thanks for providing the link. Yeah, I won't go through all this, but I'll, I guess, yeah, Roto posted the link. I'll put it in the notes here so that anyone can look at the, but the point is, I think, yeah, there's no reason to be scared about looking to the future and figuring out how we're all going to converge. And so I see our working group here as, you know, trying to accelerate did come V2 and then also AIP 3.0. And then, you know, we want to accelerate, accelerate the grand unified theory, I think, right? You know, the more that these communities come together on these standards and find ways to iterate faster so that they can converge. That seems like a good thing to me. So I essentially would think that something like this would be like AIP 4, really, it's different enough to me that if you're going to instead of using peer dids, you know, using carry dids, which the carry did method is literally under construction right now. It's trying to be accelerated so that maybe it is mentioned in AIP 3.0, but, you know, we've seen how, you know, it takes time for libraries and all these kinds of things. So yeah, carry and some form of did come that is kind of beyond originally Daniel had said that did come V3 is just did come V2, you know, maybe with some small changes, but accepted by the IETF. And as part of that acceptance, they need to have a test harness, for instance. And so, you know, the work that we're going to do with ARIES agent test harness for did come V2 essentially makes it so that did come V3 can be that could, you know, more quickly reach IETF standard status. So thoughts on that? Yeah. Yeah, so just just wrote it on the chat. Like when I hear did come V3, I start to get a bit anxious because of the change that happens from V1 to V2. Yeah. Yeah. I mean, I don't have a lot of contact with the, yeah, but Sam Curran or the others that are like working on the did come V3, but maybe you have some insider info about like, is it what would be the change? Like, are they also planning to change the message structure or is it just standardization through IETF and maybe, yeah, changing a bit from the encryption envelope side of things? I think that they're going to change the elliptic key exchange protocols. So right now they can be who uses ECDH1PU and I think they don't want it to do that anymore. So like they're going to remove Authencrypt. That's kind of like they were saying that it's kind of redundant to add authentication on the ADs. So, yeah, that's kind of like one of the major changes as far as like, yeah, it says in the presentation kind of like remove Authencrypt if you look down somewhere. But yeah, that's all I recall. Okay. Yeah, but I think there is nothing already said or agreed on did come free.dota. Oh yeah, it doesn't even exist. Yeah, it doesn't even exist. There wasn't a meeting talking about that. I think they're just brainstorming ideas that those topics will be covered on the did come working group on the first Monday of each month. So there's nothing decided yet. So I think they're just ideas and probably they're going to go that way, but there's just ideas. Yeah, and if you're more of a visual person, although I still haven't, you know, truly digested this diagram. This is a little more detailed, but this is what, you know, they're hoping to converge towards, which is this trust spanning layer, this trust spanning protocol that kind of allows for flexibility at in these layers, similar to how like a network, the network stack protocols converge at IP. They're saying that they'd like to be able to use did come and carry in the Aries ecosystem, you know, RFCs and things like that to to converge on a trust spanning layer that allows for this grand unified adoption of SSI. And so that's going to be hard and but but, you know, could be incredibly valuable. And yeah, how kind of what you're saying about, you know, it did come v3, you know, making you nervous. I mean, I do understand that from an implementer's point of view, but I do think that it's just it's the stepping stone, right? Like, you know, going from did come v1 to v2 is useful. And I think that going from did come v2 to whatever did come v3 ends up being it will be a useful step. But not without quite a bit of work. Yeah, great. But it's certainly not something that we should get hung up on, you know, in terms of because it doesn't even exist, right? It's just an idea. And so we can also shape that idea. So I think it's important for us to acknowledge it and help shape it just like we're doing with a IP 3.0. Yeah, when was the working group meetings again? Let's see. Trust over IP is doing their trust spanning meeting. They just added it, but I can't remember if it's one meeting of like the they have maybe a weekly meeting and then one of those meetings per month is focused on trust spanning or I'm not sure yet. I haven't attended a specific trust spanning meeting, but that even that won't. I don't think that they're going to necessarily develop did come v3 in that meeting. Trust over IP kind of, you know, they exist more at like the higher like architecture level. So I haven't heard of a meeting that did come v3 would be discussed at. Yeah, but I think if you want to talk about this country, that should be the did come working group meeting. That is hell. Every first month of the month, every Monday of the month. And he said, oh, let me see the date. 2 p.m. Eastern Eastern time. No. 3 p.m. Eastern time, right? Yeah, it's for Europe. It's too good. It's too essential for me. So at least 2 p.m. Center. Okay. I'll send I'll send the link. Yeah, it would be great. Thank you. Thank you both. Good stuff. So kind of we'll see we have 10 minutes. The biggest focus for us is getting, I think a IP 3.0. And, and, and, you know, related tests to that pushed for forward. Hey lens, quick question. What would it look like to have a IP 3.0 completed? Yeah, that's a great question. Because like, in my opinion, like, right, like having walkie packs and then the default protocol that they come into spec implements, that's kind of like it for from an area's perspective. Because like it's related to issue credentials and whatnot. And then did come to is the encryption development. It defines some protocols so like it makes sense to implement those to make it work, right? Otherwise, you don't have a mediator like you're not going to issue credential like exchange credentials like most most likely. Yeah, that's a great question. I did wasn't involved in the, the a IP 1.0 and 2.0 definitions. So, but what seems to be happening is this document is changing much less lately. So I feel like that means, you know, we're converging. So I think that on the Wednesday meeting, we should ask them like what else do we need to do to make this real? And then, you know, do it, whatever, whatever it takes whatever documentation needs to be done. Okay, see, that makes sense. Yeah, because I mean, in the end they are P3.0. Yeah, I don't know if they actually hold a vote or, you know, how that works. I mean, Sam has kind of repeatedly said that, you know, as a community, we define these things and, you know, we, we, we just champion them. So hopefully, hopefully we can just keep it at the forefront of their minds so that it can move through. Because yeah, I would like to see this just, you know, let's, let's settle on something. And if it's not good enough, you know, then you make a 3.1 and a 3.2 and, you know, so on and so forth. Let's iterate. Yeah, exactly, exactly. What you said, correct. That's kind of like what I was, what I was wondering is like, do you want to iterate fast? So like, let's get some more feedback from other people as well. Yeah. Yeah. Because I think like as long as like two agents can exchange credentials, like with the computer, I think that should be like the minimum requirement. So yeah. Yeah. Okay. So look, can we do a quick pass on this document and that way we can come on Wednesday and maybe say, Hey, you know, the Aries did come V2 working group says we like this. Let's let's move forward. How's that sound? So, so this base requirement, any, any, any objections to this base requirement, essentially, obviously you need to follow the did come V2 spec. And it gives you these, these, the, the, the protocols that are defined in there, trust ping out of band, discover feature routing and, and talks about the envelope routing profiles. I've stuck this link in here. And then yeah, this one as well. And then these features, revocation, notification, wacky pecs, wacky pecs present proof and using peer dids. Any objections or additions that people want to see? So maybe one question that I would like to ask that around is revocation notification. So revocation is a topic that is first of all optional and second of all, we were talking about like having did come we two light versions, let's say, or like for messaging and all that stuff. So this would not have been a place for having a basic messaging functionality with this convene to basically. And my question would be like, whether this belongs to the base requirements for a IP 3.0 in that case. So, yeah, I think that that is essentially the question that we brought back to them that, you know, several, several projects did come be to related projects don't care about verifiable credentials. They just care about did come be to and having a did method that, you know, is well established as kind of the standard within areas. So I think the pushback from that is I essentially went to the Aries, you know, page from page to remind myself what their mission is, and it literally spells out that, you know, their mission is, you know, creating agents that that can pass verifiable credentials. And so revocation, I would assume is is an important part of that for them. And so when if we say, hey, we support this, I don't think that's precluding us from as a group defining our own kind of base set, where maybe we say, you know, hey, if you want to just be able to do some messaging, then, you know, did come v2 and peer did is the is the way to go and, you know, probably use the sick the libraries right. So what are people's thoughts on that? I feel like if we establish that within the Aries agent test harness. So so a IP three, you know, on that list, that will have more on it than what we're saying we really care about. But if we start marking features with with, you know, some tag that says maybe did come v2 peer. Maybe that's our, our, you know, simpler form that you're mentioning, how can thoughts. I guess I guess what I'm saying is that we're conceding very probable credential related things as as base basic for Aries interop. But then I feel like we can have something else that that maybe isn't an official a IP three but you know that the community could know, oh, you know, if I don't want to do variable credentials, you know, there's at least you know, these these tests within the Aries agent test harness that I can, I can test to see how interoperable I am without implementing the variable credential portions. I see. So one question I had so this already has the walkie did come interrupt profile. Right. Right. And that's exactly like credential related. Yes. So how is this kind of slightly different? It's just a, if you go to issue, could I show three that all on percent proof? Three that all is walkie did it come. It's just a link to that. Oh, here we're talking about that. Yeah. Yeah. Here. Yeah. Not this one. Like the underlying protocols are all the same. Yeah. Should be the same. Maybe wrong. Broken, but if you go to the last link. This one. Walkie did come with your link. Right. Yeah. Yeah, let's see here. There we go. Okay. So what were we saying about this? Sorry. Yeah, I was asking like, how can we like, how is this a IP three different from walkie did come? Cause like they're both credential focused, I guess. And that's kind of like what those are the words that I kind of triggered this in my mind. Yeah. Yeah, walkie did it come. Oh, it's kind of. Yeah, you're right. Kind of the same. Does it, but does it spell out that you should be using the AIP three. Yeah. Yeah. Yeah. So yeah, that would be my understanding as well. This specification is from diff. And it does not talk much. I mean, I saw a couple of RFCs, but it does not talk about areas RFCs in general. Whereas for my understanding, the AIP 3.0 is really areas specific. And referring to the RFCs, that should be a part of it or that should be modified so that they are, this can be too compatible. But I agree with you. Like it's there. I don't see much difference between them in terms of what they're supposed to do. Well, I think this diff, they implement the areas RFCs like underlying this. Right. There is a lot of overlap and, and yes, the areas RFCs, I mean the people who built this stuff are, are, or yeah, it's a, if you look at the, if you look at the, yeah, it's basically the present proof. Yeah. Like in the, in the abstract, it says that he used like the present proof from areas and the presentation exchange from a diff. Yeah. So like the credential manifest, the credential fulfillment, I think those are not in areas yet. And I think that diff is adding that to the areas, RFCs. Yeah. So I, but I feel like what we're saying is a good thing, right? That, I mean, the only thing that I can think of that's, that's different is that we are specifying kind of what are the base did methods that, that you need to support in order to be AIP three. But I agree that essentially wacky did come is saying all of these things. And then we're adding this, right? And maybe we'll add a few other did methods, but peer did for sure. Am I, am I thinking of that right? Yeah. So, so it is a small addition, but I feel like a very important addition, you know, based on what we saw in JFF, Alex. Yeah. Yeah. You know, this addition is, would you agree, Alex, if, if, if you had been doing the JFF challenge and you had this list. And let's say maybe you guys, you know, decided to do a simpler form of wacky did come, but if you had this list and everybody agreed ahead of time that peer did would be used that would have saved you guys some time. Yeah, yeah, definitely. Like if we would have had like all of this, we had to do it like ourselves, like we had to like meet and like figure out, okay, what libraries we want to use, then like what protocol messages we want to send. So like if there was like already like preset, like options that we could have picked between that would have been like much easier and would have been like less time consuming. Yeah. You have to figure out for sure. Yeah. Okay, I just realized we're out of time. Any, any last words. Okay, great meeting. We'll, we'll, you know, we'll, we'll pitch it at the, the Wednesday meeting and yeah, just we'll do, we'll meet again in a week. That's great to see everybody and appreciate you. Thank you. Thank you. Bye. Thank you. Bye. Bye.