Provide guidance on choosing validity periods for status lists.

[msporny]

This PR is an attempt to address issue #48 by providing guidance on how to choose validity periods for status lists.

---

💥 Error: 500 Internal Server Error 💥

PR Preview failed to build. (Last tried on Dec 2, 2024, 7:00 PM UTC).

More

PR Preview relies on a number of web services to run. There seems to be an issue with the following one:

🚨 Spec Generator - Spec Generator is the web service used to build specs that rely on ReSpec.

🔗 [Related URL]([object Object])

Protocol error (Runtime.callFunctionOn): Promise was collected

If you don't have enough information above to solve the error by yourself (or to understand to which web service the error is related to, if any), please file an issue.

[David-Chadwick]

Given that the status list is a bit string, then the overall size should be small. So I do not think that excessive bandwidth should be a serious impediment to a frequent refreshing of it. Suggest removing the last list item

[msporny]

Given that the status list is a bit string, then the overall size should be small. So I do not think that excessive bandwidth should be a serious impediment to a frequent refreshing of it. Suggest removing the last list item

Remember that the size of the bit string is only one of the concerns. The other concerns is the size of the verifier community, because that's where the real multiplier comes in. For example, if you have a bitstring that is 125K in size, and a verifier population that is 100, then you're looking at 12MB per refresh cycle (which seems reasonable). If, however, you have a verifier population that is 10,000, then you're looking at 1,221 MB per refresh cycle (which is significantly higher).

[David-Chadwick]

I take your point. But you are assuming that every verifier downloads every list update every time. But this depends upon the frequency of user interaction at the verifier. If the user interaction is less than the update frequency then it will not be true. So a nightclub that only opens at weekends with an issuer that updates daily, only 2/7 updates will be retrieved by this verifier. OTOH an online shop that has thousands of customers daily, then downloading the list daily is negligible overhead for this verifier. Can we assume that the verifiers will be in different time zones if there are 10,000 of them, so they wont all be downloading at the same time? I think your CA DMV trial should be able to get some really good metrics for use of the mDL at thousands of local shop locations, with the frequency that driving licenses are revoked by CA forcing the list to be updated.

[dlongley]

I take your point. But you are assuming that every verifier downloads every list update every time. But this depends upon the frequency of user interaction at the verifier. If the user interaction is less than the update frequency then it will not be true. So a nightclub that only opens at weekends with an issuer that updates daily, only 2/7 updates will be retrieved by this verifier. OTOH an online shop that has thousands of customers daily, then downloading the list daily is negligible overhead for this verifier. Can we assume that the verifiers will be in different time zones if there are 10,000 of them, so they wont all be downloading at the same time?

That these all seem like important considerations for the issuer indicates to me that we should leave the bandwidth language in place.

It's also worth mentioning that a bitstring with many randomly flipped bits will not compress well -- so this should be avoided if possible or at least taken into consideration with respect to bandwidth as well. This section is intended to cover use cases beyond a status list for infrequently revoked credentials -- so other use cases with different status purposes and models can benefit from the text here.

[TallTed]

Editorial...

[msporny]

Editorial, multiple reviews, changes requested and made, no objections, merging.