 All right, welcome to the an on credit's working group meeting for March 25th, 2024 progress update and honor credits be one in W3C BCDM format, a discussion on an on credits be two in W3C, W3C BCDM format. We'll probably miss this next topic as Mike Lodder is not available today. And I wanted to have a discussion and get his feedback on that. So maybe we'll do that. Maybe not. We'll see. We can play it by ear reminder. We're recording reminder. This is a Linux foundation hyper ledger meeting. So the anti trust policy and the code of conduct is in effect. Let's just jump into it. As far as the BCDM work, the credo by fold work is complete. So that's good news. You got word from that. I don't know if the PR and by fold has been merged. I'll be checking on that today. And the ACAPI work is in progress and hopefully getting wrapped up. I know we got a. A issuance through late last week. So hopefully presentation will come will follow soon, but we'll see how it goes. But the ACAPI progress was good. And so we'll be meeting on that in a separate meeting later this morning. So with that, we want to talk about an on credits V2 and W3C format. And so I think Victor on turning it over to you to share what you've got. Is that okay? Yes, yes. Do you mind if I share my screen. Absolutely. There you go. Thanks. You guys can see this, right? So I'll see you suggested last time or the time before we've moved from Python to rust to support the verification of presentation. So this is how mapping from an address to W3C is looking right now. So we've created a credential and then we call a function called to W3C and which takes in the generated. And they'll just output the credential into and write to a file. Okay. Let me find that for you. So this is what it looks like in W3C and this is the previous and on credit show. Okay. And similarly presentation. We also did the same thing, but with one more thing is we've verified the presentation in the beginning because we want, we would like to have the predicate proofs in the verifiable credential inside of the presentation. Right. So what it means is, let me run this. So what it means is that if we look at this verifiable credential inside of this presentation, we can see the credential subject. So this was the thing we talked about last time. Yeah. Yeah, we have a claim and the statement that is related to this claim. For example, revocation has two claims, such as revoked and verifiable encryption. So where do I get this value? This comes from whether the presentation verification has passed or failed. Okay. Yeah. And yeah. So signature, well, signature doesn't have any claims related to it. So I just put a separate one. Yeah. And then the address has a membership related to it and the age has commitment and range. And then the name value is a disclosed message from this presentation. Interesting. Yeah. So, yeah. So basically this is what I've got. And I've also have the opposite mapping that takes in this W3C in JSON format and then I'll put the, I'll put back the antichrist in JSON. Okay. Okay. Yeah. Excellent. I was wondering if you guys have any questions. At this point, no, I mean, it all looks good. What form is this a PR that you can put in? No, not yet. I'll put it right after the meeting. Okay. But it is doable as a PR. Okay. Good. Yes. Yes. Yes. Excellent. But I do have a few questions. Okay. Yeah. Okay. Yeah. It's regarding about the format of antichrist. For example, if we look at this disclosed messages, for example, if we look at this disclosed messages, we have a list of lists of, so it's quite complicated. Like I understand that, for example, this is reasonable for one or two lists to exist because like we could have multiple credentials in the presentation and then we can have multiple messages coming from different credentials that are disclosed. But it's just, it's just complicated to map and to extract the information inside of this. It's disclosed messages. Yeah, there seems to be two, two layers extra. Yeah, yeah, two redundant. Yeah. Yeah. Yeah, yeah. That's one of the questions. That's a mic question, unfortunately. True. True. So Mike, when you're listening to this, help us out here. But yeah, I can see the, the statements. And I can see the names being valid. But yeah, I don't see how, how there could be that many layers. Yeah. Right. And I guess another question is that currently all my, all my functions are our public functions. So they serve like a util function, which you can just directly call from from any, I guess, any other places without, without the actual class. So I, I don't have like a specific class for this. I was wondering, should I that that was way beyond me. So yeah, I can't. Yeah. That's totally fine. Yeah. Yeah. Yeah. So Mike, again, over to you. I'm sorry. I'm like, I'm not as deep into it at the moment, but Victor, thank you for like pioneering that. Do we have to do that to that thing with the disclose messages? No. Okay. This is V2 only. This is an on-premise V2. So you wouldn't need to do this for V1. Okay, cool. Yeah. Yeah, because I noticed that in V1, you guys have this separate class called like W3C presentation or W3C credential. So that's have all these functions, I think. I think the ultimate goal we're going to get to in V2 is the, everything will be in W3C VCDM. And that would be the only way to do it. So this helps in figuring out, okay, what does that look like? Right, right. Yeah, I see. We don't want to be shifting back and forth. We just want to use W3C format. So there will be no longer end credits format during the creation. Right. It'll come directly in as a W3C credential. But the presentation is particularly tricky because of the exact issues you've demonstrated today, which is how do you represent the various zero-knowledge proof methods, especially when they're multiple ones? Right, yes. Yeah, revocation signature certainly address, again, membership if it's got an address membership. But if it's also being used as verifiable encryption. Yeah, if you've got multiple reasons to use something and there are multiple reasons to use things. So, unlike the predicate where you can possibly get away with just the one in a non-credits V1, you can't really get away with it in V2. This is excellent. Nice work. How was your Rust learning? It's pretty rough. I think this is harder than C. I was being optimistic at the beginning. Yeah, yeah. It's a good skill. True, true. It's helpful. Yeah. Yeah, so this is what I've got. And if you've got so many questions, just ask me. Yeah. Please go ahead with a PR for this. Yep. I'll do that right after the meeting. Yeah. Okay. Sorry, I was just looking at the questions in the chat. We'll get to that in a bit. Victor, this is awesome. Thank you so much for doing this and getting it ready. Nice work. Yeah, I'll just stop sharing and you can continue. Okay. Just to let me, first of all, let me get back to the chat. Where did that go? There it is. Agree on the, on the IIW. I know I'll be there. Golda, I'm not sure about whether DSR or, or, uh, Anima will be there. Let's check in with those. So. Yeah. Yeah. I was thinking we could do a slide deck and they could like stick in a couple of slides so that we represent the different works. Yeah. Yeah. That'd be great. Um, The comp. I'm, I'm hesitant to do this without, um, the full with Mike, um, not here. So maybe we'll, we'll skip on this, but I'll just briefly go over the, the idea of the schema object in an on credit. So this is, um, a topic that we've got to get to, which is in an on credits V1 and in the examples we've done so far in an on credits V2, the schema object has been simple in that it's just a list of attributes, but in, um, in our grades V2, we have the capability of doing complex JSON and in particular that means structures and also arrays. So arrays can be done, um, which is something that cannot be done in, in V1, um, in V1, you have to know. At the time you set up the definition of the credential, um, how many elements there are, how many messages, um, or in a cryptography, cryptographic, um, term, but in how many claims there are in the credential that has to be known in V1 up front in V2. That does not have to be known and, um, we can sign an arbitrary number of credentials, which means we can support arrays. So, um, what we've got to figure out is, but, or sorry, and then we still have to, um, define the encoding of each of those, um, claims. So even if we have complex JSON, we've got to know, is it a scalar? Is it a string? Is it a, is it a number? Is it a set? And so on. So we've got to have some way of applying attributes to every one of the, um, elements, of the claims, um, that are going to be signed in a credential. And so, there's a few ways we can do it. Um, possibly using as much JSON LD as we can, um, using something like JSON schema, we could flatten everything down using what amounts to JSON path references. So that the schema becomes flat again, even though it's, it's not. So I've been looking at various ways to do that. Oh, another one is, is to use an OCA bundle and, um, add another overlay that includes the and on Chris schema attributes for, um, each of the parts. Um, that one fits well with the rest of areas, certainly. Um, so it's a possibility of way to do it. We still have to, with that flatten down or come up with a way to do the, the schema properties, but an OCA, um, is an interesting possibility. So, um, I've been working on that on and off for the last little bit and, um, hope to have something more, more solid in the next couple of weeks on that. All right. Um, given, uh, the limited group, I think we will, um, leave it at that for this meeting and, um, Victor, thanks for your presentation and, um, work on that. Um, as I said, Mike is hopefully nothing serious wrong with him. He, he sounded pretty good and we'll, um, um, we'll, uh, he'll follow up with you, uh, on discord. And if we have to get together again, we're happy to do that. Um, just the, you know, the four of us. So we can follow up as needed. Great. Okay. Well, that's all we got for today. So thanks all. Have a great week. Thanks everybody. Yeah. Thanks guys.