Harrison_Tang: Hi everyone uh welcome to uh this week's w3c ccg meeting uh today we are very excited to have Manu and Dave uh from digital bizarre to lead a discussion on VC ping status list uh I saw that in the past few hours people already have questions so this will be a very exciting conversation. ✪
Harrison_Tang: Uh before we start I just want to uh go over some uh agenda items. ✪
Harrison_Tang: I think we have been doing that for the last 2 years but uh. ✪
Harrison_Tang: Doesn't hurt to have a quick reminder at the beginning of each meeting. ✪
Harrison_Tang: A quick intellectual property you know uh anyone can participate in these calls however all substantive contributions to any ccg work items must be member of the ccg with full IPR agreements signed if you have any questions in regards to that or uh any troubles creating the w3c account uh feel free to just reach out to any of the cultures. ✪
Harrison_Tang: All right uh I think it's time for the introductions and reintroductions so if you're new to the community or you haven't been active and want to re-engage with the community uh feel free to just uh unmute and introduce yourself. ✪
Manu Sporny: Yeah just uh some status updates on how the standardization work is going in the verifiable credential working group at the worldwide Web Consortium um. ✪
Manu Sporny: Uh we are uh we we've now moved the verifiable credentials to 0 specification into the candidate recommendation uh phase that's the phase right before you propose it uh for uh an official vote for it to become a global standard um so uh at this point. ✪
Manu Sporny: Uh ecdsa eddsa are all in the candidate recommendation phase in the next month we are expecting uh VC Jose cozy um uh and uh bit string status list the thing we're talking about today uh to go into candidate recommendation and then shortly thereafter for BBS to go into candidate recommendation um uh once that happens all of the documents that the group has been working on will be in the candidate recommendation phase um people are implementing now there are plenty of um. ✪
Manu Sporny: Uh companies implementing right now 11 of them are integrated with the test Suites um the test Suites continue to be updated um so if you're an implementer now is a good time to start implementing um and uh as I think folks know we have. ✪
Manu Sporny: Office hours for implementers um that are held like every other week I don't think Benjamin's here today but Benjamin uh has been heading that up so if you've got any questions concerns with implementing against the verifiable credential 20 stuff um they are now office hours that you can show up uh to and ask your questions there um so the good news there is that you know we've got many things moving into the candidate recommendation phase and we have active test Suites and implementers implementing uh the not so great news is we're running out of time for our Charter our Charter ends in June uh there is an expectation that we'll get a charter extension primarily because we've demonstrated that we're making. ✪
Harrison_Tang: By the way if you're curious about what's new on the verified credentials data model version 2 uh we actually invited monu back as well as Brent uh to talk about uh what's new uh next week. ✪
Harrison_Tang: All right any other announcements or reminders. ✪
Harrison_Tang: Last call for announcements or reminders. ✪
Kaliya Young: Um so we've got internet identity Works number 38 coming up in April April 16 to. ✪
Kaliya Young: 16 To 18 the digital identity unconference Europe happening in Zurich in the third week of June I believe it's the 18th to the 20th and then. ✪
Kaliya Young: Did unconference Africa happening in Cape Town. ✪
Kaliya Young: And we're currently deciding on dates for a. ✪
Kaliya Young: Um our Asian events in Thailand in early 2025 between the 2nd and the third week of January so but he has any date conflicts they want to to a wide let us know um I'm proactively reaching out to folks in the region to understand what our key sort of themes and. ✪
<kaliya_identity_woman> @Dmitri - I know it is a conflict - I raised it early on...but it was the only week the Musuem was avaliable.
<dmitri_zagidulin> np <3
<kaliya_identity_woman> fly home Thursday?
<dmitri_zagidulin> yep!
<kaliya_identity_woman> Or we have our own constume party
<dmitri_zagidulin> thaaaats the spirit
Harrison_Tang: More news uh and more announcements to make uh in April sometime in April so we're scheduling sometime in April to kind of present that role mapping if you have any feedback or comments in regards to the ccg road map or in regards to what kind of work items we should be taking on or what we should be working on uh feel free to reach out to any of the cultures but will is actually taking the lead on that. ✪
<kaliya_identity_woman> looking forward to the creative constumes "red line" or "open issue"
Harrison_Tang: Right last calls for announcements work items introductions. ✪
<manu_sporny> I call "The Ghost of Identity Past"
<dmitri_zagidulin> LOL
<kim_duffy> Teacher's pet~
<manu_sporny> haha
Harrison_Tang: Great let's get to the main agenda so uh again we are very excited to have Manu and Dave here to uh leave a discussion on VC Bering status list uh this is probably the very first time in the last year where the presenter actually share with me the presentation in advance so I want to give a quick shout out to them they're quite prepared uh and uh a quick note uh B string stats list is a way to publish status information like s uh s suspensions or revocations of the VC so. ✪
Manu Sporny: Okay um oh and I was able to finally extract the w3c credentials community group banners that we can put it on slide deck so there's a there's a community resource here you can copy and paste this now um if we want to put these on ccg slide decks um it's a very small. ✪
<dmitri_zagidulin> I want a desk like that guy has, in the slide...
Manu Sporny: Today we're going to talk a bit about bitstring status list um bitstring status list is uh 1 of the uh status list Technologies uh or really the only status list technology that is being standardized in the verifiable credential working group right now um uh. ✪
Manu Sporny: Today I think we we'll we'll be covering like. ✪
Manu Sporny: Uh you know why did we build it what kind of privacy aims did we have when we were building it uh we'll look into a bit uh in in how it uh works like what makes it tick um uh and then we'll have a little bit of discussion like you know a bit string status list is not the end all be all be all status list mechanism for uh VCS it it it it it achieves some good privacy goals but like we can do better and so there's some talk about what the next version. ✪
Manu Sporny: Um all right uh so let's take a quick look at what this is um. ✪
<bobwyman> Has the transcription stopped?
<phil_long_(t3)> appears it has
<harrison_tang> hm ... it says that the transcriber is still active on my end
<phil_long_(t3)> not seeing it in chat
Manu Sporny: Uh okay so uh that's what we mean by space efficient we wanted to make sure that the the status um uh list uh even with Millions to tens of millions to billions um stayed uh uh space efficient um. ✪
<phil_long_(t3)> it's baaacck
Manu Sporny: So verifiable credentials have a credential status field and that lets you publish things um that you might want to update after the holder gets the credential uh meaning like after a holder receives a verifiable credential you might want to do things to that credential like uh revoke it or suspend it or uh a variety of other kind of status flipping um uh things um we wanted um the mechanism the bitstring status list mechanism to be privacy preserving by default um some of the previous ways of doing status lists required the holder of the digital credential or whoever was verified it to do what's called phoning home so they would go out and try and ask the issuer like hey is this credential still valid and that tells the issuer that you know you the holder were using your credential. ✪
Manu Sporny: And we wanted to make sure that we covered things like suspension and revocation okay so so so some of the design goals here was we wanted to um provide status information for Long Live credentials that was like 1 of the design goals but we wanted to do it in a way that didn't like instantaneously violate an individual's privacy so we want we had some privacy goals that we wanted to design for um uh that would protect protect the individual uh uh primarily from. ✪
Manu Sporny: With the verifier and they get full transparent like they get to see you using the credentials so think about you're using a driver's license to get into a bar you know if you phone home to the issue of the driver's license then the that government agency knows that you're going into bars and when you're going into bars and and things of that nature so that's what we mean by privacy preserving we wanted to stop that from happening uh the other thing was we wanted to wanted it to be space efficient. ✪
Manu Sporny: Specification um we are almost at the candidate recommendation phase which basically means like we're pretty much done with the design um we we think we're done uh with the design we want people to implement. ✪
Manu Sporny: This thing is being rolled out into production environments um uh. ✪
Manu Sporny: Very soon now within like the next couple of weeks to months so um. ✪
Manu Sporny: Um because verifiable credentials um could have like uh thousands of different types sorry you could have millions um of uh credentials issued having a status list uh per um uh having having like a status be big per credential would be like. ✪
Manu Sporny: You know a small value like you know 1 byte or 3 bytes or 10 bytes multiplied by millions to tens of millions to billions so that wouldn't be um that wouldn't be a good thing um. ✪
Manu Sporny: Okay that's the high level um let's look a little bit at the privacy considerations the things that we wanted to. ✪
Manu Sporny: Diagram on the Right comes from the VC data model um. ✪
Manu Sporny: Specification it kind of shows you the ecosystem like the you know the issuer holder verifier um registry ecosystem and then a number of actions that you can take while you're in the ecosystem and what that action you know who communicates during that action so the the action we're looking at right here is this check status uh might not preserve privacy uh you know repeatable thing highlighted in in red at the center of the diagram here uh this is when a verifier receives a digital credential from a holder and then they go to check the status um from the status list published by the issuer um so a couple of like high level requirements here was that the issuer when when the verifier contacted the issuer and this this is a form of like phoning home right um bad phoning home is when the issuer is when the verifier contacts the issuer and says this is exactly who I'm. ✪
Manu Sporny: There has to be some kind of group group privacy uh at play there um the other design goal that we had is like we wanted to eliminate this phone home you know the the the we wanted to eliminate the verifier contacting the issue at all like completely like so the design had to enable that to happen in fact with bitstring status list the holder can provide the verifiable credential and in parallel they can provide the status list the current status list to the verifier so that the verifier never has to contact the issuer now. ✪
Manu Sporny: Whether or not that's going to play out in practice. ✪
Manu Sporny: Um is still like to be determined but um in theory if the holder you know contacts the verifier and goes. ✪
Manu Sporny: Electricians license in here is uh uh proof that this thing has not been revoked as of today the verifier can look at both of those verifiable verifiable credentials and go yep that checks out without having to talk to the issuer at all so the second bullet point here is about making sure that the holder um and the verifier can have an interaction where the verifier doesn't actually need to contact the the issuer at all um that's you know a privacy preserving more privacy preserving um and finally um uh we uh well let's stop there we'll go ahead. ✪
<dave_longley> the key point: the status list itself is expressed in a VC.
Manu Sporny: There is a valid from and valid until date on the status list credential uh that gives them some idea of like when it was issued so for example like if I hand you you know I I give you my I don't have an electrician's license I give you my electrician's license and I and I give you uh the status list associated with it those are 2 verify credentials and the only thing that you need to get from the issuer is like their did document and their their keys and you can verify that both of those you know are are valid they were they were issued today and if your use case is such that you're like well this is valid of to as of today um or it's valid as of like 3 days ago that's good enough for my use case then you don't need to. ✪
<colin_reynolds,_ed_design_lab> How does this impact an issuer's ability to see if the credential was used? Thinking in terms of education provider looking to see if an industry credential helped an individual get a job... maybe too specific of a use case for this convo.
<dave_longley> the design here is to enable status checking without the issuer knowing about use of a specific VC
Colin_Reynolds,_Ed_Design_Lab: Adapters but there are some use cases where it might actually be beneficial right from economic impact and um but yeah those are Case by case and. ✪
Colin_Reynolds,_Ed_Design_Lab: Would be conversations if somebody's actually implementing VC's in Earnest and they're they're looking at at doing some of that that would be. ✪
Colin_Reynolds,_Ed_Design_Lab: Would want to bake that in but I I think yeah totally understand what what the point is here is you don't want to enable that by default so thanks. ✪
<dave_longley> decoupling usage from status checking enables privacy preserving checks -- other use cases could involve some other layer for usage tracking where it makes sense (and with holder consent, etc.)
<bobwyman> Please provide one example of when the issuer has a reasonable interest in knowing when the credential is used.
Manu Sporny: Is important to measure how these things. ✪
Manu Sporny: When you do those kinds of things these days um. ✪
Manu Sporny: Through the technology through the core technology um a better ways meaning like you need to get consent from your community you need to be very clear that you know you are aggregating you know usage if you are going if an issuer is going to collude with a verifier they need to be very transparent about that because if they're not it will come back in a very negative way uh on them um primarily through like uh privacy regulation California consumer Privacy Act G. ✪
Manu Sporny: So those are the those are kind of the the protect against tracking by the issuer concerns that we had um we also wanted to protect against statistical analysis um I I also want people to pay pay close attention. ✪
Manu Sporny: It's such a difficult 1 to to address we can talk about it a bit later but uh I wanted to be transparent about you know the things that we felt we could address and the things that we felt like we couldn't uh easily address um. ✪
Manu Sporny: Okay protecting against statistical analysis so um we wanted to make sure that you know if we were providing something for uh heard uh sorry group privacy we're using the word group privacy now instead of her privacy um we wanted to make sure that that group privacy actually meant something meaning that if someone were to watch the status list as it changed throughout time would they be able to glean any kind of information from it would they be able to uh understand like who a subset of the population was or where you were in that subset of the population or how that how that group interact you know works in the in the real world so um the way you do that is you you watch the list and then you run statistical analysis uh on it um so for example if you had a list uh let's say you had a list a status list that's a hundred thousand items uh a large we we have. ✪
<colin_reynolds,_ed_design_lab> @bobwyman ... the value prop for learning providers offering training programs to individuals looking to upskill and earn more
Manu Sporny: Um so so if you started uh allocating indexes. ✪
Manu Sporny: Where the first VC gets the first index you know gets the first uh bit the second VC gets the second bit the third VC gets the third bit and so on and so forth and you were to just like bulk um revoke a set of credentials or you were to kind of like revoke a certain credentials um in the set someone looking at that looking at the giant list the giant array of of bits would notice that like bits of above 25,000 are just quiet they're always zero right they they never change and that would allow statistically you would basically say oh this group is less than 25,000 individuals right um uh and you could watch for patterns in that where like oh the front of the list has a lot more revoke revocations than the back of the list and over time it looks like these credentials are being revoked you know 6 months after they're they're being issued and if you know the type of. ✪
Manu Sporny: Credential then you can start kind of profiling you know the group. ✪
Manu Sporny: Status changes leak is little information as possible which means that effectively what that means is like do your index allocation randomly use a use a cryptographically you know uh uh cryptographic random number generator and every time you issue a credential you pick a totally random Place uh in there that you um issue a credential out of there are other tactics like uh use um use uh decoy values in here where some of them are not real randomly flip uh decoy bits when you flip real bits there's all kinds of uh Innovation that can happen here that that helps preserve privacy uh the spec currently just says do it randomly it doesn't say do all those other things because we didn't feel comfortable. ✪
Manu Sporny: Kind of an an emerging uh field um how you how you do privacy protection correctly um in in something like this but doing random index allocation is is pretty good to start with um uh that's that's kind of the the the bare minimum and um. ✪
Manu Sporny: All right uh I there were a couple of other goals here um you know we we wanted to make sure that it was also fairly easy and straightforward to implement there are all kinds of like super uh Advanced zero knowledge proof uh mechanisms to do zkp based like uh credential status and and things like that the the problem with many of those um uh Solutions is that they they haven't had a tremendous amount of analysis done on them uh by um frankly by like the National Institute of Standards or the European um Etsy uh which is the The Nest equivalent in the European Union um when these things are deployed and they're deployed at scale and they're deployed for doing things like foundational uh identity uh driver's licenses citizenship cards employment authorization documents things like that um it is very diff it is nearly impossible to convince um. ✪
Manu Sporny: Thing that you depend on that hasn't been vetted by them before and so we needed to 1 of the 1 of the constraints we had is we needed to design something where we didn't have to prove that the cryptography or the math was new or novel or anything like that right we we had to use boring old stuff that had been around since like the 60s and 70s um to to make sure that we would we would be able to use this in um. ✪
Manu Sporny: Throughout the the world so that was kind of another design goal here is 1 make the Implement make implementations fairly easy and straightforward um and then also don't use. ✪
Manu Sporny: Okay um how it works um any any questions on on kind of the the goals here before I move on like you know these are the these are kind of like the Privacy goals implementation goals we had uh anyone can anyone think of something that I didn't mention here or. ✪
Manu Sporny: Other things you're wondering about whether or not we thought about. ✪
Manu Sporny: So this is how it works from an issuance perspective and it it's it's super it's it's super simple it's like really really straightforward right um fundamentally you've got to verifiable credential on the left and this is like a a a degree like an example degree credential it's a Bachelor of Science in arts um and it's issued and when it's issued there is this uh credential status. ✪
Manu Sporny: That's added to it so it's this green this thing in green that is the information that goes in the VC that tells you which 1 of these bits and this bit string status list um this credential is associated with so when a verifier gets this information they they see like oh it's got a credential status in oh it's a revocation list so um in the position in the list is 94567 right and here's the here's the link here's the URL uh to the list uh down at the bottom status credential and so the verifier has all the information that they need to pull that information to get the status list and understand which bit is associated with this credential and the purpose of that bit um and that's it that's that's the only extra information that's added to a a verifiable credential um uh to say what its Association you know where where it's revocation list is. ✪
Manu Sporny: List of bits uh the lowest bit you know uh is is on the left and the highest bit is on the right and this says 16 kilobytes which is about 131000 entries um you know you can just wave your hands and say it's like it's over 100,000 entries right um now uh this thing uncompressed is 16 kilobytes in size which is Tiny by the I mean that's like. ✪
Manu Sporny: You know watch video online that is like a millisecond of whatever show or movie you're watching right so these These are super tiny um uh in size and we can compress them uh using what's called zlib compression this is a type of compression that's been around. ✪
Manu Sporny: I don't know is late 70s early 80s it's been around for a really long time um. ✪
Manu Sporny: That uh basically takes bits that are the same like see all these green values and it compresses them down into like a super small value so if you have a run of like uh let's say you have a run of like a thousand bits and they're all zero. ✪
Manu Sporny: What the compression will do is say it would use like it's very tiny number like just a just a bite or 2 to say the next thousand bits are all zero right in in that effectively will compress this down you know if you only have a handful of credentials that are revoked um that'll compress the list way down from 16 kilobytes to 16,000 uh bites down to like 135 bites. ✪
Manu Sporny: Uh if we you know if most of the credentials haven't been revoked or if like most of the credentials have been revoked their very space efficient where they're not space efficient is when you have like a total mixture of revoked and unrevoked things that don't have you know long runs of zeros or ones in the list and at that point you know the compression algorithms like I can't help you like it's you know you you end up in that case random noise is the worst thing to compress uh you end up with like around uh 16 kilobytes in size uh sometimes a bit more if it's true truly random noise um. ✪
Manu Sporny: Super tiny um very space-efficient uh and if we do you know random uh you know allocation um uh that's even better so we meet you know our we meet our size um uh requirements in our privacy requirements um uh using this mechanism. ✪
Manu Sporny: So that's that's it like that that's that's how issuance works the issuer is like I'm going to put a credential status on this thing for revocation I'm going to use this bit to specify the revocation index for this verifiable credential and then and then that's it and it and it creates that um the veriff the issuer will sign the thing on the left it'll do a digital signature on the thing on the left and it'll do a digital signature on the thing on the right which looks just like a a verifiable credential okay so that's issuance let me pause there for a half second see if there are any questions on on issuance. ✪
Manu Sporny: Okay no questions uh hopefully that means it's pretty clear um. ✪
Manu Sporny: Next thing is verification how does verification work uh right so so this this verifiable credential is given to the holder this is an individual that puts it in like their digital wallet they go and they want to use it somewhere so let's say you know they want to they're they're getting a job and they want to prove that they have a bachelor's degree um from a particular uh University um and that bachelor's degree has a credential status field because maybe you know the university wants to be able to revoke the credential in the very slim chance that they. ✪
Manu Sporny: Okay so verification the holder's got their degree they go to let's say a job site and um uh they hand the verifiable credential that says that they have graduated from a certain University over to the the HR department um the HR department would then look at the credential see that it is a credential status so it would first check the signature on the credential like is this a valid credential that was issued by this University or not. ✪
Manu Sporny: As verified yes this is a valid credential the digital signature checks out it hasn't been tampered with then the verifier would start validating in in would look at like oh there's a revocation list here I should probably check the revocation list to make sure that the university hasn't revoked the credentials since they first issued it um and then the verifier basically looks at this field here on the left this credential status field and they go like okay I need to get this from somewhere the status list credential is at this URL so status 3 this URL here and then once I get that status list I'm going to expand the bit string and I'm looking for location 94567 in that list um. ✪
Dmitri Zagidulin: Uh thanks uh so thank you first of all uh for the presentation I'm a big fan of the verification list in general uh we're implementing it uh over a DCC uh for our issuer. ✪
Dmitri Zagidulin: Ah and verifiers my question is on the cache control right have we as a community given it some thought can we. ✪
Dmitri Zagidulin: Can we allow the issuer to give some hint possibly inside the status credential itself. ✪
Dmitri Zagidulin: The intended cash uh right so I'm the issuer I'm saying you know what I'm not going to revoke more frequently than once a day so verifiers you can cache this for a day. ✪
Dmitri Zagidulin: Uh is so yes HTTP has cache control headers but for those of us hosting it uh either statically on a website or on something like GitHub Pages by the way don't host it on GitHub Pages because GitHub has rate limited so learn from our mistakes. ✪
Dmitri Zagidulin: But for those of us who don't have direct control over the HTTP response headers. ✪
Dmitri Zagidulin: Had a cache control field to the status credential itself. ✪
<nate_otto> validUntil
Manu Sporny: Excellent question Demetri yeah this is certainly come up a bit I see Bob and Dave are on the Queue um so let's let's I think Dave's got some uh uh deep thoughts on on this um but yeah it's it's a it's a it's an excellent excellent question uh Dmitri uh go ahead Bob and and then Dave. ✪
Bob Wyman: Yeah I'm sorry if this is a silly question not well thought out but if the if the recommended list size is like on the order of a 100K or so um does that mean that. ✪
Bob Wyman: It would make sense for a low volume issuer to go to a third-party uh uh uh list maintainer so that. ✪
Bob Wyman: That low volume the the low volume of bits would get buried in a in a in a higher volume of of other bits. ✪
Manu Sporny: You could do that um so yeah uh yeah so just a just to respond really quickly you could do that it's a little more complicated they would have to be some kind of agreement between those 2 organizations in my expectation is that low volume issuer um would just publish the list themselves because it's you know let's say they're only issuing like 50 credentials or 100s um. ✪
Manu Sporny: It doesn't really matter if the list is 100,000 long it'll compress down to like 200 bytes right and so it's not a huge. ✪
Manu Sporny: Even for the privacy concerns it's kind of like you know it it doesn't impact them they're they're issuing 50 credentials um. ✪
Manu Sporny: To deploy this thing that was probably not going to be a good good approach you can do it it's always optional you can always layer it on but um I'm suggesting that the um. ✪
Manu Sporny: But their list is 100,000 long and so anyone looking at the list wouldn't be able to know that they're that's all they're ever going to issue. ✪
Manu Sporny: The organizational coordination that needs to happen um might not be. ✪
Manu Sporny: But that also doesn't mean that you know bit string as a service. ✪
Manu Sporny: You know can't can't also happen there's nothing preventing that from happening um. ✪
Manu Sporny: So you can you can do it either way I'm saying and and I think that you know status list as a service is still a bit of a. ✪
Manu Sporny: Yeah it's not a requirement it can be done but it's not you know we wanted something that's easy to deploy and so if you have to like depend on some other external entity. ✪
Bob Wyman: Yeah I think I need to think about this more. ✪
Dave Longley: Yeah I was um so uh VCS come with a validity period uh built into them um. ✪
Manu Sporny: Okay um and then Dave I think you were on the Queue to respond to Demetri's question. ✪
<dmitri_zagidulin> maybe we just rename ttl to cacheControl?
Dave Longley: Using the valid until invalid from fields and what we've found uh we're current there's currently a field uh called time to live TTL that is in the specification uh we're not sure if if people will Implement using it and that was sort of an attempt to put caching into the credential itself but we found that that might create some conflict um and some false expectations with an issuer so we were a little we were a little worried that um if you know I'm specific this is specifically for cases where you don't have control of ratio be cache headers as you said to metrie we're a little bit worried with using time to live um in credentials because a an issuer might decide to Mark a credential as having a very long validity period but put a short time to live in it um and that might create a false expectation that that some verifier will make sure to actually check the time to live and not the validity period only on the credential on top of that because these. ✪
Dave Longley: There's no information that's signed about when the holder fetched it so the holder could always say no I got it within the time to live don't worry about that um and so. ✪
Bob Wyman: Okay so you're saying bit string as a service is not. ✪
Bob Wyman: Is not a big requirement okay I need to think about that. ✪
Dave Longley: We think putting those those that sort of caching information is probably not leads to a number of problems and we actually don't think that we actually think that the use case that you're talking about where you want to have for an issuer put these credentials out and have a validity period of about a day can already be solved by just using valid from and valid until in fact what they can do is uh publish these credentials on demand or as status changes with a validity period of about 24 hours um and then let people just do their own caching on that basis even if they don't have access to changing HTTP cache headers by having that medium length validity period and poh and doing publishing on demand I think you can accomplish the use case that you're talking about. ✪
Dmitri Zagidulin: Know when that time to live started from you're right. ✪
Dmitri Zagidulin: Renaming the field to Cache control might be slightly easier but again verifier doesn't know when uh when that period started. ✪
Dmitri Zagidulin: Gives issuer more information that may that we may want to uh. ✪
Dmitri Zagidulin: To provide but makes sense thank you. ✪
Dmitri Zagidulin: Uh it makes sense that we can use shorter-lived credentials so that that from valid until becomes the cache control that makes sense I I would caution against the uh issuing them on demand because that just kicks the phone home problem over 1 level right uh the the on demand part. ✪
Manu Sporny: Yeah and it's excellent question to me I mean I I it sounds to me like you know currently we're basically saying just depend on the valid from valid until for the um the status list credential like that is your you know that that is a cache control that you can depend on um and then if you can if you do have control over the HTTP headers set the headers to the same time frame uh so that if people are using HTTP caching uh headers you know it's a line with the the values in the in the status list um the other thing also to keep in mind is is remember we wanted. ✪
<bobwyman> In some cases, an ability to detect that an issuer is active would, in itself, provide valuable information. In such cases, the issuer might want to obscure its activity within a larger set of statuses.
Manu Sporny: To enable the holder to be able to deliver the status list credential themselves and so if you have like a month-long validity period for the status list if a verifier gets that like and it's a month-long status list they're going to almost certainly go out to the verifier and try to get the latest 1 because they're going to they're going to look at it and they're going to go A month's too long I can't be sure you know um I want information as of today they go and they fetch the thing and it turns out it's the same it's the same list right um uh so so maybe you know the right solution here is to have daily or weekly status list credential um uh signatures and your validity dates you know have stick to that range and. ✪
Manu Sporny: I think you were on the Queue there for a little bit. ✪
Dmitri Zagidulin: Thanks uh so I guess my other question and I think a lot of us on the call uh might be interested in that is. ✪
Dmitri Zagidulin: So what's next in terms of uh other revocations backs uh what are the design challenges that we're exploring uh what has there been demand for Etc. ✪
Manu Sporny: Yeah excellent question so I've got a a slide at the end um where I'll get to that so let let me get through the verification I think that's the very next slide or 2 2 down um okay so just to cover what verification you know the verifier gets the credential they look they they get the status list they check the bit if it's you know if it's a revocation status list if the bits 1 it's revoked. ✪
Manu Sporny: Okay so this is kind of leading up to to um Demetri's question. ✪
<dmitri_zagidulin> clear
Manu Sporny: Uh did we actually address our requirements um so you know because of the design and the way it works the issuer doesn't get to see which individual status is being checked uh individual privacy is preserved as long as the issuer is not a bad actor um uh I'll get into what being a bad actor means later uh the The Observers list so if there's somebody watching the status list change over time um we use uh Randomness and dummy values um uh and so because we do that you know group privacy continues to be preserved again as long as the issuer isn't a bad actor and is trying to like signal things to the outside world by bunching a bunch of issues you know to a certain part of the list um. ✪
Manu Sporny: This um status list um and then the 1 of the most important things is this ability to deliver the status list for the holder to be able to deliver the status list instead of the verifier needing to go and get it directly from the issuer now this asterisk here is you know we say as long as the issue is not a bad actor because if the issuer is a bad actor they can do something they can do things to violate the individual's privacy for example using 1 status list for every single VC that they issue then when the um verifier comes to check the list there's a 1-to-1 mapping between the list and the the issued credential so if the issuer is a bad actor you you really can't do much you know they they have to they have to be bought into the Privacy preserving characteristics and and employ them now you can observe issuers cheating in this way as long as you you know get a a decent number of holders together you get like for example you get a. ✪
Manu Sporny: That is a signal that the issuer is tracking us right in digital wallets can do this kind of analysis um. ✪
Manu Sporny: With consent of the individual of course uh to try and protect the individual to basically warn the individual like hey you're electrician's license has a has a tracking cookie in it um you may not want to use this or every time you use this you know the issuer is going to know you're using this. ✪
Manu Sporny: So those kinds of things can you know um be done to to catch a Bad actors uh go ahead Harrison. ✪
Manu Sporny: If the digital wallets are going to build in the support for. ✪
Manu Sporny: Delivering the status lists themselves um and counting on that happening was something that we couldn't do because we couldn't get a straight answer from the wallet providers because the wallet providers were like well yeah sure like if other wallets do it maybe we'll do it too and it's like okay well we can't really build a global standard on on you know. ✪
Manu Sporny: People waiting around to see what would happen so so we wanted to build it in a way where it was guaranteed you'd be able to get the list but there's a step up from a privacy perspective that wallets could do um if we could convince the the wallet vendors to to do that kind of delivery and the verifiers also have to support it like it's a more complex protocol where the verifier accepts the status list not from the original issue or themselves um but yeah both both approaches are are possible go ahead Demetri. ✪
Dmitri Zagidulin: Yeah I wanted to add that it seems that getting the status list from remote is preferable because. ✪
<dmitri_zagidulin> we're doing that already
Manu Sporny: You know a large actor that does do exactly what you said which is you know use 2 totally different did keys to sign 2 totally different things and then you have to have a trust list and so on and so forth so um we're putting options uh on the on the T oh Demetri saying they they do that already right so so I mean so so what we're doing is we're putting options on the table um that we don't think are dangerous um from a privacy perspective and then we're going to see. ✪
Manu Sporny: What we can nudge the ecosystem uh towards uh but this last slide gets into Demitri's you know question which is. ✪
<dmitri_zagidulin> I think this may be partly addressed with a more extensive Known Issuer list
Manu Sporny: Could we do better and the answer the short answer is yes of course we can do better right there there are these these these others are knowledge proof based schemes that allow you to do uh unlink um revocation um based on ckps uh a non-red V2 has done some really good work in this area they're looking at something called Allosaurus mechanism um in the the key Point here is that the the verifiable credential to data model is designed to be extensible right we are starting off with this because we think it it it does some good things from a privacy perspective um but we know that this is not the end solution like we are going to want to move to these other things um as long as they are proven to be secure as long as you know nation states and state governments are willing to use them like there are a number of things that have to happen in the space for us to move to a different. ✪
Manu Sporny: But the good news here is that like we have the architecture to to move to the next thing without it being super disruptive on on what we deploy today um. ✪