WEBVTT 1 00:00:02.940 --> 00:00:13.900 Stephen Curran: All right. Welcome to the June 20 sixth, and on currents v, 2. Working group meeting, few topics to go over presentation data models and predicate types. So I wanted to talk about that. 2 00:00:14.430 --> 00:00:39.699 Stephen Curran: a reminder. This is a unix sorry, a Linux Foundation hyper ledger meeting. So the Linux foundation. Any trust policy is an effect, as is the Hyper Ledger code of conduct as well. The specification that we are creating coming out of these meetings is published under the community specification license, and all of those things are linked in the meeting agenda. 3 00:00:41.680 --> 00:00:55.129 Stephen Curran: so we'll just quickly jump to meeting discussions I do have. just jump into edit mode. 4 00:00:55.370 --> 00:00:58.019 Stephen Curran: See, I've got to clean something up already. 5 00:00:59.750 --> 00:01:04.050 Stephen Curran: so I will do that. 6 00:01:07.810 --> 00:01:17.879 Stephen Curran: don't have any other announcements. So we'll just jump into it. Mike, you want to talk about. I think the the thing we want I wanted to go through was the presentation models and make sure that 7 00:01:18.220 --> 00:01:33.649 Stephen Curran: again, we we did a pass through those. And and I want to see if there's new objects or things to be created or a new one. So I will. stop sharing and turn it over to you. 8 00:01:35.060 --> 00:01:36.889 Michael Lodder: Oh, okay. 9 00:01:37.200 --> 00:01:43.570 Stephen Curran: I guess. Like, yeah. Probably better for you to call it up, and then you can bounce around to where you want to be in that. 10 00:01:45.220 --> 00:01:46.790 Michael Lodder: Okay, give me a minute. 11 00:01:46.950 --> 00:01:50.490 Stephen Curran: I'm at the airport, so I'm just bringing it up. 12 00:01:51.160 --> 00:01:59.289 Stephen Curran: Well, I I I I've got it up. Now let me know if I start turning robot. 13 00:01:59.900 --> 00:02:01.039 Stephen Curran: you know. 14 00:02:02.470 --> 00:02:04.840 Michael Lodder: and known to happen when you're at the airport. 15 00:02:06.030 --> 00:02:08.970 Michael Lodder: Okay? So I'm going to scroll down just to the 16 00:02:13.180 --> 00:02:16.010 Michael Lodder: yeah, I think it starts here. Yeah. 17 00:02:16.620 --> 00:02:17.600 Michael Lodder: Okay. 18 00:02:19.180 --> 00:02:22.650 Michael Lodder: So if we look at. Yep. 19 00:02:24.400 --> 00:02:26.069 Michael Lodder: I call them statements. 20 00:02:26.280 --> 00:02:29.119 Michael Lodder: Yeah, these are basically what you want 21 00:02:29.260 --> 00:02:31.670 Michael Lodder: to be proved in a presentation. 22 00:02:32.790 --> 00:02:35.869 Stephen Curran: Okay, most basic one is a signature. 23 00:02:36.400 --> 00:02:42.800 Michael Lodder: This is basically saying. the data is signed and 24 00:02:42.920 --> 00:02:50.540 Michael Lodder: selectively disclose the following information, so it's either a show, no show or 25 00:02:50.680 --> 00:02:54.470 Michael Lodder: I'd reveal for each claim. 26 00:02:55.210 --> 00:03:00.429 Michael Lodder: And that's all it is, and oh, and the third, the third item is 27 00:03:00.740 --> 00:03:02.459 Michael Lodder: from which issuer. 28 00:03:03.150 --> 00:03:14.239 Michael Lodder: So I just put whatever that issue or object happens to look like which could include the public key revocation information. What the credential schema is that kind of stuff. 29 00:03:14.900 --> 00:03:18.329 Stephen Curran: So what are the things that you can do with 30 00:03:18.420 --> 00:03:29.299 Stephen Curran: and on correct today is, you can say, Well, I need it to come from this schema, but I don't care what the issue or is. I don't care who the issue or is. Is that kind of 31 00:03:29.370 --> 00:03:31.770 Stephen Curran: are you for seeing that kind of support? 32 00:03:32.930 --> 00:03:36.459 Michael Lodder: You could do that I highly. 33 00:03:36.540 --> 00:03:43.009 Michael Lodder: I can't imagine a use case where they would say, I don't care who signed it, because then I could sign it. 34 00:03:43.350 --> 00:03:44.560 Michael Lodder: So 35 00:03:45.040 --> 00:03:58.280 Stephen Curran: yeah, but the idea there is that instead of instead of doing free qualification of the issue. Or you're basically doing okay, give me what you got, and then I'll decide if that's acceptable. 36 00:03:58.330 --> 00:04:00.980 Stephen Curran: So you get a presentation. 37 00:04:01.240 --> 00:04:15.250 Stephen Curran: you could verify the cryptography, but then you apply business rules. So the and the use case I can think of right off is. I need a a a you know, a university, you know, a, a, an education 38 00:04:15.360 --> 00:04:25.790 Stephen Curran: credential. There's no way I could list all of the possible issuers. I will accept it from, so I'll accept it from any that is a you know a degree. 39 00:04:26.000 --> 00:04:29.199 Stephen Curran: And then I'll decide if I trust that issue or 40 00:04:30.710 --> 00:04:32.140 Michael Lodder: yeah. So 41 00:04:32.220 --> 00:04:39.449 Michael Lodder: right here. I mean, if we could rename this right. The point is, this is the information you need to know where it came from. 42 00:04:39.660 --> 00:04:52.820 Stephen Curran: Yeah. so so similar to like. We have restrictions today, which, as a list of, I believe, is 8 things. Is there any reason not to go down that same a list. 43 00:04:53.540 --> 00:05:04.490 Stephen Curran: I can you tell me what the A are? so schema schema publisher, identifier schema 44 00:05:05.310 --> 00:05:09.229 Stephen Curran: scheme a name schema version. 45 00:05:09.300 --> 00:05:12.670 Stephen Curran: So those 4 all relate just to the schema. 46 00:05:13.990 --> 00:05:16.399 Michael Lodder: Okay? So that should be compatible. 47 00:05:16.410 --> 00:05:18.419 Michael Lodder: So that shouldn't need to change. 48 00:05:18.620 --> 00:05:20.470 Stephen Curran: Okay, still, do that here. 49 00:05:20.630 --> 00:05:21.430 Stephen Curran: Yeah. 50 00:05:21.540 --> 00:05:32.950 Stephen Curran: you've got the 2 related to the credential the issuer identifier and the issuer credit death, basically 51 00:05:34.110 --> 00:05:39.579 Stephen Curran: and then the last 2 relate to specific 52 00:05:39.950 --> 00:05:51.270 Stephen Curran: attributes within the credential, which is, must contain this this attribute name, and must contain this attribute name with a value. 53 00:05:53.690 --> 00:06:02.359 Michael Lodder: so I mean, you could apply that for me. The only thing I've needed, and that does mean it's ever used. Case 54 00:06:02.460 --> 00:06:03.500 Michael Lodder: is 55 00:06:03.720 --> 00:06:10.380 Michael Lodder: disclosed, which is like, must contain a flame with that equals or or even just 56 00:06:11.090 --> 00:06:15.379 Michael Lodder: contains the first name. I don't care what that first name is, but they have to disclose. 57 00:06:15.540 --> 00:06:16.960 Stephen Curran: Yeah, for example, okay. 58 00:06:17.240 --> 00:06:24.129 Stephen Curran: yeah, that's all this is, and everything else is to be hidden. Okay? So I would say, we just go with. 59 00:06:25.040 --> 00:06:31.170 Stephen Curran: yeah, we go with that. the replication information. I I believe that's also in there. 60 00:06:32.100 --> 00:06:40.110 Michael Lodder: Yeah, that's that's what I put right here. So I mean, yeah, we can rename this. But I mean, it's schema information. 61 00:06:40.170 --> 00:06:45.530 Michael Lodder: verification and cryptographic verification information and revocation information. 62 00:06:45.910 --> 00:06:46.790 Michael Lodder: So 63 00:06:48.860 --> 00:06:53.320 Michael Lodder: if you don't put the Revocation information in there, I don't know where else you would put it. 64 00:06:53.860 --> 00:06:55.050 Stephen Curran: Yeah. 65 00:06:55.960 --> 00:07:01.400 Stephen Curran: the I mean one sort of assumption that I think we can make. 66 00:07:01.590 --> 00:07:04.209 Stephen Curran: I well, I don't know. They they 67 00:07:04.300 --> 00:07:11.360 Stephen Curran: you you could just say, you know, anytime, if the credential is revocable. You must include a revocation. 68 00:07:12.920 --> 00:07:14.820 Stephen Curran: You must include revocation. 69 00:07:16.150 --> 00:07:17.040 Michael Lodder: Yeah. 70 00:07:17.820 --> 00:07:28.579 Stephen Curran: and then I mean currently that the whole revocation interval is really complicated, like it's, it's very confusing for everybody in in on craz one. 71 00:07:29.210 --> 00:07:41.939 Michael Lodder: What do you mean? The interval like how often it's updated or in in the request? You can say I, I I will accept one in the range of 72 00:07:42.350 --> 00:07:49.449 Stephen Curran: from this time point to this time point. and it's very confusing to people. 73 00:07:50.050 --> 00:07:52.030 Stephen Curran: because what it's saying is. 74 00:07:52.750 --> 00:08:00.840 Stephen Curran: it's basically some sort of optimization around how fresh the revocation can be. 75 00:08:01.300 --> 00:08:10.050 Michael Lodder: That's really all it is. Yeah, that's all you really care about revocation is. it has to be valid as of a certain period in time. 76 00:08:10.110 --> 00:08:16.139 Stephen Curran: exactly. And and and that rather than being saying, You know, it's as 77 00:08:16.970 --> 00:08:23.330 Stephen Curran: I mean, it's really only valid at the time point the publication of the data was made. 78 00:08:24.250 --> 00:08:25.470 Stephen Curran: You know what I mean. 79 00:08:26.300 --> 00:08:36.549 Stephen Curran: If if the if the issue or last published revocation data, you know, 6 weeks ago. You can't have it any fresher than that, because by definition there is 80 00:08:36.940 --> 00:08:40.039 Stephen Curran: nothing fresher. 81 00:08:40.650 --> 00:08:54.549 Michael Lodder: right? And that's part of like the trust model that's outside the the scope for this right? You might have some issuers that you know they are contractually obligated to update every 24 h or something like that. But you're right. 82 00:08:55.270 --> 00:09:01.280 Stephen Curran: Okay. so essentially, this is, gonna be more or less the same as we had it 83 00:09:01.970 --> 00:09:03.850 Stephen Curran: as we have today. 84 00:09:04.030 --> 00:09:05.810 Stephen Curran: It really, isn't that different? 85 00:09:05.990 --> 00:09:07.569 Stephen Curran: Okay, excel. Okay. 86 00:09:07.720 --> 00:09:23.920 Michael Lodder: that was, that was the goal I had. Because when I was designing this, I tried to save as much as possible from the one, so it wasn't a completely new thing. The main thing I wanted to do was just disconnect the cryptography 87 00:09:24.190 --> 00:09:26.490 Michael Lodder: so it could be swappable as me. 88 00:09:26.770 --> 00:09:31.099 Michael Lodder: But this allows that. So we already have that for a non crypto. 89 00:09:31.440 --> 00:09:37.100 Michael Lodder: Okay. so now I'm going to move on to the next one. This isn't much different. 90 00:09:37.360 --> 00:09:43.610 Michael Lodder: Then you have it in the non cred. One. But we only did this for the link secret. But now I'm saying we can do it for anything. 91 00:09:43.780 --> 00:09:45.080 Stephen Curran: Okay. 92 00:09:45.640 --> 00:09:50.959 Michael Lodder: this is like where I'm going to prove that 2 claims are the same without revealing. 93 00:09:52.520 --> 00:09:53.869 Michael Lodder: That's all this bad. 94 00:09:54.180 --> 00:09:56.720 Stephen Curran: Okay? And 95 00:09:58.360 --> 00:10:06.560 Michael Lodder: so let's say you didn't want to use linked secret. Let's say you wanted to use my first name to link across. or my last name, or some other unique identifier. 96 00:10:07.870 --> 00:10:14.339 Michael Lodder: You're not restricted to the League secret. You could be anything. Maybe I want to prove multiple attributes. Or 97 00:10:15.450 --> 00:10:17.289 Michael Lodder: that's what this would allow. 98 00:10:18.960 --> 00:10:24.040 Stephen Curran: Now, how how does this relate to whether the schema. 99 00:10:25.210 --> 00:10:32.320 Stephen Curran: one of the attributes, is in the same scheme or not? So one of the things that that got added 100 00:10:32.630 --> 00:10:35.420 Stephen Curran: after was the names concept. 101 00:10:36.570 --> 00:10:48.860 Stephen Curran: and in the one where you use names, and you list a series of attributes, those attributes, all must come from the same credential are these intended to? How is is there any sort of 102 00:10:48.890 --> 00:10:52.370 Stephen Curran: way for the verifier to say 103 00:10:53.300 --> 00:10:58.210 Stephen Curran: this must come from the same credential. Is that what statement? Id is? 104 00:10:58.940 --> 00:11:04.790 Michael Lodder: they can come from the same credential, but they can also come from a different one. So like, for example. 105 00:11:04.970 --> 00:11:10.129 Michael Lodder: maybe, like the credential itself is a medical record. 106 00:11:10.350 --> 00:11:27.600 Michael Lodder: and you've got. And let's say that's one credential right? And so I'm trying to say all of my kids listed on there, I'll have the same last name right? I could do that. I I could also say, now I've also got 4 other credentials for each one that is their birth certificate. 107 00:11:27.670 --> 00:11:31.669 Michael Lodder: and I'm going to prove that the last name on those birth certificates also matches 108 00:11:32.000 --> 00:11:36.510 Michael Lodder: the last name on this credential, so I could do that, too. So 109 00:11:36.610 --> 00:11:42.160 Michael Lodder: they can be different credential schemas, but they can also be the same. 110 00:11:42.170 --> 00:11:43.620 Michael Lodder: This supports both. 111 00:11:44.900 --> 00:12:04.270 Michael Lodder: The only thing is, you just say it's from this statement, Id, and it's from this claim I put label, but you called it name. It's the same idea. Oh, I see. Sorry. And that's a list. I get it. I was thinking it was just 2 things. Okay, so so the statement, Id is the statement I need, as in above. 112 00:12:04.900 --> 00:12:06.849 Stephen Curran: it's linking. 113 00:12:07.840 --> 00:12:15.839 Michael Lodder: Yeah, this statement, Id is like. from like a signature statement. That's how you know the data is valid or certified. 114 00:12:16.990 --> 00:12:25.150 Stephen Curran: Okay, so these E qualities. These supplement a previous one, a previous previous statements. 115 00:12:25.670 --> 00:12:26.610 Michael Lodder: Correct? 116 00:12:27.070 --> 00:12:28.490 Stephen Curran: Okay? Usually. 117 00:12:28.770 --> 00:12:37.839 Michael Lodder: So when I'm talking predicates, they usually have to say, Hey, the data that is input to the predicate has been certified. Well, the easiest way to do that is with a signature. 118 00:12:38.130 --> 00:12:39.670 Stephen Curran: Yeah. Yeah. 119 00:12:41.190 --> 00:12:44.169 Michael Lodder: So assuming the signature is valid, then you can do this. 120 00:12:44.260 --> 00:12:49.160 Michael Lodder: So this is just the quality statement, identifier. Nothing new. There, then, this is saying. 121 00:12:49.960 --> 00:12:57.769 Michael Lodder: let's say, this is one signature statement. Id, and then you say, first name here, and then you give another one. 122 00:12:57.960 --> 00:13:03.720 Michael Lodder: and it's the same here. So usually you'll have at least 2 items in this 123 00:13:03.980 --> 00:13:04.790 Stephen Curran: right? 124 00:13:07.780 --> 00:13:10.630 Michael Lodder: Any questions with that someone had a comment. 125 00:13:10.790 --> 00:13:27.060 Michael Lodder: Same labels or signatures. No, they're not. Claim. Labels are just name of. They're like kind of a tag, or the name of the claim itself, like first name or last name, age, address, phone number, something like that, or Id. That's what the claim label is. 126 00:13:29.800 --> 00:13:33.980 Michael Lodder: A signature is over a credential, not over a claim. 127 00:13:35.580 --> 00:13:41.200 Michael Lodder: You sign one claim, and that is your credentials with one attribute. 128 00:13:42.080 --> 00:13:43.840 Michael Lodder: So okay. 129 00:13:45.240 --> 00:13:50.239 Michael Lodder: if we're not, and any more questions on that one. I'm going to move on to the membership phone numbers yet. 130 00:13:50.620 --> 00:13:51.440 Stephen Curran: right? 131 00:13:52.040 --> 00:13:56.040 Michael Lodder: If in mind, this was just the initial proposal it, we can update it. 132 00:13:57.080 --> 00:13:59.420 Michael Lodder: If you could do set membership 133 00:13:59.440 --> 00:14:05.340 Michael Lodder: or not membership with accumulators or with Cs or some other way, there's many ways to do this. 134 00:14:05.400 --> 00:14:07.159 Michael Lodder: Accumulators are usually the fast. 135 00:14:11.170 --> 00:14:23.769 Michael Lodder: But this is the way to say what type it is. One of these 2. This is the signature statement, or a reference of where the claim is going to get certified from. 136 00:14:24.170 --> 00:14:26.040 Stephen Curran: so that reference is not 137 00:14:26.780 --> 00:14:29.239 Michael Lodder: yep, it references like this one. 138 00:14:29.430 --> 00:14:31.860 Stephen Curran: The data is coming from here. 139 00:14:32.070 --> 00:14:33.490 Michael Lodder: There's the label 140 00:14:33.600 --> 00:14:36.119 Michael Lodder: flame label. So let's say, it's 141 00:14:36.380 --> 00:14:37.970 Michael Lodder: revocation. Id. 142 00:14:38.150 --> 00:14:40.110 Stephen Curran: yeah, or a Zip code. 143 00:14:40.550 --> 00:14:45.600 Michael Lodder: And then the rest of this is kind of more like, what are we going to use to check it. 144 00:14:46.070 --> 00:14:49.770 Michael Lodder: So it's an accumulator. Here's the actual accumulated value. 145 00:14:49.900 --> 00:14:58.289 Michael Lodder: Maybe there's a public verification key. Maybe there's some other parameters. Whatever the case may be. These next 3 are kind of 146 00:14:59.320 --> 00:15:03.170 Michael Lodder: subjective to whatever the system is using it. 147 00:15:03.510 --> 00:15:06.810 Michael Lodder: You can probably get away with these 2 148 00:15:07.170 --> 00:15:09.120 Michael Lodder: parameters may or may not be 149 00:15:09.240 --> 00:15:12.839 Michael Lodder: optional. But let's say you're doing bullet proofs. Then you might need that. 150 00:15:14.690 --> 00:15:18.740 Stephen Curran: Okay, so what you're saying, I think. 151 00:15:19.290 --> 00:15:21.440 Stephen Curran: is as a verifier. 152 00:15:21.470 --> 00:15:26.899 Stephen Curran: I am going to. So I want to. I want to. We've got a claim label that is state. 153 00:15:27.910 --> 00:15:36.420 Stephen Curran: and I want to know if you are in one of 10 States. So so I take those 10 States. 154 00:15:36.530 --> 00:15:40.310 Stephen Curran: and I feed them into a function that produces an accumulator. 155 00:15:41.640 --> 00:15:42.440 Michael Lodder: Yes. 156 00:15:42.880 --> 00:15:45.480 Stephen Curran: and then I passed that to you. 157 00:15:45.690 --> 00:15:53.910 Stephen Curran: and what the presentation comes back with is, it takes the state and proves it's in or or not in that state. 158 00:15:54.670 --> 00:16:00.530 Michael Lodder: Correct. So let's say, the issuer said, All right. Here's how I map 159 00:16:00.950 --> 00:16:03.040 Michael Lodder: the States to an accumulator. 160 00:16:03.860 --> 00:16:06.139 Michael Lodder: Anyone could say, Okay. 161 00:16:06.600 --> 00:16:10.839 Michael Lodder: I'll do the same thing like like I was saying, kind of last time disaster zone 162 00:16:11.890 --> 00:16:15.970 Stephen Curran: the issue for my driver's licenses. I map them just by. 163 00:16:16.030 --> 00:16:26.669 Michael Lodder: Let's just say hashing it, because that's easiest. They're just gonna hash the State. That's public information. So then Fema comes out and says, well, the hurricane just hit the east coast. 164 00:16:27.150 --> 00:16:37.450 Michael Lodder: We're gonna say, the following states in the us or hit. and they can accumulate and use the same mapping as issuer. A. 165 00:16:38.810 --> 00:16:45.950 Michael Lodder: Then anyone who lives in those States, without changing any of their credentials can then prove that they're into the after zone or not 166 00:16:46.250 --> 00:16:47.849 Stephen Curran: okay 167 00:16:55.520 --> 00:17:02.559 Stephen Curran: okay and and they can do that because they know it's in it 168 00:17:02.990 --> 00:17:04.240 Stephen Curran: they 169 00:17:06.060 --> 00:17:19.069 Stephen Curran: I know it's an enumerated set. They know it's an enumerated set, and the verifier has said, this is how I determine the entries in the enumerated set 170 00:17:23.369 --> 00:17:24.670 Michael Lodder: right. 171 00:17:28.290 --> 00:17:43.230 Stephen Curran: and and they can do that either fully, explicitly. They can list out. The here are the 50 States. and then the other one takes that enumeration does the same calculation to come up with the accumulator of accepted ones, and then 172 00:17:44.180 --> 00:17:47.069 Stephen Curran: membership or non-membership can be proven. 173 00:17:48.320 --> 00:17:49.600 Stephen Curran: That's right. 174 00:17:50.360 --> 00:17:54.489 Michael Lodder: The other way you could do this is, you could do it with an R one Cs circuit 175 00:17:55.540 --> 00:17:58.519 Michael Lodder: a little more complicated, but you could use it to do the same thing 176 00:17:58.820 --> 00:17:59.640 Michael Lodder: right. 177 00:17:59.850 --> 00:18:06.870 Michael Lodder: All I'm saying is regardless. There is a set out there you're proving you're in or not in that set. 178 00:18:09.270 --> 00:18:18.390 Stephen Curran: And as we saw from the work Rachel did last week. These are not. Accumulator does not have to be made up of primes 179 00:18:18.500 --> 00:18:19.730 Stephen Curran: for some reason. 180 00:18:20.630 --> 00:18:22.850 Stephen Curran: No. 181 00:18:23.420 --> 00:18:27.450 Michael Lodder: no, elliptic curve. Elliptic curves don't have to contain. Pr. 182 00:18:27.680 --> 00:18:28.580 Stephen Curran: okay. 183 00:18:29.040 --> 00:18:34.010 Michael Lodder: it just has to contain valid valid elements in the field. 184 00:18:34.770 --> 00:18:38.809 Michael Lodder: The only the only accumul that needs primes is an Rsa based one. 185 00:18:39.380 --> 00:18:40.680 Stephen Curran: Oh, I see. 186 00:18:41.870 --> 00:18:44.550 Michael Lodder: So because in the one 187 00:18:44.620 --> 00:18:49.240 Michael Lodder: you know, it uses it an elliptic curve. They're just points. 188 00:18:49.570 --> 00:18:53.590 Stephen Curran: Okay, that's all they are. That's crazy to me 189 00:18:55.940 --> 00:19:06.809 Stephen Curran: like I thought that was the, you know, like as little cryptography as I know the map. The simple math was. Oh, if the cumulators made up a bunch of Brian's, and if the prime's missing, then you can tell that. 190 00:19:06.950 --> 00:19:10.340 Stephen Curran: But now you're telling me they're not even prime. That seems crazy. 191 00:19:10.660 --> 00:19:12.470 Michael Lodder: not for an elliptic curve. 192 00:19:12.680 --> 00:19:15.200 Stephen Curran: All right. I believe you. 193 00:19:15.330 --> 00:19:25.429 Michael Lodder: So. The sec. The well, the security of it, comes from the fact that you know you got 2 to the 2 to the 6 power possible values that could be in there. 194 00:19:25.850 --> 00:19:31.459 Michael Lodder: So it's impossible for someone to enumerate and try to check which one's right. It's just 195 00:19:31.680 --> 00:19:33.450 Michael Lodder: too large to find it. 196 00:19:33.690 --> 00:19:36.040 Stephen Curran: Okay. all right. 197 00:19:38.370 --> 00:19:43.400 Stephen Curran: fascinating. Yeah. Okay. okay, so that's 198 00:19:43.410 --> 00:19:58.780 Stephen Curran: accumulator membership. And then and and basically what happens is depending on how it's signed. The accumulator is is done the same way, but depending on whether it's Ps. Or Bbs, or or whatever that 199 00:19:59.500 --> 00:20:04.870 Stephen Curran: the calculation can be performed for presentation to present and to verify. Right? 200 00:20:06.270 --> 00:20:07.220 Michael Lodder: Hmm. 201 00:20:08.570 --> 00:20:12.669 Michael Lodder: yes, it that it. The signature actually doesn't matter 202 00:20:12.830 --> 00:20:22.299 Michael Lodder: as long as it's compatible with the accumulator. So, for example. cl signatures are also compatible. even though their Rsa base 203 00:20:22.880 --> 00:20:40.870 Michael Lodder: it just because those 3 signature types all our signatures over commitments. or a, you know, just a regular value. And that's all. Like, for example, the elliptic curve accumulator or an Rc. Based accumulator require to do it. 204 00:20:41.180 --> 00:20:42.150 Stephen Curran: Okay? 205 00:20:43.530 --> 00:20:50.510 Stephen Curran: And all that. The create a presentation of this you're just sending over the signature of the value. 206 00:20:51.470 --> 00:20:53.129 Stephen Curran: And then, on the other side. 207 00:20:53.380 --> 00:20:57.689 Stephen Curran: they're figuring out their Oh, oh, sorry, no! The 208 00:20:57.900 --> 00:21:03.290 Stephen Curran: the verifier sends over the enumerator or sorry the accumulator. 209 00:21:03.420 --> 00:21:13.010 Stephen Curran: and then. and in creating the presentation, the holder can tell if they met that condition. If they're in the accumulator. 210 00:21:13.730 --> 00:21:15.689 Michael Lodder: Yeah, the the holder will know 211 00:21:15.870 --> 00:21:21.559 Michael Lodder: before they even do the presentation right. And if they're not like, say, the no-fly list. 212 00:21:21.770 --> 00:21:25.009 Michael Lodder: then they could, you know? Go? Oh, crap! I'm going to get. 213 00:21:25.180 --> 00:21:29.930 Stephen Curran: or whatever right but the but the 214 00:21:30.740 --> 00:21:36.949 Stephen Curran: the verifier is not sending over the actual list. It's only sending an accumulator. Right? 215 00:21:37.390 --> 00:21:38.700 Michael Lodder: That is correct. 216 00:21:39.050 --> 00:21:46.639 Stephen Curran: Okay, so it but it could still. But the holder can still do the calculation itself to figure out if it if their value is 217 00:21:47.310 --> 00:21:50.609 Michael Lodder: yeah, because they can prove and verify if they had, to. 218 00:21:51.120 --> 00:21:55.110 Stephen Curran: what? What I wanted, to be sure there, and asking, that was that the the 219 00:21:55.120 --> 00:22:02.210 Stephen Curran: the verifier isn't sending over the list of 22 States. It's they don't have to. 220 00:22:02.330 --> 00:22:06.850 Stephen Curran: Exactly okay. 221 00:22:06.960 --> 00:22:11.910 Michael Lodder: have to send over all the States. But that's why, I think the accumulator is the better option. Because you don't need to. 222 00:22:12.370 --> 00:22:17.079 Stephen Curran: Let's say, let's say it was. Let's say, if there were a billion items in that list 223 00:22:17.750 --> 00:22:34.140 Stephen Curran: trying to send all that over is going to be very bandwidth intensive. That's exactly what I was thinking. That's where I was going by sending just the accumulator. It's really simple to send it across. Then the verifier that hold there doesn't even need to know which just needs to. Am I in it. 224 00:22:35.100 --> 00:22:36.170 Michael Lodder: That's right. 225 00:22:36.600 --> 00:22:37.650 Stephen Curran: Okay? Good. 226 00:22:40.180 --> 00:22:41.130 Michael Lodder: Okay. 227 00:22:42.630 --> 00:22:48.950 Michael Lodder: a commitment. This is like one use cases for the domain proof idea. 228 00:22:49.150 --> 00:22:58.460 Michael Lodder: Right? Where you register, you create something that's unique for that specific domain. And you want to prove that you are a return visitor versus a brand new one. 229 00:22:59.020 --> 00:23:02.519 Stephen Curran: That's one use case for this. That's one use case. 230 00:23:02.650 --> 00:23:04.070 Michael Lodder: the other is 231 00:23:04.140 --> 00:23:15.629 Michael Lodder: Some other proofs require conversion to a commitment rather than a snorp proof, which is how like Cl. Pvs plus, and how General Sanders all work. 232 00:23:16.950 --> 00:23:17.980 Michael Lodder: So 233 00:23:18.060 --> 00:23:27.530 Michael Lodder: the net or like, let's say you're doing right. That's just a regular value. And let's say you want to link it to our one Cs. 234 00:23:27.920 --> 00:23:32.269 Michael Lodder: and that requires a commitment. This is how you would do it. 235 00:23:33.460 --> 00:23:40.470 Michael Lodder: I, you and I have talked about how like it's a both for 6 commitments. Not 236 00:23:40.920 --> 00:23:44.379 Michael Lodder: so. This is kind of one of one of those. Now. 237 00:23:44.480 --> 00:23:46.110 Michael Lodder: if you wanted to say. 238 00:23:46.550 --> 00:23:50.950 Michael Lodder: Yeah, domain proof, you could just stop here with this, the domain proof 239 00:23:50.970 --> 00:23:54.779 Michael Lodder: for a commitment. It's similar to what we've seen before. 240 00:23:55.260 --> 00:24:02.689 Michael Lodder: Where? What's the value that you're going to prove? Make sure it's signed. That's what this is for. So you reference a signature statement. 241 00:24:03.340 --> 00:24:10.770 Michael Lodder: What's the claim? And then. because we deal with a blinded commitment you need to generators. 242 00:24:10.960 --> 00:24:16.549 Michael Lodder: One is for the claim itself and the others for what I call a randomizer. Another term is blinder. 243 00:24:16.830 --> 00:24:24.180 Michael Lodder: I'm not. I'm not entirely sold on the nomenclature for this yet I like Randomizer. But Winder is also. 244 00:24:24.850 --> 00:24:30.599 Michael Lodder: I just think Blinder confuses people whenever I say, Oh, it's the blinding factor they're like, wait, what's that. 245 00:24:31.540 --> 00:24:32.510 Michael Lodder: So 246 00:24:32.920 --> 00:24:33.700 Stephen Curran: yeah. 247 00:24:34.300 --> 00:24:37.690 Michael Lodder: I try it, randomizer, because I think people understand the plan is. 248 00:24:40.590 --> 00:24:42.189 Stephen Curran: and if they went to my 249 00:24:43.310 --> 00:24:45.410 Stephen Curran: presentation they would understand. 250 00:24:46.320 --> 00:24:48.539 Michael Lodder: Well, they should have? 251 00:24:51.080 --> 00:24:55.499 Stephen Curran: Okay. So from a business perspective domain. 252 00:24:55.690 --> 00:24:58.829 Stephen Curran: domain, name or sorry a delay in proof. 253 00:25:00.880 --> 00:25:06.629 Stephen Curran: Is there any other business perspective on that? If you go the you know you mentioned. There's 2 types. 254 00:25:09.080 --> 00:25:11.040 Stephen Curran: the domain. 255 00:25:11.220 --> 00:25:14.570 Stephen Curran: the second one. 256 00:25:15.300 --> 00:25:20.330 Michael Lodder: The second one is like, let's say you wanted to do bulletproofs. or what's your range proof. 257 00:25:21.390 --> 00:25:27.670 Michael Lodder: Sometimes you have to link out to to a different using a different crypto, and that's how you would do it with it. 258 00:25:31.900 --> 00:25:34.889 Stephen Curran: But but would it verify or have to know that? 259 00:25:35.360 --> 00:25:41.489 Michael Lodder: Yes, they would. Now you could. You could hide that right? You could say here I would stuff the 260 00:25:41.720 --> 00:25:52.770 Michael Lodder: a range proof from bullet proofs, or maybe some other thing. And so if you've got a Cl signature in order to get it to a bulletproof, you're going to have to do this. 261 00:25:53.240 --> 00:25:54.339 Michael Lodder: and that's fine. 262 00:26:03.900 --> 00:26:11.259 Stephen Curran: Okay, let me come back. I sorry I want to revisit this. So I domain proof. The verifier gives a value 263 00:26:11.360 --> 00:26:16.130 Stephen Curran: which is the claiming generator. They give 2 values. Okay. 264 00:26:16.720 --> 00:26:18.599 Michael Lodder: they get both of these right. 265 00:26:18.660 --> 00:26:24.830 Stephen Curran: The only things the verifier would have to get well, they'd say which one which claim label they allow. 266 00:26:24.930 --> 00:26:28.009 Michael Lodder: and 2 generator points. As long as these aren't the same. 267 00:26:28.160 --> 00:26:33.130 Stephen Curran: Okay? And then what they get is a consistent 268 00:26:33.640 --> 00:26:44.549 Stephen Curran: signature blinded a consistent, blinded signature that as long as they pass the same planning generator or randomizer they get the same 269 00:26:46.140 --> 00:26:47.590 Stephen Curran: string back 270 00:26:48.350 --> 00:26:49.420 Michael Lodder: right 271 00:26:50.550 --> 00:26:56.029 Michael Lodder: kind of think of it this way. I can. I can post this link because this is public. 272 00:26:56.230 --> 00:27:00.170 Stephen Curran: Okay, here's what I call it. It's called a commitment. When proof 273 00:27:00.300 --> 00:27:10.780 Michael Lodder: you're basically saying, I have 2 commitments. and I'm going to prove that they hide the same value. So in the domain proof. when you register, you're going to create one commitment. 274 00:27:10.950 --> 00:27:13.550 Michael Lodder: and whoever that is going to store it. 275 00:27:13.600 --> 00:27:20.909 Michael Lodder: Then, whenever you revisit, you're going to prove that you know the 2 values that were hidden. That's what this does. 276 00:27:24.500 --> 00:27:30.950 Michael Lodder: So that way. The proof looks different each time. But you're still indicating which domain proof to check 277 00:27:37.260 --> 00:27:39.739 Michael Lodder: this this link is public if you want it. 278 00:27:40.020 --> 00:27:44.510 Stephen Curran: I'm still trying to translate this into language that 279 00:27:45.510 --> 00:27:49.150 Stephen Curran: I know. 280 00:27:49.450 --> 00:27:53.270 Stephen Curran: So what I'm trying to get out of this is. 281 00:27:54.050 --> 00:27:58.580 Stephen Curran: I get that that the same credential was used 282 00:27:59.360 --> 00:28:03.209 Stephen Curran: or the same attribute value was pulled from the credential. 283 00:28:04.050 --> 00:28:05.200 Michael Lodder: Yeah, every time 284 00:28:06.050 --> 00:28:13.029 Stephen Curran: I don't get to see what the value is at the attribute. Presumably I don't disclose it, but I do know that 285 00:28:13.510 --> 00:28:19.789 Stephen Curran: I've seen that one before. And so I can correlated with one I've seen before. 286 00:28:20.760 --> 00:28:21.750 Michael Lodder: That's right. 287 00:28:22.320 --> 00:28:23.200 Stephen Curran: Okay. 288 00:28:26.360 --> 00:28:34.940 Stephen Curran: which basically gives you that ability to have a unique identifier but not share that unique identifier. But the 289 00:28:35.400 --> 00:28:40.530 Stephen Curran: but the verifier knows when the same unique identifier comes back. 290 00:28:42.360 --> 00:28:49.159 Michael Lodder: That's right. The great thing is yeah, with the domain proof. I can use that same unique identifier across 291 00:28:49.530 --> 00:28:53.470 Michael Lodder: domains. But it won't look the same to anybody observing. 292 00:28:54.370 --> 00:29:06.329 Michael Lodder: like Acne Bank, even though I did it versus the British Columbia Government. It's I might register the same Id, but because it's hidden behind the commitment 293 00:29:07.010 --> 00:29:11.929 Stephen Curran: and the and the parameter information. These 2 things 294 00:29:12.140 --> 00:29:14.339 Michael Lodder: are specific to that domain 295 00:29:14.830 --> 00:29:16.050 Stephen Curran: they can't tell. 296 00:29:16.760 --> 00:29:24.339 Stephen Curran: And as a holder I could detect that. Oh, this is the same. They've used the same values as somebody else. 297 00:29:25.640 --> 00:29:28.690 Stephen Curran: Therefore they are able to collude if they want to 298 00:29:30.240 --> 00:29:35.580 Stephen Curran: right. The holder could look at these and say, Have I seen these 2 before? 299 00:29:36.380 --> 00:29:37.780 Michael Lodder: Yes, they could. 300 00:29:38.270 --> 00:29:39.290 Stephen Curran: Okay, good. 301 00:29:40.890 --> 00:29:44.360 Stephen Curran: Okay. And that's the only 302 00:29:44.530 --> 00:29:47.470 Stephen Curran: is that the only use of this commitment. 303 00:29:49.270 --> 00:29:57.949 Michael Lodder: Now, as I've been saying, like, if you need to link out to other systems that may require something other than what? Yes. 304 00:29:58.020 --> 00:30:01.920 Michael Lodder: Pbs and Cl signatures required this. This also works 305 00:30:02.060 --> 00:30:06.289 Michael Lodder: like I said, range groups, range groups. You can't just take them as is 306 00:30:06.980 --> 00:30:12.230 Michael Lodder: from those 3 signatures. You have to do some translation. And this is the way to do that. 307 00:30:12.530 --> 00:30:13.380 Stephen Curran: Okay. 308 00:30:16.280 --> 00:30:23.110 Stephen Curran: but you can't give me a used case where I would do that other than just to say. 309 00:30:23.370 --> 00:30:29.059 Michael Lodder: well, for example, there are no range for supported by elliptic curves right now. 310 00:30:29.350 --> 00:30:32.100 Stephen Curran: as it is so 311 00:30:32.760 --> 00:30:36.899 Michael Lodder: so in order to do that, like bullet proofs is a way to do that. 312 00:30:36.970 --> 00:30:40.389 Michael Lodder: But bulletproof takes a commitment, which is what this gives you. 313 00:30:41.680 --> 00:30:44.899 Michael Lodder: So I would have something signed by bbs, plus. 314 00:30:45.950 --> 00:30:59.469 Stephen Curran: I would take that value and make a commitment for and say the same value that assigned in the credential is in this commitment. Yeah. And bulletproofs will go. Okay, I can take that same commitment. And I can also generate a range group over the same path 315 00:30:59.480 --> 00:31:01.840 Michael Lodder: to say, Okay, let's say it's my age. 316 00:31:02.090 --> 00:31:04.169 Michael Lodder: So I make a commitment to my age. 317 00:31:04.330 --> 00:31:09.119 Michael Lodder: Whole proofs then goes, okay. I can take that age commitment and prove it's greater than 18. 318 00:31:11.040 --> 00:31:22.379 Stephen Curran: Okay, so let me to propose that we do this? Suppose, even though it's got the same values, can we break this into 2 sections, domain proof and bullet or range proof? 319 00:31:23.770 --> 00:31:28.589 Michael Lodder: They already are. So range proof comes down is down below right here. 320 00:31:28.760 --> 00:31:30.760 Stephen Curran: Range proof right here. 321 00:31:30.930 --> 00:31:35.260 Stephen Curran: Okay. But it uses essentially the same technique. You're saying. 322 00:31:35.940 --> 00:31:36.740 Michael Lodder: Yep. 323 00:31:37.700 --> 00:31:38.640 Stephen Curran: okay. 324 00:31:41.050 --> 00:31:45.229 Stephen Curran: so this one, we would rename to domain. And then we've got range down below 325 00:31:47.920 --> 00:31:57.340 Michael Lodder: right? Well, range. Like I said, range takes as input a reference to this commitment statement. It needs to know that because it can't take 326 00:31:58.070 --> 00:32:00.240 Michael Lodder: just the value from the signature 327 00:32:00.320 --> 00:32:03.330 Michael Lodder: to do something else to it first. 328 00:32:03.710 --> 00:32:11.040 Michael Lodder: So it says, this is the signature that it's coming from, so I know it's certified. But then I also need to know where is that commitment 329 00:32:11.210 --> 00:32:15.550 Michael Lodder: that took it from the signature to this value, because that's what I have to use. 330 00:32:19.560 --> 00:32:21.539 Stephen Curran: Oh, I see what you're saying. 331 00:32:22.160 --> 00:32:28.520 Stephen Curran: So, in other words, I've got to have a commitment, and then I do a range proof. And I reference back to you. 332 00:32:29.740 --> 00:32:30.830 Michael Lodder: That's right. 333 00:32:36.390 --> 00:32:45.770 Stephen Curran: But another way to do that would simply be to replace that reference to a commitment. and and simply say the same things that are in the commitment in here. 334 00:32:46.560 --> 00:32:50.820 Stephen Curran: Yep, you could do that, too. 335 00:32:52.030 --> 00:32:53.050 Michael Lodder: That's fine. 336 00:32:53.880 --> 00:32:57.249 Stephen Curran: Got it? Okay, that makes sense to me. Now, thank you. 337 00:33:01.850 --> 00:33:06.139 Stephen Curran: Okay. Variable encryption, verifiable encryption. 338 00:33:10.590 --> 00:33:18.580 Michael Lodder: Yeah. As I've talked about before, this looks identical to a domain proof, the differences. Instead of a randomizer generator, you have an encryption key. 339 00:33:21.030 --> 00:33:25.179 Michael Lodder: and you're essentially proving that you've encrypted the value to this encryption key. 340 00:33:26.220 --> 00:33:27.660 Michael Lodder: So whoever 341 00:33:28.160 --> 00:33:31.889 Michael Lodder: owns the corresponding decryption key could be crypted. 342 00:33:32.190 --> 00:33:42.540 Michael Lodder: But to verify the proof, they don't need that. That encryption key they're just saying, Okay, I can check that. You encrypted the value that was in your in your credential, a client you encrypted a claim. 343 00:33:43.420 --> 00:33:44.410 Michael Lodder: and 344 00:33:44.980 --> 00:33:49.259 Michael Lodder: so it's the same value in the credential, and you encrypted it to this encryption case. 345 00:33:49.580 --> 00:33:54.160 Stephen Curran: got it, and the used case. There is 346 00:33:55.140 --> 00:34:00.559 Stephen Curran: somebody, an issue or somebody else gives you a gives the verifier a public key. 347 00:34:00.590 --> 00:34:03.249 Stephen Curran: They passed the public key 348 00:34:03.950 --> 00:34:07.119 Stephen Curran: in this encryption key field. 349 00:34:08.500 --> 00:34:15.570 Stephen Curran: And the result is they get a an encrypted data value that only someone with a private key can decrypt. 350 00:34:16.190 --> 00:34:17.219 Michael Lodder: That's right. 351 00:34:17.750 --> 00:34:25.559 Michael Lodder: There's a couple of use cases for this. Let's say that you wanted them to have some reporting system. 352 00:34:25.750 --> 00:34:33.730 Stephen Curran: Let's see, I got a claim from BC. Gov. Sorry credential from Vc. Gov. Yup and I. And anytime I use it. 353 00:34:34.429 --> 00:34:45.389 Michael Lodder: Part of that proof says you need to send me a verifiable ciphertext, which is what this gives you that says, if I were to take that verifiable cipher text back to BC. Gov. 354 00:34:45.620 --> 00:34:52.279 Michael Lodder: they would be able to decrypt it to know who you are. Obviously I wouldn't know who you are, but they would. 355 00:34:52.780 --> 00:34:53.480 Stephen Curran: Yeah. 356 00:34:53.989 --> 00:35:00.129 Michael Lodder: so they could do that. So in that case, Vc. Kev is also supplying the verify by encryption. 357 00:35:00.480 --> 00:35:04.070 Michael Lodder: even though they are the issue. So there's no external third party. 358 00:35:04.350 --> 00:35:08.080 Stephen Curran: Yeah. But it's a way that if they need to to mask you. They could. 359 00:35:08.300 --> 00:35:11.679 Stephen Curran: Yeah. Another thing that this should have 360 00:35:11.870 --> 00:35:22.870 Stephen Curran: is it should either be an encryption key or a reference to an encryption key. So this could be a did. I did 361 00:35:23.800 --> 00:35:32.599 Stephen Curran: with a hash key one, you know, a hash to the key. 362 00:35:32.780 --> 00:35:33.870 Stephen Curran: Okay. 363 00:35:34.000 --> 00:35:35.469 Stephen Curran: yeah. Good. 364 00:35:36.890 --> 00:35:54.749 Stephen Curran: Ultimately, they're all going to just be resolved anyway. So yeah. But that way they there's no question where the key came from. You can say, you know you're not. You're not accepting that the key from the verifier. You're accepting a resolvable identifier to to get the key. 365 00:35:55.940 --> 00:35:59.389 Stephen Curran: and therefore you can. Oh, yeah, this is the BC. Gov. 366 00:36:00.580 --> 00:36:02.630 Stephen Curran: he. 367 00:36:04.820 --> 00:36:05.810 Michael Lodder: that's right. 368 00:36:06.310 --> 00:36:07.720 Stephen Curran: Yeah. Okay. 369 00:36:10.070 --> 00:36:11.160 Stephen Curran: very cool. 370 00:36:11.260 --> 00:36:12.929 Stephen Curran: very cool. Okay. 371 00:36:13.230 --> 00:36:19.750 Michael Lodder: I did not list verifiable decryption, although that is something we else we can also do. 372 00:36:20.120 --> 00:36:23.349 Michael Lodder: It's just not a very common use case for it. 373 00:36:23.390 --> 00:36:28.569 Michael Lodder: I've only seen it used in my more complicated protocols outside of a non-creds. 374 00:36:28.650 --> 00:36:31.649 Michael Lodder: I have yet to see a use case for it inside and on. 375 00:36:32.410 --> 00:36:33.350 Stephen Curran: Okay. 376 00:36:33.750 --> 00:36:37.520 Michael Lodder: so I didn't add it. But we could just as easily add it if we wanted it. 377 00:36:39.300 --> 00:36:41.100 Stephen Curran: and that is that the 378 00:36:42.410 --> 00:36:45.250 Stephen Curran: issue or issues that encrypted? 379 00:36:48.230 --> 00:36:55.179 Michael Lodder: And yeah, yeah, so you can think of it as the issue or gives it to you an encrypted value that only you can decrypt. 380 00:36:55.630 --> 00:36:56.380 Stephen Curran: Yeah. 381 00:36:56.580 --> 00:37:02.069 Michael Lodder: but both sides would know what the value is. So the issue goes. This is the value I encrypted. 382 00:37:02.610 --> 00:37:08.840 Michael Lodder: and then you get you decrypt it, and you then you then you return a proof and say, this is the value id clip 383 00:37:09.430 --> 00:37:13.400 Michael Lodder: I got after I decrypted the issue work and said, Yes, that's correct. 384 00:37:13.610 --> 00:37:17.149 Stephen Curran: Yeah. But kind of like a scenario. That's weird. 385 00:37:17.790 --> 00:37:22.629 Michael Lodder: exactly. That's why I did play in here. I would agree. 386 00:37:24.180 --> 00:37:25.940 Stephen Curran: Okay, excellent. 387 00:37:28.080 --> 00:37:29.319 Stephen Curran: All right. 388 00:37:31.210 --> 00:37:36.010 Michael Lodder: There are other that we could do, but I think this covers everything. 389 00:37:36.830 --> 00:37:42.100 Stephen Curran: and then the range proof is the last one. and range 390 00:37:42.160 --> 00:37:47.269 Stephen Curran: is this. And and the predicate we have today is also covered by range. Right? 391 00:37:48.620 --> 00:37:53.109 Michael Lodder: It should. It just works a little different and a little faster. 392 00:37:53.260 --> 00:37:54.440 Stephen Curran: Yeah. 393 00:37:55.380 --> 00:37:57.100 Michael Lodder: then, how it's currently done. 394 00:37:59.580 --> 00:38:01.020 Michael Lodder: This supports this. 395 00:38:01.160 --> 00:38:07.529 Michael Lodder: What I want is that this range could be the same one used in the current one, but could also be a newer one. 396 00:38:08.320 --> 00:38:09.420 Stephen Curran: Okay. 397 00:38:09.640 --> 00:38:14.319 Michael Lodder: so it's more flexible, because right now the current one is restricted to cl signatures. 398 00:38:14.420 --> 00:38:16.669 Michael Lodder: This one should be anything. 399 00:38:17.100 --> 00:38:20.060 Stephen Curran: It could be full. It could be our one. Cs could be anything. 400 00:38:20.560 --> 00:38:22.889 Stephen Curran: Does that make sense? 401 00:38:23.130 --> 00:38:25.049 Michael Lodder: Yeah, okay, yeah. 402 00:38:30.860 --> 00:38:35.609 Stephen Curran: Okay. And then, what have you got down presentation request statement? 403 00:38:36.900 --> 00:38:44.550 Michael Lodder: I've got a schema, a presentation request. Schema. It's just a list of statements that you want first. That's it. 404 00:38:44.860 --> 00:38:46.509 Michael Lodder: That's literally all it is. 405 00:38:46.920 --> 00:38:47.720 Stephen Curran: Yeah. 406 00:38:48.560 --> 00:38:57.059 Michael Lodder: I did not put an Id, and there could be an id like, but I usually assume that. Let's say the presentation request. Schema is anchored somewhere 407 00:38:57.410 --> 00:39:01.469 Michael Lodder: that could be anchored to a dick, it being through a block cash, I don't really care. 408 00:39:01.520 --> 00:39:13.270 Stephen Curran: Yeah, e. So originally I was thinking that when we had that it would have to come from one credential. But by definition this could come from multiple credentials. 409 00:39:13.920 --> 00:39:15.750 Michael Lodder: Yep, exactly. 410 00:39:15.970 --> 00:39:17.370 Stephen Curran: Yeah. Okay. 411 00:39:18.060 --> 00:39:23.210 Stephen Curran: And if that happens, you just have 2 statements with signatures. Right? 412 00:39:23.590 --> 00:39:24.500 Stephen Curran: Yeah. 413 00:39:29.040 --> 00:39:32.989 Michael Lodder: exactly. And then this is just the data that is returned. 414 00:39:33.160 --> 00:39:34.530 Michael Lodder: I call them proofs. 415 00:39:34.740 --> 00:39:43.820 Michael Lodder: Yeah, right? There's a signature proof, inequality proof. It's that membership proofs. And then obviously, I didn't carry on. But there you have one for each one. 416 00:39:44.310 --> 00:39:45.150 Stephen Curran: Okay? 417 00:39:46.380 --> 00:39:48.170 Stephen Curran: Oh, that was huge out. 418 00:39:51.180 --> 00:40:00.520 Michael Lodder: I mean, there's other proofs that we could do like when it's called set intersection, that one gets a little complicated, and I'm not sure it's needed yet. 419 00:40:02.560 --> 00:40:11.649 Michael Lodder: because I think we can cover just about everything else with what we've got that should handle probably 98, maybe even 99% of used cases. 420 00:40:13.580 --> 00:40:14.460 Stephen Curran: Okay. 421 00:40:16.580 --> 00:40:17.660 Stephen Curran: that's awesome. 422 00:40:18.880 --> 00:40:24.570 Stephen Curran: All right. Well, I got a lot out of that the reach. I hope you did as well. 423 00:40:28.010 --> 00:40:29.960 Stephen Curran: moving on to 424 00:40:31.460 --> 00:40:48.820 Stephen Curran: other things. I am really buried this week. I will try to. I'm I've got on my list to try to come up with a a plan. a reach for the work you're you're doing and and moving on. I think we're ready for the oh, I did wanna 425 00:40:49.270 --> 00:40:54.970 Stephen Curran: have a discussion, actually, if you don't mind with the 2 of you. that idea of 426 00:40:55.420 --> 00:41:05.080 Stephen Curran: Mike. Did you follow the conversation about the the issuer. or the holder providing the 427 00:41:05.630 --> 00:41:08.850 Stephen Curran: what we're now calling the entropy variable? 428 00:41:10.520 --> 00:41:12.279 Michael Lodder: kind of. 429 00:41:12.490 --> 00:41:15.680 Michael Lodder: I was trying to figure out still exactly what 430 00:41:15.850 --> 00:41:24.009 Michael Lodder: the use for it, as you said, like, it was partially there for legacy purposes. But do we need to go forward. 431 00:41:24.420 --> 00:41:31.470 Stephen Curran: What I know is that in Indy there's this in the indie implementation. So going back to, you know. 432 00:41:31.960 --> 00:41:40.789 Stephen Curran: in the SDK and and credits. There's this value called issue. A holder did that the holder provides 433 00:41:41.630 --> 00:41:54.609 Stephen Curran: A holder did makes no sense in an up and a on credits perspective, because there's no such thing as it did. So we traced it along, and it turns out that it 434 00:41:54.710 --> 00:41:58.799 Stephen Curran: is basically used to to provide entropy. 435 00:41:59.490 --> 00:42:02.490 Stephen Curran: And so why? 436 00:42:03.500 --> 00:42:05.290 Stephen Curran: Oh, Rachel, can you help with that? 437 00:42:05.730 --> 00:42:07.820 Stephen Curran: Can you help with that question 438 00:42:08.170 --> 00:42:12.250 Michael Lodder: it? Well, is it coming from the verifier or the issuers? 439 00:42:12.960 --> 00:42:17.250 Stephen Curran: It is coming from the holder. 440 00:42:19.150 --> 00:42:20.960 Michael Lodder: It's coming from the holder. 441 00:42:21.070 --> 00:42:24.830 Aritra B.: Yes, currently currently the holder is providing it. So 442 00:42:24.870 --> 00:42:34.839 Aritra B.: that's why I I was thinking that the holder can provide anything like any random string or or the did so. The thing is that in so 443 00:42:35.060 --> 00:42:44.989 Aritra B.: maybe they are using the did only as a random string. That is what I guess from the code I saw. Are they like switching it or intruding it in like a transcript somewhere? 444 00:42:45.910 --> 00:42:54.359 Aritra B.: Yeah, I think they have some hashed it one time. I I don't remember actually. But yeah, they did something with that. 445 00:42:54.400 --> 00:42:59.710 Stephen Curran: So the the holder provides it in the 446 00:42:59.990 --> 00:43:02.379 Stephen Curran: credential request. 447 00:43:02.800 --> 00:43:08.100 Stephen Curran: And then, as far as I know, the issue, or takes the value and hashes it. 448 00:43:12.220 --> 00:43:19.059 Stephen Curran: and then add it to some other information they have, and uses that in the signing. 449 00:43:21.710 --> 00:43:24.120 Michael Lodder: Yeah, that's not really needed. 450 00:43:24.880 --> 00:43:31.079 Michael Lodder: I mean, it doesn't. I wouldn't say it weakened security. But it also doesn't. It's just kind of there. 451 00:43:33.780 --> 00:43:34.880 Stephen Curran: So 452 00:43:35.180 --> 00:43:51.389 Stephen Curran: so the 2 thoughts came from it. One so so what we did was we at least renamed it when we, when we did it, when we did the actual and on correct specification. We renamed it because we thought it was inappropriate to call it the holder did. When that 453 00:43:51.520 --> 00:44:03.569 Stephen Curran: has no no meaning unless you're using, you know, Didcom, or something like that. It has no meeting. We call that entropy for lack of a better 454 00:44:03.980 --> 00:44:12.939 Stephen Curran: name. But the question is, should we simply in the issue, or ignore whatever value is put by the 455 00:44:13.430 --> 00:44:15.649 Stephen Curran: hold her in there, and simply 456 00:44:16.760 --> 00:44:19.020 Stephen Curran: generate a random number. 457 00:44:19.960 --> 00:44:25.399 Michael Lodder: Is it? Well, like? I said, there's really no need for it. If it's going from polar to issue, or 458 00:44:26.190 --> 00:44:31.789 Michael Lodder: if it was holder to verify, I could see that, being like self a tested place. 459 00:44:31.960 --> 00:44:33.890 Stephen Curran: No, that's not in case here. 460 00:44:34.230 --> 00:44:35.870 Stephen Curran: Hold her to issue her. 461 00:44:36.880 --> 00:44:40.800 Michael Lodder: Then to me there's no need for it. I say we get rid of it. 462 00:44:42.310 --> 00:44:43.940 Michael Lodder: It's just confusing. 463 00:44:44.100 --> 00:44:47.519 Michael Lodder: And it really doesn't add anything except complexity. 464 00:44:48.770 --> 00:44:51.140 Michael Lodder: So if if we can, I'd love to drop it. 465 00:44:51.590 --> 00:44:53.910 Stephen Curran: Okay, so I will. 466 00:44:55.880 --> 00:44:58.760 Stephen Curran: Oh, Richard, could you 467 00:44:59.150 --> 00:45:05.180 Stephen Curran: basically write up an issue that that captures the flow of that field 468 00:45:05.670 --> 00:45:07.969 Stephen Curran: and basically propose that 469 00:45:08.900 --> 00:45:23.410 Stephen Curran: you know the presentation request could continue to have either of those values, but they will be ignored. And we we update the implementation to simply have the issue or do what it needs to do and not involve the holder. 470 00:45:23.790 --> 00:45:26.040 Aritra B.: Yeah. yeah, I can do that. 471 00:45:26.530 --> 00:45:28.239 Stephen Curran: Okay, well, okay. 472 00:45:28.260 --> 00:45:34.729 Michael Lodder: here, here's a thought. I just said, maybe the holder wants to say, this is a unique interaction 473 00:45:35.080 --> 00:45:42.739 Michael Lodder: request from me to the issuer. and maybe once some unique identifier, you know, for an interaction. 474 00:45:44.040 --> 00:45:50.979 Michael Lodder: That's about the only use case I could see for it. But again, it adds nothing to the security model. It's purely for, like 475 00:45:51.260 --> 00:45:53.380 Michael Lodder: auditing purposes. 476 00:45:54.060 --> 00:45:58.190 Michael Lodder: So you can say, Hey, here's the unique identifier I sent over to the issuer. 477 00:45:58.440 --> 00:46:02.929 Michael Lodder: It is short, honestly, could do anything they want with it, they could completely drop it. 478 00:46:06.350 --> 00:46:10.389 Michael Lodder: Yeah, yeah, exactly. So that's why, I think let's just get rid of it. 479 00:46:11.060 --> 00:46:20.670 Stephen Curran: because I don't see how why the holder, the holder, can do anything they want to track. The fact that they got issued a credential. For one thing, they're going to have a credential. They can track 480 00:46:21.100 --> 00:46:30.020 Michael Lodder: right? Well, and there's there's 2 things you can't really hide, no matter how much encryption you'll deploy. One is time right? 481 00:46:30.130 --> 00:46:34.389 Michael Lodder: Both sides are going to be able to see it. and 2 is location 482 00:46:34.660 --> 00:46:40.509 Michael Lodder: right? Somehow, the packets all have to route back to the, to the source on both sides. 483 00:46:40.890 --> 00:46:44.520 Stephen Curran: So those are 2 things you can't really hide. Okay. 484 00:46:46.390 --> 00:46:49.100 Stephen Curran: okay. good. 485 00:46:49.720 --> 00:46:56.109 Stephen Curran: Okay, From there I'm gonna look through. I would like to get with 486 00:46:56.260 --> 00:47:03.620 Stephen Curran: Mike. What's your schedule over the over July? Are you working or holidaying or 487 00:47:04.130 --> 00:47:10.070 Michael Lodder: no. Yeah. So this week I'm traveling. So this week I'm a little slammed. But next week 488 00:47:10.320 --> 00:47:14.659 Michael Lodder: there's a Us. Holiday on Tuesday I might be out Monday as well. 489 00:47:14.740 --> 00:47:23.170 Stephen Curran: Yeah. But otherwise I'm more. I'm playing to work. Okay. So I I'm going to set up a meeting for the 3 of us. Say a week. Wednesday. 490 00:47:25.530 --> 00:47:27.320 Stephen Curran: I can do that. 491 00:47:28.310 --> 00:47:30.249 Stephen Curran: Richard. Can you make that? 492 00:47:35.950 --> 00:47:37.319 Michael Lodder: Maybe he went to bed. 493 00:47:39.110 --> 00:47:39.880 Aritra B.: Fine. 494 00:47:40.960 --> 00:47:44.200 Stephen Curran: July fifth. Can you make that a meeting? Then? 495 00:47:46.400 --> 00:47:48.150 Aritra B.: Yeah. Hello. 496 00:47:48.600 --> 00:47:50.100 Stephen Curran: yeah. Yeah. 497 00:47:50.510 --> 00:47:54.960 Aritra B.: Yeah, Steven, I suggest, we go a little on the early side. 498 00:47:55.100 --> 00:48:00.279 Michael Lodder: I was, I was gonna suggest 2 h earlier. If if that's possible. 499 00:48:02.650 --> 00:48:08.849 Stephen Curran: Yeah, could we do? yeah, 2 h earlier? Is that good for you? By Rachel? That would work for me. 500 00:48:10.950 --> 00:48:11.939 Stephen Curran: all right. 501 00:48:12.420 --> 00:48:17.360 Stephen Curran: which time can we just repeat which time? 502 00:48:17.570 --> 00:48:20.790 Michael Lodder: Yeah. July fifth, 2 h earlier than this time. 503 00:48:21.520 --> 00:48:23.229 Aritra B.: Okay, we are fine for me. 504 00:48:23.880 --> 00:48:37.180 Stephen Curran: Okay, good, excellent. Okay. I'll set that up. I I will will have a plan for the rest of it, and a proposal for meetings for the rest of the mentorship. 505 00:48:38.190 --> 00:48:39.860 Michael Lodder: Cool. Thanks, Steven. 506 00:48:40.110 --> 00:48:44.379 Stephen Curran: Fantastic work so far, that's for sure. Much appreciate it. Really 507 00:48:46.100 --> 00:48:48.860 Stephen Curran: great. 508 00:48:49.350 --> 00:48:55.099 Stephen Curran: Okay, just real. Well, just real quick for Rita. Do you have anything for Steven? And I, 509 00:48:55.460 --> 00:48:57.130 Stephen Curran: oh, yeah, absolutely. 510 00:48:59.740 --> 00:49:04.900 Aritra B.: Yeah. nothing as such. For now. So it does. Okay. 511 00:49:07.520 --> 00:49:09.400 Aritra B.: yeah, exactly. 512 00:49:10.070 --> 00:49:13.050 Stephen Curran: That's right. Okay. 513 00:49:13.330 --> 00:49:15.210 Stephen Curran: have fun in Montreal, Mike. 514 00:49:15.600 --> 00:49:18.220 Michael Lodder: I will. I'll eat tons of food for you. 515 00:49:18.400 --> 00:49:19.869 Stephen Curran: All right. Good. 516 00:49:20.220 --> 00:49:21.510 Stephen Curran: So you can see it. 517 00:49:21.750 --> 00:49:23.970 Michael Lodder: Okay? See you. hey?