Add support for revocation
esune opened this issue · comments
As part of extending the support of Issuer Kit to more use-cases, we need to enable administrators to issue credentials that support revocation, and make it easy to revoke them.
Requirements:
- add support for revocation when defining a new schema
- starting with aca-py 0.5.4 revocation registries will be managed automatically by the agent without needing special controller logic
- for revocable credentials, add a "revoke" button in the admin dashboard to issue the revocation command
- update the record stored in the controller to include information about the type of credential issued, specifically whether it can be revoked or not
- once revoked, a flag should be set on the record in the controller
@swcurran I am refactoring the code of the api/controller to support issuing both revocable and non-revocable credentials at the same time. One of the things I am facing is that - in theory - the same schema can back both revocable and non-revocable credential definitions.
In order to simplify things a bit I am leaning towards supporting (at least for the time being) only one cred_def per schema for each issuer instance: is this be acceptable, or we must support both scenarios using the same controller?
It has to be for the short term only -- e.g. a phase one of two. The desire is to reduce complexity by encouraging the use of common schema as much as possible so that it is easier for verifiers. For example, we want all jurisdictions in Canada to use the same "Verified Person" schema, varying only on the issuer.
Yes, that is already supported: they will define a schema_id in the configuration, rather than using name, version and attributes.
What I meant is having the same issuer (e.g.: British Columbia) issuing credentials backed by the same schema definition, but using different credential definitions (one supporting revocation, one not supporting it).
I think it is a bit of an edge case, but I may have found a solution - I will otherwise log an item in the backlog.
Ah...OK - that's fine. Thanks for the clarification.
Implemented in #219