Closed paulfdietrich closed 9 months ago
Yea, we have heard the requirement about revocation time before... You need a separate credential to communicate that kind of thing.
Afaik there is no planned support for "revoked at this time for these reasons" in the current spec... There are privacy issues with this.
As @OR13 stated above, the privacy ramifications alone create concerns that probably cannot be overcome in the current VCWG.
We don't seem to have any implementers that have committed to implementing a feature like this since this issue was created (22 months ago). Until we have a few implementations that have been experimenting with approaches to addressing this issue, attempting to standardize it now is probably premature.
There are at least two approaches that could work:
I'm marking this as "pending close" as it is unlikely to be addressed in this iteration of the specification.
I've been talking to partners about revocations and their requirements. I think this represents a new requirement that isn't covered in the specification, so I wanted to raise it here for discussion.
There is a use case where the party holds a credential and wants to re-verify it (since it could be revoked) upon request from a user. But they want to correlate that revocation time to business processes around the credential. (sorry a bit vague but trying to protect the use case).
So they asked how they can find out the revocation status of a credential at a certain date and time or better yet, find the time/date of the revocation or suspension event by the issuer.
A few ways we though of:
If they are aware of that time they could ask for a StatusList2021Credential at that time and keep it with the credential. This may or may not be possible and the storage of these may be problematic and puts the burden on the verifier.
A query parameter could be added to the Get request for the StatusList2021Credential to query it based on a timestamp. This would allow the caller to know at any specific time whether it was revoked, but would not allow them to find out when it was revoked without some trial and error. The burden would be on the issuer (rightly so) to keep all the old copies of this (or to generate one on the fly) with this information.
A new format for a StatusList could include a date rather than just a bit, but of course this has some significant size ramifications that may affect the size and anonymity.
A resurface of a 2017CredentialStatusList-like implementation with an appropriate timestamp attached to the "claim". Of course this would have anonymity concerns.
Other ideas please!!
I wonder if the draft here could provide any guidance or tradeoffs or maybe even some standard language on appropriate ways to do this.