Okay, great So I'm going to talk about some this is like a fun paper, but we're here for fun. So that's good This is not there's no sort of major vulnerabilities here, which is good So we'll just have some fun the sort of setting for this work is This is kind of the theme of like a lot of my research So you guys are all familiar with the law of large numbers, right that these sort of Statistics you the average behavior converges almost surely to the expected value as the number of samples increases, you know kind of You expect things to essentially converge this way So there is a sort of counterpoint to this law, which was formulated by Diakonis and Mosteller Which is that when a sample size is large enough any outrageous thing is likely to happen All right, so if you want to show the existence of some kind of strange behaviors Then You just collect enough data points and you will find some weird outliers Then okay, so in the cryptographic context I would like to formulate a cryptographic law of truly large numbers Which is that if you're given samples from enough independent cryptographic implementations any outrageous vulnerability is likely to be present So this is essentially this is my conjecture I conjecture this based off of a number of data points, which is essentially my publication record So this is my form, you know, this is how I got tenure. I don't know about you guys so So in that spirit this paper this work, which I should mention is joint with Joachim Breitner who is a DFINITY is Taking advantage of this observation So I guess it was sort of nice that we got an introduction to Elliptic Curve Diffie-Hellman in the last talk so now we're going to talk about ECDSA in this talk So we don't care about the elliptic curve aspect at all. We just care about the DSA aspect But most people are using ECDSA and not finite field DSA, so we'll push ahead with elliptic curves So ECDSA we have some global parameters. We have an elliptic curve E We have some generator point which has order n Your private key is some integer Your public key is, you know, that integer times your generator point We also don't really care about those details So in order to sign a message you hash it possibly in some complicated way Did you know that most ECDSA implementations hash the message twice? It's kind of weird Or One bit less secure than than once it's yeah, it's it's a little odd. I Did not know this until doing this paper for whatever reason so You learn amazing things. Okay, so You hash the message and we really we don't care about the details of that that doesn't really come into this So we'll just say the message hash we're going to treat it as an integer h and we don't really care so Each signature so the ECDSA the way it was originally written it is a randomized signature scheme So you have a per signature nonce which is really like an ephemeral private key It's some integer k this k is extremely important as we will see very shortly and So this should be generated sort of per signature And then your signature itself is a pair of values r and s r is the x-coordinate of k times your generator point and this s value is computed as Written down k inverse times the hash of the message plus the private key times this r value mod n so that's just an integer and For our purposes it is useful that Like this is just an integer and this is done using normal integer module or arithmetic So we don't care about like all of this elliptic curve garbage. We can ignore that part because that's hard and confusing so Okay, as much many of you probably in this room probably know As I said the value of k is extremely important So this k must remain secret for all of the signatures you ever generate or else your long-term secret key d is revealed and using Basic integer arithmetic you just like invert this question. Okay, very straightforward Like good good undergrad intro crypto like exercise probably You can amplify this a little bit This is also super well known if this secret Nonsense k is ever reused to sign two distinct messages with different hashes h1 and h2 Then it is trivial to compute this value of k basically by Solving two equations with two unknowns and then you get this value of k and then using the sort of equation on the previous Slide then you can compute the long-term secret key and then you're you're done. So this Comes up over and over again random number generation issues blah blah blah This is well known flaw people have been exploiting it for a long time. Okay, also a fun undergrad project The thing that we are going to be playing with in this talk is kind of an amplification of this maybe but it's much more complicated so This these nonces must be generated sort of perfectly uniformly at random or else If they haven't been We can possibly use a number of signatures to compute the long term secret key D So and the way this works is we essentially have some nice linear relations that we can dump into a lattice There is also an algorithm that uses Fourier analysis. We're going to ignore that for the purposes of this talk so we dump this into a lattice and then it the secret key is just spat out and kind of the high-level version of these attacks is that if These secret nonces k i are small then the system of equations likely has only one solution and the lattice mat like lattices can magically find it and if they are not small then I Don't know other other there are other kinds of biases that that can be exploited So that's the big picture of what we're doing here The sort of formulation of this problem. We're going to be you we already heard about the hidden number problem invoked once earlier this morning, so The way that you the way that we will formulate this problem is that essentially we have a system of equations with some unknowns in the signature nonces and the secret key D and It looks something like this. These are nice linear equations. We know the coefficients here and so we're just trying to Solve for the secret key D. This is a alternative formulation of the hidden number problem, which was originally described by Boney and Vic had a son a while ago in the context of actually breaking Diffie helman With bits known. I haven't seen that exploited in the wild actually Just sort of interesting Say here. Oh, you know, let me move around. I like moving around They'll deal with it We'll prioritize the people in the room Okay, I've been tied to my podium Tragically It's a room full of attackers would like okay. Anyway, so This is this is where we will briefly get into the scary lattice section So half of you will be happy and half of you will be unhappy But it's only a few slides. So Then then everybody can be happy because we'll start breaking things Okay, so we've already see we've already seen some of these lattice constructions This is all sort of well-known. So I will just go through the lattice construction briefly. So the hidden number problem As I said the way that I'm thinking about it. We want to find solutions to a set of linear a system of linear equations that looks something like this Where we have unknowns K1 through Km and the secret key D and For the for the moment, we're going to say that all of the k i's are small so they're less than some bound capital B In absolute value. So the if you read Boney and McCanneson's paper, they construct a lot of spaces that look something like this So you have your modulus n on the diagonal and then you have your One of your one set of coefficients kind of along the bottom row and then you want to solve the closest vector problem with a target vector that consists of the other set of coefficients and It just so happens that once you find the closest lattice vector Conveniently the distance will consist of a vector of all the nonsense So you expect this to be small since we said the nonsense are all small And so then this is just sort of spat out the solution and we can solve for the nonsense Okay, you can you can work out how well this works. We don't have if you actually try to implement this you know Solving CVP is annoying. We have If you just want to like press a button It's much easier to Find short vectors than closest vectors unless if you're super lazy So what everybody who is doing side channel attacks and stuff does Now is basically sort of embed this lattice into one dimension larger lattice And then you can just find a short vector and it will just spit out the answer for you And so you don't even have to like back solve for anything. So Here we've just sort of added the target vector to the bottom and added some scaling factors And it will just spit out the private key is the shortest vector so That's cool So this is what we are doing There's a lot of papers actually that get these scaling factors. I'm gonna get off the stage. Okay There's a bunch of papers that get these scaling factors wrong actually, which is kind of interesting But the only thing that matter that means is that like you have to look hard a little bit harder for the the secret key okay, so This works how well does this work? Well, we do a little bit of back of the envelope lattice math ignoring all of the Approximation factors because we're only dealing with really small lattices here So the dimension of our lattice is say the number of signatures that we have plus two the determinant is Whatever this is it depends on the bound and the modulus So ignoring the approximation factors because the largest lattice that we look at is like 40 dimensions If we use the LLL or BKZ lattice reduction algorithms We should find some vector that is approximately determinant of the lattice to the one over dimension And we're looking for a vector with length That's basically square root of m times whatever our bound is and if we plug that in and solve Then we get that the log of our bound should be less than that and if you want to put in the approximation factor for lattice reduction and that adds like a little turn here Okay, but generally the thing that we care about is that as we As we increase the number of signatures we expect this to grow towards log n, but never actually reach it So this means that our bound you know, it starts relatively small, so we expect it to start like n over 2 for For two signatures and then grow to approach but never quite reach and the length of n so The original bonnet of a kettison paper they cared about the limiting behavior, so you could reach that limit essentially Or you can't really get past setting m equals square root of log n If we care more a much more about concrete parameters So with two signatures we we get a pretty good success rate with And we specialize for a 256 bit curve Curve so we have a 256 bit and so the length of a Small nonce that we can solve for with two signatures is 128 bits. This has some failure rate With three signatures we can solve for 170 bit nonce with four signatures We can solve for 190 bit nonce and so on and so forth. I got these empirically So yeah and the point at which lattice reduction starts to get sort of too slow to run millions of times is like say 40 dimensional lattices so we stopped there with so we can solve for 248 bit nonces with a 40 dimensional lattice Yeah, sure. Do you want to come to the mic? Okay So in order for this to be solvable though, you need the product you need a property of these nonces that they are You keep saying that they're short. Yes, they're small So this is a little different from the way you normally think of this where the problem is that the nonces have like a few bits That are predictable. Mm-hmm. So if the nonce if the nonces have a few bits that are predictable Then you have you just add the term of like the most significant bits and then you have like the rest of it is this short piece Okay, so it would have to be specific bits It wouldn't just be that there's something about them that's slightly distinguishable or something I'd have to be like some specific bits are biased. Yeah, okay so with the with the lattice attacks basically if you have a side channel attack that's giving you some Predictable bits you can say shift them to the most significant bits and then you have a small piece that is Not predictable or that's not predictable That's what you're solving for and then you just add the term that corresponds to the bits that you do know and you have to know Where they are, okay, so yeah for analysis is a little bit Works a little bit differently, but we are specializing to the lattice attacks This is great. We're like breaking all the rules here Okay a few variants of this so we don't necessarily have to have most significant bits all zeros We can solve for most significant bits known and this or not not known, but the same by adding one more signature, so Say we have two nonces that are have most significant bits that are the same But we don't know what they are. We just know that they're the same We can subtract them and then the difference we can subtract the signatures and subtracting the signatures Gives you a difference of nonces that's going to be all the all zeros and so now we're back in the short nonce case So that that is totally straightforward So we can just add if if for some reason somebody has generated a bunch of signatures with most significant bits all the same We can just subtract one from all the rest of them and solve and then we're done so we've just added one more signature to the number of signatures we need to solve for and If we can also do pretty easily the least significant bits case Or middle bits, but we didn't even bother looking at that it works the same so you can subtract your Signatures which results in subtracting the nonces which gives you say least significant bits That are all zeros and then we can multiply by a power of two to shift those known least significant bits to the most significant bits and then we get the same case as before of a short unknown sequence of bits So it's everybody on board with our lattice technique So we have a magic box we can dump a bunch of signatures in and it will spit out the private key That's the part that we care about so that is the end of the scary lattice section We are done with math for this talk Now now we start breaking stuff. All right So fun times where can we possibly find billions of ecd's a keys and signatures many of them generated by amateur enthusiasts? Cryptocurrencies this is so great So I wore I wore my themed shirt today. This was the shirt is not my fault. I'm just wearing it. So Okay, unfortunately, we do have to worry about some of the details of the way that cryptocurrencies use Cryptography in order to implement this stuff and this caused a huge amount of grief You have no idea how complicated this is unless you've tried to do it in which case like I'm with you in our shared Sort of suffering so Bitcoin Ethereum and ripple all use the same elliptic curve for ecd SA SEC P256 K1 widely known weird choice So the way like sort of the cartoon version of the way that they use it is that the sender is signing some hash of a transaction And this gets recorded on the blockchain Jane luck And sort of published to the internet so Identities are addresses and these addresses are hashes of a public key Which is interesting because the hashes are both like a cryptographic hash and it loses information So in fact, if you sort of parse the blockchain and you see a bunch of hashes And or you see a bunch of addresses you don't actually know the public keys until an address sends Currency somewhere else by and generates a signature Which is which is interesting so there can be lots of Cryptocurrency associated with an address in going but until it generates a signature itself with an outgoing transaction We are cryptographically we have our cryptographic hands tied because we can't do anything with the address itself So we are we can only look at addresses that have already spent money So okay, so these transactions are recorded on each currency's blockchain Which is convenient for the attack or everything is public So if you want to say start analyzing the cryptography You can download a client you can sync the blockchain and you can start parsing and extracting the signatures And there's a star here because this is way more annoying at practice than it sounds. How many of you have tried to do this? Is it like painful and the grief inducing? Like this is I have no idea why it's so complicated like the way that and I should say that my Co-author Joachim was the one who did kind of this last part and I was just like can you please send me signatures like this is Because the way that Bitcoin Like generates hashes of transactions is incredibly complicated and it's like changed And so the only way that like we could figure out to do this was to just like modify the client to have it like print stuff out because Like well, it was validating the signature because it was just impossible to compute otherwise and Let's see. Are there other weirdnesses. I think There's a there's a few more so okay, but the the cartoon version of this is that you can just download the blockchain You get a bunch of signatures and and it's great the non cartoon and the non cartoon version is that if you start looking at all of the like Bitcoin analysis libraries that are that people have published out there for some reason They assume that people don't want to actually examine the signatures So they don't make it easy to get to them and they for some reason they assume that you don't actually want the Concrete value of a hash of like the hash of the transaction. Why would anybody ever want that? So it's hard to get Anyway, okay, so this like much research So like what you know Matt was talking about earlier today where there's like a great little cryptographic component And then there's like months of engineering. This is like the months of engineering for this this work So all right once we have a Convenient way of extracting the signatures here is our crypt analysis program so We will scrape the block chains. So the Bitcoin blockchain when we're looking at it had a billion signatures in it Which is pretty cool We can group them by a public key that generated each signature So this resulted in say 60 million public keys for Bitcoin that had generated more than one Signature Then we can check for the two attacks that we we talked about so the easy attack is checking for Repeated nonces, which is you can just look for a duplicated our value in the signature Or you can also look for lattice attacks on the bias nonces as we described We spent about 50 CPU years running these and at that point either You're rich and you can retire to some island without an extradition treaty or You are not rich in which case you publish a paper and I'm here so You can see what happened So Sort of the details of what we ran We clustered the signatures by the public key We selected random subsets of two three four and forty signatures and optimistically just ran the attacks for the short prefix and suffix nonces so Kind of if the collection of signatures that we chose happened to be vulnerable We would get the private key if not we would get nothing And so there I want to add one little extra weird snag in the way that these Cryptocurrencies generate signatures, which is that they're really worried about having unique signatures. So Fact about you CDSA the signatures R and S and R and negative s both validate And Bitcoin makes the signatures unique by choosing the smaller of S and negative s mod M to make them unique This has the effect of negating K like the the nonce So for the prefix and suffix attacks where we had to do the Subtraction we actually have to brute force us the signs of all the nonces, which is like super annoying Maybe there's a clever way to get around this maybe for analysis gets around this but we did not do that So there's some brute-forcing going on Okay, so what did we find okay, so I'll start with the easy case Which is the repeated nonce K values, so this has been analyzed many times by academics since 2013 So we'll just sort of summarize what you find so here is so the x-axis is Signatures over time with repeated values and then the size of the little circles there is the number of signatures on that date with repeated with a repeated nonce so Bitcoin out of the billion signatures two and a half million of them have a non-unique K Those come from 1300 unique keys Ethereum there's a smaller number of keys and smaller number of signatures and ripple also There is there are multiple attackers who are systematically scanning the Bitcoin blockchain and stealing all the money from anybody who produces a Signature with a non-unique nonce so there was no money in the Bitcoin ones there there actually were funds in the Ethereum and Ripple cases, so people were not looking for this yet in Ethereum and Ripple You may notice that there's a interesting Something interesting going on here with one of the values. I'll talk about that shortly Okay What did we find with a lattice attacks? You might expect that we would find nothing because of course who would be stupid enough to like make a mistake there but in fact we found a number of things so the y-axis is the Sort of format of the nonce that we found prefixes or suffixes in the love length of the random part and so we actually found 6000 signatures from 300 keys in Bitcoin these contain it contained point 008 Bitcoin, which was think 30 something dollars and Ethereum there were five signatures from one key. They contain some ether and we also found some SSH keys That were vulnerable due to this attack So I will now go through a few stories so What is going on with this giant circle here so This value So ninety nine point nine percent of the repeated Bitcoin nonce values are That that number This is n minus one over two where n is the order of the elliptic curve used for Bitcoin and it is weird fact the x-coordinate of One half times the generator point has a hundred and sixty six bits instead of two hundred fifty six So all of these signatures The r-value is shorter by 11 bytes. I'm really enjoying John Kelsey's expression right now For those of you at home, it is amazing. Okay So Why are people doing this well apparently the suggestion to do this in the context of Bitcoin and like well The reason that people are generating these these signature values is that Greg Maxwell suggested this to clear dust transactions So like sort of small amounts of cryptocurrency left in particular addresses And I guess you pay for the length of your transaction And so by having a signature that is shorter by 11 bytes you save a small amount in transaction fees Okay, that's what people are doing this, but the bigger question is why does this value have this property and Somehow the Bitcoin people figured this out and are taking advantage of it, but then like This isn't actually like a documented property of this curve it seems to be an artifact from the way it was generated and Nobody I have talked to know like knows why it has this property, but it is the case that a number of the the other Curves of the type also have this property some of them produce the same value and some of them have Kind of variants of this value It also turns out that the the generation procedure for these curves was not documented So this this is this tells us something perhaps I mean, so I've talked to a number of people about this and is an ongoing mystery, but if you We're discovering more things as we go along So this is this is telling us something about how these curves is generated are generated properly probably because you would never expect this to happen at random and You may notice that a hundred and sixty six bits is intriguingly close to a hundred and sixty bits Which is the length of say a Shawan hash of something, but it's not a hundred and sixty bits. It's a hundred and sixty six bits so they're not just like merely like hashing something and incrementing it's like hashing and then appending and like I Can I can I if people would like to see more I can show you a little bit of what we figured out, but So this is fun things that you find when you look at public key infrastructure so, okay, we will continue on to Further fun things that we found so one of the compromise keys from repeated Nances we traced to dark wallet dot is we were basically just like googling Addresses to figure out what they were because of course there isn't much metadata in Bitcoin itself that would tell us so this was part of a three out of five multi-signature address So that means that you need Signatures like this this address is associated with a number of keys and you need signatures from at least three of those keys in order to Send money out of the address And this was used for donations to dark wallet dot is At the time that we were looking this Address held a large number of funds like pretty pretty significant So we thought that they might care about the fact that one of their keys had been compromised and so I Got in contact with one of the authors of this site Who it's very interesting person both of the people are very interesting? Cryptocurrency people are strange so So I'm chatting with him and I was like so can you like tell me how you generated these Signatures because it would be interesting to know what implementation it was And we could like sort of trace this down and he said it's either me I was calculating the signatures manually or my friend who was working on dark wallet. It might have been an earlier version so Calculating the signatures manually. There's like a lot of money in here and it's just like kind of hand-generating CDSA signatures and oops you forget to see your your on G and and then you've compromised your key so This is the state of cryptographic software So some more human factors So after finding some very small nonces we brute-forced all the 32-bit nonces So this compromised 275 signatures from 52 keys some of the nonce values that we observed were Obviously not randomly generated So people are Having fun Yes, I mean I guess we could like try to get some confidence values like if we had some prior here then I could like Don't know what the what the the confidence interval for this is Anyway, so okay Sort of more like on a slightly more serious note There have been a number of random number generation vulnerabilities that have impacted Bitcoin over several years two of the most prominent ones There was a bad vulnerability in Android secure random They were I think it was not like getting a fresh state on a fork And so there were a number of repeated nonces and a lot of people got large numbers of funds stolen because of repeated nonces generated from Android Bitcoin wallets in 2013. There was also a vulnerability in the blockchain.info Wallet From 25 I think the vulnerability started in 2015 There was an issue where they were seeding from random.org and random.org redirect from HTTP to HTTPS and so the blockchain.info Was pulling the the data from here But then when this redirect happened they were just getting the 403 redirect rather than the actual output that was supposed to be coming from random.org and so This resulted in a constant seed for the random number generator So we can see I mean It's it's hard to tell I mean these were two of the like most highly publicized random number generator vulnerabilities in Bitcoin wallets, but These don't really seem to quite line up with with what's going on here. So there's clearly a lot a lot of other stuff happening Okay, I Would like to talk about Sort of the small nonces what is going on there? So most of the small nonces that we found were in like one cluster of 64 bit nonces almost all of which were multi-signature Addresses and They seem to be confined to a particular set of dates But this was like all of the metadata that we had we like looked for the addresses We cannot figure this out and so actually after we posted our paper online Greg Maxwell wrote to us and he's like based off of the set of characteristics. I think I know what caused this and so it turns out that There was this library written by bit pit this bit pay organization and when they They made an update to the library Update sign function to use elliptic In which they gave the wrong length of buffer for the length of the knots that they were the the lengths of the random knots that they were generating and this Update corresponds exactly with the beginning of the generation of these nonces. This was fixed relatively quickly This was fixed only a few weeks later To have the correct length of nonce. So what is going on here? Well So I've marked The two dates here So this is this is the beginning date and this is the the date in which it was fixed But by this point The data which had been fixed this library had already been forked and was being used in a number of other projects And the bug fix did not make it into these downstream projects and so it continued to be used For for quite a while afterward before being fixed so yes, I Think this has something about the fragility of ECDSA in general Okay, this may also be a familiar story to everybody who's tried to report a vulnerability or fix a vulnerability in a product So, okay more fun we can We tried looking for more 64-bit nonces since our lattice attacks We were just sort of running them on a random subset of signatures We were not guaranteed to find all of the vulnerable keys, but a 64-bit nonce you can actually Compute outright if you want so using Polydoro or baby step giant step you could basically compute a 64-bit nonce in in 32 In two to the 32 work two to the 32 work times a billion signatures is not feasible still so we Altered the parameters a little bit to try to search for this so essentially we did a pre computation we can pre-computed a Hashtable of two to the 39 elements this took up 2.2 terabytes This was sized because the largest Amount of RAM that I had on a single machine was three terabytes. So this was intended to fit into RAM And then we pre-computed a two to 32 lookup table of the logs of these elements So this took a few days on a few hundred nodes of my cluster to pre-compute So then this led us do two to the 25 work to look up signature Unfortunately, the lookup was still two to the 25 should be feasible, but because you're looking up in This huge amount of memory. There is no caching possible. And so it turns out to actually be pretty slow It's about 10 seconds per lookup Our machines to do this. So we ran it for a couple weeks and checked a random subset of 140,000 signatures and The conclude tentative conclusion that we have is that 64 bit nonces are not much more common than the ones that we found So we found most of them probably Okay, so other fun Here is a set of signatures that were generated by SSH servers that had a shared 32-bit suffix so you can see this value in blue is Shared among all of these signatures. So what is this if you Google this value? it turns out to be one of the round constants for sha2 With change byte order, of course, but I Don't know how this happened. I don't know how you like I mean I assume somebody was trying to like use like sha2 to Generate their nonces, which is like a good procedure, but I don't know how you screw up your sha2 Implementation so that you get like a fixed value in the least significant bits of this so Interesting we also have no idea what implementation this is So the final sort of screw up that I want to talk about is Probably memory unsafe code so there were 54 signatures with a shared 128 bit suffix and The shared suffixes you can look So they've been grouped by suffix here and you can see that actually if you compare these to the secret keys that were associated with the nonces the 128 least significant bits of the nonce were the same as the 128 most significant bits of the secret key Which is weird So you might hypothesize that you know a possible explanation is that somebody writes some code where they get the length of the of the secret key wrong and they accidentally like sort of overwrite a buffer and Are sort of cop start copying things into the The Key, I don't know But the thing that's really interesting about this case is that These signatures when we looked at the addresses that were Where the money was being Transferred out of a lot of them had been published on the web somewhere So they were associated with mem like memory wall memory memory wallets that had easy to guess passwords like Android or something or they were contained in like Example code from various implementations That had like just you know here's a sample address and here's how you generate like a transaction to send to that address and people had Like sent money to that address presumably copying the sample code and then someone had like then Taken the money out of that address because the the secret key was there and So our hypothesis is that these transactions were actually generated by an attacker Who is stealing money from these vulnerable addresses that have been revealed somehow already on the web And that the attackers code is the one with the memory safety vulnerabilities So I don't feel that bad about sort of dropping Oday here So There is a simple and well-known counter major to everything that I have been talking about and this has been known for years Which is to use deterministic deterministic ECDSA you can generate your secret non-spy You know hashing or HMAC or whatever your secret key and your message hash and probably like basically any combination of this is essentially secure if and there's an RFC that Does this all of the official libraries for the cryptocurrencies that we looked at Bitcoin Ethereum and Ripple already do this and have been doing it For years, so everything that we have been talking about is not from the official core libraries of these cryptocurrencies at 25519 bills and deterministic non-shed generation from the start ECDSA probably should have but it didn't so Sort of backing up a little bit Sort of what are we doing here? essentially We spent a lot of time thinking about cryptographic assumptions like as cryptographers disease explicit assumptions like discrete log is hard a hash function behaves like a random Oracle you can argue about these maybe they're secure, maybe they're not but you can actually sort of This is what we talk about like at conferences like this But there's a lot of implicit assumptions in cryptography also like the implementation is correct The random number generator is functioning the code implements all the required validation checks. We've seen this be violated multiple times today and So like it seems useful to say is to think more about these implicit assumptions when we're designing cryptographic schemes so I would Sort of hypothesize that essentially fragility under human error should be a cryptographic design consideration We know that developers will make mistakes. How do you minimize the damage? One idea is to tie security to basic functionality like say at 25519 is trying to do that like your scheme is not correctly implemented if you don't do this and We'll see how like this go like goes moving forward and sort of in general There's sort of a tension between diversity of having like a bunch of different primitives and implementations and baseline security So what we would like is to have like one library. That's like really great. It's been like formally verified. It's been vetted But then if that library breaks them like everything breaks all at once So then you might think well, okay, maybe it's good to have diversity like not everything would break at once But then you get kind of this long tail of implementations, which is what I've been exploiting in this talk so Here is my last slide. So we have Other stuff in the paper like tables with numbers and more examples of ad implementations This paper was at financial crypto this year and it is on e-print So, thank you Okay, thank you very much Nadia and there are already some questions. I can imagine that there are other questions after this as well, so Anybody question or everybody wants to go to Enjoy the reception. Okay So maybe I ask about this shot to Overflow or what was it? Can you imagine that it could be some overflow or boundary violation that could be Produced in in the code or something like that? Have you analyzed it? Yeah in the last round Possibly, I mean, I guess if these sort of like but I mean it's unclear like why sort of These values would be sort of allocated next to the value that you're produced yeah Yeah, I mean, I guess if you I guess if you like allocated this whole table and then like the next thing that's allocated is like the Buffier copy and then you and then it's the wrong length and so you accidentally like copy over into the last value. Yeah Maybe So we have we have no idea what what this library is So, I mean you can rerun the calculation and find the same list of hosts and Play with them maybe without violating the CFA and But yeah, we don't know what they are Okay, so I would say Thank you very much for attending this workshop and Enjoy the reception the second workshop day Tomorrow and the rest of the conference. So thank you very much


Welcome to the July 26 2023 errors working group call. A few things. Topics on the agenda, marketing update, endorser service. And RFC pull requests and notably the one involving community toward it updates around unqualified dids. We are recording. So we'll be posting recording afterwards reminder. This is a Linux foundation hyper ledger foundation meeting. So the Linux foundation. Any trust policy is in effect. As is the hyper ledger code of conduct. Anyone new to the meeting that would like to introduce themselves say hi or talk about what they're doing in the community. Feel free to do so now, or if anyone has any announcements, please grab the mic. Any topics to add to the agenda. All right. I'll start with release status updates. Notably released 090 of acupy has been released with the new credits implementation of an on credits so the removal of the credits. Dependency and series of performance improvements and fixes. In the CL signatures implementation. So for a non credits. So that's in place. And the release was completed earlier this week. I actually haven't sent out a full announcement yet. But it is on my list for today. To let everyone in the community know. If you guys have any announcements from the various projects. Stephen I was at the AFJ call last week. And had shared the information from this call previously about wanting to deprecate. Did the indie SDK. Yeah. And so there was the fair amount of discussion about that. And so what I wanted to do was to get in touch with you to make sure that. All the. He understood everything that was going to need to happen and everybody was in sync. Okay. I have not yet heard from him, but hopefully will. I've sent him a few notes this morning about. Other upgrades. So hopefully that'll. That'll come out as well. Thank you for that. I'm going to go ahead and get back to you. I'm going to speak with. The areas VCX crew who are on C on the call today as well. And. They're. Doing their work on that. And wanted some other updates and. Information about using. In particular the. And now in credits rust implementation. So. That too was moving forward in the areas VCX community. Okay. So I'm going to go ahead and get back to you. I'm going to talk a little bit about the topics. Helen. I see you are here. And Alex as well. But can you talk to us about the marketing update? And do you want to share. Nothing to share today. But yeah, happy to give an update. We met yesterday with the Aries marketing working group. It had a few folks join us, which is great to have. The, the survey that we had presented at the last meeting here. That Alex presented. And so we've got some really great feedback from others in the community who had. Just some help rounded out that the survey results, which was great. So our next step is that we've identified is to now reach out to the. And then we're going to go ahead and talk to the foundation staff. And talk with them about updating the, the website there in the process of updating the entire hyper ledger website. So we're trying to figure out how to get in there. Kind of their workflow to get some of that information updated. And then we'll move towards making sure that we are in alignment with the layout. Kind of the prescribed layout that is already there for projects and the wiki as well. And then we're going to go ahead and talk to the foundation staff. And then we're going to go ahead and talk to the foundation staff. A lot of the conversation yesterday was talking about how high level to start. Some of the messaging and communications and kind of overview. And then how to. Kind of lower the barrier of entry. For use adoption, contributions, involvement in the community for developers as well. So kind of how to describe. And then how to direct the developers where to go as well. So I'm really excited for the progress in the kind of maturity of what we're talking about and what the direction we're going. And now it's all about finding the right way to implement it across the kind of various touch points that folks reach when they are heading towards areas. So stay tuned for, for those updates between now and probably our next meeting. Cool. We're having an internal workshop at BC gov Helen that. We hope it will be a. The start of a series of workshops that. Simplify the ramp up for developers. And that, that can be used, you know, repeatedly within our organization, so that we'll apply outside and so make it. That, that initial climb much, much easier than it's been in the past. That sounds awesome. Yeah. I know a lot of organizations are really trying to crack that net in terms of trying to. Yeah. Just increase adoption. Reduce time to adoption, et cetera. We at a DCO just put out a short kind of beginner's guide yesterday that we're circulating. Yeah. Yeah. I think it's more of more geared towards the business audience, really explaining what. What verifiable credentials do what, I mean, very, very kind of a very high level. But I think it's, it's that sort of essential guide that I think a lot of people, especially business decision makers, kind of need early on in their, their process. So yeah, I'm happy to post that somewhere if folks are interested. Yeah, very cool. I would be interested in that as well. Cool. Maybe I'll just put it on the discord link or something. So cool. Okay. We're also seeing, by the way, for developers that I'm, I'm helping or working with a person who's new to the community and every turn they hit M1 problems on a Mac. So we do have to figure out how to deal with that. We're almost there. We've got lots of fixes, but not quite everywhere. So one thing that I would suggest the different projects do is, is make sure that somebody is trying these on a, on a plain M1 Mac and seeing how they go and because that's super frustrating when you're just trying to try out the tools and even the demos don't work because of issues like that. Okay. So, and just one last thing is that our next hyper ledger Aries marketing committee. Work meeting is it's last Tuesday of the month, so there'll be one in our next ones in August. And again, even if you're not a marketer, you're not necessarily interested in marketing per se, but you do have opinions about what is useful information for different audiences. Please, please, please join us. That's the best. Some of the best conversation yesterday happened from folks that aren't necessarily in, in the marketing realm, but definitely have opinions and ideas about kind of Aries communication and we will be extending a special invitation to Steven and Sam to join us because we have some questions that we'd like to pick your brain about. So hopefully you guys can join us as well at the end of August. So I'll try to get that on your calendars. One other thing to point out to everyone is that I believe there is said quarter three is identity themed. Yes. So basically anyone that wants to, you know, do some promotion or have hyper ledger promote what they're doing in the community, what they're doing, what their product does and things like that. That's a great opportunity to use hyper ledger to do that. And, and we encourage that. So definitely keep that in mind. Yeah. And if you have any questions, please feel free to direct your market, marketer folks, marketing team folks on your teams to me and I'm happy to answer any questions or to Ben, you know, the hyper ledger staff, they've been putting out. Yeah, lots of messages about it. So if you have questions or need, need further information, please, yeah, don't hesitate to reach out. Awesome. Thanks. No problem. Okay. Thank you. Aries endorser service. We're doing some work in BC gov. So we thought we would. Share this presentation and sort of set the scene and then talk about what we're doing. So Aries endorser service for those not aware. Aries endorser service is a. Aries endorser service for those not aware. So it's a version of acopie. To act as an endorser. So the idea there is that in your own. Enterprise and your own environment, you can spin up an Aries endorser service. And then point your Aries agents to use that when necessary. So this, this presentation is about going beyond rejecting or accepting everything, which is where we're at today with the Aries endorser service. A reminder of what the Aries endorser services originally implemented to support the hyper ledger Indie endorser model. So on Indie. An endorser is allowed. An endorser is a role. That is given to a dead and an endorser is allowed to write transactions and allow to endorse transactions for others. So basically. Aries endorser uses their dead and verification key from their dead on the Indie network. When writing transactions to the network for themselves. But they are also used that to endorse transactions for others. And so the common pattern. Is for an organization to have a single endorser. And for any other. Services within the enterprise. So basically, it would not be an endorser, but rather be an author. An author is not allowed to write transactions unless they are endorsed means signed by an endorser. So basically all of the other issuers within an entity. Would send a note to an endorser saying, Hey, here's this transaction. I want to write, can you endorse it for me? The endorser signs it. And either. The endorser, you know, submits the transaction for writing or sends it back to the author and the author submits it for writing, either works as long as the signatures are in place. The author must have constructed the transaction. The endorser must have signed it. And then after that, whoever submits it. Is able to do so. And then on a public indie ledgers endorsers are able to write. As long as they are not responsible for, for paying a trend, paying for a transaction that they write and that they endorse. So the ledger itself doesn't care what transactions they write as long as they're properly signed by the author. And if necessary, an endorser. And then that the endorser would then be charged for them. So. The endorser would then be charged for them. And then the endorser would then be charged for them. Endorsing. Service within an enterprise may be useful on other verifiable data registries. So as we start to think about using other services, the enterprise might want to have control over who's allowed to write. So an example is in BC gov. We have a central digital trust. And I think I've got that in here. Maybe I don't. I think we have a digital trust group. And that digital trust group is. Charged with making sure that. Other groups follow the. Policies and regulations for using for issuing credentials. And for using common schemas and, and doing things in a collaborative way. And so. We have a digital trust group is basically the endorser. And so even, you know, even if we weren't using India, we would still want that control to make sure that. Organizations within BC gov are not. Issuing credentials, for example, that they're not authorized to issue. They're not the actual authority over. We don't want. We don't want them to issue credentials. We don't want them to issue credentials. We don't want them to issue credentials if you will. Issuing credentials that they shouldn't be issuing on behalf of the BC gov. Okay. So basically within acupy, at least, and certainly with the endorser service. There's two roles, the author role and the endorser role. The author simply has to know who is my endorser. And the endorser role is to a single ledger. So we in BC gov, for example, we write to multiple ledgers. There's an endorser for each of those ledgers and author needs to know, Hey, which ledger do I write to and therefore which endorser do I use. Basically the author, the author is handed a. Did for the endorser and they can establish a connection with that endorser and then. The endorser needs to know it's endorser did. Whether it should auto accept a connection request, should I just accept a connection from anyone that sends them, should I auto endorse request every time an endorser sends or an author sends a request, should I endorse it. And. The endorser service doesn't have a controller right now, so it isn't built in. You don't have to build your own it with the Aries endorser service. So as a result of it, if there is no controller that you've implemented no business rules that you've implemented. It's an auto reject service and that's the why I had that in the title. Right now the Aries endorser service that exists either auto endorses everything because you've told it to or rejects everything because there's no controller to override. So there's no controller to do anything that you've told it to or reject everything that requests. There is a configuration on writing. You know the. Sorry, that the first sentence in this is wrong. This would say the author must write the transaction to create. Oh, sorry. No, this is right. When using this. For rights to actual to Indy. The endorser must write the transaction to create the transaction to create the transaction. And the author must also write the transaction. Writing the transaction that creates the authors did. The author sends the did over not the transactions, but rather the did and the very key. And then the endorser writes the transaction and submits it to the ledger. For all other transactions that the author wants to create to create a schema, credit, def revocation registries and so on. The endorser may execute the sign transaction or the endorser may pass it back to the author to submit. So either of those work, it doesn't really matter to Indy who who submits it as long as the correct signatures are on the transaction. The author has to be the author of the, and the endorser has to endorse it. So that's basically the roles and and functionality of the of the endorser service. So, preliminary ideas we had for for what the what a finer grained controller might have a finer implementation. So authors might be authenticated somehow and authors would have all or nothing privileges in other words if an author was allowed to use an endorser, then that auto correct would work the author could write whatever it wanted. So a way we can enforce control over the in the endorser would be to create some sort of allow list a list of dids allowed to be endorsed. It's a bit tricky because the author did is not known until the first time they request there did be created. So it would submit a request and then it would be held until it would either be rejected right off or held until their did was allowed, put into an allow list. And so then we thought well we need a UI for managing the allow list we need, we need a way for people to add and remove dids from it. So that's hard to do, you know if you're having a generic service, how do you create a UI that will fit everyone's use that's, that's pretty tricky. Oops. This touches back on the BC government requirements but a little bit more we have that I mentioned the digital identity and trust group approve rights to the ledger. We wanted BC gov wanted finer grain controls they actually wanted permission not over just whether a an author is allowed to write transactions but rather every specific transaction be approved so in other words, if an author wants to write a particular schema, we would want the digital identity and trust group to look over that schema review the schema agree it is necessary agree that it's appropriate that this group use this schema and not use one that already exists. If, if the schema should be one that already exists, the, you know, the request to write a schema would be rejected. Similarly, you know, a credential definition and so on. So basically we wanted control not just over who the authors were, but actually each transaction that the author wants to write. So that, that creates a logistics problem how do we implement such a thing. Without that, and with that, I'm going to turn it over to a miliano soon a who is working on ideas for for implementing such a thing so I'll stop sharing and pass it to you a million. Thanks even. I'll put a link in the chat in the meantime, because it's what I'm going to be sharing for the most part. I figured out how to share the screen that would be great. There's a button called share screen. You know it's early for me. You're welcome. All right. I think you can see my screen right. Yep. So this is the, an issue that I've logged. And we have been having a conversation on in the ears endorser service repository in GitHub, and they should describes a little less in detail, but Steven just exposed so sort of like the requirements were looking at implementing and provides a suggestion or initial starting point at how to implement the access control this endorsement more granular controls and configurations and the idea was to keep it as simple as possible. At least for the first cut, as Steven mentioned, it's hard to come up with like a UX that works for everybody. And especially if you're looking at at the UI controls. So we try to put together something that should work in most cases and should be extensible in the future without too many issues. I'll just skim skip to the bottom. A recommendation just to give an overview and then we can open the conversation if you want. The idea would be to have a few different levels of authorization that are stored in the endorser service as a permission matrix or allow list. We have at the very as an initial step and allow list to determine who is in the first place allowed to get a connection to the endorser and even have the opportunity to request any type of endorsement transaction. So this can be just like a simple table that includes the did of the requester or in case of multi-tenant instances, we're working quite a bit with multi-tenant stack up high, in particular with traction, we're trying to get that to be our default way to go to a new agent for a government business unit that requires one. So in that case, I think we might just want to match on the public URL for the agent, since it's going to be the same for all of the tenants. And these will allow the items in the allow list to establish a connection with the endorser, nothing more. The next step would be to have a permission matrix that finds each did to the operations that they can perform. They can publish their own did, they're public did on the ledger, they can publish schemas, credits, and while publishing the did is only a true false flag, schemas and credits would have three different states that could be applied, these are reported up here that are auto, manual and deny. This comes from a suggestion from Wade Barnes. These are basically the, what would we envision seeing like the three paths that could happen. If a request comes in, it could be automatically approved for a schema, if more on that in a second, but the endorser could work automatically on that request. It could require input from an administrator. This is what happens nowadays. We need to basically accept the endorsement request via API, or we could add a denying case. I don't know that that particular author has been misbehaving and is not allowed to request endorsement anymore. This permission matrix would be a top level type of permission to explicitly set what each did is allowed to do and how everything is treated. And there would be two additional allow lists that depend on that. So there would be sort of like a foreign key relationship on the dids in these table and these two tables. One would be an allow list for schemas and would specify a schema name and schema version that can be published. This goes back to what Stephen mentioned. Determine whether the author should be allowed to publish that schema or it would be better for them to reuse a schema that's already published. Some ID documents might follow the pattern where a higher entity organization publishes the schema and then, in Canada as an example, it could be a federal government publishing like an ID document schema and the provincial government having their own credential definition. As you can see, there's a possibility of adding wildcards in case it was determined that a specific schema name is okay and further versions can be updated automatically. And the same thing, so to speak, would happen for the credential definitions that tie any insurance schema. I see Stephen, you have your hand up. Just a quick confirmation. When you say manual on the permission matrix manual implies go to the allow list to check versus allow or whatever it was called where you don't even need to check the allow list it's just they can do, they can do any creating schema. Right. Manual would just mean the request gets to the endorser and stops and then something needs to happen for it to go through. It could be updating the allow list and kicking off the process again if that specific entry can be approved or it could be a one off and admin goes to the API for the endorser and manually approve that transaction and move it forward. That would be basically a way to handle exceptions. But the problem with that is that implies that the areas endorser service will have a UI and I think that's probably a bad idea. You can call the API is there exposed right now just using postman or something else right like that that's really like a edge case scenario that could happen. It's there's no really way to prevent it, in my opinion, and depending on who's running the endorser service they may or may not they may decide to do it that way or not like that. But what would happen right now like right now, if there's nothing in place so if you send a send an endorsement request to the endorser, the transaction would just either be approved automatically which is definitely what wouldn't not what we want, or sit there until an administrator goes to the API and calls the API for the agent to approve the endorsement request. What I'm suggesting is that that that hang option not be an option that basically the not be possible at all basically possible at all they'll either get accepted or rejected and and therefore either you know it's either if it's manual and it's on the list it would be accepted but if it's manual and not on the allow list it would get rejected and and it would be the responsibility of the caller to decide if they are what to do about retrying. Gotcha. Steven the system challenges in manual workflows, because then you end up having to pull the, pull the endorser service for exception right. Yes, yes, but the benefit of that is the endorser service is has no interface no user interface and no need to hang on to things otherwise you're basically just hung there. If you reject it at least you can have some. So, my thought is presumably the organization that knows how endorsement happens. You know how approval happens such that they get on the allow list so they could decide what their retry strategy would be. This this endorser service then won't have any API is to do manual processing that it does. That's why the manual step was set there. I just want to I just want to throw in my two bits I the manual the manual approval is already an existing workflow within the endorser service I think it should be left there and it should be left as an option simply because somebody. Somebody might decide to, you know, build out a UI around the endorser service and I don't think we want to stop them from being able to do that. The manual process in my opinion would be if you had a UI basically what would happen let's say somebody requested a endorsement of a particular schema. If you built in, you know, if you built a UI and notification system around that if you decided to, you would end up having notification that a request has come in that would be queued for a review that you could go in review the request review the schema and then, you know, approve that through UI.  This is Tim and yeah in Ontario that would break our complete automation if we didn't have that ability. So we use pipelines to approve. And the endorsers don't know anything about the dids really that much of what they do but they get requested by a ticket. And then they go in and they use pipelines to approve against the API is. Yeah, there's a chicken egg problem I think other way around in terms of process. I'm not so sure you can always pre configured the allow lists before the requests are made. I'm not so sure that's the right necessarily the right process it might be but I think this the reverse of having requests come in and then be approved makes a lot of sense and certain flows especially if you're using a ticketing system, or an enterprise request of a service to request approvals for things external to this. Anyway, that's the way we're doing it so yeah I just yeah breaking that that that pattern would break our entire deployment. So total now a total agreement but now I think it just means that there should be a fourth one, which is allow list. So that you get so that it can be that you get approval or rejection based on whether it's in the allow list or not. I think that's where auto comes in auto would just default to the allow list and then no process the rules there and then do the allow list says so that's what auto is to me. Oh, that's right auto meant. Yeah, whatever they want. So they would be endorsed if it came from a certain did then it would be endorsed and I think that is also another policy should that should be there so that's why I would say there should be a fourth one. Well that that that would be you would have auto at the did permission matrix and then you would have the did listed in the allow list for schemas with with name and version as wild cards and in the credential definition allow list with wild cards I mean, maybe I should try basically auto endorse anything. I mean running through an example here of how we're, how the things were were thought through or or not through thought to some extent to just try and clarify. One note is noted up here I kind of like skipped over it because I kind of assumed that I was known, keep in mind that there's flags that can be set at the agent level to fully automate certain types of actions as an example connections you might set the endorser to always accept connections from everybody but not process any request until further rules or input are are in place. Anyway, if you do just just run through an example that might help clarifying what I meant. Some tenant from a multi tenant service with the did you I whatever is asking to connect for the endorser. If these are the base URL the connection would happen automatically, but until something else is set in the permission matrix and allow list. No operations would be automatically endorsed. Somebody would go in the configure the permission matrix to include the did and set these flags, the way that they wanted so did public true means like these did will be able to request the endorser to publish the data to the ledger and endorser will accept the transaction and will do it. That's sort of like the only way to do it is based on what the presentation that's even gave before and explains and then based on these flags as Wade was explaining say like schema endorsement if these were set to deny the transaction request would be rejected. Clear clear and loud. If it is set to manual the transfer the transaction is not rejected or accepted it sits there and goes in a queue for an administrator or some kind of process and administrator could be a theoretically like an automated process to review it and act on it. If it is set to auto, then it would drill down and look into the allow list for the specific item. Let's say it is the schema and check if there is a did registered for that matches the one that is making the request. If the schema that is being requested endorsement for is in the allow list. And if the version for that schema isn't the allow list keep in mind that could be wildcard so in theory if I really wanted to have something super open. Don't know the reason why I could put wildcards in both columns. In that case, if the allow list has an auto flag, and there is a match in the allow in the allow list, then the operation is completed otherwise it would fall back on to the previous state sort of like hierarchically which is manual, and it would just like sit there and wait for somebody to to act on it. We could change the default behavior to be to deny it. That's something we can discuss based on or we could make it configurable but that's kind of like how the workflow would go through. I see Warren has his hand up.  You don't necessarily want to be updating the endorser's lists to allow those those functions so this is creating an overhead for that kind of deployment if I understand this correctly. I mean, there would be a small overhead, because the list would have to be maintained, but again you could use wildcards for most of the well most the schemas and credential definition, the permission matrix would be set explicitly to sort of like there's a record that the agency or an endorsement company accepted to endorse transactions for that specific did and I believe that could also be automated I'll just give a big step forward tiny bit to explain that the idea, at least initially to make things simple and also tied into what we as we see gov think we might be using is to have these tables in the endorser service match one to one CSV files that can be maintained by the business user, rather than having a developer having to go in and and changing the database or having a specific UI, the CSV files can be stored somewhere in our case, it might be a get a repository as an example, and maintained via pull request that provides the benefit of being able to run this on the state at different moments in time and see the diffs when you when a request for update is being submitted, and then the endorser would just expose some API endpoints to load those files or it's going to take a week, and the load process would be a fairly simple, whatever you're giving me is the snapshot of what I'm going to be using there's not going to be update or merging of of records is going to be, I don't know I just pushing the credential definition law list. This is the new one everything that is there will be replaced and because it would be iterative that should not be a big problem in Yeah, two things I think warrants question answered actually by ready to talk to your screen what connections are allowed so connection is allowed from your multi tenant occupies, you could then say, the global auto endorse so only connections from here would be created but you auto endorse everything else I think that covers your case. You still might want the overhead of adding an addition just in case, you know, in a zero trust idea, you might want to use a little bit more but but that's a possibility. I cover it. I, and then back to, to my point after your description I still think the extra overhead of having the allow lists beyond the permission matrix is unnecessary if we add a fourth option of auto actually meaning auto everything for a given did versus directly allow list for a given did. So I think it would be worth having a fourth but I'm, you know, not a hill to die on but just that would be my thought is it's worth that fourth option. Just looking at the chapter meantime because I noticed there's a couple messages. I mentioned that while you're doing that that that is the model we're thinking of doing that Emiliano handed out which is that, since it's largely business users that are going to approve these will probably do something like use pull requests as the actual mechanism for use in GitHub, and then the pull request will in turn generate these allow lists, they'll be loaded into the endorser service and that's how they'll be maintained is more that way. And then my assumption would be we mostly use, you know, have rejection on the other side but but it's possible the other way that they just hang there. If I just don't know what would happen if they're not in the allow list. If they actually hang, hang there, or do we send back a rejection if they're not in the allow list and then assume that they'll retry after some time but but our something like GitHub is the actual human approval part, and this will be this service will all be just an automated process. These tied into the question in the chat from Colton about the manual step, like, basically his question like, if we have these automatic configuration, why do we need manual. And I think the series of one is just to provide flexibility, you may want to go a certain level of configuration and then just like keep track of who you're endorsing for and do everything manually or with another process that is not resulting into the endorser. The other one could be the series just described Steven where somebody from just going back to the multi tenant agency, multi tenant agency. It's allowed to connect connects with the endorser and submit an endorsement request before the permission matrix and the allow list and credential definition allow list are updated these could happen since the tenant might be generated and you may not know the did ahead of time, what would happen here is like, you might have the transactions just sit there in and wait for manual approval with the API, approve those manually and then update the permission matrix and allow list to match what you just did, you know, in order to like, not have them have to retry that could be an option. Oh, I must have then misinterpreted the question sorry Colton. But yeah the overall idea is to get something that is like flexible enough to cater to most not all use cases with some degree of configuration. What are these is right or not I think this is to be debated and decided. Another question I had. Is it. Do we think it's necessary that in addition to my schema and version that the endorser service actually check that the attributes in the list are the same as what was approved. So my thought there was, we could add to the schema allow list and extra field that says here's a, here's a CSV list of the attributes and then that the endorser service could actually check that the the writer is adhering not only to the name and version but also the actual attributes. Again, that might be going too far but we could always leave it as an open option in the future. Yeah, I honestly had not thought about that. It could be something that we could potentially add as a new column and have wildcards. I'm wondering how complicated it might become. If I'm, if I'm not wrong, I've heard some something about schemas becoming a little more descriptive than they are right now than just a list of attributes and at that point. If we're just like shooting ourselves in the in the foot by adding too much granularity but I need to think about it a little bit. That's a good point. And then the other point I was going to mention about the you get hub is one of the other reasons for using get hub as well as it being relatively easy for anyone to use for for this type of approval process, but we could also use it to generate a static human consumable human friendly website that says here are all the schemas that exist in our ecosystem and here are all the and the credentials they issue that exist in our ecosystem so that we not only provide fodder for the allow lists but we also put out a human thing that says oh the person potential is this, you know, is has a human description to it and so on. One thing that is missing from this list. And I was forgetting there's a longer thread down here you guys can go in and check out separately is whether we want to get the granular control down to the revocation registry and revocation registry entry as well. Or do you want to set it explicitly what what's going to happen. I personally had don't have previous 100 what 100 and clear on what should be allowed or not allowed or which do but just mentioning that there's that possible that that level granularity as well that is being discussed. That's the link to the schema for verification. Yeah, this is talking to the, what Stephen was talking about but adding the attributes and stuff like that. I just wanted to mention to the group. One of the things that I was thinking about as far as the allow lists and permission matrix goes is that it should be completely explicit as to what's going on rather than leaving things implicitly working on on something so in the comments. I'm really a proponent of, of having the reg red, red, red, red def and entries being included in the allow list in the permissions matrix as far as how those are to be processed as well. It's simply because if they're not there and you don't explicitly define what they are then what ends up happening in the endorser services you end up coding, hard coding business logic around how to deal with those two objects based on what you're doing with either the schema or the more specifically the credential definition associated to those to those objects. So that whatever you code is going to be one interpretation of what should actually be happening with those objects where, and that's not going to work for all situations. If it's actually explicitly defined in the permissions matrix then you can let whoever is implementing this decide how they want to deal with those objects. It's down all the way to the credential definition list or right because each credential definition is going to have their own revered right but not that that you can imply safely, because, because of there is that one to one between the red forever and the red, the red and the revered entries and you're going to have, you know, it's, it's a one to many for the deaths and the entries but that that you can, you know, imply not imply but you know figure out. What I meant is like, you know, in a situation like this one where the say that the same did with two credit deaths. This is not the case but whatever. The same did with two credits if we only have flags at the top here at the top level of the permission matrix then I wouldn't whether this is desirable or not. I don't know, but like we wouldn't be able to say, Oh, for this first credit death, don't allow more revocation registry entries to be published but still allow it for the second one. That's what I was going with. Yeah, okay, I get where you're going with that. We're getting to the point where we seem to be wanting to like do a very like point to point granular control and at that point we would need it at this level.  And the only way you can really do that is to, you know, stop them from creating red red definitions, you know, additional revered definitions. I see Colton Colton's comments in the chat. Yeah, the wild card could be used at this level, similar to what was envisioned above, because at that point you have the extra two columns here for the revered and revered entry. And you could just have it populated by default with wild cards. To me, there's a one to many credential definition to revered definition and one to many revered definition to entries so that if you have permission to for writing a correct F it implies you have permission to write any revered credentials associated. And if you ever wanted to cut off somebody from doing updates to, you know, adding more definitions for updating the state you just remove their allow list entry for the cred def, and that would be good enough. Just because they're, they're all linked together. And so that would give you the control that you're looking for Wade but Yeah, and that's that's I think that's where we also differ on, you know, a little bit on an opinion with that, like, I think once something's in the allow list. I don't think it should be removed to indicate that it's no longer allowed. And that causes operational confusion later on because you end up going okay well, you know, this person is, you know, this, this credential definition is not in this list yet it's on the red, you know, on the on the ledger and there's been an issue against it. And then you have to go back in the history of the, you know, of the allow list to figure out okay yeah, we did, you know, we were endorsing this at one point in time and it disappeared at this other time, where if it's explicitly denied from the permissions and left in the allow list, it, it is very clear from at a glance that, you know, we no longer endorse this, you know, this credential definition. And then the only thing you need to do is go back in the history and go okay well when did we make that decision. I think that's getting pretty subtle. Yeah, one thing to say is like if we add the extra controls at this level, either pattern would work because you could leave leave the record and kind of change the permissions or deleted completely and the results should be the same. But either way you have to change the record. You have to change something. Yes. Yeah, something needs to change for sure. All right. Well, that was all I'll stop hearing a lot. Definitely. So we're going to start implementing something along this at some point, and so we'll finalize what what we plan to implement welcome input from anyone based on these questions obviously we're, we're still debating it. I'm hoping to have that and and if any others want to use this. Let us know what your thoughts are and how you would like to see it done because we'll see if we can build that in. And with that we ran out of time so there won't be any other topics and Sam will be back next week so it'll all be better. Thanks all. Thanks everyone.