 All right, welcome to the non-creds working group meeting for the 22nd of January, 2024. We'll talk about the non-creds in W3C format project, so status updates and issues and then move on to a couple of things to do with an on-creds v2 and the roadmap for an on-creds. We are recording the call and we'll be posting it after. Reminder, this is a Linux Foundation Hyperledger Foundation meeting. So at every meeting, we have to remind members and participants of the Linux Foundation anti-trust policy that's in effect and the Hyperledger Code of Conduct. Let's be good to one another. Any, so we have as far a reminder that in the specifications and related repositories, we did get the 020Dev7 release of an on-creds out there. This is the one that includes all of the W3C updates. We have merged that into the main branch of an on-creds or at least we have a PR very close to that. It took a bit of adjustment, not too much, but it wasn't just a switch of the implementation, but it is now cleaned up, tests added, and so on. Meeting preliminaries, welcome to all. Any introductions, any announcements people want to make? Timo, you want to mention that we now have a new wallet name on the block, Credo? Nicely done. Yeah, we're going to do a formal update, but we have decided on a new name for our framework JavaScript. It's Credo, Credo, however you want to pronounce it. So now we're in the process of renaming everything and then getting it ready for the 05 release. Congratulations. How do you pronounce it? How do you want me to pronounce it? Well, we don't have a singular pronunciation because it's different in a real pronounces it differently, like Credo or Credo or something like that. So I think Credo, I think. Excellent. Okay. All right, as far as, you know, on credo in W3C format, I know we'll be likely merging the PR from the design on the ACAPI side. That's looking good. Any comments from the team there? I just updated the PR with the ACAPI version. Yeah, it will be great. Excellent. Good. I saw the updates went through. Some of them I need to do a little more work. This afternoon I want to, or later after this meeting, I mean, and get Ian to look at it as well, and then we'll move it forward. Excellent. Any questions or comments we want to actually, sorry, Martin, any comments from you on the Credo implementation? Any questions or comments or status you want to raise? No, so far everything is looking good. I created an implementation for the issuance attachment format, which was proposed from Timo that's working at least the issuance part, or at least the unencredged part. I did not do a lot of tests with issuing non-unencredged credentials or with the other data integrity proofs. Yeah, and I'm currently working on making the percent proof protocol working with the BAX attachment format. Yeah, but so far so good. Excellent. Good. Thank you. All right. If there's no questions or comments from the teams on this further, I'll jump into a brief presentation. I've done on an unencredged V2 object. So we'll shift from an unencredged and W3. Oh, Timo, yeah. Yeah, maybe one on this topic. I don't know how far the acupyteam is with their implementation exactly, but might be good. Like if in a week or something, we could start doing a bit of like interoperability testing or probably better to do that sooner or later. But I don't know how far the implementation is along and if it's time to start looking at that. Probably early right now, but one of the things we could start to do is plan out how to do it at next Monday's meeting. Maybe, Martin, you could say, OK, here's how you would be able to run the code you've done. In other words, where you published it, presumably you have your own fork of what you're working on and then we could see how to use it, interact with it. Yeah, I have my own fork. I can try to make something. Yeah. OK. Yeah, just brief instructions for how to run it, although that's just anything that needs to change as a result of what you're doing. Yeah, OK, that's fine. And Tuna, you should keep that in mind as well as you start to move forward in the implementation, what fork you're using and how to spin it up so that others can see it. So ideally, as you're working, you're not keeping it locally, but pushing it out to your GitHub repository regularly so we can access it. OK. Yeah, I noted. Good. Thank you. OK, moving on. So one of the things that we've got happening in an RPEG-B2 is the first PR came in, which was an item done by a team in the University of Toronto, which is where I went to school, interestingly. And they contacted me a bit to do a small project in there, and they've done some work towards an on-creds V2 and W3C format. And the first thing we needed to do was sort of see what the objects looked like today as far as that. So they've added some debugging and work in it. So status background on an on-creds V2, same operations and objects as an on-creds V1. So we should have more or less the same offer request issue on issuance, the same presentation request presentation in presenting. And obviously a credential and a presentation are obvious, but we also have the cred death and the schema. The main difference from an external perspective is significantly more information about the schema claims. So there is a ton more information in the schema than is today. And as those who have looked at it know, there is almost no information. All there is is a list of attribute names in the schema. And then by looking at the data, we determine what the encoding is. So in an on-creds V1, there's basically nothing. An on-creds V2, we get all sorts of information about what the encoding is. Is it a hashed, which is a string in V1, a number, which is a number in V1. And then we get these additional ones, scalar, which is currently only the link secret in V1. Now an issuer can create a scalar for using for multiple things. It can be a set, so we can do set membership and we can have a range enabling a range proof. So all of those that encoding information becomes explicit versus implicit as it is in V1. As a result, with more data, we get more flexibility and we get more capability. So the main flexibility is we are able to use multiple underlying signatures. And CL signatures is actually included in this, but I never included in a presentation. But CL signatures could also be supported. But Ponsha Valley A Sanders, PS signatures is available. BBS plus signatures is possible and PS post-quantum are available as well, which is quite interesting. PS post-quantum is just a pluggable version of the PS signatures. But it's the first one that sort of gives us the possibility of a post-quantum implementation. So that's the flexibility. The capabilities is mainly the additional ZKP capabilities. So we still get selective disclosure. We still get predicates. We now get claim equality across credentials without revealing the claim value. So you can do a comparison of say names across two different credentials without revealing the name itself. Just proving that it's the same set membership. So, you know, if you want to have the 20 EU countries, you can show that they are within a certain, you know, a handful of them. And prove that without saying where the person is. A range proof, blinded value, a range proof, obviously a range of values, blinded, being similar to a link secret, but able to be used in different circumstances. And then super interesting, one verifiable encryption. So a value that can be verified as being provided, but can be encrypted with a given key. So this is what, similar to what credit card companies do when they generate it on the fly. So credit card number for you. And then when it gets back to the issuer of the credit card, they can decrypt it and determine who made the purchase. So all of those capabilities become available. There's one more, which is a domain proof. I'll add that to this list. So as a reminder, a domain proof is where. You have on repeated presentations to the same domain, to the same verifier, the verifier can use a common value and get back a repeated value from the credential in the presentation. So they get a consistent value from the presentation, but each verifier gets a different one. They can't do correlation across verifiers, but when somebody returns and presents the same credential as recognized as being the same credential, so that's another interesting one. Implemented as part of an on-credits to is the Allisaur revocation capability, and that has very interesting properties. Super scalable, it basically has unlimited scalability, but has would likely be implemented as a type of call home capability. So it's got some pluses and minuses there, but we've got some ideas on how that call home can be mitigated. And so that it doesn't become either a perceived or real tracking mechanism. So that's where we are with an on-credits to and what's there. There is code, it's available, and we've got a to-do list of things we want to do most importantly starting with making the signatures pluggable. Currently it has PS signatures built in, but we want to make it pluggable and then BBS plus added as soon as possible. And that's just because BBS plus has more momentum in the VC marketplace. We also would be super interested in getting a team interested in experimenting with the post-quantum capabilities. We do want to formalize the objects with an on-credits 1.0 features built in so that the link secret is automatic just as it is in V1. We get the W3C VCDM format. We get the diff presentation exchange format so that we're building right from the beginning off of those. Date and date time encodings is an addition we want to put in right away so that you can have user-friendly date and date time encodings, but they get converted into, for instance, the date integer format we're using for dates in an on-credits B1 and the unix time we're using for B2. Currently there's a couple of tests, an issue and an issue present. And so Victor Wong of University of Toronto has put in a couple of things to enable printing out of those objects. And so if you run with Rust Log and then creates tests, you can actually see all the objects. And that's what I was after to be able to show some things. So I put these into our repo so we can start to see what a credential schema looks like. Hopefully you can see that. Let's see. I think that would make it a little bigger. So this would be the entire V1 schema you would get. Link secret would be missing because it would be implicitly created, but you would just have the list of names. And so here we get much more information. We can have multiple blinded claims. And so that is enabled that you can put more into it. And then this is where I meant by you have more information available. So for things like the name, you've got a length here. You've got the type is revocation, scalar, hash. So you're being very explicit about the type here. You've got a number. You've got a range on it. You've got a length on the string. So you got validators, which allow you to indicate attributes of those. And so this is the additional information that comes with a schema in Anarchized V2. There is an example with and without. I have done the dip. They're not very different. So there is that. There is two calls depending on which one you're using. And so I have questions for Mike Lauder as to why there is two calls. There is a call that says I'm blinded. I'm sending a blinded and there's a call that says I'm not sending a blinded. And I'm wondering why that is. So part of the effort in doing this was to come up with questions and differences. There also does not seem to be the equivalent printed and available in the of the credential definition object. I think I've gone through the test now and found where that should have been printed. And so I'm looking at getting that printed out so I can take a look at what that looks like. The credentials are kind of interesting. For one, as they are today, the credential, I'll start with the credential with the link secret. Yeah, there it is. Notice that in it is explicitly the entire schema object. So this needs to change to being an identifier and referencing the scheme itself. So this goes away entirely. That entire plain type. We do have the cryptography in here. So we've got verifying key blindings revocations in here. So those would obviously go into the proof in W3C formats. And finally, we've got the credential, which gets down to address and the value. So, you know, in W3C format, obviously this will become the subject credential and the various values within it. We will think about what the ID will be. Revocation is interesting. I do want to talk about how we can do revocation such that we can support both the bit array format and revocation with Alasor in the same way. And I think that is doable, but we're going to take a look at that. And finally, some additional values related to the signature. So this format obviously needs to become in line with W3C format, but it does not look difficult to do that using essentially the same strategies we've used in an on-premise V1. So quite pleased with that. It's interesting that there's a difference. I think it's a bug, but I'm checking with Mike on that. In the no link secret, for some reason, the name of the claims is not included, but in the with link secret, the label is included. So I'm not quite sure why that is, but presumably that's just a bug in the implementation. But I'll find out that. Obviously we need to publish the schema so it can be left out. There's no reference in the tests today and the objects we're printing out to where the revocation update for Alasor comes from. That we have going too deep into it with Alasor. What the holder does is they request an update to their witness, a value they hold, and then they use that in creating the presentation. And so much like the holder has to get the deltas or the status of the credential in V1, they have to get an update in Alasor for V2. Obviously the holder needs to know where to get that and that's not provided in the information now. Presentation schema, this is an object that I've been thinking about the last couple of days as we've gone through this. I call it a presentation request, but that's not right. It's the schema. It is what is being asked for, but what's. So the idea in and our presby 2 is basically a a. It's much like a presentation exchange a. A verifier requests for a single credential the the attributes they want out of it the the information they want from each credential and then at a higher level. Multiple credentials can be asked for and so on. And so this is saying here are the claims in the in what's called the presentation schema. So it more formalizes the idea that there is a schema associated with the presentation. And the holder processes that schema to determine what their presentation is going to actually look like. So here there's a schema much like on the. Issue inside of what's being asked for. Now, this is what's throwing me off is there's this is the actual looks to be the. The credential itself that's being passed in. And I think what this is is this is the information that the holder assembles. In order to generate generate the presentation. So I think this is all of the various information that's provided. Within the holder themselves in order to produce a presentation and this is the actual presentation. So this shows the various values related to the proof of knowledge for a signature. So those are the number so this is revealed revealing attributes for the revocation. Interestingly, even though there's no verifiable encryption or membership involved in this. That information is provided in this presentation and I'm not sure why that is in this play in this particular presentation. The only thing we're doing is disclosing one of the fields. So even though we're not doing these other things, the values are included. And again, this is a session I haven't held with Mike yet. I was hoping he was going to make the call today, but he's flying right now. So we could go over those things, but. I don't have a presentation request included in the printouts yet. So I'm going to get that hopefully this week and be able to look through it. But as I mentioned, the current model is like diff presentation exchange this presentation statements, which reference the claims in a single credential that the verifier wants proven. And then those can be combined those sets of statements can be combined into a higher level. And then into a presentation schema. And finally, as I mentioned that I've gone through this already the presentation itself. The noting the items that are always there. The one thing I did not see at all was the equivalent of the aggregate proof. So proving that something comes from the same link secret. And I do have to talk to Mike on that because I don't see that. And I think that is a concept that would need to be added to this to be able to show that if you're going to present. Provide a presentation based on a set of credentials that they would be. They would all come from the same link secret. Anyone has any questions on that, but I wanted to go through that. The last thing I had and again this. Okay, Timo, yeah. Yeah, a few questions on like some of the features it supports. Well, it's because I saw that claims where an area structure with with claim names. Will it natively support like nested structures and also like arrays and these kind of things. Yeah. I believe. I'm not sure. I'm not sure. I've had. I've had several conversations where we've talked a bit about that and I've got my recollection is I've received conflicting information about that as to whether the arrays are. Would be supported. I think nested would be easy in that. I mean, all you really need to do is flatten it out. That's what that's what happens today. In like bbs plus and the other ones is it all gets flattened into a flat array. Or a flat list and so that's easy enough done with what I don't know is whether an array would be supported and whether possible. My understanding is it could be. But. And and for use with generic W3C credentials where where. You know, we've currently we have a limitation that in in W3C format and non-creds B1 you have to. It has to be a non-creds format first W3C second with the credential subject completely flat. So we're aware of that. I pretty, I think we can get there, but I have to talk to Mike to get his take on it and how we would do it. I think that might be a bit. The tricky one, the big thing I see about that is how one expresses the presentation request. Presumably. You know, if you have an array. How you would say I want the, you know, prove to me the third item in your array is is complicated. My guess is you would do something like say. Show me the third and, you know, this value and this value out of this array and you would show all of them in the array. I don't know. That seems to be to me the most complicated is how you figure out how to how to request information where you have a raise. Super difficult, I think in in W3C because they flatten everything out into the end quads. Yeah, I think with with a raise, I think with this presentation stage, you can, for example, using the JSON schema syntax, you can, for example, say this field needs to be an array that contains the value. Stephen. And so, if I would satisfy that with limit disclosure, I would disclose only the property Stephen in that array. I know in BBS, they did, I think they supported arrays. Also, but a problem was raised. I think that you could see how many entries there would be in arrays. And I think that that was a problem. But I think yet we could always define it higher level away to do nested structures but I think it would be good to include that. As like if we're going to create like, this is how you define ammo threads feed to with W3C credentials or or whatever that that we support them. I think that is a, yeah, a very nice feature to have. Yeah, I know in with CL signatures, there is a cryptographic value per item and that makes arrays essentially impossible. And I believe that goes away with these other signature schemes, but again, that's where, you know, my knowledge of the cryptography the underlying cryptography is, is, is limited. I'll take that as a key question to talk to, to Mike about. And another question is, I think link secrets have been like, sometimes we said that like, it's, it's a bit hard to like, they're not always really secure because you always generate them software based and then you share them. And is that a thing that is going to try to solve for like, I don't think so. I don't think there's a way to solve that. And so it becomes a security privacy trade off. I don't know of a way to solve it. I've spent some time and thought I was on the edge of coming up with a way but I don't know of a way to do it. I know that there is a way as soon as you force going to a hardware based key you, you are by definition requiring a unique identifier and therefore you're, you're losing the unlink ability. So that's going to be a challenge. I don't know quite the answer to that. All right. Last thing I wanted to bring up at this meeting was to go over the quickly the annual report. So I have put together an annual report as a draft and published out. Hopefully people saw that on the discord channel and the email. So this is a requirement from the hyper ledger to see to to put together an annual report. So that's what this is about covers the metrics for the past year, the diversity adoption of a non cred. You know, the different formats. Some of the things Timo you just mentioned with the, the why it might not be the push away from tying it directly to an indie ledger and things like that for pushing it forward updates to prior things we try to push and then finally the goals. Big one being what were what a lot of the folks on this call are working on, which is the W3C format completion. And this is just a formality completion of that spec. But, but moving the V2 forward and getting into a lot of the things that we're talking about. I just went over as part of this. So that is what's been put together. I encourage everyone who's interested to go through this to provide any comments or updates. And then we will shortly be presenting this at an upcoming W3 or TOC meeting. That is all I have for this meeting is any comments questions from anyone on any other topics or anything else you want to raise. All right. Well, thanks all have a great week. It's a very short week for me. So I'm going to have a great one extended weekend. See you folks. Thank you.