 Putting in recording in good. Yeah. Yeah. So I got it going for the Alice favor demo and, uh, I didn't integration tells basically it connects and then when you go to issue a credential, there's an error and I think it's the there's some. I tried it with the Ascar wallet and with Ascar non-creds wallet and with the Ascar wallet, the error is related to one of the marshmallow validations on the dead. So at some point there's some really on the did this failing and then with the Ascar non-creds it was a different error, but I suspect it's the same thing. So, it doesn't like did pier somewhere. You know, it's got to be, is that on a folder? I didn't, I didn't look, I just, I didn't run through the integration test and it failed and actually I updated Alice favor and I ran it in Alice favor and I was getting an error and then I thought, oh, I should have just done an integration test. That would be easier. Yeah. So I, so I did. Anyway, so, so let me ask the question differently. Did it, did it fail in Alice? I was joking. There's an error or something. Or should I think in the integration test it failed in Bob. Oh, interesting. Anyway. Oh, okay. So, there's a place where the holder did is sent over for no apparent reason. And so there must be some checking of that did, which we should probably eliminate because it really doesn't matter whether it's a did or any other piece of data. There's no use of it done as it did. Why it was ever done in, as it did in the first place is a mystery. So that's probably what it is and it's definitely an unnecessary check. So it's probably the receipt of the holder did and it's checking to see that it's a dead when it has no reason to be a dead. So. Did you want me to actually track that down and fix it? Well, let's record it. We got to get it fixed. Anyway, the integration test fails, but it's not tagged to run as part of the nightly. Okay. So it's not going to fail like an integration is not going to fail any PRs or anything, but yeah, once we fixed it, we should tag it as a GitHub action and then it'll run like as part of the report. Yeah, yeah. Okay. Okay. Anyone. Okay. Um, make sure that issue is in there. I think that's all that's been assigned and shared. Um, Patrick has been working on this one. It'll get in. I think he's pretty close with it. Super interesting what he's done here is this is enabling using W3 C credentials and running the traceability suite. He ran into an issue with it that he's cleaning up and doing that. Well, how are we on this one? Is this ready to go? Um, okay. You've already requested a review. Yeah. And you read some minor feedback. Okay. It's just some more of the same type and corrections that there wasn't a red squiggly line underneath it. So I didn't catch it on my pass. So, but just for consistency, I can go through and I can probably change that in the next few minutes. Just to get that. Okay. And then I'll get it. I'll get it reviewed and and a sign or approved. I've moved this one, as I mentioned, into a, into a hack and D document just because doing doing design docs by a github are really hard. So I'll cover exactly what we're going to do with that. I haven't looked at that one at all. It's still in draft. So I guess that's okay. This MD document I haven't reviewed. So I think we're up to date. Did rotate. I'm hoping Syro is going to look at this, but he's been pulled into something else, but should be onto it after. Yeah. Yeah, highlight when you, when this PR goes in. Ian, are you going to do this PR? Yes. Okay, just make sure you put. Yeah, that's next on my list. Yeah. Make sure you put breaking in the, in the PR title. Yes. Yeah. That's why I put breaking in the total. Exactly. Yeah. Jamie, with this one, do you have improvements or you're just looking for someone else to give you improvements? It sounds like you've made really good progress. No, I like the. Dev container and there was one example for multi tenant configuration there already, but. It works really good even having like multiple agents open. So that's what I'm using to develop right now. And it. I'm just like, yeah, so it's more obviously you can run multiple agents and they can. You can run it just on local host and stuff. So I just want to. Update that. Yeah. Yeah, Jamie, Jamie was showing me that his setup last week and I suggested that he had some documentation and check it out. Yeah. Okay. I'm going to do a demo and. Excellent. He's got like the, the debugger hooked up to all of his like multiple agents and he's got the debugger hooked up to all of them. That's like, that's good. On this one, Ian, this is what I meant to ask you. Sorry, this was the goal and how you got into the break with that, but were you able to use reuse. Well, I could use connection reuse to reuse the connection, but then. Yeah, that's what I mean. You were able to do that. Yeah. It broke when I got to the point of. Yeah. But this part actually worked. Okay. Well, I mean, it works, but the connection doesn't work. So. Yeah, yeah, I know I get what you're saying. Okay. Anyway, I added that there was an integration test. That you had. Yeah, I updated it. I can't remember what I did. Anyway, I tested it with Alice favor and I opened up multiple connections between Alice and favor and confirmed that it was just using the same one. Okay. Okay. Those are the ones that I wanted. Do we need want a new release. So. Sorry, I was like just talking over someone. I don't know. I'll go ahead. So it's something I'd like to do. I would like to have a release soon with all the did peer updates. I think that would be really nice. But something I would like to get around to and haven't had a chance to yet is going back to the act by if J. Interop setup thing that I had and test things out and make sure that there's no small tweaks that need to be made to the implementation to help those to align. I just haven't had a chance to do that yet, but I'd be really interested in doing that so we can catch the issues before we have it committed to a release, I guess. Okay. Sounds good. Okay. Any, any other topics before I jump into the what we're doing about an on credit and W3C format. All right. So this is sort of evolved and it's been quite interesting to see it evolve. The an on credits work is complete. There's one little tiny tweak that might still get done but the an on credits rust work is complete. And a dev release has been put out with all of the an on credits in it. I believe it's there. But I think about it may have been something else, but it will be shortly and and in the main branch, all the major merging has been done so W3C format credentials is supported in an on credits. So then the issue became, okay, we got to get it into AFJ and occupy how are we going to do that. And so what we've gotten to is agreement on the interoperability components, how we're going to use issue and present protocols and in particular the attachments to use when using W3C. And then behavior changes in issuers, holders and verifiers and in figuring out how to trigger when to see what to do when they're in there and then some notes on in and out of scope so we have we've decided to go with the RFC 809 which is still a pull request but we're still going to go with it which is the W3C data integrity attachments. And we're going to go forward with that and Timo put together test vectors to show what those different things look like. So there's a repo of test vectors that he's created and a set of documents that outline those including publishing, you know, credential thefts and link secrets and so on, so that tests could be built with that. In particular, the offer the request and the issue are highlighted in that. And so if I come down here, I've got an offer. What the attachment would look like of an offer which the big thing here is that there's a binding method, and it can be an on creds link secret and that's where the offer information for an on creds is put, or it could be a did consigned attachment which would be used if you're going to have it have for example I did key with a proof in it and so there would be a signed attachment associated with it. If the side attachment is there here's what the side attachment should look like in it and how it should be defined. Once you have an offer you get a request back from the holder, so it would have this information interestingly Ian this used to be called issue or did now is called entropy because it's not actually a did. So that's where I think you're getting into that that error that you saw is coming out of it. Sorry, I remember in an on creds there is something that changed from issue or did issue or ID. Is that now changing again to entropy or no. This is holder did this used to be holder did and now it's entropy because it is nothing but a string. And why it was ever called a holder did when it had no association. No one knows. So that's the request and then finally you get a an issuance. And here's what a credential looks like, including the proof value, and so on so everything goes into here for those that haven't seen this already. There is no an on creds context. We just stuck with the straight data integrity plus vocab vocab allows us to have arbitrary things in here without having to have a specific reference to what ages or what name is so that gets us away from having specific things for the credential. And then anything sort of an on creds related including revocation is in this proof value encoded in this proof value. So it's a data integrity proof using the crypto suite and on creds. So it's a data integrity proof using the crypto suite and on creds. And everything about that is encapsulated in this base 64 object. And then this is an example where we have a credential with two signatures associated with it and an on creds and a EDS a credential using did key. So there you go. So that's an offer an issue and a request so that's what is happening on the issue inside so a new attachment and that was where my question came out of can we make this pluggable or do we add a new one in. So that is something that we'd like to figure out is do we do in it. Enable it to be plugged now or do we do this as yet another attachment format that is hard coded in there. Any Daniel you had comments on that one. Sorry I was distracted because you repeat the last or not. Ten seconds. Comments. Whether we make this a pluggable thing now. Oh, right. So I think there is at least an easily identifiable place to make it pluggable. But I don't necessarily feel strongly about whether we do that now or not. Okay. Okay. Yeah, I think it's fair to like just keep things the way they are, especially as we, you know, we can focus on other more important things like getting the actual attachment format. Exactly. But yeah, there's definitely some weird, ugly things. So I think there's at least an easily identifiable place to make it pluggable. But I don't necessarily feel strongly about whether we do that now or not. Okay. Okay. So, yeah, I think, okay. Yeah, there's definitely some weird ugly in there and some like kind of heavily JavaScript type scripts influenced. And I think it just ends up being a little weird in Python. But yeah, we can worry about that later. Okay. Present proof protocol will use the existing diff presentation exchange. So RFC 510 diff presentation exchange. So we are actually making the shift where presentation exchange is used for the request instead of a and an on credits presentation request. A submission and a presentation is then provided again, these are links to the test vectors. I had this question was more for Timo because the submission that he put in is very simple. It turns out a submission is a item in inside the presentation. So a a an unsigned part of the presentation is is where the submission goes. Evidently that seems weird to me now that I think about it, but there you go. Oh, I guess not. It's fine. It's fine. I think we lose functionality in restrictions. We don't have as powerful a restriction language. And I'm not exactly sure how revocation goes. AFJ folks are going ahead with this one. So we'll probably learn from them. But anyway, that's something to keep in mind and then we'll make any clarifications necessary. Possibly if we have to changes to this RFC to support this. Does that make sense? So this is something we've long talked about. Timo has done a bunch of exploratory work and figured out, yeah, we might as well just do it. We already have presentation presentation exchange supported. And for the most part, as with an on credits presentation, it's the controller that constructs the request and then passes it on. So it's not that much in a copie. So that's the way we'll go with that. So those are the attachment formats. Any comments on those. Surprise. Any comment on on what you just said there about the controller being in charge of the creation of the requests. One thing I wonder about is if it again I don't think this is necessarily something we need to worry about initially but I wonder if there's room for like another API on act by that will construct like a basic and non creds. There's a presentation request for you or something presentation exchange, especially like all the presentation definition objects. Yeah, you go and you look at the docs. It's, there's an overwhelming number of options and and things you do with presentation definitions. Enough that it's been kind of a struggle like internally add in DCO for us to be able to pick up and understand what the heck we need to construct in order to do Jason all the creds today. So just in a very similar thought space to like revocation is complicated so I should do it. I kind of have similar feelings about presentation exchange formats and the API so we used to interact with them. But yeah, maybe that's like an additional API. It's not supposed to the only API so you still have like the the full control if you want it but if you want to just do. Okay, like basic stuff or straightforward stuff anyway. There might be something like that available to us. Yeah. One of the things that I also like to see is, and I think it belongs in Akapai is at least a way to say things like dollar now. And then a an on credits presentation, you know, so, or, or now minus 18 years that inserts the proper values at runtime. And, and that shouldn't be up so you can have a presentation request template if you will that inserts the right values. So, you know, it's it does the date in calculation if it's a date in field that does a Unix time calculation if it's a Unix time field and so on. That would seem to be a nice helper as well. So I think that's along the same lines. Yeah, for sure. Less to do and in an on credits and what you're saying is there's more in presentation exchange or would need that. Yeah. Okay. So, with that, I'm going to jump to here's what changes issuer the proposal messages are out of scope. Only the issuer via the offer can initiate issuing an on credits W3C VC. So they use the 809 attachment with the an on credits bike holder binding. Obviously, we're assuming that the issuer and holder can both support and on credits W3C VCs. There is a question about the V1 and V2 VC DM and the verifiable credential data model, but not a big issue with barely any changes so it's not a big issue. Issuer is no longer encoding the credential attributes because those is those are handled inside and on credits now. So the issuer encoding is out of the way. And then there's future possibilities of making you know the holder being able to initiate a W3C and so on. But the basic trigger is for the scope of work happening right now is the 809 attachment on the verifier side verifier uses a 510 attachment to request and an on credits presentation in W3C VP format. The verifiers can process presentations with a 510 attachment containing an on credits W3C VP so they would receive so they would send a different patient submission. They would receive a presentation and see that the it's a data integrity proof with a non credits crypto signature and that would trigger processing it as an an on credits VP. The encoding is handled and I'm not exactly sure where that all fits so this encoding has to be looked at of where the responsibility of doing the encoding and checking. I pretty sure it's now in an on credits. It doesn't have to be done in acropi but we have to verify that. And finally the holder behavior holders can receive credentials using the 50592 or 593 which is in the attachments in 592 also and 593 is JSON LD. And the new 809 so this is an addition is the 80809 attachment formats. Holders send the request message in the same attachment format as the offer so if it's a came as a 592 you respond when a 592 came as an 809 respond as an 809. And holders can receive existing 592 presentation request so normal and on credits and 510 presentation request that could be an on receipt of a 510 the holder includes a non credits credentials in when finding suitable credentials to use in the presentation. And so if an on credits credential is found obviously it needs to be put into W3 CVC format as a presentation submission. All right. That's that's the trigger there out of scope. Oh, and on credits credentials can be sent as VP's whether they received as legacy or W3 CVC format. That should work the same and I think that should be pretty straightforward. And then finally in and out of scope. We're not going to worry about issuing credentials with multiple signatures as part of the code with us. I will do the creation of the age test. I'll be leaning on Sheldon to work on that. Okay, that's enough on that. Hopefully that is helpful. And if anyone has any feedback on that and guidance. The group that one, the code with us is called what's cooking. Who's at IAW is leading that team Daniel Hardman's involved with the team and then it's some other developers so we're bringing some new people on so that could be a challenge. I've asked Ian to sort of oversee their work, but certainly if would welcome people's input on that if you don't mind joining a discord for conversations about that. I think it would be appreciated, but weighing in on how things should be done would be helpful. And that's about it. Let's go ahead and put question that came up as you were talking about the behavior changes. So when you when you say proposals out of scope, is that simply for the code with us effort? Like, is there a proposal that proposal defined in the attachment format still? Is there shoot? I don't think there is. Okay. That is a good point. I'll put that in. It is still a PR so I will put that in as a comment or you could put it in as a comment. Because you're right. Proposal needs to be needs to be there. Would you happen to have a link to the slides or to the PR you mentioned? Yeah. Copy. So into there. That's the deck. The other one I wanted to send was the HackMD document that I did, which I'm not seeing. And I don't know, again, how much you want to go through this so I wouldn't be surprised. But it, I think I covered most of it here. So this first part is what I just said. What functions are we going to wrap everywhere from here down with stuff that had already been put in and it's code level so I didn't want to weigh in on it, but this is where, you know, things will have to be adjusted. Okay, cool. Thanks all. Have a delightful day. Have a good day. See ya.