 Alright, welcome to the June 19 2023 and on credit specification working group meeting. Few things to talk about unfortunately a new zoom link it's causing lots of fun today that not people are unable to find the room unfortunately have the wrong link so that's not good. Report on the non cred 010 release. A little bit on the workshop we had. Mentorship program. We're delighted to have started and making great progress already. I don't have the to do this so I think I'm going to knock that off the list. As much as in a form that I'd like to have it in so I think I'll knock that off the off the list. The chat link into the agenda in case anyone wants to update I'm going to edit. Turn on editing so I can update as we go so we're not going to get to that this week. The big thing I want to talk about was a couple of things on revocation approaches and go over possibilities there there's a few things happening that I wanted to share. We are recording this a reminder this is a Linux foundation hyper ledger foundation meeting so Linux foundation anti trust policy is in effect. And as well the code of conduct. For welcome. Are you sure it's here. I think you can see her last time as well but really like to welcome him he is the hyper ledger mentor for them from the mentorship program and so he's joining us is beginning work on the non cred specification implementation so basically they are coming up with and completing the work on the cryptography in an on credits and aligning it with the implementation and he already has done some great work this week it was good to see him following working with Mike lotter. We're working together really nicely on on coming up with how the tails file is generated in the revocation process so very cool we'll see a full request, relatively soon so definitely huge welcome. Thanks for joining us. Okay. So, from, as I mentioned, in the non credits announcements that zero one zero rust implementation was officially released so we have that. It is still using the Ursa crate but will soon transition that over to use the CL signatures crate, the on credit CL signatures crate so that's good. It's starting to be used I believe it is in the zero four zero arrow frameworks areas frameworks JavaScript code. So that's good to see. Good to have that out there. That allows us to keep moving forward with making that the official or the use release. There is work going on in Acropy to get it used there it's not complete yet. But we are working on it so hopefully that will be available very soon. And we can transition away from the, the older implementations of an on credits into this new one. And on credits v2 working group. Last week we talked about how the model supports the multiple underlying cryptographic signatures so in an on credits 2.0. There are currently four signatures that my daughter has worked with and and has has demonstrated. Signatures BLS signatures, bbs class signatures and PS signatures, the latter two are the most likely to be, you know the first, the most commonly used. And so those are might sort of show how the different models are supported and basically how we get all the features, or almost all the features bending on the signatures use from a zero to zero proof. The cryptographic primitives to be able to use to use the different signatures. Next week we'll be talking about presentation data models. So with that, anything anyone have any other topics they want to raise for this meeting in particular. Okay. So I'll go down to be an on credits workshop report. I'll just briefly cover that we did have an on credits workshop couple weeks ago really well attended. Very happy with it this is the first being since then of that so just to recap we had around 400 people express interest close to 200 show up. You know for the initial part of it and over the entire workshop wound up with about 70 left at the end, three and a half hours in which is excellent. There's a lot of interest there. We did use a tool for doing the lab labs in the course that worked out really well I'm trying to get an instance of that deployed so that anyone can continue to use that it's I believe it's still available right now, but won't be available too long. I'm trying to get a permanent instance of that running. So that can be used and people can experiment with an on credits and with other things and verify the credentials community they can basically really easily create their own experiment with their own schemas and and generate them so that's kind of cool. One of the things that I mentioned that are on the list to do or is it to do list I actually have a to do list written in in pretty rough form but more or less it's written on my iPad. So not really in a form for sharing. And then one of the things that I reach for a mic and I are working on is sort of coming up with a way to in the specification how to balance out, you know, making me spec understandable of how the process works and putting in the precision of the cryptographic details for the staff and so we're going to take a look at a couple of examples. How bbs plus has submitted to it and Mike also has access to how the yes signatures are submitting theirs to it and we'll take a look at those for how, how to best balance those two. So I'm sort of competing goals, making the step understandable and useful and to, to everyone and providing the detailed cryptography necessary to implement it. With that I wanted to talk about revocation today so let me take a moment to move this so I can get access to my command line. I guess I could do it this way. And so it's all good. I wanted to take a look at sort of where we are with revocation options and share that so jump in any time if anyone has questions I can see hands raised or chat so feel free to let me know if I'm. People are interested in jumping in. So, we need to replace the insufficiently scalable in our credits be one, as soon as possible. Revocation is a requirement of almost all use cases and that's true, but they realize that they're not I mean there's a lot that aren't using it right off but almost certainly they, they, they would use it if they could. We definitely want to use expiry dates in verify the credentials. Those are crucial but not sufficient. So we want, we must be able to support revocation as well and every provincial scheme needs to be able to. I'm going to talk about the options in terms of the participants, the attributes and trade offs, and then the options themselves what are the, the, I think we're up to five different ways of doing it right now. The participants obviously issuers holders and verifiers we know about those issuers issue and revoke unilaterally revoke they want to be able to, you know whether they notify the holder or not they want to be able to revoke the credential. The holder wants to be able to prove that they are, they have a credential that has not been revoked. And then the verifiers want to verify that when they get a credential from a holder that it has not been been revoked. What we found recently is based on the various choices or options available for revocation we've got sort of three resources of data. The verifiable data registry is one, and that's what obviously is is commonly used ledgers. That's what Indy uses for an autographs which is the source of the revocation data whether it's the source of data for the holder for the verifier for both is the ledger itself. That's, that's one way to do it. We also have come out now with what are called revocation managers, the revocation manager might be simply the issuer but also might be someone somewhat independent of the issuers they have to work with the issuer. But they can be independent of the issuer so the revocation manager is a term, we will start to see now and some of these themes. Basically they interact with the issuer to get revocation information and then they respond to request from holders and or verifiers for revocation status information. So, they. The idea here is, is that, although the scheme is a call back to the issuer by the holder to get some information necessary to prove that their credential has not been revoked. It would be nice if they were separated from the issuer. So you were calling home to the issuer so revocation manager is a way to do that. The revocation manager could indeed be the issuer. And they respond to request from the holders for that information. But, but they, you know, in addition to be the issuer they could be independent and simply the issuer publishes information to them, and the revocation manager respond uses that information to respond to holders. The last is sort of a combination of the two as well as is a file server which is a revocation manager or even a VDR a verifiable data registry where the revocation manager is passive in other words, the file server provides static files, not a server generated response. So a revocation manager is, is, you know, kind of by definition an active component, it gets a request, it does some sort of calculation it returns the result. A file server in the way I'm using it here is, is a revocation manager where all it does is pass back a file. But it somehow has a static file, usually received from the issuer, and it passes it back a verifiable data registry. Interestingly, a verifiable data registry could absolutely be that passive file server in Indy. It's kind of interesting in that it's a combination of those two because Indy, actually, the, the ledger does a calculation that passes back a result. So in Indy, the status, the static data that is passed from the issuer and put onto the Indy ledger is deltas of what credentials have been revoked or unrevolved. And then all of those get collected by the BDR by Indy, and then on request Indy sends back a, a calculation that is all of the deltas collected from the time the holder has requested it to the current time, or at least for a time range. So this is somewhat different. This is not, this is different than a generic file server. On the other hand, in the BDR approach used by checks, for example, they actually in that implementation. In the BDR, the checked ledger is operating as a file server. It is getting the full state of all of the credentials within it, and it's passing back a result to the holder that is simply the state that was given by the issuer. So it's, it's much more passive. It doesn't have to do a calculation. And that's a, in my mind, that's a better quality, a better attribute in that the, the ledger in this case doesn't have to know anything special about revocation or do any special operation. It just treats the data as this is what the issuer put onto the ledger and here's what I'm giving back to you from the ledger. And hopefully those participants make sense that the three kind of blur together but but there's definitely distinct differences between them. Okay. So, here are sort of the characteristics the attributes of the schemes and the trade offs amongst them. A hard requirement for all of them just, it doesn't make the list unless it is one that no linkable identifier is given to the verifier. That is somewhat undercut or can be undercut if the scale is such that the identifier is not large enough so this third one. If the revocation registry size is not large enough to hide in the crowd, then a linkable identifier can be derived from multiple credentials that are in different registries. So, although, for example, the, the current and non spreads does not provide a linkable identifier. It doesn't sort of pass muster because the size of the revocation registers is small enough that given say two credentials, the likelihood of to two credentials that have a large population, chances are, that will produce a linkable identifier that combination of registry revocation registry identifiers will be will be unique enough that you pretty well get a linkable identifier. So, hard requirement there, register of revocation registry size must be large enough. There will be a revocation registry ID to find the information. And usually a revocation ID is the revocation registry ID plus the index within that revocation registry so that that is the information. The revocation ID, whether it's named or not in a particular scheme, essentially exists. And that is how a, the, the holder specific credential is identified, so that you can tell whether it's been revoked or not. And ideally that is shared between the issuer and the holder only. So, the. That's basically just a characteristic that there's a revocation register ID. That's usually very latent and specific it's revered ID exists somewhere, but there is also the index of the credential and the combination of the two is the revocation ID. And then we don't want to share with the verifier that would be a unique linkable identifier so that's the thing we're not sharing. Another hard requirement is that there essentially be some mechanism that allow an effectively unlimited number of credentials for provincial type. So, if the revocation registry size is limited, there must be some way to have multiple registries for a provincial type. So, this is supported in an on pres obviously with, you know, even though that, say, 10,000 is the max you can have for a, for a, a, a revocation registry each specific one, a credential type can have many of them. And so you get effectively unlimited. Lots of things to manage and stuff like that but you get effectively unlimited number of registries, unlimited number of credentials per credential type. I talked about call home earlier. Call home is a thing that would be really nice to avoid. So, this is the idea that the issuer of the credential can track what the, the holder is doing with their credential, if they can correlate that the, the holder has to do something. It has to interact with the issuer every time they go to use it, or. And worse, if the holder has to call back to the issuer to get a piece of data to create a register of presentation and then immediately the verifier has to go get a piece of information to verify it. And that actually could enable the issuer to, to use the metadata basically to track. Oh, this holder created a presentation and this verifier verified one right in the same period of time so probably that holder is interacting with that verifier and again that's allowing the issuer to collect more information. So, basically, we want to, it would be nice if we could avoid calling home during presentation entirely, or at least enough that we can avoid, can minimize either the actual or perception of tracking of the issuer. And so this is where that, that, you know, avoiding that tracking, or the perception of that tracking gets interesting when you talk about a revocation manager that is independent supposedly independent of the issuer. If they are actually colluding together the issuer and the revocation managers, and such that they're sharing, for example, Weblog information that tracking can still happen. And so the more we can get away from that the better. This is again why the ledger is a good place to do that if the ledger is independent of the issuer. And then the holder calling the ledger to get some piece of data and the verify calling the ledger to get pieces of data is far more difficult to actually get collusion going on such that tracking can be done. Very unlikely that that can happen. So that's where the ledger is, you know, kind of the ideal revocation manager. So basically column assessments must be considered must consider the likelihood of collusion. So hopefully that makes sense. This, this page goes to the amount of effort that the parties must go through. So we can assume an issuer is an enterprise app, or has sufficient power to track all all issuances that's just to give an if an issuer wants to revoke a credential after issues it must track all the issues, issuances, the revocation ID, and whoever the holder is that that credential was issued to so that it knows if later something happens that it needs to revoke it. It has all the information necessary to do it. So we can unilaterally relax revoke credentials I mean with or without letting the holder know they've been, they've been unilaterally revoked credentials with or without contacting them. And finally, they have to be able to publish revocation as necessary immediately or in batches. So, whatever there can be a decent amount of processing necessary it can't be obviously a ridiculous amount of processing for an issuer to publish a revocation but it can be, you know, a relatively costly calculation. And that's okay, it is not. We assume that an issuer basically is not a mobile app, and therefore it's limited by its, or has it has severe limits on its processing for processing or, or data, the size of the data files that it's an enterprise app that can handle things like that. Apologize I missed the question earlier, what do we mean by perception of tracking versus tracking proper. Just to get back to that a little bit. This is a particularly sensitive issue for governments. And that is that certainly in in a number of places and this has been very true in Canada at least and I think in Europe as well. I have a great desire that the government not only not track but also not be perceived as tracking the issuers and and one of the things that can happen is that basically initiative setup to provide this type of digital trust and digital identity has been blocked or eliminated not not necessarily because the technology was bad but the perception was bad. And so, one of the things that governments are particularly sensitive to and that's why, you know, we raise this and talk about this as as one of the concerns when I put my BC go pattern is is making sure that there's not a that we're able to provide as much evidence as possible that we're not tracking and we're, you know, going out of our way to put a scheme in place so we're not tracking and so that's what I mean by perception and tracking. If, you know, for example, the government BC gov domain is gov dot BC dot CA, if all of the calls from the web from the web app to when when you present a transact when you when you present a provincial, there's always a call back to a gov dot BC dot CA domain. Well, that would be a bad thing. And that would be a perception that oh, the government was just notified that you used your web app to do a call a presentation you were sharing your, you know, you were proving your age. And in doing that you called back to gov dot BC dot CA to do that. That's not what we want. Does that make sense. We assume the holder is a wall, a wallet web app. It doesn't have to be a wallet web app but it will be a common use case and so that's kind of the lowest common denominator so should not have to download substantial files during presentation, e.g. It shouldn't be more than a make a bite of information as at the outside of how big a file should be and presentation generation time should be relatively short in along the side along the expectation of a web app so they one to three seconds including data collection. So, from the point you say oh I want to, you know, generate a proof I scan, I scan it, and I get a prompt back saying do you want to send this that presentation generation time should be pretty short in the into the one to three seconds, including data collection and how many activities going on the user interface and so on. I'm surprisingly assume the verifier is also a mobile app and again this is less likely. It will be a common use case we think in us particularly in, in, you know, personal identification that that a point of sale terminal that a kiosk iPad kiosk that actually a user scanning it will be a verifier app and so while this is not nearly as likely as the similar attribute should be taken into place so that the verifier can be a mobile app so again should not have to download substantial files verifier time should be short basically the same criteria as the holder. That's not as common, commonly seen but we're seeing that a lot more often. Why is it not a requirement to notify the holder and then the holder can ignore the notification doesn't the holder get notified when a credential is issued. So a holder definitely gets notified when a credential gets issued, but they don't necessarily get notified when a credential is revoked. And so that's what I'm talking about does that make sense. So Aries has a. So if an issuer retains a connection or relationship I did come connection with a holder. There is a protocol that allows the issuer to notify the holder that their credentials been revoked. But if no such thing. But if no such thing exists, then it's, then they do not have to notify and the wallet, the holder would not know, not necessarily know that their credentials been revoked. So if they're using something like open ID for for VCs there is no mechanism to allow a issuer to reach out to a holder say hey your credentials been revoked so that would have to be a separate topic is that does that answer the question. So it makes it tricky for the holder because they have to. They can, they may be able to monitor something like a ledger to see when their credential gets revoked. They can certainly determine at the time they generate a, generate a presentation, oh crap my my credentials been revoked I didn't realize that so they would know it before they share it, but they may not notice until the time they go to construct the presentation that their credentials been revoked. Okay. So attributes characteristics and trade off one more is preferences. Holders and verifiers collect whoops. What have I done. There we go. Holders and verifiers collect data from different sources so that's a preference. This is that comes back to that perception of tracking. And while it would be bad to track that a holder is generating a presentation that would be even worse. The tracking was the holder was, you know was presenting a verification and the verify and there was there was tracking of who the verifier was at the same time. That would be particularly bad so and so these are not hard and fast rules but the preference would be the holders and verifiers collect data from different sources. Again, nice to have the holders and verifiers collect their data from other than the issuer. And then this is that one revocation data sources should be perceptively independent of the issuer so again that same topic that we that we went back to. And, and finally a static source is preferred over an active source. So it would be really nice if the source of data was a simple file server with static content versus requiring a dynamic service which has to do some sort of calculations. Some sort of calculation in order to do it would be nice if the holder could simply collect a static file and be able to do some sort of calculation on it to get on its own. Versus calling a service which has to provide a real time calculation and so on so again not hard and fast those are are flexible and sometimes schemes might be better because for different combinations of reasons. That's one. And then finally this is a new one that I threw in there just because I noticed it but nice to have alignment with status list 2021 spit array technique so for those, I think most of us on the call here are aware of status list 2021 uses a bit array. Now it, it is, it provides linkable information so just quick summary. Issuer has a revocation registry and an index, a, that is an index into the registry that is a, and the registry itself is a bit per provincial. And basically, the bit is on or off, depending on whether a credentials been revoked or not. When in using status list 2021 the issuer publishes the location, or the data, the bit array periodically whenever they want to revoke credentials, the issue once they give the index there are the reverage ID plus the index to the holder on presentation, the holder gives that that reverage ID plus index to the verifier and it's the verifier that goes looks up in the bit array. One of the things that would be nice to have would be alignment with that and the reason it's nice to have is one of the things we're seeing lately is that a verifiable credential might be issued with multiple signatures on it so a non creds plus a NIST signature. And what that allows is that on presentation, the verifier can say I must have a NIST signature therefore you must give me, you know, proof that there's a, a NIST base, you know, signature from the NIST. You know, allowable cryptography. Now, when you do that when you have if you have that combination of a NIST plus an on credits you lose. If you use the NIST one you lose all of the non creds privacy, and that just goes out the window, but at least you can present your credential. If you, if the verifier does support the privacy preserving capability inherent in an on credits then you can present in an on credits credential. What would be really nice to have is not to have two different registries for revocation but rather just a common one. So alignment with status list one to one's bit array technique would allow you to do that. But of course, the mechanism must be have those attributes those must have like unlinkability so that is a requirement still. But I throw that in there because one of the techniques is actually aligned with status list 2021 so it would be a really nice to have if we could actually use the same revocation publication method with both NIST and an on credits credentials. So, with all that said, wow, that took a while, we've got for for revocation methods that are known and non credits v one that we've talked about which is cks signatures with the Taylor's file. Alasor, which is revocation managers contacted presentation time. So this is the validity to verify the credentials this was a technique proposed by under a strike tag. At descent paper. So he published it last, you know, we've talked about last week or the week before. Can you hear me. Any luck. Sorry about that. All right, let's I'll try finishing. Obviously I was on the last slide. All right, so that's the the final slide I don't know where when I cut out but I won't repeat too much and on credits. It gets it's red because of this. We have call home on these two as yellows not eliminating them. We have nice size of attributes because all you're doing is doing a call and getting basically a the data backs it's the revocation managers that are holding on to data and they're providing data back so relatively small holder size requirements. ZK Sam has a larger requirement, but you're not calling home you're calling back to some static array, and it's, and it is a bit array so that it does align with the status list 2020. So, that wraps up what I wanted to share out we're really looking at trying to nail down and moving forward with these. The LVVM is quite an interesting option that was new it's very similar to Alasdor but in my opinion much less complex it's much more aligned with exactly what is a similar way to do it with LVM basically you call to a revocation manager and basically request a new credential be issued that that your credential is not revoked and it's therefore and hasn't expired or at least sorry a time of issuance associated with it, and so a verifier when they request a credential it's revocable, they expect to get back the a, a not revoked credential as well so it's very explicit it's just using a non creds to verify the credentials the actual credential, plus the not not revoked credential and so it's very similar with a non creds it uses the it was issued to the sending blinded link secret to show that they're bound together the binding between the remote credential and the, and the originally the non revoked credential and the issue credential initially. Those are the techniques ZK Sam I think I've talked about for at least some of you before but this is one that is the least rigorously reviewed but has some super interesting characteristics to it I think it's got the best characteristics. So you get a million credentials and a revocation size, and yet worst case you've got 153 k file that gets put on to a file server, or gets published somewhere that can be downloaded and and read and and process by the holder so the, the attributes of it are very nice but it is the least rigorously reviewed in fact it's very been reviewed at all so so that's one we're interested in getting reviewed. So that wraps up what I was going to share. Yes, reference material on LVDM. Yes, I will send it out to the mailing list, and I'll send it to you directly as well just to make sure you get it. And, yes, and make sure you have that. As they say it was just published the other day I can send out links to all of these. Okay, I will do that. That wraps up what I had planned for today is or any other, any other things to talk about or show we call it a day. Next time we talk. We will have whoops where did I go there they are lost the screen. Oh, yes, go ahead. Just listening. Hi. I asked a question in chat. Is there a location to be unlimited. So, in all of these schemes you never should share a the, you never share that with the verifier. So the ability for the verifier to re verify should not. Actually, you're right. I should put that in explicitly as a hard requirement that it's not a thing we want. We don't want to allow. That would be a privacy native. You are absolutely correct. So, in the status list 2021, which we don't consider, you know, a privacy preserving it would not meet the requirement because it shares and it shares a linkable identifier. And in sharing that, it allows for the ongoing monitoring by the verifier to see if that credential ever gets revoked. And so, yes, that would be a definite privacy negative. All right. Thanks all. I hope that was helpful. I'm meeting with the L of CL signatures tomorrow and we'll be sharing some of this as well as we talk. Anna is interested in understanding the state of where we are, and maybe willing to help out in some way or, or, or try to coordinate things. So that's a possibility. So Hart Montgomery and I are meeting with Anna tomorrow and looking forward to that. All right. Have a great day everyone, or the rest of your day. See you again a couple weeks. Bye. Thanks.