AnonCreds Revocation List Model

[TimoGlastra]

Issue to discuss the data model for the AnonCreds revocation list. This is based on what I've presented in a previous AnonCreds Spec meeting, and is also what we're now targeting for the implementation in AFJ/ACA-Py/AnonCreds-Rs.

Here's the data model:

{
  "revRegId": "<revocRegId",
  "revocationList": [0, 1, 1, 1, 1, 1, 0],
  "currentAccumulator": "<current accumulator value>",
  "timestamp": <timestamp-number>
}

• revRegId (string) - Identifier of the revocation registry
• revocationList (number[]) - Bit array defining the status of the credential in the revocation registry. A value of 1 means the credential is revoked, a value of 0 means the credential is not revoked.
• currentAccumulator - The current value of the accumulator
• timestamp - the timestamp at which the accumulator value is valid

This is using camelCase. I know in the spec we've been moving to snake_case, but the current AnonCreds implementation uses camelCase, so maybe it's better to keep it like that. Anyway, snake_case or camelCase the data is the same.

An example:

{
  "revRegId": "4xE68b6S5VRFrKMMG1U95M:4:4xE68b6S5VRFrKMMG1U95M:3:CL:59232:default:CL_ACCUM:4ae1cc6c-f6bd-486c-8057-88f2ce74e960",
  "revocationList": [0,1,1,0,0,1,1,0,0,0,1,0,0,1,1,0,1,1,0,1,1,0,0,1,0,1,0,1,1,0,1,0,1,1,0,1,0,1,1,0,0,1,0,1,0,0,1,1,1,0,0,0,0,0,1,0,0,1,1,0,1,0,0,0,0,1,1,1,1,0,1,0,0,0,0,0,1,0,0,1,0,0,1,0,1,0,0,1,0,0,0,1,0,0,1,0,1,1,0,0,1,1,0,0,0,0,1,1,0,0,0,0,0,1,1,0,0,1,0,0,1,0,0,0,1,1,0,0,1,1,0,0,1,1,1,0,0,1,0,1,1,0,0,0,1,0,1,0,0,0,0,1,0,0,1,1,0,1,1,0,0,0,1,0,0,0,1,1,1,1,1,1,1,0,0,1,1,1,1,0,1,0,1,1,0,1,0,0,0,1,1,1,1,0,0,1,0,1,1,1,1,1,1,1,1,1,0,0,1,0,1,1,1,1,1,0,1,0,0,1,1,1,0,0,1,0,1,1,1,0,1,1,0,0,0,1,1,0,0,0,1,1,0,0,0,0,0,1,1,0,0,0,0,1,1,1,1,0,1,0,0,0,1,0,1,1,1,0,0,0,0,0,0,1,1,0,1,0,0,1,1,1,1,1,0,1,0,1,0,0,1,0,0,1,0,0,1,0,1,1,1,1,1,1,0,0,0,1,0,0,0,0,1,0,1,0,1,0,0,0,1,0,1,0,0,1,0,1,0,1,1,1,1,1,0,1,1,1,1,0,1,1,0,0,0,0,0,0,0,1,1,1,1,1,1,1,0,0,1,1,0,0,1,1,1,1,0,1,0,0,0,0,0,0,0,1,0,0,0,0,1,1,1,0,0,0,1,1,1,1,1,0,0,0,0,1,0,1,0,0,1,0,1,1,1,1,1,0,0,1,0,1,1,0,0,0,1,1,1,1,1,1,1,0,0,1,1,0,1,1,1,0,0,0,0,1,0,1,0,1,1,1,0,0,1,0,0,0,1,1,0,1,1,0,1,1,1,0,1,0,1,1,1,0,1,1,1,0,1,0,0,1,1,1,0,1,0,1,0,0,0,1,0,1,1,0,0,1,0,0,1,1,0,0,1,1,1,0,0,1,0,1,0,1,0,0,0,1,1,0,0,0,1,1,1,0,1,1,1,0,0,1,1,0,1,1,0,1,0,1,0,1,0,1,1,0,0,1,0,1,0,0,1,0,0,0,0,0,0,1,0,0,1,0,1,1,0,0,1,0,1,1,1,0,0,0,1,1,0,0,0,1,0,0,0,1,1,1,1,1,1,1,1,1,1,1,1,1,0,0,0,0,1,1,0,0,0,0,0,1,1,0,1,0,1,0,0,0,0,0,1,0,0,1,1,1,0,0,0,1,0,1,1,0,1,1,0,0,1,1,1,1,1,1,0,0,0,1,1,0,0,0,0,0,0,0,0,1,0,1,0,0,1,0,1,1,1,0,1,0,0,0,0,0,1,1,1,1,1,1,1,0,0,1,0,0,0,1,1,0,1,1,0,0,0,1,1,0,0,1,1,1,1,0,0,0,0,1,0,1,0,1,0,1,0,0,0,0,1,0,1,0,0,0,0,1,0,0,1,1,1,0,0,0,1,0,0,1,1,1,0,1,1,1,1,1,1,1,0,1,1,1,1,1,1,1,1,0,0,0,0,1,0,1,1,1,0,1,0,0,1,0,0,1,1,1,0,0,0,1,0,1,0,0,1,0,0,1,0,1,1,0,1,1,0,1,0,1,0,1,0,1,1,1,0,0,0,0,1,0,1,0,1,0,1,0,1,0,0,1,0,1,0,0,0,0,0,0,1,1,0,0,1,0,1,1,0,0,1,0,0,1,1,0,0,1,1,0,0,0,1,0,0,0,1,0,1,0,1,0,0,1,1,0,1,0,1,0,1,0,0,1,0,0,0,1,0,0,0,1,0,1,0,0,1,0,0,1,0,0,0,0,0,0,0,0,1,1,1,0,0,1,1,1,1,0,1,0,1,0,1,0,0,0,1,1,1,1,0,1,0,0,0,1,0,0,1,0,0,0,1,1,0,0,1,1,1,0,0,0,0,1,1,1,0,0,0,1,1,0,1,1,1,0,1,0,0,0,0,1,0,0,0,1,1,0,1,0,1,0,1,1,1,1,1,1,0,0,0,1,1,1,0,0,0,0,0,0,1,0,0,1,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,1],
  "currentAccumulator": "21 124C594B6B20E41B681E92B2C43FD165EA9E68BC3C9D63A82C8893124983CAE94 21 124C5341937827427B0A3A32113BD5E64FB7AB39BD3E5ABDD7970874501CA4897 6 5438CB6F442E2F807812FD9DC0C39AFF4A86B1E6766DBB5359E86A4D70401B0F 4 39D1CA5C4716FFC4FE0853C4FF7F081DFD8DF8D2C2CA79705211680AC77BF3A1 6 70504A5493F89C97C225B68310811A41AD9CD889301F238E93C95AD085E84191 4 39582252194D756D5D86D0EED02BF1B95CE12AED2FA5CD3C53260747D891993C",
  "timestamp": 1669640864487
}

[TimoGlastra]

@swcurran Could you bring this up during the AnonCreds WG tomorrow for discussion and feedback? 🙏

[whalelephant]

@TimoGlastra

Is the path to updating the witness from the prover's perspective, 1 query state at timestamp at issuance and time to update to; 2 locally calculate the delta for the update?

[swcurran]

My apologizes @TimoGlastra -- I think I missed your earlier note about raising this at a Meeting, or at least it didn't register. I'll try to get some conversation on this generated.

[swcurran]

@TimoGlastra -- should the tails file (path or binary) be included in that? The holder will need that in creating the NRP. Also, should the size of the RevReg (number of credentials) be included.

Would it make sense to make the state parameter a compressed bit array, perhaps use the Revocation List 2020 approach as found here? We could use a smaller minimum size than 16kb as that is impractical for the current revocation scheme. I would think it would be helpful for "full state" AnonCreds Methods and a bit of pain, but not too bad for "delta" based approaches.

[whalelephant]

@swcurran The tails file location and the number of credentials and other data are stored in Revocation Registry Definition. That can remain unchanged even as we implement this data model.

Regarding the compression, perhaps @TimoGlastra has better understanding. We do not know what format / data type the ledger will store this state in (whichever ledger), it might be that the ledger can store it even more efficiently, so perhaps it is best to let the ledger sdk handle such expansion directly.

[swcurran]

Thanks @whalelephant --

Agree on the tails file location and number of credentials in the RevRegDef.

We talked about the compression on the call. Basically, it has to be available expanded somewhere and adding compression would be worst case for some methods like Indy, where it would be expanded in the method, compressed to pass to AnonCreds and then immediately expanded again. No help :-). So we'll leave it as defined above by @TimoGlastra .