-
Notifications
You must be signed in to change notification settings - Fork 516
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ACA-Py Admin endpoint for revoking a credential #428
Comments
I can take this on later this week. It may prove more involved than meets the eye: how to distinguish between many credentials on the same attribute values? Keeping too much info can wreck the design intent of holders holding and issuers issuing. |
@sklump, @andrewwhitehead - the other objects on the ledger (DIDs, schema, cred def) have an ACA-Py admin endpoint that is "list the entities created on put on the ledger" that takes no arguments and returns a full list. Should there be an endpoint like that for Revocation Regs? I'm not sure there should, I was just noticing that when playing with the OpenAPI. It's easy to just get a CredDefId and use the endpoint for the list of RevRegs by CredDef. What do you think? |
I can write this up and submit it for review and we can decide then. |
#461 provides. I think it's a good addition: the search can specify states too, in case an operator needs to audit full rev regs, canvass active rev regs etc. |
The initial implementation of the revocation in ACA-Py is that the to revoke a credential, the controller invokes this endpoint:
/issue-credential/records/{cred_ex_id}/revoke
. Given the credential exchange ID, the necessary data to revoke a credential (the rev_reg_id and the cred_revoc_id) can be collected and the revocation executed.However, in "normal" operation of an ACA-Py wallet, the credential exchange record is deleted upon completion of the protocol execution (there is a start option to change that behaviour). In any high volume issuer, deleting the exchange records will almost certainly be the case. As such, getting the data elements for the revocation should by default assume to come from the controller, saved off by the controller at the time the credential was issued.
Please create a new endpoint that takes from the controller the rev_reg_id and cred_revoc_id for the specific credential to be revoked. Presumably, it would be just
POST issue-credential/records/revoke
(perhaps withoutrecords
?) with a data structure passed with the necessary fields for revocation.I would think that unless the app is started with the option to keep credential exchange records (
--preserve-exchange-records
), the existing option should not be available. The new option should be available in either case.The text was updated successfully, but these errors were encountered: