aries-cloudagent-python icon indicating copy to clipboard operation
aries-cloudagent-python copied to clipboard

txnTime check on AnonCredsVerifier.check_timestamps during revocation

Open dbluhm opened this issue 2 years ago • 1 comments

See: https://github.com/hyperledger/aries-cloudagent-python/blob/anoncreds-rs/aries_cloudagent/anoncreds/verifier.py#L160-L168

Discord Discussion:

dbluhm: Indy revocation registry definitions as retrieved from the ledger include a txnTime attribute that is currently getting used in validation of non-revocation timestamps in ACA-Py. If the timestamp for non-revocation predates the creation of the revocation registry definition, the presentation is rejected.

The generic anoncreds revocation registry definition object does not include a timestamp. We could return transaction time as a part of the metadata when retrieved from an anoncreds object registry but if we wanted to keep this check we would have to essentially require that all anoncreds methods return this metadata. This makes me wonder if it should just be a part of the object still. Thoughts?

swcurran: Is it useful? Can a RevRegEntry (state) predate a RevRegDef? That seems impossible. Maybe I need to review the spec. though...

dbluhm: If the timestamp predates the transaction for the rev reg def, the prover/verifier will attempt to find a revocation list for that time stamp and will get back nothing. The existing implementation doesn't account well for this possibility at the moment and fails while trying to extract data not present in the response.

Andrew Whitehead: It does seem a little too dependent on the publishing method

swcurran: Is there a "RevRegEntryId", or is the "RevRegEntry" identified by its TxnTime. Ultimately, that is what is needed -- the presentation must identify exactly the RevRegEntry (the state of the RevReg) used to generate the presentation.

dbluhm avatar Jul 31 '23 19:07 dbluhm

This seems like it could only ever happen in a test. The holder would get the txntime from the VDR when constructing the NRP. The verifier would get the txntime from the NRP, as set by the holder. The VDR would get the txntime from the ledger, which by definition would be later than the RevRegDef. I don’t see how this condition is possible. If we are just talking about a test, then the test is invalid.

swcurran avatar Aug 08 '23 13:08 swcurran