 Good morning Lance. Good day Bruce. How are you? Good. How are you? Good. Good to see you. Remind me what time zone you're in. I am on the east coast of the US. Okay. How about you? Mountain. Okay. Are you in Utah? Yes. Okay. Gotcha. I'm in Maryland. And close to DC. It might just be us. I know Roto. I think he's traveling today. So, yeah, we might have a smaller group shorter meeting. I know Hakan also had, I think said that he was starting a new position that he could tell us about in February, but we haven't heard from him since the switch. So he's probably very busy. Oh, here's Roto. Good morning. Roto, how are you? I didn't know if you were traveling. No, no, not on Wednesday. Okay. Hi Lance, hi Bruce. How was the weekend? Good. Good. Great. Summer here was hot. Oh, so nice. It was fairly mild here. Have you guys been getting snow, Bruce, or no? Yeah, we got a skiff last night. Okay. Good. All right, let me share my screen. Where are you located, Roto? I'm in Lisbon, Argentina. It's La Plata, Argentina. Close to Buenos Aires. Oh, nice. Okay. So welcome everyone to the January 30th, 2023. Aries Didcom working group. Please be aware of the antitrust policy for hyperledger, as well as the hyperledger code of conduct. And this meeting is weekly and our focus is on accelerating the momentum of Didcom v2 within Aries. Let me share the meeting page for today. If you'd like, please add yourself to the attendees list. And I mostly copied things from last week. So catching up on AIP3, Aries Agent Test Harness updates. And if we want to talk about gut alliance, but yeah, we could add anything we want to the schedule for today. So just let me know. And we'll add it. Okay. I just see Bruce and Roto. So the usuals. But yeah, let's do updates. Any updates from the attendees or related to status updates for projects? Let's see. Oh, maybe the only update is maybe related to that I've been working with Kerri working group on this Kerri light that is an alternative to the PRDID. So I need to still make some refinements on the proposal. I'm going to meet today with Phil who's one of the Kerri guys who's working on did Kerri. And after that, I maybe show that to the Aries community in general. Great. How is that going? I guess, do you have any additional thoughts since you presented it to the Kerri group? Or you think you will after you talk to Phil? No, I think it's fine. It's just doing the same as did PR is working the algo 2. So the algo 2 allows you to put encryption key and to put service endpoint on the document and be resolved by looking at the PRDID. In that case, it's going to be kind of similar but you're going to have a small DID method with the Kerri parameter on the DID method that the Kerri parameter is going to contain the rest of the message that needs to be resolved to produce a few documents. That is going to be you can verify everything just by looking at that for the DID, the DID plus the parameter. Now, are we, I guess, what is that did document? Yeah, how should I ask this? How does the did document differ from like the PRID did document? Well, in the document, something that you compose based on the information that you have. So it should be looked like the same. You can produce the DID document. The thing is that you should be able to recover the information that you want from the DID document. In that case, for a basic PR to PR communication, you need two things. One is the public encryption key and the other one is the service endpoint. So if you can recover those two elements, you are done. You are just doing the same PRID idea. That's the goal. Okay. Yeah, very good. Great. All right. Bruce, do you have any updates you want to give? Unfortunately, no. The student meeting is only bi-weekly and so it's tomorrow. Okay. Yeah, fair enough. Okay, let's see. Just going through real quick, I'm looking to see if any of these things remind me of updates. Certainly the, well, so in the Aries Framework JavaScript meeting, they showed OIDC for VC. So OpenID Connect for VC as just a client receiving a credential. What they called a pre-authorized, which I think is a simpler thread for OIDC, yeah, OIDC for VC. And similar to kind of what they talked about at IOW, you could essentially, of course, receive a credential over OIDC for VC and then present it later via DidCom or something else. So just AFJ growing its ability to yeah, use multiple protocols for variable credentials and messaging and, well, for, yeah, connections, I guess, and transfers. So anyways, I thought that was a nice presentation. There's no movement that I know of on the PRs that have kind of stalled from Sikpa. I mean, it's something that RootsID would love to work on, but just no bandwidth for it. And yeah, I haven't heard anybody step up and say they're going to do it. So that remains on hold, which is sad. And okay, so then in terms of getting into it. Oh, sorry, go ahead. Oh, hey guys, sorry. Can you guys hear me? Yeah, I can hear you now. Hi guys, sorry for joining up late. I've been having like technical difficulties with my Zoom, my browsers had to restart, reinstall a bunch of things. I don't know why it's psyching up this morning. Did I miss anything? Sorry. You missed everything. No, no, no, no, it's good. Roto was just saying that he's going to meet with Phil today, talking about carry, the did method, carry light specifically. And so we're looking forward to hearing about that. And that was pretty much it. We were just going through status updates. I was saying that they did the OIDC for VC the demo in the Aries Framework JavaScript meeting. I don't know, Alex, do you have any updates in terms of maybe Brian? Yeah, I mean, like right now I'm working on the deep peer for the Veramo framework. So like I'm pretty much replacing like I'm copying the Brian's deep peers and trying to like format it as a plugin pretty much. Okay. So for the Veramo PR, pretty much like I opened the issue and then I'm trying to tell them myself. Right. Okay. So you're using Brian's Avery tech did peer in full, adapting it as a plugin for Veramo. Yeah. Okay. Cool. Yeah. Cause I was looking also like, there's a couple deep peers actually like in JavaScript, SIGPA has one, like the resolver and also like a J has like their own deep peer resolvers. And I noticed that the SIGPA guys opened an issue on the deep peer of the AFJ guys because the formatting like the multibase, it was like WAF and it was like the same issue that I recall that Brian and I were having. So, you know, like the formatting like the keys, I thought that was like, while I was looking into it. But yeah. I can link the, I can see because I saw that how come open an issue. I think. Okay. Good. Let me, I'm just going to repost our meeting page today in case you don't have it. Yeah. I'll put it up in there. Great. Good. All right. Good update. Okay. So then in turn, okay. So then kind of updates, but in taking us into our discussion topics, AIP three. So we did attend that Wednesday meeting and talked about, hey, how does, how do we move forward with AIP three? My brain is trying to remember, but I'm also going to put the page here for everybody to see. So that was the 25th meeting. So I'd need to go through and note the RFCs that are included in the V2 spec on the HackMD. HackMD is here. So, do you guys think I should put that just in the notes portion here? And so we say which, which ones are included, but then the corresponding RFCs. So, you know, like, I guess there's an RFC for trust ping one. I should list that maybe underneath here in the notes section. Does that sound good to everybody? Okay. Yep. So I'll put those in there. But also, I guess, the list of possible things to be listed in AIP three is growing significantly, which I kind of, I don't think I pushed back, but, you know, I kind of said, we need to add these extra things, you know, because I want to see AIP three move forward with DidCom V2, obviously. But yeah, I guess there's a bunch of more things. And maybe that's a good thing because then maybe you have more interest from the rest of the community in seeing AIP three move forward. I don't know. Any thoughts on this list? We have a non-cred W3C formatted stuff, BBES plus, did web, UX OCA supplements, action menu, push notifications, and Bluetooth NFC was mentioned. I guess like I'm trying to figure out what's the purpose of AIP three? The purpose is for Aries agents to have a target, essentially, of, you know, some bundle of, you know, specs, implementations, things that would make it so that the Aries agents have taken a step forward and but remain interoperable. So they don't just diverge right into all the different paths that, you know, maybe one supports W3C format, credentials, the other one supports the non-creds and now they can't understand each other's verifiable credentials, right? So there needs to be this kind of foundational interop profile that everyone can target so that we're moving or the community is moving forward but they can interoperate. Got it. So this is only like for agents, like Aries Wallace, sorry. Well, Aries specific, like for that Aries specific community, right? Yeah, I mean, it's my belief that Aries has enough gravity within the industry that if this is, you know, if AIP three exists, then, you know, others that are outside the Aries community will be interested in targeting AIP three as well. But I guess you've got to gain momentum for that within Aries first, right? So if nobody in Aries wants AIP three as defined, then yeah, that's the opposite of what we want to see. So definitely. I guess, yeah, because like one of my big questions, I guess was like, I don't see like other people rushing in like adopting VidCon V2. And I was wondering why is there a reason like, are they happy with VidCon V1? Do they, like, I was trying to figure out like what's their, like what's other people's incentives to adopt AIP three, like animal, like right, like Sam's like their wallet. And I guess, like, it sounded like they have a lot of like legacy stuff that they need to also like think about when like migrating over. And that's something that like, I guess, like, we don't really think much because we don't have like any productions app. And like all that, like we don't have like anything like deployed and like, we don't have to worry about like migrating and like, luckily, all that, all that like stuff. So yeah, like, I think for them to make like the conversion over to AIP three, we need to like sell it like, I don't know if it's selling it. But it sounds to me that there's like a lot of hurdles for them to like, migrate over and stuff like that. So I think that this, the closer we are to whatever they're doing, the most likely we will have like migration and adoption from the current like Aries community. So whatever like makes them adopted, I'm all for it. I guess that's my, my perspective on all this stuff. Like, of course, I don't think we'll be able to like implement all this stuff ourselves. So yeah. Yeah, fair. Other thoughts? Well, I think that that's the goal of this group, try to make the Aries and Aries frameworks. Adapting this can be true, right? I think that there's a the whole community agreed that it can be true. It's a nice path to go. And of course, that there's no immediate incentives. But once the frameworks are ready to have it, it can be true. Everybody using the frameworks gonna shunt, can shunt you, it can be true more easily, right? Yeah. It certainly is proven, you know, really good comments, I think, observations. It is interesting to look at it from the standpoint of, okay, I'm Akapai, I have DidCom v1. DidCom v2 is some kind of improvement, but is it actually changing like their lives? You know, other than being very difficult for them to adapt? I mean, it sounds like quite a bit of work has already been put into it. And, you know, it's not done. So it's, it's this interesting, is it just a nice to have for the group? Like what is, that that would probably be something good that we can provide is a succinct message of why DidCom v1, why migrate? Other than pierce the new, new thing, and there's some simplicity, but, you know, saying that it's DidCom v2 is simpler, maybe is a tough selling point when it's not simpler for them in terms of implementation. Unfortunately, like the most simple thing for them is just like do nothing and like keep that like it's tough, right? Yes. Yeah. But it's a good point to throw to the user, DidCom user group, where Daniel, Sam are there to give me the, where are the selling points? DidCom v1, yeah. Right. Why DidCom v1 is, where are the gaps on DidCom v1 that going to be nice to, to move ahead? Yeah. Okay. Well, that would be, that would be a good thing to ask, right, in the user group. Now, no user group today, right, Rodo? No, not today. Not today, because it's the fifth. So the next one that is, I think, February 6, it's going to be working group. Yeah. So the other, the 13, Monday 13 is going to be the next user group. Yeah. Wait, today is the specification, right? I don't think even that. But today is nothing because it's when we agree that we're going to have Oh, we cancel today? Yeah. First Monday, we're going to be working group, the specification, and then the next three Monday of the month. Yeah. It's user group. If there is a happen to be a fifth Monday, they want to skip it. Oh, God. Oh, yeah. I guess today is the fifth Monday of the month. I didn't even notice that. Okay. All right. Good stuff. Yeah. Important conversation, right? Because I guess everybody here is basically coming from the, you know, oh, I don't have really a legacy that I have to maintain. We all like DidCom v2, even though we know that, you know, there's complexities that even we're trying to wrestle with. So I guess in the spirit of full disclosure, I'm double agent because I implemented part of v1 in the Pico system. It seems like a long time ago now. And but I, but I work closely with Phil Windley, who after, after some discussions that I was not privy to with Sam Curran and Daniel Hardman, when he recruited some students to do some work on the Pico system, he wanted them to do it in DidCom v2. But no one's ever explained to me one way. So I'm a little different, I guess. Yeah. Well, that's good. That's good feedback. So you can try out your arguments on me. Yeah, very good. I'm attending this meeting so that I can support the students. I suggested to the students that they can attend this meeting, but it's too early in the morning for them. Fair. Yeah. Hopefully they can make it to the user group meetings. Yeah, since those are later. Okay. Good. Anything else that we want to say or give feedback for the AIP3? I suppose. Yeah. Any, I mean, any thoughts on this other stuff? Some of it's a little bit outside of our range other than DidWeb? Obviously DidPeer. I guess a question I've had whenever we say like, did the support, do we mean that are these the DIDs for the DidCom or are these the DIDs that can be resolved in the agent? Right? Because like, those are like slightly two different things. Like you can issue credential to a DidPrism without having to have like a DidPrism to the DidCom. Interesting. Yeah. Give me the, give me some more details on that, as I've never really thought about that. No, for me, it's just for the communication. It's just how you establish the communication between two peers and which method are you going to use to establish that connection? What's happened about protocols? It's different stuff. Maybe it's part of the, but I think it's not not in any AIP. So maybe that's a good point also. But when you do like this Wacky DidCom, the issue credential, which method do you support? I don't know if that's clear. I don't know even if that should be on the AIP. So, but good point too, maybe to discuss in the ARI score, I think. Yeah. I guess Lance, what I was talking about, like if you like the subject of a credential, like I can have a DidKey that can be my identifier, but like I establish a connection using a DidPier. So like you issued a credential to a DidKey, but the the connections established via like a DidPier. That's what I meant. So in that case, well, I guess what I, what does, but what's the difference between what you have to support for that? Right. So is it that you can stick any did in, when you issue, you could stick any did, even if you can't resolve it. Okay. But is that, is that practically? What do you mean? So like worthwhile? Like would you issue a, you know, a credential to a Did that you can't resolve? Resolve? Like I don't think so, right? Like you wouldn't because then you can like verify like the keys and that kind of stuff. But I mean, if you like somebody gives you that identifier via like a secure connection, can you assume that identifier is, is legit, quote unquote, right? Because like if you give them your identifier, like after you establish the connection, like, hey, please give me a credential for this key, for this identity, for this did. And then they can issue the data and then they can sign it. The issue should always be able to resolve it. Yeah. And challenge. Okay. I use actually the controller of the DID. Correct. And check that. But yeah, for the communication, you are always be using like private DIDs and ephemeral DID. That's why we use key, did it key, did it peer or did it carry in the future? Yeah. So I guess if we, do we only want to use ephemeral? Because then the web is pretty much the opposite of ephemeral, right? For, I mean, the idea with the ephemeral is, or there are two, two main points. One is being ephemeral because you can rotate it whenever you want. And the thing is that you can, you should be able to resolve it without trying to go to it, maybe to the cloud, to a DNS service or whatever to resolve. Yeah. That's, I think that's gonna be fast because you need to resolve it every time you send a message and you change the DID. Okay. Is there anything else I need to, so what would our message to, let's say in the next ARIES working group meeting, do we feel like we need to bring this up or to clarify so that kind of people are thinking in terms of, oh, did peer for communication or it's not? I think that's clear. What I would like to ask if the AIP should state you should be able to in order, for example, for the, for an issue prevention, do you need to be able to resolve in the DIDs or check the ID? I don't think that should be on the AIP, but would be nice to ask, right? To be sure that you shouldn't be, you don't need to be an in the agent to pass the AIP, right? Okay. I don't know how is that being handled on the ARIES test currently? It's all in the different versions based on the lecture. That's a good question. I know there's DID orb. There certainly is, it stands up in the related infrastructure as well, so I'm sure there are tests using DID-Indy, but yeah, that's a good question. It's a parameter on the, on the configuration, right? With the ID method, do you want to support? Yeah, supported and how do you configure to use DID-Indy or etc? Okay. Yeah, I have not looked at that detail, but I should. Because I'm looking at the AIP too and the way they have it, they have like the base requirements, then they have like different quote-unquote features. They have like the Indy cred, they have the mediate, they have the LD credential, VBS credential. So it's like they have different sub profiles almost. Okay. Yeah, like, because to me like an AIP, it's like a list of RFCs, so we would have to create like an RFC for each DID method that we support, I guess, like in this case. That's interesting. Is that true? I'm just looking, let's see here, pull this in here, so that everybody's looking at the same thing. Okay, so ARIES RFCs, I don't know. Zero, three, zero, two. Zero, three. Zero, three, zero, two. ARIES. Am I, should I not be in features or should I not be here? I send the link in the chat and also be ARIES RFCs slash concepts. Oh, concepts, okay. Oh, yeah, okay, for the interrupt profile. Okay, AP2, and then. Yeah, if you go ahead again. One of my section four here. Oh, base requirements, okay, protocols, agents, did come, mediators, wallets, skull codes, X. They've come in mind types. Use of did key, okay, static peer dids. Okay, and this is what we have listed in AIP3 right now, right? Static peer dids. Okay, so then the question is, what other did methods have to be listed and do we need RFCs for those? It's surprising that. So if you scroll a little bit down, I think there's like an indie one. Oh, sorry. Sorry, yeah, it jumped on me. I thought it would just go down to the next. Oh, is it lower here? Yeah, this, so yeah, scroll, yeah, see how they have like different LD cred and they have different like RFCs for these two, for the BBS credentials, and a little about the indie attachments. Yeah, this kind of stuff. So like, I don't know like how like indie credentials, like, because like those should be like unknown creds now, right? So those should not be indie anymore. Those should be like unknown creds. Those are like ledger agnostics. So how do we want to figure out what's like, is there a default for unknown creds? Or like, right? Like, how do you go about that? Since now they're not indie anymore, right? They are ledger agnostic. Yeah, I have to believe that there's probably, if one doesn't exist, there's gotta be a, let's find the indie one first. Okay, indie attachments. Is there anything in here about unknown creds? What about concepts? No. Oh, it's got to be common, right? I mean, it's worth asking though. Yeah, I think we should definitely bring it up. Like, how do we go about negotiating like unknown creds did method support? Yeah. Now, just going back to his list, right, he has it listed here as indie creds to unknown creds. But yeah, what are they going to do in terms of RFCs and stuff for this? Yeah, there's going to be like a new unknown creds RFC for sure. Okay. And so that's why this is here for you, Alex, is to create an RFC for DidWeb? Yep, yep, yep. Okay, so it can be included? Right, right, because like there is no like DidWeb RFC point of view yet. Oh, and this is interesting. So, but this DidPeer method to RFC is the static DidPeer or not? Or is this one too broad? Is that what we're specifying? I think that was the issue that we're talking about. Like, we wanted to only use like the second method because I got the wrong. So like, like you said, like everybody's on the same page. Because yeah, I think this specification like zero one and two. Oh, it's too broad. Okay. Yeah. Targeted generation methods, several different algorithms. See this, the RFC targets method zero, method one, okay, right. So, so now they're saying basically constrain it further. Okay, so that makes sense. So then this should be updated probably right with notes saying. Yeah, maybe like make like a new RFC and just reference this one is like, hey, out of this RFC, we're just using method two. Well, you said create a new RFC. Yeah, I think, I think that's what Sam was suggesting, right? For PeerDids, was he? Yeah. Okay, right. Yes, you're right. Okay. Yeah, just so we can like only have it for like the second algorithm. Yeah, fair enough. Okay. How do I find this thing here? Feature, static, new, fair enough for now. Okay. All right. Well, that's, you know, that's important, I think. So we're essentially, if we kind of think in terms of the layers for trust over IP, yeah, we're addressing the layer one things in this case. So that's good. And yeah, the legacy Peer stuff, I've heard Sam talk about it, but I'm not super familiar with it. Sounds like some kind of adaption they have to make in order, I guess these weren't like, they don't follow the spec or something like that. So they have to do something. I think maybe those are further indie dids or something. Okay. How do you guys feel about like having like UX in an RFC? Like, I don't know how one go about that. In my mind, like AIPs are like more like back-end technical, like you're trying to negotiate like what keys and stuff support. I don't think that how you go about displaying should be like, is there a standard way of displaying it? Like, is that going to like differentiate like the underlying metadata that's getting signed? Like I don't think so, right? The ability to display credentials. It is an interesting question. I think it's natural for protocol designers and people who care about crypto and stuff like that to say, UX, you know, whatever, but there probably is wisdom in trying to drive agents to support OCA because they're very interested in different translations and different views for credentials. But I've only heard them talk about it. I haven't really, you know, gotten into it too much. It certainly has a bunch of different layers that are defined. And so, yeah, I mean, probably if you're someone who's familiar with this stuff, it feels like this is just as important and just as technical probably. And, you know, well, anyways, it's a good question. I don't know. I probably don't think it's something that we should really, you know, spend any effort on. If they want to define it, they can define it and... Yeah, yeah, yeah. Yeah, I'll go because we don't have like do we have like an OCA, RMC? I was looking for one and like... Yeah, I guess they would have to. So that's why like, right? Because like you're like now like you're requiring agents like and wallets to support specific display format as well. Like... Oh, here we go. Look, they listed it here. Oh, 075. Yeah, I can post that in there. Chat. Yeah. Oh, because it's in features. Yeah. Yeah. I don't know which current that is. Is that Sam or Steven? I just see SW current. So I don't know. Yeah. So... Oh, yeah, I remember this one. Yeah. Because I guess like another thing that I noticed is that the wallet rendering. So like pretty much the same thing, like the same specification, right? Like to display credentials, but like this is like working on a different specification, right? So like I see what Daniel Harmon is saying, how like there's like multiple organizations working on similar standards. And there's a lot of overlap in terms of technology because like it was... Yeah, like it just restarted the group like this year. And like because like I was looking at the spec it was like two years old or whatever they were saying. And yeah, I noticed that I did they're also trying to work on how to uniform like uniformly display credentials and that kind of stuff as well. So yeah. Yeah. This kind of stuff is... It's difficult for someone like me because I want to see everybody, you know, working together. But it seems like everybody wants to have their own implementation or their own protocol. And I mean, I get it if when you do that, you know, you're much smarter about what's there. But cash, yeah, it's frustrating to me. It's going to be a market and then one of them is going to be all going to death, whatever. Yeah, or not because the market takes so long to develop, you know, something else comes along. You know, this is this is why JavaScript was so bad, but so well adopted for so long because it got there very quickly and experienced rapid adoption. So it was working. Correct. Right. Yeah. All right. Any other thoughts? I think I think it was important for sure to be talking about these behind you when you talked about did legacy peer and thought I would throw a sample. Right. So what's the encoding information in there? I guess. So prior to a IP one, when we implemented whatever areas, we called the the string starting a C J D, etc. We called it did. It did not begin with did colon and a method colon. It was just ah, just a string. And and I have many agents that that are using those things as if they were kids. And to bring us into the third millennium, we should be we should treat those with did colon legacy peer. So that's what that is. You were wondering what it was. It's fair. Thank you. Oracle thing from the previous millennium. It's very old stuff. Yeah. Well, good. I'm sure there's yeah. Well, obviously it's called legacy. So there there's there's systems out there that have these things and they need to keep working. So good. Okay. Anything else with a IP three? So I guess if we were to like start like how would we go about it? Let's say like we figured out what we want to implement. Yeah. Magically. And like how would like do we want to I like the idea of like doing test driven development for a p three. I think this like a good place like write test first and then write the code for the test. What do you guys think about that? Just because like right like the way we define test, I feel like is going to pretty much like isn't that supporting a p three means passing test. So yeah. So that's that's one of my goals right now is to begin to contribute to the area's agent test harness a IP three related tests. Maybe I'm not sure that I'll be able to tag them as a IP three yet since that's you know, maybe not defined. And so that would be cheating a bit to tag them as a IP three. But to start. Yeah. Essentially did come v two related tests. There are some already. But you know, some more so that at the very least agents can be scored. But yeah, I agree with you that that defining tests I think are useful. And of course we have customers that that want to be able to show did come v two capability and get a score within the area's agent test harness. So we have incentive not to just do it for an exercise, but also yeah, to produce real scores. Right. And now I guess like the way like since we get to define the test, like we can kind of like, yeah, like see like what exactly I call the foreign or not. So yeah, I guess like if we want to like support Cardano first, we can do that because like, yeah, like for an upgrade stuff like that, I guess. But yeah. Yeah. So I guess that is one interesting thing to consider is which tests would we want to prioritize first. So if right now, there are areas agent present proof establishing connections, which includes a trust ping, I think, and then wacky issuance. I think things like discover features, etc. We would be very interested in right instead of focusing as much on on credentials, kind of getting towards the, I guess, more message based communication based portions of did come the two thoughts on that. I think that would be good for Bruce's use case, for instance. And yeah, we could start showing like the did method things that we've talked about today in terms of did web to peer. Yeah, yeah, definitely. I think also rather than what you call like per call or yeah, trying different bound invitations, like all that kind of stuff. I guess like how about like mediation? Like how do we test mediation? Like we test like if an agent is a mediator, or like, do we test if an agent supports, like I guess it has to support mediation, quote unquote. If it's an offline agent. So how do we, one question I was wondering, how do they go about testing like mediation? I can discuss how they have like the immediate I guess. Yeah, that's a good question. You actually have a role, for example, in the 80 in the test, you have a role. So based on your role, you need to support whatever your role required. So if you are the mediator, you need to support the mediator role. And if you are the the wallet didn't support it. Yeah, I don't know what's the name of that. Mediation role. Yeah, fair enough. Right. So favor Bob, Alice, all these things, there's got to be a mediation role. So I'll look that up as well. Yeah, because like, I guess you're rather can walk you like you need to test both that you can issue and then both that you can hold and like present. Yeah. So, okay. Okay, good. Okay, cool. The first to be happening is like have a bit can be to envelope, like, right. And I guess another question I had, like Sam mentioned that the AAPs are backwards compatible. Like in the last meeting. But is that the case? Like if AAP3 also support AAP2, like, like, because I know you mentioned that at the very end of the meeting, which I was going to like, I thought that the AAPs are breaking changes. No, I don't think he said that. You can support the AAP3 and not support AAP1 or AAP2, right? That was my understanding. A particular agent technology could support more than AAP3. It could also support older versions, but that wasn't required for AAP3. So is AAP2 able to talk to AAP1 or no? I thought so, but I could be wrong. Okay, I guess that's what it meant. Like, right, because like AAP3 cannot talk to AAP2. Right. And I would assume, I don't know if the encryption envelope stuff, for instance, right, might be introduced in AAP2, but not AAP1 in terms of, you know, the differences. So how would, if you were only AAP1, how would you do AAP2 if you don't support those envelopes? Right, right, right. It's kind of like how do you exchange OIDC potential if you don't support OIDC, right? Yeah. So yeah, I don't recall him saying about the backwards compatibility, but maybe what he's saying is if you stack, you know, AAP1, if you could support, I would think, you know, all of them, but you just... Yeah, I guess like I just wanted to make sure that AAP2 is not required to talk to AAP3 and vice versa. That was like my, because like that cannot, like, right, like the only way to talk to AAP2 is like, just for Ducan V1. Right. So V1 supporting... Yeah. See, like, we shouldn't do that. So yeah, I guess like, I don't know, okay, maybe like I just imagine, but I hope that's not the case. Yeah. Yeah, we could ask for clarity for sure, but I'm hopeful that it's not that... Right, right, right. Also, did we want to discuss at the ARIES Working Group, we had discussed what they called new entry points for a protocol. So we had had some discussion in terms of... And this touches back with the JFF stuff that Alex and Brian and others had been doing, where they didn't necessarily probably support what, like proposal and offer. So maybe, yeah. I would request. Just request. And so they were talking about, should that be... So the role is here, issuer, right? And so the concept is, issuer should have to support all of this, but do you create a new role that has a new entry point that says, you know, I am a non-proposal issue or something like that, right? So defining a new role. And then I kind of suggested defining a new... What? Did I suggest protocol maybe? Like a sub protocol? So, yeah. Any thoughts on that? Roles versus sub protocols? It seems to me, I always think in terms of Legos, it seems to me that if something's complex and you don't want to support all of that complexity, you break it into sub parts, right? So you had this funky looking Lego, maybe you need to break it into simpler looking Legos that can make the funky piece, but that's a simple way of looking at it. I guess to me, similar to supporting multiple credentials, that way they added V1.2, V1.3. Can we keep track of that that way? We're using sub versions. Well, the versions in a protocol are like Sembar, so it's incremental. So that cannot be used. What the other problem is that you are trying to use the feature discovery protocol to understand what the other patient can do, can produce. That's why we try to stick with the roles, because roles is part of the protocol query on the feature discovery. So I also ask if you can add another parameter on that protocol, but that's kind of fixed and everybody's understanding. So maybe the fastest way is to create sub roles or different roles inside the protocol to understand if you have this role, you support everything. You have only the role that supports issue credentials for three. So you know, once you receive the other agent support for three, you know that this issue is going to only issue credentials without accepting anything else. Isn't the, I don't know, like to me, it might be like an issue is also always going to be a holder and is also always going to be a verifier. Well, not a whole lot of what? I'm just saying like, yeah, like in terms of like supporting protocols, right? Like, I need to like, even if I'm an issue, like I'm not only supporting the issue of roles, right? Because like, I need to hold. You can have both. Well, no, I'm sure don't need to hold credentials, right? Got issue credentials and give it to you and delete everything and don't store it. Anyway, so it's not needed to hold the credentials. Right, right. Yeah, like I guess like in the protocol sense, yeah, itself correct. But if we leave it like in a world where like everything's are credentials, like I assume that everything everybody will need to hold credentials. Oh, yeah. In the issue, for example, in that one that is shown, this is the issue credential protocol, there are two roles. So issue and holder. Yep. So if you support both, you just in the query in discover feature query, you say so. I suppose it's like an array. So it's an issue and holder. Yeah. I guess like what I'm trying to say is that I would argue that you'd support always both roles. But I think like, I don't think you would ever support only one role. Well, if I'm a wallet, I'm only supporting holder, right? I mean, yeah, but like, you can also issue credentials for your wallet, right? Like issue, you can issue, but you can support the protocol or not. If you don't want to issue credentials, you just say don't support. You shall say I'm only a holder. Right, I guess what I'm correct. What I would say is that having a wallet that only holds credentials is not that helpful, per se. Like you also need to issue, present proof, be a verifier, right? Like you can also, you need to present a verifier in credentials. Like you want to verify your friend's credentials for whatever reason. Remind them over when it was COVID and make sure that their COVID pass was right. I don't know. I had that happen to me. Like some of my friends wanted to check my COVID infection, that kind of things. So like you're also going to be a verifier and a holder, like most of the times. I think that that is often true, Alex. But then I think in JFF, for instance, you would want to, you guys essentially created a new role, right? That it was some subset of this issuer or holder role. Well, I ended up creating actually like a whole new protocol, right? Because like in our protocol, we also did like some, did authentication, like tried to like log it in and like prove like exact, like prove ownership of dits and sign some things. And then offer the credentials like all like in one type of thing. So like, yeah, like when they're creating like our own like authenticated issued credential, like minimal protocol. All right, so since we're out of time, maybe some food for thought over the next week, consider what would things look like if there was a much more nuance in these roles? So that to take into account things like what Alex is talking about from JFF, where they almost created, they composed a bunch of other parts. And yeah, how would you name these things? And yeah, consider that. But great meeting today. Great to see you all. And yeah, we'll meet back next week. Thank you, Lance. Thank you, Lance. Thanks, Jenny. Bye. Bye.