 All right, welcome to the July 10th and on CREDS B2 working group meeting. A couple of topics for today made one being revocation requirements and trying to get to a formal definition that can be put in a paper of what the revocation requirements are so this is a chance to talk through those and then this to lead to a formal document that we produce that outlines the requirements of revocation. Since it seems to be the trickiest part of all that we're doing. I hear that this specification is under the community specification license so if you're going to work on it, make sure you're aware of the requirements of that it's kind of like the Apache for not for open source but rather for open specifications. This is a Linux foundation hyper ledger foundation new meeting so the Linux foundation trust policy is in effect, as is the hyper ledger code of conduct. I'll share in the chat the link to the whoops that's not it. That's not it at all. And hopefully you. Hey, I can delete a message. Whoa, cool. Anyway, this document is here I want to shift into edit mode for it, but if anyone wants to add their name to the attendees please do so. And help with the note taking that would be great. Anyone is new to the community and wants to introduce themselves and what their interest in this is that would be good to have done now so grab the microphone. My name is Ashley. I'm new to the group. Just trying to get my feet wet a little bit and get my, get my understanding oriented towards what what what you're doing with an on credit so just kind of interested in listening in today and seeing what it's all about and hopefully we'll be able to contribute down the road. Awesome. Welcome Ashley good to see you. Hope you are well. All right. I want to get into a presentation discussion on what we need for revocation that's the big topic for the day. So let me share a presentation that I've got share. Copy the link. I'll put that also into the chat. So this is the presentation I'm using. As I say looking for feedback on this. Whoops, what we're trying to get to is an academic paper or style that outlines the, the revocation requirements in a formal way. So I'm using a bit of pushback from the academic community and in looking at some of the revocation methods that we are talking about. And part of that is they just don't feel like we've got enough in the formal definition stage so that's what the goal is coming out of this. Problem statement. We need to replace the insufficiently scalable and our friends be one revocation scheme as soon as possible so that's the main thing we're trying to accomplish. So revocation being a requirement of pretty much all use cases for verifiable credentials there's some that don't need it but but most do even if, even if it's not understood at the time you get started, even if the only reason you need revocation is because you issued a credential by mistake and you need to correct that. That's the requirement for having revocation and and so almost every use case for verifiable credentials includes revocation. Expiry dates in verifiable credentials are crucial and and are recommended but are insufficient for revocation if if there's any sort of pseudo real time need for revocation it has to. be available. It has to be part of the revocation scheme and expiration isn't good enough, or generally not good enough expiration is is well we'll go from there. The dog wants in so I have to open the door. But that's okay participants so revocation options I'm going to go through a set of options but do that by going through the participants the attributes and trade offs and then look at the options we've got. So participants generally people know these issuers holders and verifiers anyone who knows anything about verifiable credentials knows those. Revocation manager is a new participant from time to time a revocation manager is someone who provides information about revocation in some form. In some of the schemes we've got their formally called revocation managers. Others, they, they just hold and provide the data necessary. Data sources are include revocation manager so where you get revocation manager issuers published revocation data holders retreat generally holders retrieve that information and generate a proof verifiers also generally retrieve revocation information and they verify the proof in the holder so that's the common model there's a couple of variations that we're going to see. So it's not always that. But that revocation data source, where the information that gets published by the issuer appears can be in a couple of places. So verifiable data registry eg ledgers or, you know, places where it did to reside. Ideally, it would be passive meaning that the verifiable data registry itself does not dynamically need to generate revocation data. It is just static data that it serves out. So just like a did doc is a static document that is returned when a did is resolved it would be nice if revocation data were static data and could be returned as as is from a registry and the reason for that is it reduces the capability necessary for the registry. So for example is hyper ledger Indy which dynamically generates requested data so Indy knows about an on Cres revocation register they're not just some static data that gets published on an indie ledger but rather Indy knows about them and accept specialized requests to return. For returning the deltas being the change statuses of various credentials so instead of getting the entire state from Indy. You get a list of the credentials whose status has changed since you previously asked for it whether that's from the beginning of time or from some point in time where you previously asked. That's a potential privacy issue. Yep. Exactly. And, and it adds an additional requirement on the ledger to say oh I need to be able to do that so in an on creds v one that we've implemented we basically taken off that as a requirement that well Indy can do that. Other other ledgers can simply return the full state of all credentials and not asked for a point in time or anything so when they get the state of, you know, a given state of the of the credential status they get all of them. So that's a way to turn it into being passive. Revocation managers are proposed for some schemes basically they are an active server that responds to a request from from perhaps an issuer to get revocation information. The response is dependent on the type of scheme so one example is basically called linked verifiable not remembering LVVM that we're going to talk about through this. Basically, the issuer asks a revocation manager, give me a proof of non revocation of my credential as of now. The revocation manager simply issues a verifiable credential and a non credits verifiable credential that is in the same format as the primary credential. But the purpose of that verifiable credential is to prove non revocation. And so that's one method of doing of a revocation manager operating. And there's other ones as well Alasor in its implementation has revocation managers as well. Generally revocation managers share are provided information from the issuer, and then they share that information. And again, last one file servers is really the same as verifiable data registry. If it's a file server than it truly must be passive so it provides only static files not server generated responses. So, where a revocation manager responds to a specific request. A file server is simply providing a state object essentially a static static file that was issued to it, perhaps likely from the issuer. So those are the participants in the process so the basics. A revocation state of all credentials is public published periodically by the issuer. So the issuer keeps track of every credential that issues. When it wants to revoke a credential or a bachelor credential it publishes a state update where it shares either. Either the deltas of what it's changed recently since its last update or it simply shares the entire state of all the credentials, and that gets published periodically to whatever is the appropriate place for the given scheme that's being used. When presenting a proof derived from revocable credential the holder provides proof that their credential is not revoked based on a specific revocation state. So, the issuer has published a bunch of revocation states, the holder gets one of those, and if their credential is not revoked they are able to produce a proof that their credential is not revoked. So I guarantee we're looking for the, the, what we're interested in is that the holder cannot provide a non revocation proof, based on a published revocation state in which the holders credential is marked revoked. It would be nice to have so that's that's the, what we're aiming for it would be nice to have that a holder can create a non revocation proof for a given time in the past so the use case is. So a car accident occurred on in 2020 and the holder could produce a non revocation proof that at the time of the crash back in 2020 their credential had not been revoked, even if it had been revoked later. So that's a nice to have proof. A credential is not revoked must be linked to the credential to which it applies so a given proof of non revocation for a primary credential cannot be used. It can only be used for the credential to which it applies so there must be a linkage between the proof of non revocation and the credential about which it is talking. And finally there must be an unlimited number of credentials for credential type so there must be no set limit on how many credentials can be issued. And if a revocation registry size so if you do have a limitation on the size of a registry a revocation registry, there must be a way to have multiple registry so you can just create a new one and continue to issue the same type of credential. That had been that you've been issuing just using a different revocation registry. Jump in anytime if I'm not being clear as I say I'm trying to get this to be a lead to a formal document that outlines all of these things so help in making sure I'm getting that down would be useful. It's in a in a zero knowledge proof based system unlinkable identifier so no linkable identifier is given to the verifier. The goal is to prevent correlation across verifiers and between verifiers and the issuer so when a when proof of a revocation is given to a verifier you given to multiple verifiers, you don't want to wait for those verifiers to. Compare a unique identifier across each of those so they can correlate or or with the issuer so they can report to the issuer when a credential gets used. There generally are two IDs that are involved. So one is the revocation registry ID itself so where the revocation is tracked, and it is okay to share that or it should be okay to share that now get to that next. The second is the actual revocation ID. And this is a loose term because generally it's a, it's a concatenated key if you will generally it's the revocation registry ID and the index within that registry of the particular credential. For a particular credential, it is not okay to share this revocation ID that would be a unique identifier for the credential itself. It is okay to share the revocation registry ID and often necessary so that the verifier can verify the can verify the proof provided. The revocation ID itself is commonly shared between the issuer and the holder, it is not shared with the verifier so that's the limitation there. The registry size must be large enough to hide in the crowd. Hey, Stephen, what about a revocation registry public key? Can that be, I mean, obviously not every revocation registry needs it, but can it be optional? Yeah. Okay, that's helpful. Thank you. Yeah. No doubt on that. Because some accumulators use them some accumulators don't but you might like let's say you're on a file server, you might have the public key use to verify a signature overhead revocation set. Yeah, I guess we could say public parameters that are unique to the registry. Yeah, yeah. So like maybe instead of revocation, well revocation ID is fine. Registry ID is fine. I'm just talking about like, yeah, public parameters for that revocation registry. Yeah. Thank you. Okay. The registry size must be large enough to hide in the crowd. So the idea here is, suppose I have two credentials that are revocable. I share them, I present them together. And in doing that I provide a revocation registry ID for each of them. Basically, registration, the rev regs themselves are so small. Basically that the chances of somebody being in those particular two revocation registries is as unlikely and hence you get what amounts to a linkable identifier so this is the current problem we have in on with an on credits one. You inadvertently wind up sharing a unique credential because of sharing multiple revocable credentials together. And so the suggestion that I've heard of. What I just made it up was at least a million credentials needed within a revocation registry to prevent this this to prevent this kind of linkability. And obviously, if there's only, if it's a single credential with a registry a population smaller than the revocation registry that's fine there would only be one revocation registry for that entire credential. This one is probably the loosest requirement I'm not quite sure how to say it any better than that so. Hopefully that's clear. This is the one that I didn't realize for quite a long time was this, this issue. Once the verifier has received a proof of non revocation the verifier must not be able to see changes to the revocation status of that credential. This is a complaint that I see or and I certainly make with the revocation list 2021, which is a non ZKP to begin with but basically once a holder shares their identifier for their credential to the verifier the verifier can go to monitoring the revocation status and see if in the future the credential gets gets revoked which is could be a feature in in some people's view but I see it as a consent issue that you're actually not giving you don't want to give the verifier ongoing ability to track your revocation status. Linkability can also be looked at from a calling home perspective. So nice to have and perhaps required in some cases is to avoid calling home during presentation so calling home is where the issuer or sorry the holder or the verifier, or both have to call back to the user for example the issuer to be able to retrieve the information necessary to do a presentation. And the issue there is basically web logs can be used to track holders and verifiers and track what they're doing and the correlation between them. Nice to have, and in some cases required avoid the user being able to track when a holder is doing a presentation, avoid a user being able to track both the holder and the verifier during presentation and the problem there is a holder gets revocation data from the issuer to create a presentation and then immediately afterwards the verifier calls the issuer to verify that presentation. And now the issuer can correlate that the holder use their credential and the verifier with which with whom they used it. And that's, that's what we want to avoid. Even the perception of calling home is a problem for government so for example if I, every time I used my person credential to prove my age. There was a web call made to a gov.bc.ca, you know, domain, a government of British Columbia domain, even if there wasn't data being tracked, this perception of calling home is problematic. And that could just be the rejection of the use of the mechanism. Basically a viral. We won't use this because it's it's government tracking. Call home assessments must be considered based on the likelihood of collusion so the revocation manager idea can be considered a call home, even if the issuer and the revocation managers are different parties. So that is something that needs to be looked at as well. For example, in, in Canada, where the revocation information is going on in indie ledger that ledger is actually operated by a different government entity but it's still government entities, or sorry, entities. So there is a call being made which may offend holders and may develop mistrust in the system because even though it's going to a ledger which is in theory a neutral party. So that's the possibility of tracking now again it's all a, a range of of gray in this. So it's not always clear exactly where this problem needs to be prevented I mean you've got to get the data from somewhere. But there's better. Some places are better than others is the idea. And I'll do an aside on this that an idea came up recently where the verifier provides revocation data to the holder so the verifier is the one that reaches out to wherever the data is is cat. And then the verifier provides that revocation data to the holder. That's an interesting idea that I've been exploring a bit to try to eliminate this call home from the holder. It does require in some cases and extra back and forth between the verifier and the holder but it does mean that the holder is only interacting with the verifier and that's it. I've been looking at a paper from Andreas fry tag, based on a diff survey he did that talks about issuer holder privacy and issuer verifier privacy so this is the issuer holder. So this formalizes a little bit the issuer gets no information about the usage of the VC and the verifier and or the verifier involved. Semi private the issuer gets information that the VC is used from the holder. Or gets information that a verifier is performing a validation process. So one or the other, and the, and then the no privacy is where the issuer knows the VC the holder and the verifier used in the validation process. So obviously the higher we are on this scale the better. So this is likewise from the same paper holder verifier privacy so full privacy, semi privacy and no privacy. You can see those definitions so those might be useful in the paper we use. We're creating. So we can use those descriptions. So just looking at the last slide of course there's always a risk. Because the verifier knows who the issuer is. They can. They can tell the issuer that a verification is happening. They might not be able to tell them who the holder is exactly. Although most of the time they will have one or more attributes to write back. Not based on the fact that presentation was given, but based on what was presented in the credential. Yeah. Yeah. I think you can always do that. I'm going to be careful not miscommunicating that you can always of course, if you know the issuer, which you're going to have to report back, but it's it's important that to achieve the verification required that you're not systematically required to. Yep. Yep. Competing capability so basically. Assumptions that that I've seen lately assume issuer and revocation managers are enterprise apps so they have pretty powerful systems, lots of storage. You know an issuer must track all the issuances unilaterally revokes them and publishes revocation is necessary either as the revocations happen or in batches. Our assumption has always been pretty much that the holder is a mobile wallet. In the worst case. You should not have to download substantial files during a presentation presentation time generation time should be short and I've actually got numbers on the next screen about that based on Andreas's work. And then this is a bit of a new one. Usually we think of verifiers as enterprise apps as well. But we're actually doing a fair amount in verifiers being mobile apps. Where, you know, a mobile verifier could, could, you know, display a QR code scan it by the holder mobile app and the two of them just trade a presentation and the verifier would have to be able to do it so again, if we if we go with the lowest common provider this is a reasonable requirement should not have to download substantial files verifier time should be short. This is the from a paper that Andreas did again based on the Diff survey. This is what the survey participants said they sort of you know, the verifiers and verifiers in this case as enterprise folders as wallets. They've got a tighter bound on the size of the data that the holder should have to, you know, retrieve and use on their device. And then in the initial time, nobody really cares about the issuer. They can throw more metal at it so that's okay. We want it to be within a second. For the most of the respondents to the survey and a tenth of a second for verifiers so they want them to be very fast. So those are higher numbers. So if it's with the call home, I should probably get rid of this slide. This is really to do with calling home that the holders and verifiers collect the data from different sources. They do it from other than the issuer because of a call home issue and perceptively independent so really is the same issue. There's one extra one, which this requirement stands from the idea that when issuing a credential that you may want to sign the credential with an on creds signature, but you also might want to sign it with a nest signature. In that case, if you also want to support revocation, it would be nice not to have two different revocation schemes having to be kept in sync. So, if a relatively simple bid array techniques similar to status list 2021 was available, it could be used for the nests. It could be used for the on creds purpose, but also used for an on creds purpose so that's, you know, another reason, a nice, a nice to have alignment. That is looking like a possibility down the line of having a credential signed with two different signatures and then, and for them to be used by the two different. Signatures to be used by verifiers, depending on their needs so that is a possibility coming down. These are the. This gets into finally the four schemes that we've looked at you know on creds 1.0 Alasaur, LVBC, which is the one that Andreas produced, and then finally ZK Sam, the signed accumulator membership. So papers are linked to all of these. As I said this, this presentation is more about less about the solution more about the different how to how to formalize what the requirements are, but this sort of shows where the on creds basically falls apart, can't be used. A benefit from ZK Sam. Having a bit array type data scheme. The size of the file being much, much larger but still not massive in the ZK Sam but much larger than the other schemes. The call home or perception of call home is in both of the Alasaur and LVVM approaches. So yellows. Well, maybe have a clarification like Alasaur doesn't necessarily need to call home every time you present. Yes. And when it calls home it's anonymous. Yeah. And that's why I've got in here revocation managers. They are dynamic. The revocation manager is a dynamic service that must be available right. Yes, that's. So that's the summary. Anything I've missed there. And Mike, in particular, do you see anything that would contribute to a paper. So what I'm thinking of doing. If I go back here. Andreas has a section that that basically uses the survey as the, what are the scheme so I'm sort of taking some of that from his but less survey based. And talking about the things that are in my in that presentation as the way to present here are requirements seem reasonable. Yeah, I think for the most part. Maybe I don't know how to add this. If it does call home, is there a way to say it's required to be anonymous. Yes. Yeah. So the other requirements and I don't know where to put this either and maybe you already covered it is the. The inability of folks to like the issuers or revocation manager to determine when was the last time they updated like if they have to call home. Then they can't determine whether they last called home like a year ago or just a month ago or yesterday. Because that was one of the requirements we had an Alasaur was to was to solve that. Yeah, I wanted to check to the Alasaur update protocol does that mean that the revocation manager doesn't know what index they're updating. That's right. They do not. Okay. And even if they how did they not know. How did they not know the last time updated. I thought they basically that was what you did you call back and said the last time I updated was now when the update me. The holder knows the holder knows but the revocation manager doesn't. That was the whole idea behind Alasaur was to fix that problem. Because, because one of the methods of tracking is that like you said earlier, when was the last time they updated or last time they phoned home, like, so Alasaur mitigates all of that. What does it do that. What do you what do you request when you call when you call to the revocation manager and Alasaur. In a nutshell, a little more complicated than this but in a nutshell basically I split my share, or my revocation ID into multiple secret shares, as many as I want say like, first time I could do five or 10 next time I could do seven of 20 it doesn't matter. And I contact vacation manager that many times that maybe it's all at the same time maybe it's different times it doesn't matter. And then I can I alone can obviously re aggregate those, but they're all anonymous so the revocation manager can't determine whether one request is the same user or a different user because they're all the same. I'm also resistant to like, let's say even if an attacker tries to request for something. Let's say he doesn't know my revocation ID, or maybe he does. He's going to he requests an update for it. Unless he had a valid witness at any point in time unless he unless he has one that response back is completely useless. And that is like a that when this is a signature. He never had the signature to begin with, but then his result is useless. So even if the bad guy asks for data, his result is useless. But, so the holder still says, Oh, I last updated on June 20. Yeah, well the holder, the holder, the holder will know that right the holder has to know when they last updated. Actually, they don't even care. They only care do I have a valid witness for what the, can I present a proof that's valid for what the verifier wants. Okay. I'm saying just the holder specifically passed to the revocation manager June 20 because that was the last time they updated or they just say, No, they just say I need I need a version for this one. That's it. So they could they could say like, yeah, let's say each revocation ministry was tagged by a date. He could say yeah I need one that's valid as of June, July 20 or something like that. He could. Oh, but the cryptography doesn't matter the cryptography that the pro as as Nathan George always says the protocol does not betray you. That's the metadata that would. Yeah, yes. So if the revocation manager was just saying, here's my versions of the accumulator. And if someone said I just want the latest, then they don't know when they last updated. Or actually they don't even know when they last update they just know which one they're which version they're requesting. That's it. They learn nothing else. And then, and the way you do that is you split the key. If you don't split the key, do they know who you are. Well, that's it. Yeah, that's equivalent to spending the full thing. So yeah, they would see it. Well, actually it's a commitment so they really wouldn't you could say hey this is one of one. But the protocol would still hide it. My gosh, Oliver, what do you need. Okay. Sorry, my kids are asking me lots of questions. Any other questions or comments. Also, do we like, do you want to add like a section on calling home private, because I don't think calling home is entirely bad. In every case. Yes. And that's why I lost you there. I was just saying the perception could be that it's bad but I don't know like calling home isn't always bad but it could be a yellow flag if it's done wrong. It's a red flag if it's definitely done wrong. Exactly. Yeah. Yep. One of the ways evidently Jen digital did the link to validity verifiable credentials what they do is they provide a list of essentially revocation managers, and you can call it to any of them, and you basically pass an ID to them and then you get back to the non revocation that's linked to the credential you've got so it's got to use the same. It's got to be linked somehow to the to the credential but you could use different managers and the verifier has to know which are the trusted managers to get that that from. So, they've got a technique to do that. But that would be considered in the calling home. How, how safe is it how good is it. And is it every time or is it just once per any time the registry changes. Um, that would be important to call out because if it's like every time or just once, because like Alistair for example, the only time you have to call home is anytime the registry changes. Otherwise you never call home. Yeah, I would think it would depend on the verifier because the verifier doesn't know how often it change well. Yeah, the verifier wouldn't even know in that in that because there's no accumulator anything for it to collect it just got to know it just got to know if the if the if the credential is valid or not. They wouldn't know when it changes so they would do it more like they based on how recent it was how recently did you you get a a get a non revocation credential. Okay. The other topic I wanted to go through so we'll leave it for there I'm going to try to get that right up done. The other topic I wanted to do Mike was in in schema claim type. You've, you've listed a series of claim types I wonder if I wondered in doing that, whether the way that a piece of data is encoded is a useful claim type and in particular around dates. Do you have an ISO 860 date type or an ISO 860 date time type. The encoding of that could be into the integer date form or the Unix time form. That would be helpful. Do you see that as a useful. Is that what you were thinking schema claim types to be used for do you think that was useful. Mostly yeah so like when I said there's a number type you can obviously be more specific. Right. And you can create subsets so yeah obviously date date times day since 1900. I mean there's all sorts of different times or numbers that you can represent with that. Sure. Yes. So it would make sense to put it in the spec that since we're going to have claim types anyway, having these two would be particularly useful so that the data could be provided and I 60 but be useful for ZKPs for for predicates. That's right and then whether you want to support negative numbers or not. Right. Yeah. That's, that's built into what you've already got because you've got that zero centering. Correct, but if you don't need zero centering and like some things don't make sense like when did this happen. You know, within this century, for example. Yeah. Okay, well that was quick and easy. All right, I want to get that into that use. All right. So those are the topics I had for now as I say the next chunk of work I think for the, the two oh is to and and in our present general is to get a more formal definition of what the revocation requirements are suitable for photographers to use in evaluating schemes. And to try to get those schemes. Some evaluation done on those schemes to try to get contributions from some cryptographers on the various places on the various schemes where we want to use where needed. So I had any other comments questions. Discussion points. I wanted to maybe add to non creds to is what just as we're doing with revocation requirements, credential signature requirements, missed or not snark allowed or not, you know, basically, can you say the signature is missed approved, but the ZKP is not approved is mostly KPs. I don't know of any exception or that are missed approved. I think the path that we're most likely going down is that in addition to an an on credit signature you can put a nest signature on it but you lose all of the capabilities. A proof can still be be created about the about the credential but the an on credits capabilities go away essentially. All right. So that's it for today's meeting. Thanks all for attending. We'll be back in a couple of weeks with some new topics go over and hopefully some new get to some documents. Sounds good. Thanks. Thanks.