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. 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. Stephen Curran: so we'll just quickly jump to meeting discussions I do have. just jump into edit mode. Stephen Curran: See, I've got to clean something up already. Stephen Curran: so I will do that. 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
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. Michael Lodder: Oh, okay. 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.
Michael Lodder: Okay, give me a minute. Stephen Curran: I'm at the airport, so I'm just bringing it up. Stephen Curran: Well, I I I I've got it up. Now let me know if I start turning robot. Stephen Curran: you know. Michael Lodder: and known to happen when you're at the airport. Michael Lodder: Okay? So I'm going to scroll down just to the Michael Lodder: yeah, I think it starts here. Yeah.
Michael Lodder: Okay. Michael Lodder: So if we look at. Yep. Michael Lodder: I call them statements. Michael Lodder: Yeah, these are basically what you want Michael Lodder: to be proved in a presentation. Stephen Curran: Okay, most basic one is a signature. Michael Lodder: This is basically saying. the data is signed and
Michael Lodder: selectively disclose the following information, so it's either a show, no show or Michael Lodder: I'd reveal for each claim. Michael Lodder: And that's all it is, and oh, and the third, the third item is Michael Lodder: from which issuer. 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. Stephen Curran: So what are the things that you can do with 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
Stephen Curran: are you for seeing that kind of support? Michael Lodder: You could do that I highly. 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. Michael Lodder: So 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.
Stephen Curran: So you get a presentation. 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 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. Stephen Curran: And then I'll decide if I trust that issue or Michael Lodder: yeah. So 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. 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.
Stephen Curran: I can you tell me what the A are? so schema schema publisher, identifier schema Stephen Curran: scheme a name schema version. Stephen Curran: So those 4 all relate just to the schema. Michael Lodder: Okay? So that should be compatible. Michael Lodder: So that shouldn't need to change. Stephen Curran: Okay, still, do that here. Stephen Curran: Yeah.
Stephen Curran: you've got the 2 related to the credential the issuer identifier and the issuer credit death, basically Stephen Curran: and then the last 2 relate to specific Stephen Curran: attributes within the credential, which is, must contain this this attribute name, and must contain this attribute name with a value. 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 Michael Lodder: is Michael Lodder: disclosed, which is like, must contain a flame with that equals or or even just Michael Lodder: contains the first name. I don't care what that first name is, but they have to disclose.
Stephen Curran: Yeah, for example, okay. Stephen Curran: yeah, that's all this is, and everything else is to be hidden. Okay? So I would say, we just go with. Stephen Curran: yeah, we go with that. the replication information. I I believe that's also in there. 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.
Michael Lodder: verification and cryptographic verification information and revocation information. Michael Lodder: So Michael Lodder: if you don't put the Revocation information in there, I don't know where else you would put it. Stephen Curran: Yeah. Stephen Curran: the I mean one sort of assumption that I think we can make.
Stephen Curran: I well, I don't know. They they Stephen Curran: you you could just say, you know, anytime, if the credential is revocable. You must include a revocation. Stephen Curran: You must include revocation. Michael Lodder: Yeah.
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. 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 Stephen Curran: from this time point to this time point. and it's very confusing to people. Stephen Curran: because what it's saying is. Stephen Curran: it's basically some sort of optimization around how fresh the revocation can be. 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. Stephen Curran: exactly. And and and that rather than being saying, You know, it's as
Stephen Curran: I mean, it's really only valid at the time point the publication of the data was made. Stephen Curran: You know what I mean. 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 Stephen Curran: nothing fresher. 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. Stephen Curran: Okay. so essentially, this is, gonna be more or less the same as we had it
Stephen Curran: as we have today. Stephen Curran: It really, isn't that different? Stephen Curran: Okay, excel. Okay. 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
Michael Lodder: so it could be swappable as me. Michael Lodder: But this allows that. So we already have that for a non crypto. Michael Lodder: Okay. so now I'm going to move on to the next one. This isn't much different. 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. Stephen Curran: Okay. Michael Lodder: this is like where I'm going to prove that 2 claims are the same without revealing.
Michael Lodder: That's all this bad. Stephen Curran: Okay? And 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. Michael Lodder: You're not restricted to the League secret. You could be anything. Maybe I want to prove multiple attributes. Or
Michael Lodder: that's what this would allow. Stephen Curran: Now, how how does this relate to whether the schema. Stephen Curran: one of the attributes, is in the same scheme or not? So one of the things that that got added Stephen Curran: after was the names concept. 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 Stephen Curran: way for the verifier to say Stephen Curran: this must come from the same credential. Is that what statement? Id is?
Michael Lodder: they can come from the same credential, but they can also come from a different one. So like, for example. Michael Lodder: maybe, like the credential itself is a medical record. 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.
Michael Lodder: and I'm going to prove that the last name on those birth certificates also matches Michael Lodder: the last name on this credential, so I could do that, too. So Michael Lodder: they can be different credential schemas, but they can also be the same. Michael Lodder: This supports both. 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. Stephen Curran: it's linking. Michael Lodder: Yeah, this statement, Id is like. from like a signature statement. That's how you know the data is valid or certified.
Stephen Curran: Okay, so these E qualities. These supplement a previous one, a previous previous statements. Michael Lodder: Correct? Stephen Curran: Okay? Usually. 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. Stephen Curran: Yeah. Yeah.
Michael Lodder: So assuming the signature is valid, then you can do this. Michael Lodder: So this is just the quality statement, identifier. Nothing new. There, then, this is saying. Michael Lodder: let's say, this is one signature statement. Id, and then you say, first name here, and then you give another one. Michael Lodder: and it's the same here. So usually you'll have at least 2 items in this Stephen Curran: right? Michael Lodder: Any questions with that someone had a comment. 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.
Michael Lodder: A signature is over a credential, not over a claim. Michael Lodder: You sign one claim, and that is your credentials with one attribute. Michael Lodder: So okay. 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.
Stephen Curran: right? Michael Lodder: If in mind, this was just the initial proposal it, we can update it. Michael Lodder: If you could do set membership Michael Lodder: or not membership with accumulators or with Cs or some other way, there's many ways to do this. Michael Lodder: Accumulators are usually the fast.
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. Stephen Curran: so that reference is not Michael Lodder: yep, it references like this one. Stephen Curran: The data is coming from here.
Michael Lodder: There's the label Michael Lodder: flame label. So let's say, it's Michael Lodder: revocation. Id. Stephen Curran: yeah, or a Zip code.
Michael Lodder: And then the rest of this is kind of more like, what are we going to use to check it. Michael Lodder: So it's an accumulator. Here's the actual accumulated value. 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 Michael Lodder: subjective to whatever the system is using it.
Michael Lodder: You can probably get away with these 2 Michael Lodder: parameters may or may not be Michael Lodder: optional. But let's say you're doing bullet proofs. Then you might need that. Stephen Curran: Okay, so what you're saying, I think. Stephen Curran: is as a verifier. Stephen Curran: I am going to. So I want to. I want to. We've got a claim label that is state. Stephen Curran: and I want to know if you are in one of 10 States. So so I take those 10 States.
Stephen Curran: and I feed them into a function that produces an accumulator. Michael Lodder: Yes. Stephen Curran: and then I passed that to you.
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. Michael Lodder: Correct. So let's say, the issuer said, All right. Here's how I map Michael Lodder: the States to an accumulator.
Michael Lodder: Anyone could say, Okay. Michael Lodder: I'll do the same thing like like I was saying, kind of last time disaster zone Stephen Curran: the issue for my driver's licenses. I map them just by. 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. 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. 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 Stephen Curran: okay Stephen Curran: okay and and they can do that because they know it's in it Stephen Curran: they 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 Michael Lodder: right.
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 Stephen Curran: membership or non-membership can be proven. Stephen Curran: That's right. Michael Lodder: The other way you could do this is, you could do it with an R one Cs circuit Michael Lodder: a little more complicated, but you could use it to do the same thing Michael Lodder: right.
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. 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 Stephen Curran: for some reason. Stephen Curran: No. Michael Lodder: no, elliptic curve. Elliptic curves don't have to contain. Pr.
Stephen Curran: okay. Michael Lodder: it just has to contain valid valid elements in the field. Michael Lodder: The only the only accumul that needs primes is an Rsa based one.
Stephen Curran: Oh, I see. Michael Lodder: So because in the one Michael Lodder: you know, it uses it an elliptic curve. They're just points. Stephen Curran: Okay, that's all they are. That's crazy to me 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.
Stephen Curran: But now you're telling me they're not even prime. That seems crazy. Michael Lodder: not for an elliptic curve. Stephen Curran: All right. I believe you.
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. Michael Lodder: So it's impossible for someone to enumerate and try to check which one's right. It's just Michael Lodder: too large to find it. Stephen Curran: Okay. all right.
Stephen Curran: fascinating. Yeah. Okay. okay, so that's 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 Stephen Curran: the calculation can be performed for presentation to present and to verify. Right?
Michael Lodder: Hmm. Michael Lodder: yes, it that it. The signature actually doesn't matter Michael Lodder: as long as it's compatible with the accumulator. So, for example. cl signatures are also compatible. even though their Rsa base 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.
Stephen Curran: Okay? Stephen Curran: And all that. The create a presentation of this you're just sending over the signature of the value. Stephen Curran: And then, on the other side. Stephen Curran: they're figuring out their Oh, oh, sorry, no! The Stephen Curran: the verifier sends over the enumerator or sorry the accumulator. Stephen Curran: and then. and in creating the presentation, the holder can tell if they met that condition. If they're in the accumulator.
Michael Lodder: Yeah, the the holder will know Michael Lodder: before they even do the presentation right. And if they're not like, say, the no-fly list. Michael Lodder: then they could, you know? Go? Oh, crap! I'm going to get. Stephen Curran: or whatever right but the but the Stephen Curran: the verifier is not sending over the actual list. It's only sending an accumulator. Right? Michael Lodder: That is correct. 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 Michael Lodder: yeah, because they can prove and verify if they had, to.
Stephen Curran: what? What I wanted, to be sure there, and asking, that was that the the Stephen Curran: the verifier isn't sending over the list of 22 States. It's they don't have to. Stephen Curran: Exactly okay. 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. Stephen Curran: Let's say, let's say it was. Let's say, if there were a billion items in that list
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. Michael Lodder: That's right. Stephen Curran: Okay? Good.
Michael Lodder: Okay. Michael Lodder: a commitment. This is like one use cases for the domain proof idea. 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. Stephen Curran: That's one use case for this. That's one use case. Michael Lodder: the other is 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.
Michael Lodder: So 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. Michael Lodder: and that requires a commitment. This is how you would do it. Michael Lodder: I, you and I have talked about how like it's a both for 6 commitments. Not
Michael Lodder: so. This is kind of one of one of those. Now. Michael Lodder: if you wanted to say. Michael Lodder: Yeah, domain proof, you could just stop here with this, the domain proof Michael Lodder: for a commitment. It's similar to what we've seen before.
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. Michael Lodder: What's the claim? And then. because we deal with a blinded commitment you need to generators. Michael Lodder: One is for the claim itself and the others for what I call a randomizer. Another term is blinder. Michael Lodder: I'm not. I'm not entirely sold on the nomenclature for this yet I like Randomizer. But Winder is also. Michael Lodder: I just think Blinder confuses people whenever I say, Oh, it's the blinding factor they're like, wait, what's that. Michael Lodder: So Stephen Curran: yeah.
Michael Lodder: I try it, randomizer, because I think people understand the plan is. Stephen Curran: and if they went to my Stephen Curran: presentation they would understand. Michael Lodder: Well, they should have? Stephen Curran: Okay. So from a business perspective domain. Stephen Curran: domain, name or sorry a delay in proof.
Stephen Curran: Is there any other business perspective on that? If you go the you know you mentioned. There's 2 types. Stephen Curran: the domain. Stephen Curran: the second one.
Michael Lodder: The second one is like, let's say you wanted to do bulletproofs. or what's your range proof. 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. Stephen Curran: But but would it verify or have to know that? Michael Lodder: Yes, they would. Now you could. You could hide that right? You could say here I would stuff the 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. Michael Lodder: and that's fine. Stephen Curran: Okay, let me come back. I sorry I want to revisit this. So I domain proof. The verifier gives a value
Stephen Curran: which is the claiming generator. They give 2 values. Okay. Michael Lodder: they get both of these right. Stephen Curran: The only things the verifier would have to get well, they'd say which one which claim label they allow. Michael Lodder: and 2 generator points. As long as these aren't the same.
Stephen Curran: Okay? And then what they get is a consistent Stephen Curran: signature blinded a consistent, blinded signature that as long as they pass the same planning generator or randomizer they get the same Stephen Curran: string back Michael Lodder: right Michael Lodder: kind of think of it this way. I can. I can post this link because this is public. Stephen Curran: Okay, here's what I call it. It's called a commitment. When proof 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. Michael Lodder: and whoever that is going to store it. 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. Michael Lodder: So that way. The proof looks different each time. But you're still indicating which domain proof to check
Michael Lodder: this this link is public if you want it. Stephen Curran: I'm still trying to translate this into language that Stephen Curran: I know. Stephen Curran: So what I'm trying to get out of this is. Stephen Curran: I get that that the same credential was used Stephen Curran: or the same attribute value was pulled from the credential. Michael Lodder: Yeah, every time 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
Stephen Curran: I've seen that one before. And so I can correlated with one I've seen before. Michael Lodder: That's right. Stephen Curran: Okay. Stephen Curran: which basically gives you that ability to have a unique identifier but not share that unique identifier. But the
Stephen Curran: but the verifier knows when the same unique identifier comes back. Michael Lodder: That's right. The great thing is yeah, with the domain proof. I can use that same unique identifier across Michael Lodder: domains. But it won't look the same to anybody observing. 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 Stephen Curran: and the and the parameter information. These 2 things
Michael Lodder: are specific to that domain Stephen Curran: they can't tell. Stephen Curran: And as a holder I could detect that. Oh, this is the same. They've used the same values as somebody else. Stephen Curran: Therefore they are able to collude if they want to Stephen Curran: right. The holder could look at these and say, Have I seen these 2 before?
Michael Lodder: Yes, they could. Stephen Curran: Okay, good. Stephen Curran: Okay. And that's the only Stephen Curran: is that the only use of this commitment. 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.
Michael Lodder: Pbs and Cl signatures required this. This also works Michael Lodder: like I said, range groups, range groups. You can't just take them as is Michael Lodder: from those 3 signatures. You have to do some translation. And this is the way to do that. Stephen Curran: Okay. Stephen Curran: but you can't give me a used case where I would do that other than just to say. Michael Lodder: well, for example, there are no range for supported by elliptic curves right now.
Stephen Curran: as it is so Michael Lodder: so in order to do that, like bullet proofs is a way to do that. Michael Lodder: But bulletproof takes a commitment, which is what this gives you. Michael Lodder: So I would have something signed by bbs, plus. 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
Michael Lodder: to say, Okay, let's say it's my age. Michael Lodder: So I make a commitment to my age. Michael Lodder: Whole proofs then goes, okay. I can take that age commitment and prove it's greater than 18. 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? Michael Lodder: They already are. So range proof comes down is down below right here.
Stephen Curran: Range proof right here. Stephen Curran: Okay. But it uses essentially the same technique. You're saying. Michael Lodder: Yep. Stephen Curran: okay.
Stephen Curran: so this one, we would rename to domain. And then we've got range down below 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 Michael Lodder: just the value from the signature Michael Lodder: to do something else to it first. 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 Michael Lodder: that took it from the signature to this value, because that's what I have to use. Stephen Curran: Oh, I see what you're saying.
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. Michael Lodder: That's right. 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. Stephen Curran: Yep, you could do that, too.
Michael Lodder: That's fine. Stephen Curran: Got it? Okay, that makes sense to me. Now, thank you. Stephen Curran: Okay. Variable encryption, verifiable encryption.
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. Michael Lodder: and you're essentially proving that you've encrypted the value to this encryption key. Michael Lodder: So whoever Michael Lodder: owns the corresponding decryption key could be crypted.
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. Michael Lodder: and Michael Lodder: so it's the same value in the credential, and you encrypted it to this encryption case. Stephen Curran: got it, and the used case. There is Stephen Curran: somebody, an issue or somebody else gives you a gives the verifier a public key. Stephen Curran: They passed the public key Stephen Curran: in this encryption key field.
Stephen Curran: And the result is they get a an encrypted data value that only someone with a private key can decrypt. Michael Lodder: That's right. Michael Lodder: There's a couple of use cases for this. Let's say that you wanted them to have some reporting system.
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. 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. 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. Stephen Curran: Yeah.
Michael Lodder: so they could do that. So in that case, Vc. Kev is also supplying the verify by encryption. Michael Lodder: even though they are the issue. So there's no external third party. Stephen Curran: Yeah. But it's a way that if they need to to mask you. They could.
Stephen Curran: Yeah. Another thing that this should have 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 Stephen Curran: with a hash key one, you know, a hash to the key.
Stephen Curran: Okay. Stephen Curran: yeah. Good. 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. Stephen Curran: and therefore you can. Oh, yeah, this is the BC. Gov. Stephen Curran: he.
Michael Lodder: that's right. Stephen Curran: Yeah. Okay. Stephen Curran: very cool.
Stephen Curran: very cool. Okay. Michael Lodder: I did not list verifiable decryption, although that is something we else we can also do. Michael Lodder: It's just not a very common use case for it.
Michael Lodder: I've only seen it used in my more complicated protocols outside of a non-creds. Michael Lodder: I have yet to see a use case for it inside and on. Stephen Curran: Okay. Michael Lodder: so I didn't add it. But we could just as easily add it if we wanted it.
Stephen Curran: and that is that the Stephen Curran: issue or issues that encrypted? 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. Stephen Curran: Yeah. Michael Lodder: but both sides would know what the value is. So the issue goes. This is the value I encrypted.
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 Michael Lodder: I got after I decrypted the issue work and said, Yes, that's correct. Stephen Curran: Yeah. But kind of like a scenario. That's weird. Michael Lodder: exactly. That's why I did play in here. I would agree. Stephen Curran: Okay, excellent.
Stephen Curran: All right. Michael Lodder: There are other that we could do, but I think this covers everything. Stephen Curran: and then the range proof is the last one. and range Stephen Curran: is this. And and the predicate we have today is also covered by range. Right?
Michael Lodder: It should. It just works a little different and a little faster. Stephen Curran: Yeah. Michael Lodder: then, how it's currently done. Michael Lodder: This supports this. 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.
Stephen Curran: Okay. Michael Lodder: so it's more flexible, because right now the current one is restricted to cl signatures. Michael Lodder: This one should be anything. Stephen Curran: It could be full. It could be our one. Cs could be anything.
Stephen Curran: Does that make sense? Michael Lodder: Yeah, okay, yeah. Stephen Curran: Okay. And then, what have you got down presentation request statement? 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.
Michael Lodder: That's literally all it is. Stephen Curran: Yeah. 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 Michael Lodder: that could be anchored to a dick, it being through a block cash, I don't really care. 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. Michael Lodder: Yep, exactly.
Stephen Curran: Yeah. Okay. Stephen Curran: And if that happens, you just have 2 statements with signatures. Right? Stephen Curran: Yeah.
Michael Lodder: exactly. And then this is just the data that is returned. Michael Lodder: I call them proofs. 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. Stephen Curran: Okay? Stephen Curran: Oh, that was huge out. 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. 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.
Stephen Curran: Okay. Stephen Curran: that's awesome. Stephen Curran: All right. Well, I got a lot out of that the reach. I hope you did as well. Stephen Curran: moving on to 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 Stephen Curran: have a discussion, actually, if you don't mind with the 2 of you. that idea of
Stephen Curran: Mike. Did you follow the conversation about the the issuer. or the holder providing the Stephen Curran: what we're now calling the entropy variable? Michael Lodder: kind of. Michael Lodder: I was trying to figure out still exactly what Michael Lodder: the use for it, as you said, like, it was partially there for legacy purposes. But do we need to go forward.
Stephen Curran: What I know is that in Indy there's this in the indie implementation. So going back to, you know. Stephen Curran: in the SDK and and credits. There's this value called issue. A holder did that the holder provides 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 Stephen Curran: is basically used to to provide entropy.
Stephen Curran: And so why? Stephen Curran: Oh, Rachel, can you help with that? Stephen Curran: Can you help with that question Michael Lodder: it? Well, is it coming from the verifier or the issuers? Stephen Curran: It is coming from the holder. Michael Lodder: It's coming from the holder. Aritra B.: Yes, currently currently the holder is providing it. So 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 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?
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. Stephen Curran: So the the holder provides it in the Stephen Curran: credential request. Stephen Curran: And then, as far as I know, the issue, or takes the value and hashes it. Stephen Curran: and then add it to some other information they have, and uses that in the signing. Michael Lodder: Yeah, that's not really needed.
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. Stephen Curran: So 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 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 Stephen Curran: name. But the question is, should we simply in the issue, or ignore whatever value is put by the Stephen Curran: hold her in there, and simply Stephen Curran: generate a random number.
Michael Lodder: Is it? Well, like? I said, there's really no need for it. If it's going from polar to issue, or Michael Lodder: if it was holder to verify, I could see that, being like self a tested place. Stephen Curran: No, that's not in case here.
Stephen Curran: Hold her to issue her. Michael Lodder: Then to me there's no need for it. I say we get rid of it. Michael Lodder: It's just confusing.
Michael Lodder: And it really doesn't add anything except complexity. Michael Lodder: So if if we can, I'd love to drop it. Stephen Curran: Okay, so I will. Stephen Curran: Oh, Richard, could you Stephen Curran: basically write up an issue that that captures the flow of that field Stephen Curran: and basically propose that 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.
Aritra B.: Yeah. yeah, I can do that. Stephen Curran: Okay, well, okay. Michael Lodder: here, here's a thought. I just said, maybe the holder wants to say, this is a unique interaction Michael Lodder: request from me to the issuer. and maybe once some unique identifier, you know, for an interaction.
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 Michael Lodder: auditing purposes. Michael Lodder: So you can say, Hey, here's the unique identifier I sent over to the issuer. Michael Lodder: It is short, honestly, could do anything they want with it, they could completely drop it. Michael Lodder: Yeah, yeah, exactly. So that's why, I think let's just get rid of it.
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 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? Michael Lodder: Both sides are going to be able to see it. and 2 is location Michael Lodder: right? Somehow, the packets all have to route back to the, to the source on both sides. Stephen Curran: So those are 2 things you can't really hide. Okay.
Stephen Curran: okay. good. Stephen Curran: Okay, From there I'm gonna look through. I would like to get with Stephen Curran: Mike. What's your schedule over the over July? Are you working or holidaying or Michael Lodder: no. Yeah. So this week I'm traveling. So this week I'm a little slammed. But next week Michael Lodder: there's a Us. Holiday on Tuesday I might be out Monday as well.
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. Stephen Curran: I can do that. Stephen Curran: Richard. Can you make that? Michael Lodder: Maybe he went to bed. Aritra B.: Fine.
Stephen Curran: July fifth. Can you make that a meeting? Then? Aritra B.: Yeah. Hello. Stephen Curran: yeah. Yeah. Aritra B.: Yeah, Steven, I suggest, we go a little on the early side. Michael Lodder: I was, I was gonna suggest 2 h earlier. If if that's possible. Stephen Curran: Yeah, could we do? yeah, 2 h earlier? Is that good for you? By Rachel? That would work for me.
Stephen Curran: all right. Stephen Curran: which time can we just repeat which time? Michael Lodder: Yeah. July fifth, 2 h earlier than this time. Aritra B.: Okay, we are fine for me. 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. Michael Lodder: Cool. Thanks, Steven.
Stephen Curran: Fantastic work so far, that's for sure. Much appreciate it. Really Stephen Curran: great. Stephen Curran: Okay, just real. Well, just real quick for Rita. Do you have anything for Steven? And I, Stephen Curran: oh, yeah, absolutely. Aritra B.: Yeah. nothing as such. For now. So it does. Okay.
Aritra B.: yeah, exactly. Stephen Curran: That's right. Okay. Stephen Curran: have fun in Montreal, Mike. Michael Lodder: I will. I'll eat tons of food for you. Stephen Curran: All right. Good. Stephen Curran: So you can see it.
Michael Lodder: Okay? See you. hey?
2023-07-06