[greycol]

You could technically implement a system to do it if you increase the number of keys revoked by an action. i.e. The the first X digits of the key are generated in a small enough range that they overlap with other keys. You revoke all keys that match that grouping forcing all those users to renew their keys.

There's obvious other drawbacks to this but it technically preserves privacy while still allowing revocation. The problem then occurs that once the system is in place it's easy to change. A recent and obvious example is that for years in the US undocumented immigrants paid taxes under the understanding that the tax department would not furnish that information to the arm of the government detailed with immigration enforcement, this policy recently changed with no equivalent law change and there is no recourse for those most disadvantaged by that change. Unrelated to the point at hand; going forward undocumented people are now encouraged to not pay taxes and that lawlessness is also encouraged in businesses that want to take advantage of that labour.

[dpark]

The real problem isn’t the revocation list itself. It’s just a list of numbers. If you get a credential that has been revoked it certainly tells you that it’s been revoked, but not much else. Assuming of course that it’s actually a revocation list being fetched and not a “is this particular cred revoked” call, because that would reveal that the cred is being presented to the caller.

The real question is how do you know when to revoke? How does the government know if a cred is being used by a minor or used broadly, indicating it’s been shared? These imply some sort of feedback from the entities accepting the creds and mean that the privacy guarantee is breached.

(I’m also not sure how revocation lists work with zero knowledge but maybe there is some crypto magic for that.)