 All right, welcome all to the Anoncred's working group meeting for the 1st of, no, the 8th of January 2024. Glad everyone is here. Hope everyone had a good break. I know I've had a long stretch where I've not been thinking about things or thinking about other things. So good to get back to this and we definitely have a bunch of work to get done. I want to introduce the topic of the Anoncred's roadmap. So, that'll be briefly, but that'll be a future discussion. Primary topic for this meeting is the areas issue, credential and present proof attachment formats. See if we can nail that down. Use the great work that team most done. To try to get that all prepared so we can move forward with an implementation. Reminder, this is a Linux foundation and Hyperledger foundation meeting. So the Linux foundation antitrust policy is in effect, which is on the screen and the code of conduct is linked in there. Everyone is welcome at these meetings and everyone is welcome in our discussion. Welcome and introductions. Welcome to all joining and welcome to those new to the call if anyone wants to introduce themselves and and mention what your interest is in being on the call. Please do so. The mic is open now for any introductions. Hi, my name is Devin just helping out new to all of this. Yeah, all of this blockchain sector. And yeah, just just learning and trying to help out where I can. Yeah, basically. Good. Where are you based. I based in Florida, but I go back and forth between Florida and Costa Rica. Welcome. Good to have you here. All right. Okay. The topic as I mentioned is the non credits roadmap so the for those not familiar with Hyperledger Hyperledger has a quarterly report from all projects and at in the TOC last year. They introduced the concept of an annual review. And so that the first quarter. Quarterly reports for each year will will change to being an annual report. And there's a new structure to the document. And the idea here is to get a. A sort of look forward of what the project is going to do or has the plans for the project over the next year and. Once we have those to look at a look back on what was accomplished in the year previous. So. This is a little different from the the quarterly reports, which have become quite routine to to build out and just to talk about the progress being made. So I'm working on the an on credits. Annual report. But one of the topics we'll have. Is the roadmap and creating that so. Looking to have a discussion next week at the meeting. The possible list. I'll have a more. Complete document to drive it from but. The. Topics the 1st 2 are obvious ones and on credit W3 CBC format what we're here for what most of us are here for on this meeting. And the finalized be 1 spec both of those are. Very close in and you know, not just on the roadmap, but but very active the finalized 1.0 spec is. Just 1 pass through probably a few more hours of work and a PR a few PRs to complete. So that's. Almost done. An on credits V2 is the area where where we really want to see work done this year. Thoughts I had with it and just coming up with this combining. The work we're doing in an on credits with other work happening in data integrity proofs and BBS plus signatures so combining those efforts. And it doesn't have to be an on credits format or things like that. It's more about getting CKP capabilities. It's possible and and easily used in a variety of verifiable credential use cases. It's really about the maximum privacy preserving that we're trying to keep. We want to look at combining. We've got for ZKP revocation, which currently is Alasaur was which is implemented in an on credits V2. And seeing about whether and how that can be combined with status list 2021 I think it's actually very close and potentially quite easy to do. So looking to do that, obviously, taking an on credits V2 and putting it into W3CBC format. The big thing there being how much how much further can we go than the flat format of an on credits 1.0 the pure list of attributes. We're continuing to work on the hyperlature labs of Gora, which is the underlying cryptography. Evolving the 1.0 back into a 2.0 SPAC and then finally the big one that I wanted to mention would be post quantum signatures in a ZKP. We have support already in an on credits to for what are called PS signatures. There is a version of PS signatures that are evidently. Plugable that are post quantum. And so can we combine that with the in on credits work and experiment with that. So those are the those are the projects, the roadmap we're looking at at least. And I'm interested in having a longer discussion about the various things in there for how we can move those move those forward in 2024. So as I say, that's a topic for next week. But I wanted to introduce it here and get people thinking about it and and what else we can possibly do. Okay. Major topic was areas issue credential and present proof attachments. I know Timo you've done a lot with these test vectors. Maybe you want to introduce where you're at with it and what you're thinking about. Do you want to take it back in that direction? Yeah, sure. Let's do it. You may have to help me a bit because I've been out of it also since the new year but I can go for a bit of the the test factors that I set up and maybe solve the. I'm sorry. Do you want me to stop sharing and you take it. Yeah, I think that would be useful. So during last week last meeting, we discussed to set up some test factors to discuss like what is it that we are we targeting. So I set it up before the end of the year. And there's some outstanding questions in here still. So I'll quickly go over what's the list. I try to include a lot in here and basically what it should cover is everything that you need to create. So I'm going to add an Anacred credential, transform it to a W3C credential, issue it using the new attachment format and then also create a presentation of it with the presentation exchange. So that's all the messages. I also included the where is it all the private data needed like the link secret so you could like completely run rerun the flow that I did here and get the same results. So I think how I created the test practices I first created like a legacy credential. And then I use the code from DSR. So the code that's currently in like the pull request with the JavaScript wrapper, and I transformed it to a. Let me see. Yeah, I transferred to an Anacred credential. So this is also actually the actual output is the science credential. And I think it still has no this is already the update from where they removed like the like updated to the data integrity. So this is the credential then. And the next thing I did is I use digital bills, our libraries to take that credential and add an upwards signature also using data and equity proof to it. So this is also an actual valid signature on the credential. And then we have like a credential with two proofs on it one is the Anacred one, and the other one is the data integrity proof. The code for that is also in this repo so you have like generate. And at words this is the code for it. So you can rerun this again as well. And next is all the ways to issue it. So we have like the new attachment format where we can send an offer. We send an Anacred offer data with all the key correctness proof credential definition that we need. And also the thing to bind it to credential like a date, for example, for the non-anacred credential and credential that you want to offer. Then you have. Yeah. So that this one here. So this is the new attachment format that you're proposing. Yeah. And so it changes. Okay, so offer request get this new format as well. Yeah, so yeah, and I still need to add it that that's what I also send an email when it is there need to be some options added here but like the general like that will be very similar to the current one I think. Yeah, but like the main thing we add I think which is very important is the binding methods. And that is how do we bind the credential to something. So keys or crypto material is something that the holder can prove when presenting it. That's the goal of it to add this mainly. And so we have to link secret for Anacred's and then the Bitcoin signed attachment is the one I propose to do like we we sign an attachment using a specific key or specific date. And that way we can prove that we own a date and then we can use that as the credential subject of ID in the issued credential. Then that's the offer then the holder so the one that will receive the credential will send a request and it will include binding proofs. So for the link secret, it will be the same as you normally would do with an Anacred's request, but now you include it in here. And for the Bitcoin signed attachment you will reference an attachment ID that will be included in the message and then I also included here a attachment which is signed so you have the data. I think I can decode it here quickly. So you see I prove ownership of the date and I do it with the nonce that was also included there to prevent replay attacks. And once that is done, we can go to the issue message which just includes the credential and in this case it will include two proofs. One with the data and technical proof and for Edwards and the other for Anacred's VC. Yeah, I think one thing that was outstanding here, a question for me is like, could the ID also be included in the Anacred's credential. And I think your stance on it was yes, Stephen. Yeah, yeah. So then you need to add it to Anacred's schema. If you want to have a credential, have an ID in the, what is it in the Edwards credential as well then. Yeah. Okay. That was all stuff then I think I currently I haven't done it like that but I'll update it to to then include ID fields in the Anacred's. Yeah, and then we just need to make sure that yeah, there's like that, because it makes it easy to disclose it and that's something we should watch out with them. Yeah, but I think it also like it also doesn't make a lot of sense to only sign it for the non Anacred's credential. So it's like a field that's in the credential but in the credential in all forms. I think so. Otherwise it's another secret value that an on credits has to know about and ignore. Yeah, yeah, so it depends on like if you were to first sign it as an Anacred's credential and then at ID field then you wouldn't run into the to the problem but probably afterwards yeah if you then parse it. Yeah. Yeah. Okay, yeah that makes sense. And so and we can just air off if you don't have it. Okay. So that's it for issuance, the issuance flow, and then we have the proving flow. So, I also picked a different to see. Let me see. Yeah, so I converted a Anacred's presentation request wait let me pick that first and Anacred's presentation request. I have two groups where we asked for the name and the height and we asked for the age which is greater than 80. And that is I have transformed that into a different presentation definition. I hope I converted it correctly. Yeah, so I converted into this structure where we included this one because like we lose the ability to filter by credential definition ID. So we have a credential which we can do with an Anacred's request but like for example using this you can already filter it quite well. Another thing I thought initially we could filter by is the type field as well. So basically if you have the issuer and a credential type that I think that matches quite with a credential definition ID. So filter credential definition ID may be using the verification method that's added to the proof which we landed on, I think. And then we request other fields we request name and height I haven't had any like filters for what it should be. And then I added a predicate with like H is over 18 and the predicate is preferred. And in this case this could be submitted using both like a zero knowledge proof where I only disclose H is over 18 but let's say I don't have the Anacred's credential. And this would also be possible because it's preferred and then I would just reveal the H attribute completely and then it won't be a zero knowledge disclosure. So this making it this way allows it to both submit an Anacred's one which is more like selectively discloseable or one that reveals the whole value. And then in here I have this is another outstanding issue is like how do we specify which formats we support because the current way to do it is using the proof type but because all the types are now going to be data and technical proof. You're not really saying anything about like which actual crypto suits you support. So this is a new format I added here and also one I opened an issue for in the play format registry to see like OK how do we want to add a new one or do we want to extend the current ones with a crypto suit which I want to get some input on. I think for now we should just probably go with something and wait for this to process further in this space. I think because this can probably take a while for this to resolve and I don't think we should wait for it. So this is the request then and then you can update that into a mission. This is just a it's one credential we're submitting here. So we were saying like OK this input descriptor satisfied by credential zero and let me see. I think yeah. So and this is then the presentation. So it's presentation has one verified credential and how I did it like this now is I removed the predicate complex structure open for discussion happy to change it back. This is I dug a little deeper into the presentation definition spec and I found they actually have a native way to describe how you should do it. And that is if you include predicate then the value that you include in the presentation should be a Boolean Boolean. And so I was thinking like we could come up with our own way. But if the presentation that exchange specification mentions how you should do it. I think we should follow that. And the only thing we lose with that is that we can do multiple predicates on the same attribute. But I think that's a fair one. So there you go. That would last your video or your audio good. But do you mean go down with where where would we put H over 18. I mean, didn't you have something where it says age true like I don't like the idea of age true right. It should be. Is adult true or age over 18 true because you could also be saying like, you know age over 30 or age under 10 or you know there's a lot of things you could say about age. It should be 100% semantically meaningful and self contained. So if possible, can we make the predicate be, you know age over 18. So you're saying that the item that Jason item would be age over 18. Yeah, because I think that's a very common thing it's a really common thing it's like are they an adult but maybe in Europe, maybe it's over 14 or maybe it's over 21 and so you know just having age true isn't a thing right. I think how, because the reason I went with true is because they define it like this in the presentation exchange specification. I'm just saying that the, the thing should be age, it should be eight over 18. Yeah, I think, but I, I'm not sure because then it would be a bit weird because if we go back to the example presentation request. Presentation presentation is that I'm requesting property age, and then suddenly the presentation includes age greater than 18 so then there would, there won't be a mapping between like I want this property to be over 18. You're asking I want age to be over 18 and then it's put in another property, which you could do but then we deviate from what the presentation exchange specification describes because they say you request that, or you request age, and then the value of that property should be the output of the predicate so age over 18. And requesting age over 18 but yeah I guess if they're already requesting age a lot in a lot of actual implementations we have to live with it. But if they're not already doing that, we could actually make the example be like request age over 18 I mean they should actually be requesting what they want which is is the guy an adult that's what they're requesting. Yeah, I mean, there's so many ways to do that and this would vary on every use case. I think this is the way to do it is is just to say, we've got a predicate on what we've requested a predicate on a on a particular item. Okay, okay, so we're saying the predicate is true we're not saying that the value is saying the predicate is true predicate is true. Got it. And trying to merge the name plus the predicate into into a single string is difficult I think it's, I think that's a stretch. No, no I see what you're saying then it's because you're, you're, it's this field is this predicate on this field true, and then you're returning the value on the field which is weird but okay. Yeah, yeah. Yeah, it's a bit weird but I thought like, because it's described in a specification that we're using, I feel like if we don't have a very good way to do it, I think we could best follow what somebody else already wrote up. Yeah, got it. Okay, if I think of anything good I'll do it but I understand. Yeah. Okay, so sorry that was a very long walkthrough but that's, that's all the different test factors that I have set up and so there's a few to do some and I think we now covered most of them and then I can update them to to make them actual verifiable. And then you could write your implementation against it. I think. Yeah, so the only thing is the RFC that needs to be finalized. But if we have consensus on the mall, I can work on that tomorrow morning directly and have a version like that's ready for implementation of feedback by tomorrow. Okay. One of the things I'm really nervous about is, is the amount of the amount of work. It's, it's feeling too large for this code with us and I'm very nervous about that and I don't want to have that happen. I think one of the things we have to do is Timo you've done the perfect, I think the correct amount of work here as far as figuring this out but what one of the things I don't want. One of the factors hung up on on this first pass is too much of combining the two signatures at once. So, we need the focus to be on just getting an on credits in W3C format across. That makes sense. We've got a path to how we would do it, but the focus needs to be just on on just getting the non credits through and W3C format to try to keep the scope down in this first thing does that make sense Timo and others. I think that that makes sense. I'm just a bit not sure what the good point would be then to like what is included and whatnot. Well, certainly, I don't want, I don't think we should spend time doing coding examples that that handle the, I've gotten a non credits already and then I attach a non and non credits. Another data integrity proof to it. Let's just go through with I all I the only path we want working. The end of the code with us is I've gotten a non credits schema I create a credential and it goes through and the end as a W3C format. The trickiest part of that from what I see is the is the definition, the PE so if you could think about that Timo as to you know how far you want to go with that and and where that cut off should be. Yeah, that's a good one. Don't want to do is is have the. We want to know what the path is, but we don't necessarily have to have the code written. So it's this balance of, let's not do anything that screws up the path. But let's not do any extra beyond exchanging and on credits credentials. Yeah, I think like if I would focus on like if we are not doing the multiple proofs on a credential. I think my focus would be mostly on I think the proving part because I think that is where you can gain like the flexibility. I think if you also look at like m docs for example they are very specific in how do you do interoperable proving but the issuance part is very like because there's like there's tighter integration usually between these two. So I think, like even issuing it in an on credits format but then proving it as a door to seek credential and VP using presentation exchange I think would be what I think is the most beneficial. But yeah, otherwise I think doing the new attachment format and presentation exchange proving also fine. And then we could add like not proof in the future or something. But it's up to you also I think to decide like what is most important for you to get out of this. Yeah, I mean, the most important for me would be an end to end test that shows and on, you know, occupy issuing receiving a presentation, you know, obviously, where we use it BC gov uses it is so my other hats on is issuing from by holding by AFJ and and proving to an acopie verifier. So that's the that's the flow that's most important. So I think the attachment format is the biggest thing right now is to get that going and finalized and then we can for complete the phase one here's what we're trying to do. We're trying to get very clear on exactly what is going to get implemented. That's what we want to get down to right now. And we're, we're getting tight on that so I really want to see that. So we've got a combination of things that if you could push on the attachment looks like it's pretty much complete. Looks like we do have our set of test vectors look pretty close. I'm thinking as we highlight which of those test vectors, you know, the form of them that need to be worked on and then what specifically will happen in the code. Ken, I can't not hearing you if you're speaking you got your hand up. Maybe. Yeah, we can hear you now. Yeah, so I said, I earned some, some test. Okay. Test suit on the test vectors and some of them passed on some don't. Well, I don't know if that's normal, but I think it's normal. And I don't need this. If there's other samples that can compare to it. I get what I'm saying. Yeah. Yeah. The V2 for testing against the V2 test suite. I think there would be two changes needed. Can you go to the credential Timo display the W3C credential. Yeah, so we'd have to change the context at the top and the issuance date. Yeah. I don't know what the year would be. 2023. Is it what year is the credential V2? It's it's optional now, I think. Oh, and then you think this should be an issuance date you took out it needs to be valid from. But I think the property is optional now. So and we just added it to be spec compliant. So, yeah, interesting. That's interesting. I didn't know it was optional. So everything's now optional. Issuer is not, I think. Type context. Okay. And the W3.org 2018 credentials V2, the 2018 there. That can't. That's probably not right. I just changed it to V2. I didn't know what to V2 context URLs. Yeah, start sticking in years one after another 2022. Let's go 2023. I bet it is. See what resolves. 22. Oh, okay. In space. Get rid of the year entirely. Okay, so this should let me see if I can save it as a new. I'll add it here. And that's V2. So. Could you run it again against the new file I added? Well, verify it also with because I think. DSR has also added support for V2 already via like a version switch. So I should also be able to get it out in V2 format from their library. Yeah. One thing. Okay. So I'll be working. Let's keep in touch on, on making the progress. I think the. Thing to do. I'm going to look at is a hack and D to try to figure out. Okay. Here's exactly what we want to get implemented and what needs to get implemented in. In Akapai and I'll try to pull. The. Some of our developers in on that. I've also asked Andrew's been on vacation Andrew Whitehead, but I've asked him to focus on the and on credits. Pull requests. And get those finalized so we can get stability in the main path. As you mentioned, Timo and your note that. That we need to get the main stabilized. The main branch stabilized. So get Andrew focused on that. And then nail down exactly what we're going to have implemented. In the two, in the two frameworks as part of this code with us. Feel free to get together if there's anything in between, but otherwise we'll meet back next week to discuss further. That works. Good. All right. Any other topics for today's meeting. I had one thing I tagged you in today that we could maybe discuss. Just to clear up some confusion on my side. And I know, like, if this has any implications. Wait, I'll quickly share my screen again. Yeah. What was that topic? Shoot. I saw you post it and. Oh, yeah. So we were in the progress of, uh, removing in the SDK, uh, support and moving and everything to an address. And in that we kept some tests that were using in the SDK, but now created the proof using an address. And it turns out that the test were now failing because the proof. That was created is different. Um, and, um, it seems that, um, um, with in the SDK, if you reveal an attribute and a predicate, um, from the same credential, it will create one proof. So you have the combined proof of the attribute and the predicate, but with an address that creates two proofs. Um, um, one for the predicate, one for the attribute. It still creates one proof if you combine all attributes, but like there's no link anymore. It seems between the attribute and the predicates. Um, I don't know if there's like an overarching proof that, that does, uh, this, but, um, um, I'm curious like whether this has any security implications. Sorry, that's not what I was expecting this to be about. And I had a real hard time figuring out what the differences between those are. So I probably should have done more to sort of combine them. And understand what the difference is. So I'll, I'll talk to Andrew more about this one. My understanding is this was, was the same between the two. Um, I thought there, there might be something. Different between them, but I would not have expected different proofs. Um, see. Yeah. So. The quality proof. Yeah, as you can see here, like. There should be one equality proof per source credential. And one. GE proof. Per predicate. And that should not have changed between in the SDK and. As far as I know, that should not have changed. So I will, if you're saying that. Yeah, go over again, what you're saying is the difference between them. So if, if, if you look, this is an address. Um, and you have two proofs in this, uh, uh, two proofs that are created in the, and the first one is an equality proof for the name attribute. And the second one doesn't have any attributes revealed, but this closes the H is over 1550 predicate. Um, then if we look at the proof for, um. In the SDK. Let me scroll. I can understand you. You couldn't make sense of it with this. Um, if you look here, um, there's only a single proof entry. And on that is the revealed name and, uh, um, the predicate proof, but the proof request is the same. Um, and I've been confused about this before already because it seems in the proof request structure, there's no way to indicate that if I, for example, want to name, um, uh, attribute to be exposed and age over 50, that I can say, I want these to be from the same credential. Well, if you ask for multiple attributes, you can say I want the name and the age to be from the same credential, but there's no, in the proof request, there's no link between it. And it seems that it now also sees the most separate proof. So in the, under the hood created one proof of that. Okay. Um, yeah, I got to think about that. As far as I know, that should not have changed, but obviously I'll talk to Andrew about what could have changed in there. Cause it should be, as I say, I mean, it's all, it all comes back to what are the source credentials you're using. And the grouping, as far as I knew always was, you know, there's an equality proof for a source credential and then however many GE proofs for the source credential, regardless of what was in the presentation. And then that was mapped to, to the presentations elements. So that this change is a surprise to me, unfortunately. So I'll have to talk to Andrew about it. I understand this better now. Thank you. Okay. Yeah. Perfect. And we'll wait to do this response. Yeah. Okay. Okay. Thanks. Any other topics for today? Thanks all. Have a great rest of your day. However much is left. Thank you. Bye.