 Okay, welcome all to the September 11th and on credit specification working group meeting few things to talk about less formal than normal, but we'll see how it goes. PR is to review. Mike, I'm hoping to ask you about an on credits to code. And then see if we've got enough participants here to talk about the share components and then open discussion people are welcome to discuss other topics. We are recording the meeting reminder. This is a Linux Foundation hyper leisure meeting. So the Linux Foundation, anti trust policy is in effect as is the hyper leisure code of conduct. So please follow those. Anyone is welcome to edit this meeting if you'd like to add your name to the attendees please do so that can be done in the agenda. Is there anyone new to the meeting that would like to introduce themselves talk about who they are what project they're on and what their interest is. Feel free to do that. Go ahead and she got me everyone. Hello. I'm Anshika buses. I'm doing my engineering and information technology and also working on some projects powered by hyper leisure foundation. I was researched a project based on Solan. This is my first meeting and first attraction to this whole project. I'm very new to this project. There are many things which I want to understand. All right. Well welcome glad to have you here and feel free to use discord and and this meeting as we have time on the in the agenda to ask any questions you need. No, I present related to this. I don't have any questions. I couldn't quite hear that. Could you repeat that. Yeah, sure. From what point of time point of view. I don't have any questions at this point. But I will discuss. Okay, great. All right. Please guide me regarding the first contribution and what should be the first document from which should I start my journey so as to have a better understanding of the whole project and organization. You, sorry, you'd like a overview of the organization. And how the projects organized. Yeah, exactly. What document should I from which document should I start my journey. Okay. Basically, it's it's the so I non creds is a specification so the specification is there. This is the rendered version there is a link there to the source of the specification. And so that's the primary definition that we're working on and then there's an open source implementation here, which is this and on credits rest open source. And so it allows zero knowledge proofs verifiable credentials based on and on credits to be issued to be held to presentations to be requested presentations to be provided. And those presentations to be verified. So those operations are defined in the specification. The implementation is in the rust source code. Is that what you were looking for. Exactly. Thank you for the information. Okay. And so definitely if you want to get started, the non credit specification is probably the best place. Okay. So just to review, we just have a couple in there. To take a look at. I think this one is now ready to go there's just one minor thing of the use of a link secrets which I should have responded to long before but I did 10 minutes ago. And so our retra just to be clear link secret should be used everywhere. Except where we're actually talking about a data element in a data structure that is shared across. What's been done in the implementation is basically Andrew has changed all references. In the code to link secret. Except where existing interoperable data structures are involved so things where a credentials been issued presentations are created or a credential definition has been published. Everywhere else in the code and and should be in the specification should be using link secret so that's that's the clarification there other than that I think this is ready to go. And I think if you can just adjust that we'd be good to merge this one. And that's about the credential offer and the nonce details and in particular clears up the confusion of the two nonces and zero and one and zero coming from the issuer and going to the holder and and one going the other way. And both of them verifying that the nonce is used in the responses from the respective parties. Any questions or comments on that. Okay, and I reach I don't see you have a microphone. But if you, if you do let us, you know, you can just use chat or anything if you have any questions or comments. Poor requests. So likewise I think this one is ready to go I didn't get a chance to look at it. Before this but I think we're ready to go on completing the credential signature data model might select at it so I think we're, we're good to go. Looks like there is one question in here to be cleaned up or reach her hopefully you can take care of that. And there is conflicts to be cleaned up. How best you want to do that so you've got to get a task to do, unfortunately, but a return I'll leave you to clean that up and submit updates to it. Sure, I look into that. Okay, great. And then the last one is a fairly substantial rewrite that I've done. That basically goes over the create presentation section and converts it from being sort of the list of calls which we had before to what is going on in the in the during the process. Basically it takes out of the specification how one collects data in order to produce a presentation. So how you determine which credentials you're going to use and so on, and focuses more on what are the inputs to the, the, the presentation generator. And then what is the process for generating the presentation. I did include a, a multi credential presentation that I want to update to be a basically a complete example. So I will be doing that. And then, then there's to do's which reach or this is where you come in. And then the places where, given the inputs, how is a EQ proof done for proving the signatures on the credential, how is a predicate proof a GE proof done. And then finally the process for generating the aggregated proof and the data elements of that so this is the core of the generator presentation section so that's a fair bit of work I reach out that you're going to be looking at and I assume you were anticipating that I hope so. So we'll get this one merged. I welcome any reviews of this to take a look at this and then we'll push it through the format is basically in alignment with the rest of the spec which is only the things that are shared interoperably the credential and the schema the credential definition the revocation registry the presentation presentation request and are what is formally, you know, on a on a per data element defined to define the sources of all of those. Anything else, such as you know how you find the credentials or other things are more outside of the specification, as long as you have the inputs to pass in the presentation can be generated. So I would like anyone to take a look and a quick review of that I think it's it's fairly straightforward. It probably needs another pass through it, but not before merging we can put it merge it through. Next question. So that's the end of the PR section. Any other questions or comments. Are you good with what you've got next to work on. Yes, I look into it. It should be a chunk of work. But based on what you've done in the past it'll be awesome. For those not aware, a retra is working on this project through the hyper leisure mentorship program. And it's done a fantastic job at reviewing sort of merging the the mathematical paper on an on creds, looking at that in the lens of the implementation and then documenting into the specification, the various algorithm, the cryptographic algorithms being used. So stellar work being done there. Mike, and on creds v2. So those who haven't been with us we've been working on and, you know, over the past number of months and on creds v2, and basically come up with a definition of what it, what it is. And what is what we intend it to be. And, and essentially the, the core components we can boil down into these things. The increased information in the schema part of the process to formalize from a cryptographic lens what the types are of the schema elements, such that one can expand the zero knowledge proves that are possible in the presentation. So, right now the schema is simply a list of elements and they're assumed to be either a string or an integer and that's it and therefore the things like the predicates that can be done are limited to when the data element is an integer and the, the four logical operators that can be done for a predicate greater than or or equal less than or equal greater than or less than. So those are kind of the limitations. And, and what Mike has proposed is basically the schema have more information about the data elements so that additional DKP predicates can be performed on that data. So things like a, the link secret mechanism can be used by an issuer for data element like that a, a data type can be an enumerated set of values and a, and a proof of being a member or a proof of being not a member of that can be done. So, for example, if you, if you want to know if a, if a person resides in a particular set of states, but not require asking which one, just that they be a member of a certain set that can be asked in a presentation request. So that's number one is expanding the zero knowledge proof capabilities in presentations and then the second key element is allowing for multiple signature schemes to be used. So that, in addition to CL signatures, BBS plus signatures, and or, or, sorry, or PS point Chevelle, oh shoot who's the S senders and there's, yeah, or several fixed Sanders signatures can be used. So that we have more flexibility in, in which signatures get used and that opens us up to with BBS plus, all of the work being done in that area by teams like matter and, and, and so on that are pushing BBS plus into standardization. And then with PS signatures similar work being done there, but also access to a, a version of PS signatures that are post quantum secure. So, I have some updates on that. Yeah. So, just to briefly give context and then I'll pass to you Mike. There was a, I believe a conference in the key cryptograph cryptography conference done in August and sanders at all. We're going to present on post quantum PS signatures. Yes, they did. They did talk with them. So, so the update is so yeah it's called crypto was in Santa Barbara back in August or second August. And this is actually during the hurricane that hit California so if you can believe that. I talked to Oliver Sanders and his PhD students Corinth and Judy. They are very interested in standardizing all of their signatures, and they just needed the practitioner so that you know because standardization requires at least two parties that aren't related to each other. So, so they represent orange labs and then obviously I represent, you know an independent so that that makes them happy so we will start work on the PS signature standardization. Probably within the few months, like probably let's say January is when we're going to submit the proposal. They presented their post quantum version that's based on lattices. Yeah. And so right now we're working on that and a private repo of theirs, just because we're just testing things out nothing standardized yet. It's looking pretty reasonable. So to present to create a proof is about one second. This is like if you have 10 say you have 10 attributes takes one second, and verify it takes a quarter of a second. So, it's not too bad. The, the signature size is 270 kilobytes. The proof size is 640 kilobytes for relative you know just so you can know it relatively speaking, the same thing with the punchable Sanders signature the signature is only 96 bytes. So it's quite a bit bigger, but the proof size is also only about three kilobytes. So it's obviously a lot bigger. Yeah, because the biggest pain is the key size the private key size is nine megabytes. And you heard that correct that is megabytes and the public key is eight megabytes. So, they are working to try to get that down, which is, you know, they're still iterating through it, but it does work. It is also the only post quantum option available, based on their research. And so anyway, I'm also collaborating with analysts and ski on this. So the also in question what code exists. I do have code written that works. It's not the post quantum version. Right. And unless in ski is currently reviewing it to make sure what I've implemented is safe. And when her and her PhD students are done, I will probably open source it. Okay, I'm happy to share my screen and show you what I have if that's helpful. That would be awesome. It would be very helpful. Okay, it's, it's been written primarily in rust but I do have going node JS Python and PHP available also, but the API looks something like this if you're running node. So, just a second in the drawer. Okay, but it looks something like this, you know, it's just a bunch of JavaScript options. This is just what the API looks like when we when we document it for them to review. But this follows the same data model, Stephen that we've talked about in the past. FY Knox is what I call the base layer so here's your PS signature. Here's your accumulator. And then this is just generic so if I wanted to swap in BBS plus I could. Now have you done that, or if you mostly focus on PS signatures. Um, no I have BBS that I can just swap in and out. It does not change much at all. So, they both work. Here's all that credential stuff we talked about. Like here's your credential offer. Yeah. Here's the schema. Yeah. And this is all like the membership checking and membership proofs. I call the bundles like includes all of the issuer information and the credential that's just a friend to do it. Here's all of the claims that I've talked about. So I call it claim data. Whether it's, you know, hash to scaler a number revocation value or some enumerated value. It's all there. Here's the types you can have. See unknown hash number, whatever we've that this is all in the credit non credits to spec. So this is where we basically where I did that hack MD doc was based off of the code I've written then obviously some updates since then. So here's, here's the validators where you're checking links or ranges or rejects or any specific value like an enumeration. And this all works. So if I do like cargo run and release mode I'm not going to do it right now it can issue. Sign, prove and verify in about five milliseconds with this, which is really nice. The code I've written, you know, it's based off of some bullet proofs that's open source that this one's already open source so you can all take a look at it if you want. It's based off of crates other crates that I've written the rest of these, all of these dependencies are open source. So you don't have to worry about that this one also the curve implementation is now written in assembly. So it targets arm, it targets risk five and it targets x86 64 bit or just for speed up. If you're targeting anything else that isn't that then it just reverts back to raw rust, but it's really great. That's the BLS signatures is that one of the options or is that a core element. That's a core element of it whether you're doing bbs or PS signatures, both of them are variants of BLS signatures. This, this crate is open, blissful crate I've written that it's this just does the BLS signature but it does a bunch of other stuff to this one's already open source. But it does sign encryption. It does signature proofs of knowledge. That's what this does it also does time lock encryption, which is really cool. This is all open source, and it does verifiable encryption as well. These are all things that we want on top of for non credits to a lot of that's open source. So the main thing that this repo is doing is mostly just gluing a lot of that together. For the most part. Wow, not not too complicated. Here's the fire. Here's the statements that you can do that we've talked about in other spec the code, the code is all here. Just a matter of interest Mike, I know that's a. So two questions it's private repo. Would you be willing to have I shouldn't ask you this in a public forum anyway if, if I could interest someone like Mike, or sorry like Andrew Whitehead to take a look through would you be, would you be willing to let that happen in still a private context. Don't worry about it. I shouldn't ask such a question. The other thing is you said it was, who, who did you say was reviewing it was it. Yeah, the L and CL signatures. Yeah, exactly. Awesome. Yeah. Okay, excellent. Okay. Good. All right. That's super helpful Mike that's exactly what I was looking for. Any questions for Mike from anyone. Feel free to take a look at that blissful crate that does all the current operations and a lot of the supporting cryptography. So, like I said, the only repo I did that you just looked at was mostly a wrapper around kind of the metadata and the packaging. Above that all the rock, most of the rock cryptography is in that blissful crate. Okay, awesome. Awesome. Which is already open source. Yeah. And then the only thing we've got to discuss is our little disagreement on whether there needs to be two objects or one in the schema, which is pretty minor. Remind me again what that is. I wanted you to just use the schema object, as opposed to having the schema repository and then the schema object referring to the repository. Oh, you were, I don't really care per se. It's not a big deal. The implementers are going to do it as convenient for them. Yeah, yeah. That's awesome. Any other questions for Mike. Thank you so much Mike for that really appreciate it. One of the things I wonder I don't know if you're going to IW but in looking at that. I was thinking I'm going to prepare an on credits to sort of overview, plus state of the, you know, state of the work. Is that okay with you. Oh yeah, yeah, feel free to advertise it. Okay. Yeah, I'll be pushing that there I am going to IW and I think this would be an excellent presentation to do so or a session to hold and get the discussion going on it. Cool. Excellent. Okay. I don't see the folks on the non credits RS implementation the current state of the non credits. So I will figure out a way to have that just so people are aware. There's a ton of work going on in ask our indy BDR and non credits RS and CL signatures basically there's a series of updates going on amongst the various participants in those repositories and I wanted to sort of try to get a state of where we were. I will pursue that in other ways and I'll share back. Once I know better. That's, there is a fair amount going on in those and it's leading up to another release part of this is to do with, you know, eliminating Ursa. Part of it is the optimizations that Andrew Whitehead has been working on with respect to the CL signatures code. And it's just making it so that ask our, and the other components are easier to consume, both in areas VCX and when wrapped and pulled into say Python and or areas framework JavaScript. And of course these libraries can all be used in other other scenarios beyond areas. So, I'll find out more about that. I didn't actually have something on remaining work so I'll just take that out that was a leftover that I intended to remove before then. So without that ends. The formal part of the agenda I had planned went really well. Any any open discussion points that people would like to raise at this point. All right. Well then that brings us. Yeah. I was trying to find my hand I couldn't find it. I don't have anything to add in terms of discussion but this is only my second meeting that I've attended but we spoke earlier in the spring about about revocation in particular and I'm just wondering if there's anywhere that or anyone on the call who who might be needing some support in some way. I'm still kind of working through the specs so I haven't read the whole thing yet but but but I'm interested in supporting in any in any capacity that seems reasonable. Okay, awesome. We'll consider that I'll put it out there. Yeah, yeah, yeah, I'll probably reach out to you. I'm traveling for the rest of this week but I'll probably connect with you again Ashley. I know where to find you so we'll connect again. All right. Excellent. Okay. If there's nothing else. Last chance to raise your hand. Excellent. Okay, we will not hold the meeting next week. Again, but but we'll be back in two weeks. And I'm hoping we've got a further PRs to review and push and wanted to probably as I think about it try to formalize what what to talk about at IAW in doing that and also bring an update on where we are with the shared component implementations and the use of the non credits libraries the ledger agnostic and on credits in the various areas frameworks. So look forward to seeing everyone again then. Thanks all. Thank you. Bye. Bye. Thanks.