 All right, welcome to the January 15th and on credit's working group meeting holiday in the US didn't realize that until a few moments ago. So we'd have less from the US here. But anyway, everyone, as I said, all the right people are here reminder that this is a Linux foundation and hyperledger foundation meeting. So the anti-trust policy of the Linux foundation is in effect as is the hyperledger code of conduct. Let's be good to one another on the agenda. I really want to focus on nailing down exactly what we're doing as far as implementation so that we can get started on the implementations or continue with the implementations for those that have started. And make sure we've got a good design for the frameworks and interoperability. So that's going to be the focus of today's call. And this is about an on credit W3C format. Before we get started, any, welcome to all thanks for attending any introductions people want to make or announcements or any updates to the agenda people would like to start with. Feel free to grab the mic. One of the things I should highlight I noticed as I look over at the list and see if anyone jumped up to the top to speak. Artem is at the top of the list. Artem, fantastic work on keeping up with the requests. All the merges of the major tasks have been done so much appreciated for that. Fantastic work. We finally merged the last of the three major big PRs. We've got a couple more for evolving the predicates a little bit as per requests that have been made. Since since more since the major work was completed. So thank you for that. There are a couple of PRs in there. The CL signatures one was merged today. Enabling the predicate list and we'll look at anything else that might be needed. All right. I think, you know, after doing a bunch of reading yesterday and going through things, I think this represents this presentation represents where we're going and allowing us to really move forward with this. So I'll just go through this. What the heck if I can see it, why might as well go into I can't move things around. Why not? I don't know and I can't see because of where zoom is the slideshow, but I won't even bother. All right. Goal is agreement for finalizing the two designs and adjustments we're going to make in the library and able to enable support of this interoperability components. What are we going to use for issuing and presenting and what attachment formats to use? And then what are the behavior changes that we're going to see in issuers holders and verifiers in and occupy and and agent framework JavaScript in order to both enable the functionality allow issuance holding in and presenting of such credentials and and what triggers these things and then what's in and out of scope. And this last bit, I was a little light on, I was surprised that I didn't have more in there. So I might not have thought of enough things. So let's keep that in mind. And if I've missed things there, please let me know. So I think what we've agreed on is that issue credential protocol will use the proposed new attachment format of RFC 089 W3C data integrity attachments. Timo has put the pull request in here. So we've got a description of what will will be produced in this document. It's pretty clean and concise. We've got an offer attachment, a request attachment and an issue attachment for the items we cover. Detection of when in an on credits credential is to be used what the binding methods are when a we could have multiple signatures on it. And how that would get implemented. So all of that is, I think, well covered. I don't doubt we'll we'll uncover things in the implementation and that's fine. We can and and I'm happy to what what the areas community decides as far as merging this either ahead or after the implementations is fine. But this is what we'll drive off of. Agreement on that any comments questions about that great work Timo on that. Now we've got test vectors available for those attachments. So there's a repo. There's an offer or request and an issue. So if I go to the repo. It's already open, I'm sure, but and look at the vectors. In particular, the D I offer the D I request and the D I issue are the main ones with this extra one being the holder binding for when we're using a non and on credits. So these three and I've got links in the presentation and I should share the presentation. I don't know if anyone. Actually, I can't see the share button either. I can't see those buttons. Maybe I really need to do things around. Okay. Pop that into chat. Okay. So those test vectors and and again as we discover anything in the implementation in the attachments or, you know, and in the test vectors themselves, we can we can adjust them. So that's issuing a credential that only covers issuing. So the proposal as well is that we present protocols using the existing diff presentation exchange attachment format. And this is a relatively big change for an on credits in that a request will come in via a diff presentation exchange. Will be processed. And a presentation returned using that format. Timo the big question I had I was kind of surprised at. I thought the submission would include the proof itself. Am I missing something, or where, how does the, the submission and the presentation. Connect, or what happens in the presentation message or both the submission and the presentation set independently or what's the process. And you would sense. So it depends on like which protocol you use but what did come you include the submission within the presentation itself so you would have presentation submission key in the verifiable presentation and that contains it so I can maybe add another example where it is the combined version of those two. Okay, could you please do that because I wasn't clear. I know about a submission I know about presentation I don't know how they they connect together based on this. So there's an example in there. I'm looking at one in the presentation exchange thing. There is a presentation exchange but it's the submission. So the diff presentation exchange calls for a submission. Which is just this. And then, and it is combined in some way and that's what I'm not quite clear on with the W3C presentation. Which is here is what that looks like. Yeah, so they'll just be in the presentation here as a key presentation. Okay. Added here as the submission would be right here. Yeah, at the top level. So go to that's part of the diff presentation exchange back and it is what gives the map between the request that came across, which is the definition and then how you interpret the presentation to map it back to the definition that came in. Okay, no, having an example will be great and yeah, I appreciate you having those. Okay. I think I put this in here because this is I think we will we will have clarifications and perhaps changes necessary to the 510 protocol. So let's see how to handle it clarifications just for those new to the areas clarifications we can put in without any, you know, version change or anything changes might entail a minor or a major upgrade to the version. So the goal here would be to implement something regardless of what happens and we'll do we'll deal with a fallout of changes of versions and so on. We'll do what we need to do to get it to work. As far as this work context and we won't worry about the administrative overhead of actually getting the changes completed and through. Hopefully that makes sense. I don't want to hold up any implementation because, you know, we've got to get approval to change the version or anything like that. We're just going to get something working with agreement across and and go from there. Okay. The biggest thing I see there is that an on credits has more powerful restrictions than does diff presentation exchange and so we're probably going to lose some functionality. I think. But we'll live with that. So you seem pretty happy that we can do this in a reasonable way and weren't too worried about the loss and and and in many ways we also get we add functionality I think as well. So it's kind of a trade off we'll see how it goes. Okay. Yeah. And I, I don't think we're really losing any functionality. Because I was thinking, and you can even do a on a input descriptor you can do multiple predicates. It seems because you can do like minimum 18 maximum 21 in the same input descriptor and I don't want to be able to create to get some pretty good proof from it. So I don't think we lose any functionality. No, I was thinking more of the restrictions on things like the credit def ID, and things like that. It's the restrictions. The other thing I didn't know was, do you have an example of where the verifier expresses revocation, and how we would do it and Okay, could you sit it again sir. How a verifier expresses that they want a proof of of revocation. I'm okay in losing some of the interval functionality because I think it's dumb. But what, how exactly does a, and a non creds verifier say I want revocation proof of non revocation. I think there is a section I think in the facts back with I'll find it and send link in a bit. Yeah, no rush right away. Okay. Okay, so now this gets us to the behavior changes. And, and here's kind of what I'm suggesting. It changes with an issuer, a verifier and a holder. So with an issuer. The constraint I'm suggesting is that only the issuer via the offer can initiate issuing and an on credits W3C VC. So the holder does not have a say in it. But the issuer does. And the trigger is that they use the 80809 attachment with an on credits settings. They assume that both the issuer and the holder are both supporting it on credit W3 PCs. I'm not sure exactly if how or if we can support both the 1.1 or the two and the two, but we might be able to was just something we'll figure out as we go but I don't think this is a major issue. I think this becomes just something we implement or, you know, worst case hard code into the into the implementation, wherever it happens to be. I had thought it needed to be part of the. And on creds RF library, but I now think it actually. Is is controlled by the controller of the issuer. In other words, it's a business decision that can be made at runtime essentially. So we'll see how that goes. Not a big deal on that for now. We'll use the 1.1 for initial initial work and we'll see. As the implementation moves forward. So the issuer via the offer initiates issuing an on credits in W3 CVC format using and it's done from an interoperability perspective by using a 0809 attachment, the D I. VC attachment. Issuer encoding of the credential attributes is dropped that would be normally done in a legacy and on credits VC, but we don't have encoding in the W3C. So that really is the change in the issuer obviously they have to be hand able to handle receiving back the 089 attachment and sending an issue in. Sorry, sending the issue message with the 089 attachment. The trigger is the offer, but after after the offer is done. They'll be back and forth using the new attachments. The future possibilities could be that a holder responds to a legacy and on credits format offer with a 089 attachment and transitions over so that the holder says, hey, I want it in W3C format. The other is that the issuer could fall back if they get a problem report because the holder doesn't understand the 089 attachment, so it's an older attachment and they get a problem report. Again, those are future possibilities, not something we need to worry about in this implementation. The only thing we're going to have is that there's somehow the issuer will be able to say. This offer using the 089 attachment and that triggers the entire flow the rest of the way. Everything else is based on receipt of information and the processing. On the verifier side when we're talking presentations and I did verify our first and then get to holders because holders are affected by both issuers and verifiers. Verifiers use the 0510 attachment format to request a presentation and so they're using and so they expect back a W3C verifiable presentation with a diff via the diff presentation submission. And it may or may not contain in an on creds presentation. Essentially, what we'll talk about what the holder does, but the verifier simply uses what certainly an ACAPI is existing functionality to send an attachment format. There may be updates needed again to deal with the risk, the way that an on creds restrictions are done in the way that. Revocation is invoked with the way the verifier is expresses that hey, I need a proof of non revocation included with this. Pretty much that should be done in the business logic side and as long as the. Verifier can process the attachment and send off the request that should be fairly straightforward in there. Again. So holder implementations respond with non and on credits presentations, they can do that if that's what satisfies the proof request and and then there's the thing I mentioned earlier about. There's some features in an on credits restrictions, what are called restrictions in the presentation request format of an on credits that we lose. And so we'll have to take a look at that. But again, I think that's mostly in in what the controller constructs as the presentation request and then hands to the framework, whether it be ACAPI or AFJ. Obviously verifier needs to be able to process presentations with zero five 10 attachments. So receiving a presentation from a holder that contains an an on credits format VP. They've got to be able to receive the VP and go, hey, the crypto suite is an on credits. Therefore I passed this to be handled by the non credits verifier or the code for verifying in an on credits verifiable credential credential. And then again, in verifying the credentials, the encoding of revealed attributes must be done. I'm not quite sure where that happens. I wasn't clear on exactly so we'll run into that in the implementation. It'll be it'll be clear in the implementation, I think. But the encoding is in order to be able to verify you have to encode it. I think it's done in the in on credits RS implementation and the verifier won't need to worry about it, but I, we do need to verify that. Okay, so that's the verifier we've got the issuer it triggers it through an offer the verifier triggers it through the use of the dip presentation exchange and now we've got the holder behavior. Once again, the, the proposal messages out of scope, which is one of the messages in the issue credential protocol. So we're not going to worry about proposal at all we're assuming that we only have the happy path case of an offer a request and then an issue. Holders can receive credentials using the existing 592, which is the legacy and on credits mechanism and the JSON LD mechanism so we don't want to disrupt those, but we do want to support the new 809 attachment formats. So they would be able to receive. So existing functionality should keep working and the new 809 attachment formats come forward. If there are is their holder code and this is something I didn't know about AFJ and whether it supports 50593. If it doesn't support it today it doesn't need to add that support obviously the only reason we continue to support. 593 which is J existing JSON LD functionality would be if it's already supported. Holders would be except expected to send the request message in the same attachment format as the offer. So if you get an offer in the legacy in the legacy and on credits format, you would respond with a request message in the same format. If you receive a request in the 089809 format. The holder would send the attachment back in that same format so it gets a holder gets an offer and it responds with a request using the same attachment format. Holders must generated the revealed credentials. I think I got lost in writing that. Yeah, I don't know what I meant by this. I'm just going to mark it as I can't quite see yes I can. I'm not going to delete it because I don't know what it means yet. I'm sure it was something important that I was thinking about. Okay, so that's the holder behavior. So a holder can't initiate. A issuance in. Um, cannot. Generate an issuance or sorry cannot trigger the use of. W3C format and on credits, they just respond to whatever the issuer says. Old format or new and finally, um, on the. Uh, on the verification side, it's the same sort of thing if the if the we don't want to disrupt the existing. Receipt of a legacy and on credits presentation request if that comes in everything flows as it exists today. If the holder receives a 0, 5, 10 presentation attachment, which it certainly in occupy can be done today. What changes is the holder should include health and non credits credentials in finding the credentials that satisfy the presentation. So today. When when a 5, 10. Attachment is received. Only Jason LD credentials are considered as a way to respond. And so what changes now is when a 5, 10 is received, then an on credits credentials may be used in responding. Um, if they are used in responding, we conduct it. We construct a and an on credits verifiable presentation. Um, I did include this and I think this is okay to include, which is it doesn't matter what format. The an on credits credential was received in whether it was received as a legacy and on credits or a. Uh, W3 CBC format. Uh, and on credits either 1, our candidates to be. Used in a 5, 10 presentation attachments and the non credits r s. Functionality, I believe covers that. If we run into implementation issues with this, we can we can address it, but I think this is a safe assumption to make. So essentially, when you get a 5, 10 presentation attachment. Any credential in the wallet is a candidate. For for use in the presentation to be sent back. And then holders send the presentation messages using presentations using the same attachment format as the request. Again, this idea that. If I receive a legacy and on credits presentation request, I'll respond with a legacy and on credits presentation. If I receive an 0 5, 10. I will respond with an 0 5, 10. As far as out of scope, there was a few things in there. We're not going to worry about right now doing issuing credentials with multiple signatures. We'll experiment with it as the implementation gets done, but it's not required. It would be great to have any to-dos tracked and noticed if if. Of what would be needed to make that work. This topic came up last week a little bit. And Timo, I don't know if you want to. Document this anywhere, but we'll assume that if you're going to use both. An on credits link secret holder binding plus a signature. A signed attachment. Holder binding for a non and on credits credential that there there must be an ID in the an on credit schema. Will we, as in with my BC gov hat on will worry about the creation of the A A T H tests. So people will not have to learn how to construct those tests. And, and we can prepare for the execution of those tests. So. We do assume and this was in the code with us that best practices as far as unit test unit tests be done integration tests be implemented. Those are going to be necessary. So those are within the CICD of the frameworks, but the A A T H across will worry about separately. And we will execute them and raise issues if there's problems. So I think that covers it. I've talked a lot. Any questions, comments. Okay. Um, I did expand on this in the. As a hack M D document, which evolves the acopie design document that we that has been worked on and I apologize for transitioning it from a GitHub document to hack M D. I don't know if you're familiar, but it's just marked down, you mark down on one side and mark down visibility. This is more like Google Docs and I actually tried to put in a Google Docs later to try to make it easier, but we I'm happy to use Google Docs as well for this, but I think we need to iterate a little tighter than we can do with GitHub. So I re re re re wrote some of this up front. And yeah, we can go to sync between them, but I, I felt it was really hard to put them into comments and questions and then have somebody else write it. I just wanted to write some things. So I've tried to put in here as as much as possible. What's needed for the acopie work. And so invite you to look at this. So with this, we can obviously make changes directly into the document to fix it. We can see the track track changes or versioning is automatically on. I actually paid for hack M D finally, so that I've got all all versions. Unfortunately, I did that after I did all the updates and hack M D if you're using the free account only keeps 10. So it lost the changes that I made from the original document. So apologies for that. But going forward, we can see changes anyone makes. So feel free to make direct changes into this document. There is a commenting system that you can use or you can just say, you know, Yeah, that Steven says this is silly. Since I wrote it, I can say it was silly. So feel free to put a comments in there and I'm hoping this helps in leading to jumping into the presentation or jumping into the implementation. So I think we can nail down exactly how to do this and get that first part complete faster. And, and an easier way. Yes, the hack and the link is let me grab it out of here. Where did I put it? Oh, you know what I did is I put it into the. No. Hang on one sec. That's not grabbing. There we go. So I put that into a comment in that but here is the hack and the link. It is open for everybody to edit. So you should be able to edit it right away. And I'll go through and and continue to. Monitor that and help out as much as I can as far as nailing down that. I've also lined up a acopai developer as a. As a guide for development. So you'll have that resource available to you for as you jump into the implementation to be able to. Define the code parts of it. That is a level I'm not able to help with. I can help with an awful lot on the protocols and and that experience. But when it gets to changing line 792 of a file, I'm not going to be very good. We appreciate it. We have Daniel when we need him to, but it would be super to have an additional resource. Exactly. Exactly. And I'm hoping you use it. Yeah, Daniel. We'll jump into that as well and and play with that and happy to have direct meetings now that we're implementing in acopai and we're ready to implement. Let's let's have meetings on within with an acopai maintainer directly available. Great. I'm excited. Yeah. Yeah, I'm really excited to get to this point. It's time. Okay. Back to here. T mode. Did you hear anything that scares you or Martin, did you see anything that is unexpected in any of this or is this what you intended. I think it is what we intended. Excellent. Okay, good. Yeah. Savory. Awesome. Okay. All right. Anything else to talk about today? Excellent. Well, as they say, Peter Golda do check out that document encourage Daniel to take a look and let's evolve. Let's iterate on it. And get it nailed so that we can get going on the on the coding on the acopai side. Yeah, no, no, exactly. And I think Peter was about to email you to schedule a meeting with you. So he'll probably do that. That's awesome. Excellent. We'll have a wonderful what remains of your day depending on where you are. Thank you. Thanks. Thank you. Thanks all much appreciated.