Aca-py not recording revoked status correctly

[ianco]

Aca-py no longer records the internal credential "revoked" state correctly.

Steps to reproduce:

• run local von-network and tails server
• start faber ./run_demo faber --revocation
• start alice ./run_demo alice
• accept invitation in alice agent
• issue credential(s) from faber to alice
• revoke a credential
• check credential status using GET http://localhost:8021/api/doc#/revocation/<rev_reg_id>/issued/details

Expected - revoked credential will have revoked state
Actual - still in issued state

This breaks the new "revocation fix" endpoints

Also see integration tests @T002-TAA and @T003-TAA which fail against the latest release

e.g. run von-network as ./manage start --taa-sample --logs and then ./run_bdd -t @T002-TAA

[swcurran]

@ianco , some questions.

First, can you tell when this change was made? Was it part of 0.7.4?

Second, it should (at least in some/most cases) be the controller that tracks the revocations. I assume we’ll need too provide a way to support a fix for that model, right? Where we have to rationalize the controller set of revocations with the ledger set?

@andrewwhitehead - can you please look at this as a top priority?

[ianco]

First, can you tell when this change was made? Was it part of 0.7.4?

This changed in this PR: #1804 (I tested an early version of the PR and it worked ok so these was a change later on that broke this feature)

Second, it should (at least in some/most cases) be the controller that tracks the revocations. I assume we’ll need too provide a way to support a fix for that model, right? Where we have to rationalize the controller set of revocations with the ledger set?

Yes we should rationalize these calls. Right now the revocation status is tracked in both the indy-sdk wallet records as well as aca-py (as well the controller needs to track issue and revocation status vs its own "business" database). aca-py needs enough information to be able to verify the wallet/ledger consistency (unless we want to push this down to the controller as well).

[swcurran]

I'm wondering if we should be tracking revocation status in the RevReg object in ACA-Py. If the credential object has been removed, we still need a way to batch update the RevReg, so I think this might be necessary. For example, could we have arrays pending_activation and pending_revocation that get added to when a credential is activated/revoked, and on successful publication, we move those to IDs to activated and revoked arrays, respectively.

[swcurran]

@andrewwhitehead -- can you please take a look at #1804 again to see how it impacted this? Good to get RC4 or the final 0.7.4 out sooner than later.