 All right, welcome to the last meeting of 2023 for the on creds specification and on creds working group. Eliminating the need for the non creds Jason LD this is far too late coming but I apologize but hopefully I've got it. I'll clear it out and nail based on some back and forth with man who and things. Issue credential and present attachment format sounds like Timo you've done some thinking I've done some thinking I've got some stuff laid out as well. So we'll have a discussion on that. Reminder this is a Linux foundation hyper ledger foundation meeting so the anti trust policy is in effect which is on the screen and the code of conduct is linked in. All right. Any other introductions announcements anything to add to the agenda. Otherwise we'll jump right into it. All right. Special at context. Part of my hoping you can still do something about this. I'm hoping the changes are really small, mostly eliminating or moving things but want to get your feedback on that. I put a hack and the document that I shared around and then I've got a presentation to go over sort of what the points are. I assume you can see my screen right. Yeah. Yeah. Okay, so summary is. So got a hack and be a why and proposal for how which is basically going to the data integrity proof, and then hiding anything we need credential status and the predicate format are the most interesting things. Add the most complexity to it so I thought I'd throw a little bit out there on that. The why is because if we include it, even though it's only for an on creds. The context does get included with the signature for, you know, if we attach to proofs. The context gets included and the general handling of by a non creds processors or sorry by Jason LD processors is they won't load a context they don't know at build time. And so to introduce a new context. I would prevent the processing of non and non creds signatures so that's why I meant it was so pushing hard against it is that even though it is helpful for a non creds it's not helpful for non and non creds those that want to if we were to issue it to a holder and then the holder presented to a verifier, the verifier would refuse to process it because it would have a context that didn't know about that build time. So they don't do any dynamic runtime loading. In theory, we could keep it for non creds W3C verified predict verify presentations format for the same reasoning and that if you are presenting in a non creds by definition whoever you are presenting it to understands and will process and on credit So that argument would be, you know, they would allow it. But my feeling is we probably should continue forward and just eliminate it overall. So the first part of it is to use data integrity proof. And then the value of crypto suite so when you use crypto suite when you use when you use the type, you need to specify in the context information about the type. By using crypto suite though it's similar to a tight it has values but you do not have to have the the crypto suite value specified in a context you can just put an arbitrary string in there. And the handling of the proof value is dependent on that string. So the only thing you can mess with, if you will, can can can play with is the content of the proof value field, but you can more or less put whatever you want in that. So, my, my thought is we have three values that would go into the crypto suite and on creds VC 2023 and on creds. So presentation VC 2023 and an on creds VP so these latter two would go into the to the two proofs entries. So this one for all of the each VC within a verifiable presentation for each derived source VC, and then this one for the VP itself. And so if we look at jump to the revised. This is what a VP would look like so there's a proof on each of the verifiable credentials within a VP so this would be an array you could have multiple source verifiable credentials. You have a crypto suite for each of those and then a different one, and that's because the proof value format is different for the VC versus the VP you've got different things in the proof value. So that eliminates the need for a credential schema eliminates the need for the credential status. And I'll talk about that later. And the identifiers, which are the only things the actual data elements that you lose those those would move to the proof value so basically, we're going to have to move the VC and VP. Which is kind of annoying, but acceptable. The loss is you cannot look at a verifiable credential in this format and see the, the type. See some chat there. I don't think it's really necessary. I, we, I could make the string longer to add the prez. But I don't think it's really worth it but but I guess I could check with what Manu thinks I didn't think it was that serious. I think he, I guess we could eliminate the one and just make it recognizable and do VC and VP. So combine these two. I'm open to that suggestion. I don't know. I have an idea. So I'm just reading Timo's comment there about eliminating this one and just using this one and detecting the difference between the two sort of snipping the value and detecting that it's different between the two. So you've got the first thing the, the processor does is recognize the difference between the two. Do you think that's better, Timo? No, not necessarily. I just saw Manu suggested it in his email. So if he suggested he probably has a reason to do so. So I was just curious why you didn't like include that suggestion from him. My, his question was, did I need, did I have it as a typo? He thought I'd made a mistake, but I've been very deliberate in putting that there as different. I'll go back to him and do a quick back and forth with him on that in that chain. I should have sent him a message on Friday about that. Supporting VC DM 11 versus 20. I see Andrew's joined. I'll go back one Andrew just so you know, we want to eliminate the app context. It is a good idea to do. I agree. Now that I've thought about it with non and non credits processors of proofs. The major technique we use is to use the data integrity proof as the type of the proof and to have crypto suites, three crypto suite values to hide the, the to put to understand what the proof value is. And in doing that, moving the identifiers, which are the data elements that we need moved into the proof value. The thing is, do we support VC DM 11 versus 20. Here's where I could use a little help on Rust and what's the best way to do this but basically, it's a it's a minor difference for VC DM 1.1 we need to add an extra context for data integrity proof for 2.0. The day integrity proof is included in the VC DM at context. So that's the only difference up there is is what we put into the context values are code into the context values and then the issue or issuance date changes to valid from. I believe those are the only two changes that would impact us from 11 to 20. It would be nice. So that, so that we could put it if then else piece of code in so that we could change it change it not dynamically but but at coding time I think. So, so we would actually code in the differences but hard code that oh we support 1.1 or we support 2.0 and it would just do it. Timo. Yeah, this is a question I ran into today and I was curious like, in the difference between fee 1.1 and 2.0. And would it be possible for credential to be compliant with both versions as to as the difference are so minimal or would that be not be possible with like the differences in context URLs. So because you have to have the at context of to be either the, the 1.1 or the 2.0 at context. So the very first one is so if I switch over to here, it's this line right here. There's a specific context for the to be to. So you have to pick one or the other. And this line gets added if you're using the 1.1 and this line and this data this information is included if you pick the 2.0 up here. Does that make sense. Andrew. Yeah. I think what one of the differences for 1.1 we need to add vocab rule for the attributes. Oh, okay. Because it's included in to. Okay. Okay. And you then don't have to define every variable anymore so it will like allow to be issued without a custom context for your custom properties. Yes, there's a default context. Yeah, default namespace rather for undefined terms. Okay. That that is it. Not a bad difference. Okay. So what about this idea and Ross, I don't know. Does it make sense to have a little flag even if it's hard coded to say so that the differences between the two are defined in the code and switching between them just means changing the variable does that make sense to do. Yeah, I think there's only a few things that need to be adjusted for. Yeah. And it's reasonable that it be just a, I mean, a compile time of, you know, a coding time flag, even though you can't really apply. I believe so. Okay. Okay. Okay, so that's that. And I think we leave it at 1.1. And put those in and then and then just have the code in there and the differences for what 2.0 would look like so we know how to change it easily. credential status suggestions so the idea we originally had was oh let's just put the credential status and we put the revered value into there. We didn't really do much for us so so moving the revered value into proof value again that the loss is human visibility. I put in a few options into that document to say, well the way you could, the way you can improve it where you have multi proof VCs is you could implement a parallel status list 2021 credential. You have to revoke in two ways. So which is of course horrible but you you implement the two of them and then the other thing we could do is have a hyper ledger and on creds artifact that basically returns a status list 2021 object derived from the REVERGE and I think that would be very easy to do all it would do would be to monitor the the REVERGE of the identifier it got and return return back a bit array in the format required by status list 2021. So my thought is I put an issue in that somebody could implement if we do that then then status list 2021 the credential status could be a status list 2021 type thing not a specialized one for a non creds. But that's a future thing I don't plan on doing that or suggest that all I want to do right now is we simply don't include any credential status, even if it is a revocable credential, and the REVERGE ID goes into the proof value. Hope that makes sense. And then finally this one. Changing this would be relatively easy. Except for the darn array thing. So I'm suggesting just doing some sort of delimited string. I know it's ugly but in the vast majority of cases it will just be a single value and we just do it as as the age is a value of a string and so that it's no different doesn't need any type doesn't need any definition. Is this okay. What do you think of your of my suggestion to I think you suggested to try to get it into the VC data model fee to. Yeah I sent him an email saying I fully support that. But I don't think it helps us enough today to do that and I don't think it'll be accepted. It's fine. But for now I think we just go with something like this so we don't have to mess with an app. This is only in this would only ever be delivered to a and an on creds verifier that has requested and an on creds verified presentation so this has, this is completely independent this is entirely within an on credits only. So there's no sort of broader context for it. Yeah, I think I just did the goal would then of course be to have it in a more like generic way that could be supported by other crypto formats in the future and so then wallets won't have to implement the on credits way of doing predicate but it would be more of like, how do you do the on credits in an entity. Well the, the more interesting thing for an on credits is like we support an on credits be to supports many more things than this. And so that also becomes an issue for an on credits like this is not sufficient for an on credits to so as a future proofing. It doesn't really help doesn't get us very far. How do you specify a membership set membership in here, or something like that, like it just doesn't help to look at like, maybe we can get it as part of like verify potential data model. But it could be like a separate context that you could add in which is like, I don't know, prove some like as like advanced proofs types where you have like predicate where we start with that one for now and like it could also include like other types of advanced proof mechanisms that you can add to a VP. And if you want to support these advance ones you only need to support, like that specific context URL. Yeah. Again, given that we want to implement this immediately. I don't think that's really an option. So, I'm happy to, as I said to Manu happy to help in whatever way he needs to to build something in that in the BC working group. But for what we're trying to accomplish which is delivering on credits in w3c format I think this is sufficient. Is there a better way than this that anyone can think of, or is this okay. It seems this would be a trivial change in what we've implemented and as I say it, it really is just for human consumption anyway. And from a processing, one assumes all we're doing is looking at the actual proof of the predicate itself, or predicates the proofs. I mean, this seems a little thrown to abuse, I guess, if the verifier decides to just look at what's in the credential status, sorry, credential subject block. Instead of using the non-cris methods to pull out the attributes. You know, they could just parse this out and then end up with that string for value of the attributes. Oh, I see what you mean. So would you do age underscore predicate? I mean, most likely if we couldn't format it in the array format, because we would, we wouldn't have a way to define this type of term or the value term there. I would probably just put it right into the proof value and not try to make it human readable. What about, do we just do these two? Predicate and value is still the undefined terms here. But I mean, they would be in the default namespace. Would they be, yeah, would they would be covered by vocab? Yeah. It's not tight. Vocab is not defined in V.1.1, right? But we would add it. So that's what Andrew said earlier is, sorry, it's on this one. We would have to add the vocab in the 1.1 and in 2.0 we wouldn't because both are included. And who would add that because we're trying to get rid of the custom context. Does every user of on credits then have to add that or? That would go automatically into the, into here. So we would add it right here. These are hard coded values in an on credits so that we would just be putting these in hard coded. And so we would have to have the third whatever the form of doing vocab is. What does it look like, Andrew? Yeah. Oh, I see what you're saying. Okay. I get it. Okay. So it would go like that. And we'd drop that. So this would be hard coded to this. I noticed I have to include it as well down below. So it would have to be here as well. But neither of these things have to be. They're just hard coded values. So it's not something that an on credits is introducing and anyone that is processing. You know, some other proof type, and it's particularly up here. If there's another proof type like an 8025519 they would be happy to process both of those. So it wouldn't cause grief. Like having an on credits one would. So, again, what do you think, can we settle on this so you think. Is the feeling this would be a better way to go with and remove the. Simply remove the type and rely on the defaults vocab to specify these. The, the RDF expansion of this is kind of ugly. And if it ever does get this kind of thing does get formalized in the data model. That representation will change. Yeah. I mean, this is ugly no matter what, but again, if we assume we have no option to include any sort of type in here that eliminates. We can't include this because we don't have any place to define this type. Well, they, I think the type just gets expanded. Just gets added to that default namespace as well. So you think we can leave this in here even. So you're saying we could leave a type in and just not. And not define it. Yeah. I'd have to run it through an RDF process or to check, but. Okay. So we just leave it as is, and just ignore the fact that there's no such things and on credit predicate to find anywhere. Good. Okay. Which gets to more where you're where both menu is trying to go and what Timo suggested earlier, which is we try to keep it. The same. Okay. So we just leave this as is. Can you verify that Andrew is, I don't know if you can do that on the fly, but if you could verify that that would be good. I need the HackMD link. Okay. There it is. Oh, there's no predicate in this. Oh, yes, there is. Yeah, so you'll have to tweak the proof at the bottom. So just on the fly here, get this added to just so we've got it. All right. So the final would be to have some sort of part coded flag in the repo so that when we need to we can switch from BDM one to two simply by changing a hard coded variable, eliminate the creds in VC and VP, use data integrity proof with the crypto suites. We need to have three. So for now we'll go with three. Move the required data out of the credential into the proof value and basically those are the identifiers schema cred depth and reference. We're going to not make this change pending Andrews. We're going to do a quick investigation. And the result is we have, we have the two in here that we get, and I still need to fix this then. Does that sound reasonable. Are you able willing to make that change. Yeah, it seems quite small change and easier. I appreciate it. Sorry, it's so late. I really appreciate it. We would really appreciate it if you could get that done. I'm getting a syntax error on the info cab. Maybe I'm not remembering that. Okay. Remember being like, base. Hang on one sec. We could look at. I believe you had it in these so. Yeah, here it is. Oh, I see. Look, see how it is. Yes. Neither was something weird about it. Okay. All right, we'll leave it at that. The next one. Let us know Andrew what you find. The next topic is the, the format. So this is, this is now into the what the two teams. Okay, so I just written an, Animo are going to do an AFJ and acopai. And the issue is this idea of a new attachment. I've done some thinking about it as well. So Timo, why don't you go ahead since you presented last week. And then I'll. Follow up with what I've been thinking as well on this. you Timo. Can you hear me or? Now we can. Do you want to share a screen? Oh, I see this. Yeah. For issuing don't receive credentials during the Airsoft group last week. Got some feedback from that. And based on that I make some changes. I think one piece of feedback was to like, I added like a way to do different formats. So KDOT credentials and JSON LD, but that added another layer of abstractions. And you already have multiple attachment formats. So I think the main change I made from last Wednesday's call is just focusing on data and equity proofs in this attachment format. And then if you want to issue a derivative sheet, JDRT credential doing it with another attachment format that will be defined. So it's still a working progress, but like, I think most of the features are at least in there right now, where this is a credential for attachments, where you can indicate which binding methods there are supported. And based on that, you can send a request and that allows you to do both Anocrates issuance, but also like ED24549 issuance if you want that. And there are different binding methods that are defined in this RFC. In this case, you have Anocrates link secret. We can also just call it Anocrates binding, where we define the needed fields for an Anocrates offer. And as well we have in this case, and that comes signed attachment. So you can do using a signed attachment. And in this case, we support like the key and the web binding using Edward signatures. We can include an offer of the VC and we can include some options. These are still to be defined. It will probably be very similar to the current traditional detachment format. And then in the credential request, I can include a binding proof based on the binding methods that have been defined in the offer. And that could then be an Anocrates link secret, or did come signed attachment, or I could also include multiple and that would allow issuing a credential that is both an Anocrates credential as well as like bound to a did, for example. And then finally, the last method will contain the VC, which can be a proof object or an array if you have multiple. And then more down here, I have to find like the different binding methods. And this could be more could be added in the future if there's like other ways you want to do binding. If there's some like hardware based binding you want to do, we could just define a new one in here that would allow to do the binding process based on hardware bound keys, for example, if you need custom properties for that. So I think in that way it's extensible to also include other binding methods. I added something in for like which data model version should support it, I'm still not really sure on this. And what we want to do with it, do you think it would be good to make this attachment format flexible and which data model version it supports, but not sure yet how we want to do that. And maybe that should also just be like, again, another attachment format where it just like we have a V1 and a V2 data model one, if that's the way to go. I think one other thing I wasn't really sure about like, you see a lot that you can indicate like, that's currently what we have in the current protocol that you can indicate which crypto suits are supported. And if I look at how OpenID is doing it, their stance is that it's not really relevant to the holder of a credential, which crypto suit will be used by the issuer to issuer credential, because the holder does not need to verify the credential itself, it just needs to be able to present it to a to a verifier, which in this case of Anocrates is a bit more difficult because you need to have very deep understanding of Anocrates to be able to create a proof, but for like normal credentials, you just have to make like a proof of the credential subject, so the binding method. So I'm still not sure like which metadata needs to be included. That's the same. That's right. It is the same thing. Yeah. Yeah, but so but there the difference there is is it does matter because they the crypto suit supported for them is like which crypto suits are supported for the holder binding and not for the the suit the issuer uses. So I could use an RSA key to do the holder binding, but the issuer could then issuer credential using ED2549 and that's okay. Yeah, I understand. Yes. Yeah. So that's currently what I have for the offer attachment. It's still a bit sloppy, but like I think the base things features are in there and I didn't want to work spend a lot more time on like all the details until like we have some like consensus on like is this a good way to go. Any comments from anyone? I think this looks pretty good. Definitely a bit familiar from the open ID side of things. I don't quite understand what did come signed attachment means in the context, but like wouldn't it just be JWS or something? Yeah, so you would use a did come signed attachment to do basically you would sign this payload with like a nonce in an audience with a specific key and then basically because you have signed it, the issuer knows you are the owner of that key so then it can use that as the credential subject by the and I use did come signed attachment because that's a way in did come that allows you to do signatures on content. So yeah, it's just a JWS. Okay, yeah, I get it. It's just they were already in did come so they did come that seems a bit redundant, but I guess it might be clearer this way that what level it's at. It's not inside the payload. If you could let me have shared back and I'll go through a presentation. So what I'm trying to figure out is how you know, given that we're there's there's relatively little time in the code with us. What is the best way to to share to to present sorry what attachments to use. So I started thinking about that and going through what's the best choice short and long term. So, you know, obviously we want to get the balance right between them and I've got a slide on that. So we've got sort of existing attachments RFC 592 which is called the indie attachments. There's an RFC 0771 that is the same as the indie attachments but it's properly called now the non credits attachments. It is in proposed and hasn't had a lot done to it. So in theory we could adjust one or either of those. We have the JSON LD credential attachments and the RFC 510 presentation exchange attachments which were used and are implemented. I believe in both libraries to do JSON LD verifiable credentials so W3C format JSON LD and because that's exactly what we're doing this time we could in theory use those attachments. Presentation exchange use is a little bit different and then we've got Temos proposed and I've got the link to the hack envy. So we've got links in all of these. I believe I've shared this already but just to be sure let me put this in chat. There's chat and folks can take a look at that. So those are the options. Our goal is what's the best implementable long term solution. So this balance between what's the right thing to do in the long term which is probably a lot closer to what Temos talking about but something that's implementable in a short in a reasonable amount of time so that the folks doing the code with us can do one of them in a reasonable amount of time and get through it. So RFC 592 or 771 and on creds attachment is a reasonable way to go from what I was thinking through and does allow it switching to 771 is not absolutely needed but we could make 592 and 771 handle identically and they just oh it's either of them I'll just go forward with that and have the attachment hand what are the same so that we enable a transition so that if you see the format saying slash envy then you do it if it says slash and on creds you use the same handling. So basically a a regex that understands both and leads them to be handled identically can be used for legacy format and detect format so we could use content sniffing to tell if it's a non creds legacy or a non creds w3c format we could use the mime type we could put an explicit flag into them to to determine which what when I receive an attachment which format it's in. If it's in w3c format and if there are multiple proofs on it there would be some extra handling on the holder side so that it can be stored in a way that it can be used as a non creds a non and non creds in a non creds json ld presentation so in other words we want to store in a way that if the holder gets a presentation exchange request it can handle it and if it gets an non creds presentation request it can also handle it. The thank you for putting that in Timo about the did binding and the the holder binding method. If we did that on a on an non creds there would have to be in the non creds credential an id attribute that would be put into the credential subject in other words since a non creds is agnostic of any particular field the only the only field that is it knows about is the link secret that it inserts into it that the the issuer doesn't even need to include if we were to support a multi proof issuance and we wanted to include a way to do holder binding of the non and non creds proof we would have to have a convention that the non creds credential the the issuer would insert a id attribute into the non cred schema and would use it as a did basically would insert a did into it to enable did holder binding so all of that's possible and doable once we get there we have as I mentioned continue to use the existing protocols for an on creds presentation sorry agnostic existing attachments for an non creds presentation um 592 and 771 and we would continue to use 510 diff pe for non and on creds presentation so this is the fastest easiest way to do it but gets us the furthest distance of a longer term does not touch the idea of jwts or anything like that so that becomes an entirely separate issue um we could use rfc 593 and 510 for json ld alignment so reminder rfc 593 is the issuance of a json ld w3 cvc format bc and was implemented specifically for essentially data integrity proofs that are non and on creds um there is no credential offer in rfc 593 that would have to be added there is no extra holder binding data um in the credential request as far as I know and there's certainly not any and non creds um holder binding information so that would have to be extended to support the in on cred data um using 510 um oh also on the issuance need a way to request multiple signature types and preferences implies that a credential proposal might be useful um something timo said on his was interesting in that he said um that it's up to the issuer and not the holder so maybe this isn't needed at all that that it's simply up to the holder sorry the issuer to decide they're going to attach multiple um um proofs on it and that could be eliminate the need for this extra piece um for presentation we can do what I said on the previous slide which is we use 510 if we want a non and on creds w3c format and we use 592 771 for and on creds so um respectively non and on creds and an on creds for the for this I didn't work that very well so let me just keep this okay um and then the other reason I don't know if you were going down this path at all timo but extending rc 510 to handle an on creds presentations and um that gets kind of ugly well I mean it's certainly something we've talked about before and one of these days we're going to look at it probably in an on creds too um is is to look at a way to request an on creds presentation using dip pe by either mapping a dip pe request into an on creds or simply using a dip pe directly to determine the source credentials to use what are the revealed attributes and what are the predicates once you know these um the process to generate a proof doesn't matter what format the um the presentation request is in all that matters is you know what credentials you're using what you're revealing and what predicates you're using it does have an extra holder question because of the dip pe feature of being able to present either vc one and v2 or present vc three I mean an on creds just doesn't have that functionality and it basically comes down to an extra holder question yeah timo um so the like the extra holder question um um how we were we were intending on using this presentation exchange for the on creds presentations um uh because it supports all the features you need to because we it wouldn't be a separate like custom how do we do an on creds presentation request because it's we could just use the dip pe to filter the credentials um and um the on creds level wouldn't have to know that the initial request was like present vc one and two or v3 but if you have decided based on the dip pe logic which we already have in place then you would just construct a request that is either vc one and two or you will construct an on creds request that is a request for vc three and both sides could do that um based on the credentials that were submitted so you because you construct the on creds request later than when you have figured out what of the um constraints you want to uh uh like fulfill it won't be a problem well you still have to ask to me you would still have the code automatically figure out okay what can i produce can i produce this version or this version and then you got to ask the person or the entity to say oh you you know if you you can you have the option of doing this or this and you have credentials that satisfy both which do you want to do yeah exactly but that is all like dip pe and that is for example in our paradigm wallet we already have that logic so there's nothing specific to that so that's all before like we just have in storage a credential with a type we don't care that it's on creds then we construct like everything okay we want to submit these credentials uh to uh satisfy this proof request and then only then we would pass it to the on creds specific handler and then would know like all right based on these two credentials pc one and two create a proof um and then the verifier would just be like okay you chose pc one and two so i know that i need to verify for that requirement i don't care about pc three because you um yeah use pc one and two yeah yeah okay so so the way you're doing um this is you're assuming we will use five ten for an on creds and we'll do it this way in other words we're not going to try to map it into an on creds pr you're going to do the searching for the credentials based on the dip pe lodger correct yeah so yeah eventually we will map it to an on creds uh proof request because we need to provide something to the uh the on creds arrest library okay um and that but and that's only the last step basically yeah that's this question here okay so your suggestion would be to try to do um to not do this to use this and then we have to figure out this problem which might take us back to this but anyway um and that's because the presentation request is expected in the in on creds w3 cvp right do you mean what do you mean with presentation requests so so to understand it i get i get a dip pe we're running out of time sorry about this let but let's take two more minutes to see if we figure this out i receive a dip pe i search my credentials using the dip pe directly which results in me knowing what which source credentials i'm going to prove what what i'm going to reveal what predicates i'm going to use and so with that information i can generate a an on creds presentation but my understanding is that in the presentation is a presentation is is the incoming presentation request in an on creds legacy format is that accurate um no i i i had something in our design doc but i i can add some more on it specifically but i think uh our plan was to just make it a presentation submission from dip pe and on the verifier site you map that to a presentation request so we could like base on the uh the identifiers of the um presentation um submission we could consistently map that to a presentation request in on creds format um so the uh holder and the verifier site would be able to construct the same presentation request based on the um the presentation definition that was um um requested so you only uh convert at at the end of the holder and the end of the verifier site but the other in between you use like dip presentation exchange okay okay i got it i'll i'll update this and and try to make sure we're we're connecting right because we have to do this exactly the same in both right so we got to get this right and occupy an afj um just quickly since we are out of time my concern with the new format would be the time to get it right and completed as part of the code with us so that's a balance we've got to figure out um my thought had been to stick with um five ninety two so using rf rfc five ninety three for issuance is too big a stretch so stick with five ninety two for issuing and then presentations i was going to suggest we just stick with what we're doing as well but i could be convinced to go for presentations to go with um i want to explore this of going with five ten only um so let's go through with that and then my thought on the new attachment format was give it time to stabilize keep moving with it but not part of the code with us so you're you're not tied to it okay all right well um so timo's saying in the chat that he does not like this idea so um we'll see how that let's see how it plays out and and and how well we can define either the new new format or or another way to do it i don't think five ninety three is the way to go um just because it's missing so much so it would to me if i'd want to go if we're going to switch i would want to go to the new attachment format so um let's have that conversation it's going to have to move into the new year um but um if we could keep having conversations online and following up i'm happy to get together for more meetings uh sorry i was going to say it can't happen in a non-credits meetings i'm happy to have individual meetings with both teams that on the code with us directly so um just let me know when you want to meet and talk and um the timing of that all right yeah it'd be awesome bolder if you and timo get together wicker without me feel free and um i'm happy that i'll keep thinking through this and and see what what i could do to help as well yeah if it's okay with guys then maybe you know we'll set a meeting that works for us and invite whoever wants to come uh super okay perfect whatever timeline again i'm not sure where everyone is i know timo's um it's 11 o'clock at night where he is right now so there's lots of um funky times things going on so i'll leave that to everyone to figure out and with that um we'd better wrap up thanks for this much appreciated that was a great conversation take care all thank you thank you guys