 Alright, welcome to the March 4th and on crids working group meeting of 2024. Um, looks like we won't have any updates on the BCDM work. W3C BCDM work, um, but I do want to talk about the presentation flow. Cover in that, uh, Victor, your issues, um, might talk about the pluggable signatures work you've done. And then, um, some ideas on. The hyper ledger mentorship program so we can nail that down. I want to get a submission in as soon as possible. Um, we're recording, so we'll post the recording after and others that can't make it will be able to listen. Um, reminder, this is a Linux foundation and hyper ledger foundation meeting, which means the Linux foundation anti trust policy is in effect as is the hyper ledger code of conduct. Um, let's see, am I editing yet? No. Tweak that down so I can see that I'll post this and chat in case anyone wants to help update or add their name to the list of attendees. Yeah, I'll keep chat over there and handy. Alright, let's get into the topics. Um, announcements, um, they're in the, um. In there, um, announcements, there is a upcoming zero knowledge proof, um, webinar in April and as well in April, IW is coming up anything else that people want to talk about, um, in this meeting, is there any other topics. Oh, Martin is here. Good. Oh, and gold. That's who good. Okay. We will have an update on things. Okay. Um, let's jump into the agenda update on the W3C BCDM work, um, credo by fold project progress. Martin, do you want to go over how things are going? Um, yeah. So, uh, the PR is merged into credo now. Um, but we're still waiting for the 0.5 release, right? But it's, it's not available in an alpha release. Okay. Um, any progress on the by fold or thoughts on how you're going to progress with that? Um, I'm currently working on that, but I haven't made too much progress yet. I was able to update the agent to 0.5, but I have some trouble getting everything working. Okay. All right. Um, feel free to, um, contact the by fold team. And, and if there's any issues with that, and we'll try to help out as much as possible. Um, Golda, do you want to give an update on where things are with, uh, the acropy progress? Um, I see Peters here. I know he just got to London. So I'm not sure if Peter, are you able to talk? Cause I know you've been more closely supervising the team. Um, he's only his auto autopilot is here. So he's not actually here. All right. So I have been, been watching, but not closely on it. So there's two complications. I apologize from our team. Uh, tuna, as you know, is in Myanmar and he has to evacuate quickly. So, um, slight, slight delay with that, but he's still been, they've been working on it. I've been seeing them running tests. And the last I saw was they were having a little bit of difficulty getting some of the tests to pass. So we should be quite close. I know we're aiming for them and to have that in mind. Um, I will go look at the code and see if I have anything else specific to report, but I do know that they've been working towards the 6th and that their, their issue is with the tests. Okay. Um, I believe their, um, the plan is there's a, a acopug, um, acopy users group meeting tomorrow. Um, at the hour after this and their, their, as I understand it, they're planning on presenting at that. Okay. Okay. Super. I will double check with everybody that we can. Kenny has mainly been running the tests and he will be able to be there regardless of the rest of the team. Okay. Yeah. We'll make sure we get that. Excellent. Okay. And I know I'm pretty sure they're meeting with Ian as well today and Ian's been monitoring and so on. So Ian on our side. So good. Yeah. Appreciate it. Okay. Okay. Thank you. Okay. Next, uh, I wanted to do a presentation. This came up, um, Victor, um, from the University of Toronto has been working on and our credits v2 has helped out in producing some, um, like things like debug statements so we can see the objects and, and other work. He's got a, a, a Python notebook that allows him to run things, run the crates and has produced some interesting things. He raised a question the other day on discord for Mike and I on presentation. And so that got me into thinking about, and I did a presentation on the flow for an on credits v2. So I thought I would present that and then we can use that to drive off both the ideas for this and then as well hoping so might get your feedback on it and then make sure we cover Victor's questions. Uh, as well in this as part of this. So this is all about an on credits v2 and pres presentations. So the idea is how do we get the flow. Topics I want to cover presentation request format, what we're going to use. Um, adding different ZKP types into the presentation request, inserting ZKPs into the presentation itself, and then cover a bit on revocation and link secrets. So, um, the presentation request format has multiple options that we could choose from. And on credits v1. And so it that format is relatively well known. We've got a full section in the v1 spec of what a presentation request looks like and how it works. And so that's a possibility we can use. Um, it allows for, uh, has, has, I'll cover the different attributes as we go along. Um, diff presentation exchange is what is being used. Um, in the, um, W3C VC DM work in, uh, in our credits v1. So that is another alternative. It is a fairly well used. Um, presentation request and presentation supply format. Um, has a lot of the, um, capabilities we would want. Um, and so it is, uh, and, and is used by a variety of communities, including open, open ID for VCs. Um, so those, that's a good way to do it. And then there is the, and on credits v2, which is. I think a little different. And so I've kind of got a proposal for how I'd like to see that used and an idea and, and Mike, I'll be looking to you. So goals is reusing existing approaches as much as possible. Ideally, we could upgrade from a non credits v1 to v2 and sort of evolve the, the v1 presentation request without doing a radical change or likewise update to diff presentation exchange. So we're reusing the existing diff presentation exchange approach and taking use of that. Um, obviously those 2 approaches would have to be somewhat extended. I'm pretty sure to presentation exchange. I'm not 100% sure, but I presume it would need to be extended to support the new and on credits v2 capabilities. Um, make sure that we've got, um, the way to request certain types of, um, the, um, CKPs to be there. And then we definitely want to be able to have multiple credential handling in a single, um, presentation request presentation. So we want to be able to request multiple credentials in one go and get them back in one go. Um, and on credits v1 has this format. The, the key thing there is you've got to request it attributes or requested predicates as two separate ways. You can have multiple sets of attributes in there. Um, you can specify the names of the claims you want to have obviously because and on credits v1 only supports a flat list of attributes, then it's, it's good enough to just have the list of attributes. So the restrictions allows you to focus in on exactly what credential or credential type you are looking for. So the restrictions include, I believe it's seven different items. You can have a name, credit, credit ID, schema ID, schema issuer, credit issuer, or the issuer of the credential itself, and then things related to specific names and values of, of claims. So specific claims and values of claims in those restrictions. So those are the things that restrictions can be. You can have self attested things. You can have specified revocation related to either all of the attributes, all of the requested attributes or a specific set of restrict a specific credential. And predicates, which likewise allow you to specify the only type of CKP predicate supported, which is a numeric expression and then the value, the claim, the, the operator and the value you want to compare. But you can also have the same types of restrictions. So that allows you to focus on it. More extensive example is available here, but those are the capabilities you get with the v1. Issues for v2 is insufficient CKP expressions. Obviously the single predicate type is not enough for all the different CKPs you can have. The revocation handling of a range has been problematic from the start. And so it would be nice to clean that up. That's been a pain for implementers over time. What is that? Can you elaborate? I don't know what that is. This, basically having a range is not very useful. The two use cases you want is I'm, the main two use cases you want now is I want a current, I'm not revoked now, or I want some time in the past. The idea of the range. Yeah, it's the time stamp. The idea of the range was a verifier could say, oh, I'm willing to accept, you know, the last five days or something and they could put a range in, but that just confused people. So it's not technically wrong. It's just, it's, it just was not helpful. Made things more complex. Well, so all of those should be fixed in v2. Yeah. Yeah, it's more I'm talking the request format. Gotcha. Okay. You know, how would we evolve this to support v2. We would have, you know, CKPs revocation handling, obviously support for complex names, JSON structure. I'm basically in there, and possibly ends and or is in restrictions. There is some of that, but the, this one use case that actually comes up a fair amount. I want to allow one of many vcs to be used. I want, I want to enable, you know, these fields from these different types of, of vcs that are actually different, but they have similar names, stuff like that that came up, but it's not that crucial, but it did come up in, in our, our attempts to deploy things. The second example is the diff presentation exchange. So again, we have a more complete example where we have a real world. In here. You're able to request. You have paths. So it supports structured. You can specify which, which fields you want out of it, you can specify the issuer and various things like that you can do expressions. There is some support for predicates. And I'm just not sure how rich that support is and how, how that compares with what we've got in an on creds v2. So big issue there is just the expression of CKPs. As I say, this is used diff presentation exchange is used fairly widely so that's good. And so this is an obvious choice to, to move to. And then finally, there's the non creds v2 presentation format, which is an example is here and it's basically, here's the list of claims I want to have back. And here's the information associated with those claims that I have to provide. Yeah, I've just realized. Yeah. Super interesting when you get into some of these. You know what you've got to provide for commitment or verifiable encryption and so on. These are the. This is the information needed in the, you know, extending out either in our credits v1 or, or. Diff presentation exchange to allow us to do that. Okay. Issues with that it's a completely new format and not really designed to be multiples you can provide multiples but the presentation request format itself is for a single credential, and you extend it out. Somehow, and the somehow is to be determined and that's what I want to get to the way I think this could work and might check me on this so verifier creates a presentation request using one of the existing approaches either a modified and on credit v1 or a diff presentation exchange. So that's the presentation request format that the verifier constructs. Then the holder logic consists of. As it happens today query the wallet for credentials that satisfy the request given an on credits v1 or a diff presentation exchange query the wallet to find the sets of credentials that satisfy the request. Once you have those. Possible UI at this point, not really relevant to a non credits but in a proper flow. You know if you're on a wallet. You figured out what credentials you have in your phone in your wallet. And you show the ones you're going to use to respond. You might ask the user do you want to share this data to confirm they really want to respond and you also might want to. If multiple credentials can satisfy the request, which one do they actually want to use in this case. So if they're asking for a university degree and the person has three of them. They may want to select which of the three they want to use so the UI will pick. A default one likely the query from the from the wallet will pick a default one usually the most recent that satisfies a given part of the request. And then there's an option to say, oh, by the way, there's a bunch of them if you want to switch you can. And so ultimately you wind up with a selection of credentials to use. So, assuming it's a multiple credential. It could be a single obviously but if there are multiple, you wind up with a list of credentials, each of which will respond to part of the potential credential, the presentation request. Then what I think has to happen is a conversion of the presentation request in its given format to the in on credits v2 format for constructing the presentation so this process will be given a presentation request and the credentials you're going to use as input constructs a an on credit presentation schema per source BC. And so, while we still continue to use the in on credits v2 format it's sort of under the covers within the holder. And it constructs it based on what's needed for the given credentials and the the presentation exchange so that's a conversion process. Then you generate a presentation per source credential then you generate a verifiable presentation with the embedded signed. Drive VCs and the proof across the VCs. Mike, what do you think of that flow does that make sense to you. Yeah, one thing we might want to add to maybe holder processes presentation request is. Does the verifier send all of the public data necessary or should the holder retrieve it. Okay, either the verifier has to say somewhere along those lines there has to be a known registry of where that's retrieved from. Yes, yes, yes. I don't know where that belongs does it belong in the verifier saying this is where you can get it or does the holder just know it and then both holder and verifier kind of have a predetermined share. Where those restrictions in an on credits v1 and diff also has the ability to say those things oh it can come from these issuers. Well it's not just that there's there's. I mean we're dealing with verifiable encryption where did those keys come from because it could be in order. Right. Oh sorry that's what I meant by we've got to modify these to to provide these capabilities to put whatever inputs sorry whatever inputs are needed for them where you said public. So where there's public things they can reside but where where it is specific to a ZKP that they want to get those have to come from the verifier I believe. Because I mean we've got to add a ability to do that. Right we're allowing multiple membership tech checks now. And so that could come from anyone that's not the issuer there's revocation. You know that should come from the issuer but doesn't have to you have a revocation manager that's separate you know anyway, but that's all my point is. Yeah, okay. None crates to already supports that we just this is all above the cryptography layer. Right. And that's what I'm trying to get to. So I'm, I'm brushing it aside with this general statement about oh we've got to have a way to express the ZKPs that the that the verifier wants. I'm just glad includes the additional data. The photographers aren't the only ones that do hand waving. It's hand waving right now but it's the it's the way we'll go so I think, you know, we, we definitely need to start from standardized or, or, you know, commonly used presentation request formats and these are the two that make sense. We have to extend them out to include what's needed in doing the, yeah, in doing the verification as you mentioned. Okay. The next question is the ZKP handling and, and the big issue is what if there are multiple ZK please ZKPs apply to a single claim so if you're just revealing a claim. You know, you have the claim name and the claim value so if you're doing selective disclosure and you're revealing claims that's all you do in in V1 we ran into the issue. When using the W3C BCDM that what happens if you have a predicate multiple predicates on the same claim. V2 code will just say hey, you know, I can't do the predicates and reveal it because there's no point in doing the predicates. So it's kind of results in an error right now. That's all the V2 code. Yeah, that's fine. That's not the issue. The issue is more, I want to have a domain proof and verifiable encryption on a unique identifier like a driver's license. Yeah, V2 already supports that. I know it supports it I'm saying how do we request that how do we handle that how do we get the data back to the verifier in a standard way so if we want to support the W3C BCDM. So again, this is a layer above encryption. We know we can produce it how do we get it back in a standard way to express in the derived credential. We want to use the W3C BCDM as the way to provide the presentation but we have to be able to have essentially multiple values for a claim. And Victor, is this the issue you were running into? Yep, this was one of them. Okay, so the idea, I mean, the ideas are not great. They're generally hacks that we put in as a convention what I would call hacks, just some way to do it, which is that the claim is complex JSON item with an item for each ZKP type. And so you would have DL being the driver's license number as the as the claim, and then you would have complex JSON that says, you know, domain proof colon and value verifiable underscore encryption as a name and then a colon and a value for that. And so you would basically make the value for each claim is in itself a complex JSON item with potentially a set of names and values associated with it. And the other is you put a suffix on to each DKP so you do DL underscore domain, and you give it a value DL underscore verifiable encryption give it a value. So the claim name is essentially repeated with a suffix on it. Those are the two that I can come up with I think this is probably the easier one. It's not great. Any thoughts ideas. I think it would be great if I could sit down with someone who understands W3C, whatever that name was. Yep. And just reconcile, because I know exactly what the cryptography needs, and they know exactly what the data model needs and how we could reconcile the two. I don't know if there's an expert of that here in this meeting, or someone can connect me. I mean this is just a for this this is just the derived credentials so it. Whoops, you need both right you need both the request and the presentation. Yeah. Whoops, sorry. I'm all over the place where my God. Back. Let me get to here. I like you have just trying to shoehorn everything in I think if we can propose changes that are reasonable. I think the people go for it and say oh there's actual use case for that. Yeah. What we want to look at is here. I mean we don't have to do it in this meeting I'm. No, I know I'm just going to give you a quick view of what it looks like. So here's a presentation where right there. Where we're sharing. So the credential subject. So this is a presentation. It's got a bunch of stuff and then you've got an array of verifiable credentials. And then for the data you're actually sharing about a credential, you've got this. So the credential subject and then this is a claim this is a claim this is selective disclosure there's this credential actually has a lot more in it. And then finally, this age equals true. So this is a predicate. So we're we're sharing a predicate and all we're saying is age equals true. However, if age had, you know, four different and on creds V2 ZKPs on it, true isn't going to cut it. Presumably you'd want to have multiple values in here like the verifiable encryption value or the domain proof value in here, and you'd want that to be expressed as part of the credential subject. And so the question. So the question is, do you put it as a structure in here where you've got multiple, or do you, you know, hack age underscore and something else and put it. I would just do age as a struct and then like the result true or if it's the encryption, it's the cipher text and proof. I mean, that's how I would do it. Okay. So that would be this one. Whoops. Value for claim is a complex JSON item. Okay. Yep. I think there is a man who did weigh in men who's born he did weigh in a bit on this. And I think that's where he was going as well so I think that's reasonable to do. Again, he was just limited in the in the question he was asked was limited to just the predicate. And they do want to put it into the standard. He wanted predicates in the standard in some way but wasn't able to get it there. Okay. So that's the main issue. And so the idea is we would have a complex JSON item which we would define and say, okay, here's what the potential values are. The same value pair for each, each potentially potential type of ZKP that would be there. And we would put that in and anything selectively disclosed is just disclosed. Okay. That helps revocation handling. And inclination is to do it exactly the same as an on creds v one, which is rather than having a that that as we're you've shown in an on creds v two right now it's explicit and the, and a revocation is inserted by the issuer as a specific claim. I would say we would want to have it as either on or off per source credential and that it's automatic based on that. So it's in other words it's handled as a convention of how the claims is done much like a link secret is handled in in v one today. So, don't leave it entirely up to the issuer to name the field, and what they want it to be and put it in or not it just automatically goes in if they specify that the claim is going to have revocation or not. That model works better. Again it doesn't change the, the cryptography it just how how the user interface if you will how the, the data flow is. The verifier may or may not know if a holder has a revocable or non revocable version of a credential and that's where this automatic handling comes in nicely. Consider a request for educational credential from any university they're basically not saying some universities will will and others won't support revocation and so what credential a given holder has may or may not have revocation and the verifier won't know until they actually get the presentation whether revocation is there. So, this is definitely an issue that has come up a lot in v one, and was part of the confusion on that. If I request revocation, and you have a non revocable credential are you allowed to present it well you absolutely should be able to it's was the issuers decision to support revocation is not the fault of the holder. So they should be able to present that credential whether or not it's revocable so that's the goal we have presentation may request inclusion of revocation. So true, or for a given point in time. So dropping the range. The now is so true is similar to now. And maybe there's a way to specify that like you can say zero indicates you want revocation but it can be for any time and then otherwise you specify a integer. Being a, you know, a given date time, a UNIX time measure of what point in time you want revocation checked. If the verifier knows exactly what issuer and credential type, they're asking for in theory they could provide the accumulator in the request. And that's what you were thinking Mike right that the verifier could give revocation information in the request itself. Yeah, I mean, yeah, mostly the only thing he really needs like if you're using Alasor is the ID. Yeah. That that only applies if if you know exactly the credential type and issuer they're going to provide it anything that allows flexibility there which I think we need to provide. This doesn't work. Well, we'll have to go over what that looks like. I'm the most part, if you're using say a blockchain for this. Yeah, I'm going to have a timestamp at which it was written. The ID which is just the verifying key and the actual accumulator value and that's it. Yeah. And so my thought is that the we're going to need the accumulator value and a timestamp associated with it or a version associated with it. And the revocation managers. Right. What's that version is the accumulator value. Does it change it's like a hash right just changes. Okay. There's nothing else to really do with it. Yeah. Yeah, I guess that's okay because the verifier would then say, so the idea is the holder sends the verifier the time version of the accumulator used and the verifier gets it so if the time version is the accumulator the verifier would still confirm with the revocation manager this this accumulator does exist. Right. Yeah, I mean, they can't trust the holder in other words to that that the accumulator exists they have to go confirm it right. Yes, well the verifier could also lie right and say I want you to prove against this one, and the holder can go check go that doesn't exist. Yeah, the same. Yes. Okay. And then the other one is possibly the holder could ask the verifier to update their witness for the desired accumulator sure this should say to the desired accumulator. Is that right. Well, that could be done. Yeah, that well that's just the verifier doesn't know if they need to update or not right right the whole. Right, but the holder could ask the verifier to do the update. They could. Yeah, only only if they're using it. Alice or I wouldn't want them to do it for any yes. No, exactly. I'm not saying for any other. And then finally, okay. Ideally, and this is is the we would use the VCDM credential status for this. And this is where it gets weird. The VCDM allows for multiple types of statuses revocation is one of them. For some reason there's a desire. I don't quite get it but there is a desire to support other credential statuses in the VCDM. And so you could actually have multiple, and that gets kind of interesting how to support that. Yeah, like suspended revoked. Yes, exactly. They would be alternative statuses though they wouldn't be simultaneous statuses. Exactly. Yeah. Oh, oh really, you could only have one at a time. Well I'm asking that that's a question. Oh, I think you could have suspended and revoked. So yeah I think you can actually have multiple in parallel. Yeah, that's a little problematic because then you have a lot of combinations you have to decide what to do about to have a rule like there's five rules now you have to have like 25 rules or more. Okay. So this is an area of research a bit is is what does the VCDM support and why and what are the use cases you want. Yeah, I mean I would just make that argument very strongly because the thing is, if the people accepting them have to set 25 conditions. Exactly. Yeah. Like this is revocation just is very clean if you just say we support revocation yes or no. And which is yeah, it's clean, but doesn't cover all the use cases which I think what what's got to be looked at and how the W3C VCDM works. Okay. So that's revocation handling. Again this flows, both on the presentation side and on the credential side, which is, you know, what is the claim called. How does it manifest into the credential if it's revocation is supported or not. So, and it's very similar to link secret handling, which is again, I think we would like to support link secret automatically so it's automatically built into the claim and automatically included in the credential schema in the credentials and the presentation and always disclosed. So this is the and on creds v1 model, which is there's always a link secret. It's always put in so it's not. It doesn't get included in the claim schema. It just is automatically added as part of as part of that claim schema without the issue or doing anything it when it issues a credential there's always a link secret in there. And when doing a presentation it always gets disclosed. And Mike, you don't see any issues in that right. It can always be there they can add additional blinded secrets or blinded claims if they want, which is the idea of the v2 extension but but having a link secret you're not, you're okay with that. That's fine. Yeah, okay. I think that's all I had for this. Victor I don't know if that helps gets you far enough I mean we did. I think this idea that we're going to use this first idea is a complex Jason item we can give you, you know, you, we can just pick the names for each of the items. Is that enough for what you need. Yeah. Okay. Okay. As I say the most likely is diff PE because it automatically handles the Jason path idea so you can have complex. Jason in the credential itself which is what we want to be able to do. So I think we should we should be covered for that. I'd like to get some examples produced of these where we have complex Jason but that's going to take a little bit of work because it's got to go into the credential claim as well. Okay. Any other thoughts comments on this. There's all sorts of predicates that we could do. Do you want to create like a registry that says these are the current predicates and then we can always as needed. Okay. All right. I think it would be nice to say, here's the predicates we support. Here's what they satisfy, maybe how they work at a high level, and why you, you know, here's a couple of use cases for him so. Yeah, clear reason and benefit. Yeah, I think when you go to the W3C if we need to modify the data model in any way. Yeah, yeah. So that's good. Okay, and I have a dog arriving. Yeah, go buddy. Okay. Mike you did the pluggable signatures PR. Did you see my note that it's not and the tests are failing. Not anymore. Well, not locally I've pushed, pushed some minor changes to see if that would fix it because when I do the cargo test local they all pass. Okay. I definitely have you updated it since the other day, because it's definitely not working. I can see it. More this morning. Oh, there it is. Okay, sorry about that. I didn't see that. Oh, it's still didn't. Still didn't work. Hang on. A lint issue that's an easy fix. Yep. Guys and you're linting. Yeah, that's a new one. Okay. So you got that covered. You're going to have that in and we can get that done. Okay, good. Excellent. Okay. Thanks. Okay, so we'll have that submitted. The hyper ledger mentorship program is coming up. So here's all the information we did this last year. It was very, very successful. So we would like to do another one. So a couple of ideas for ones to use. Mike of the, these are ones we've talked about, but we only. Discord sent discord messages back and forth. Replication manager implementation or the post quantum, I think are the most likely. What do you think? There's also they could add it bbs plus. Oh, okay. Yeah. What order do you prefer of these? Probably the bbs plus. And then risk just those first two you have. Okay. This one you think is a stretch. For post quantum. Yeah. Okay. After talking with Oliver Sanders, he said they're, they're still optimizing things. Okay. They're trying to shrink the size of the keys. Like, I don't think anybody wants to deal with a nine megabyte secret key. Or an eight. This is the. Definitely. This is the sexiest. If you will. The one that's going to attract the most attention, but if the, if the underlying work is still in flux, yeah, we probably don't want to touch that. Well, I think the revocation and adding bbs plus. We'll give it a lot of attention to all of that. That's true. Absolutely. I mean, these are necessary. Yeah. And bam, it's going to be like, Hey, not only can we do revocation and constant time. It's super fast and also preserves privacy. Yeah, exactly. Without a lot of the negatives to current things. Yeah. Most quantum work is still progressing. I mean, heck, you see. NIST had to extend their competition by another couple of years. Did they? Couple of years. Interesting. Well, two of their methods that they actually standardized in round four got broken. So now they're like, Oh, we got to go longer. You know, Interesting. I hadn't heard that. Okay. Yeah. They got broken. So they had to drop it. So as far as like key encapsulation methods, they're down the two signatures, they're at three. And so now they're trying to add more key encapsulation methods, which is equivalent to a key exchange. They're just number two. And then one of them that they approved Kiber. Daniel Bernstein, you know, the inventor of 50, 555 19 the next cha-cha, he's claiming that their lowest version 512 is broken. So. And he's written messy. And he's written a few paper. Yeah. So I mean, it's all over the place. So yeah, As far as the work goes, I just wait. So. Okay. I think this one area over the next year or two. This one, I think he's going to get done sooner than later. I'm thinking this one time to be spent on. Yeah. Maybe the revocation stuff. Yeah. Yeah. Okay. Okay. All right. Any other topics for today's meeting? All right. Thanks for attending. That wraps up for today. Thanks. Take care. See you.