Enable verifier to check revocations without user interference


As I gather from this document, it is the user/holder that creates proof of non-revocation (of a credential) that a verifier can subsequently check for correctness. This provides a verifier with assurance that the credential he has received from the user has not been revoked at the time that the proof was created (and sent to the verifier).

However, verifiers need to have this assurance for the time at which the data in the credential is actually used. The time between the creation of the proof and the use of the data in the credential may be very short, but it may also be very long: days, weeks or even longer.

Here is an example. Consider the situation where Alice needs a permit to park in the street where she lives, and she decides to file an online application form on friday afternoon at 16:47 pm. She provides her credentials, which contain claims about the car she owns (licenseplate), that she has a valid driving license, that she lives near the place where she wants to park, etc. Also, she provides the necessary proofs of non-revocation. Civil servants don’t work in the weekends, so decision making is deferred to at least Monday morning, after coffee. During the weekend, Alice may be caught speeding which causes her driving license to be revoked, or she can sell her car causing her car-ownership credential to be revoked. After the weekend, the civil servant that decides on her application cannot tell whether or not any of these events occurred.

Use-cases such as these call for a new or updated revocation mechanism that allows verifiers to check whether or not a credential it has received, has been revoked at any point in time after having received it.

Having such a revocation mechanism has various other benefits. For example, it would allow the organization that issues parking permits to check every now and then whether or not the permits it has issued need to be revoked because one of the premisses on which it was issued has been rendered invalid (expired and/or revoked). This also allows (parking permit) issuers to issue credentials (permits) that need not be renewed every year (which often means that the applicant needs to reapply every year); it suffices to regularly check for expiration and non-revocation of the credentials that underpin the issuing decision, thus saving a lot of bureaucracy.


The challenge with that requirement as stated (verifier checks revocation without prover involvement) is doing it in a way that (a) does not require going back to the issuer to ask, and (b) does not make it so that verifiers can correlate the prover. That’s a hard problem.

One way we’ve thought about doing this is a feature in the agents that enable automatically responding to proof requests without notifying the user. E.g. the user says to it’s own agent “If you get asked by this verifier to prove this again, go ahead and don’t ask me”. The user can from time to check that they have done that and remove the authorization. They can also check to see how often the verifier has asked.

That approach automates the interaction, but keeps the Prover-Verifier model in place. It is a pretty classic security vs. user experience tradeoff, giving the user the choice of how to handle it.


I like the property of the prover remains in control. However, I also think such an approach would not work in practice, because it requires provers to organize that they have at least one agent that is always online (my phone sure isn’t) and that this agent is capable of/assigned to participate in that process. No problem for technology savvy users, but for many other’s that’s not going to work.

Would it not be possible to enhance the proving mechanism itself? I was thinking that since in the current setup, the issuer can disable the capability of provers to construct proofs for verifiers, why not modify the mechanism such that provers can disable the capability of verifiers to verify proofs? I’m not a cryptomagician, but I guess there are some out there that can find ways to do this.