hyperledger-archives / indy-sdk

indy-sdk
https://wiki.hyperledger.org/display/indy
Apache License 2.0
666 stars 737 forks source link

Revoked credentials pass in c# wrappers verifier verify proof function #2558

Closed erenakyildiz-code closed 6 months ago

erenakyildiz-code commented 1 year ago

Hello,

I am currently working on an application that uses revocation functionality of indy-sdk,

Currently my ledger shows that a credential has been revoked by the issuer, but the c# client can still verify the proof of this revoked credential.

The function I am using is AnonCreds.VerifierVerifyProofAsync() from the c# wrapper.

The last 2 transactions on my ledger are attached OUTPUT.txt (output of ./read_ledger --type domain)

If you require more information to fix this issue, please contact me, this is my 2. issue on github.

joyride9999 commented 1 year ago

do you pass a timestamp for getting the objects needed for verification? I guess timestamp should be now() to unix timestamp format!

erenakyildiz-code commented 1 year ago

The timestamp of all operations are same as the ledgers revocation txnTime on the latest revRegEntry transaction, in the gettingstarted.py example the same operation with the same timestamp (ledger's revocation entry timestamp) is done, and the credential can not be verified.

I am attaching 2 files, one containing the C# Anoncreds.VerifierVerifyProofAsync() functions parameters that does not work, and one file that contains the gettingstarted.py's anoncreds.verifier_verify_proof() parameters that works.

Revocation transaction txnTime for gettingstarted.py : 1675350999 INPUTOFPY.txt Revocation transaction txnTime for c# application : 1675348913 INPUTOFC#.txt

erenakyildiz-code commented 1 year ago

Hello,

I have now tested my inputs on both python and C#, the inputs do give correct outputs (false) in python for both input files I had attached on my latest comment, and on C# both revoked credentials pass the verifierVerifyProof() as true even though they are revoked, as I understand this is certainly a problem with the C# wrapper.