Skip to content
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

Cannot present same credential with different revocation timestamps (or lack thereof) #922

Open
gmulhearn-anonyome opened this issue Aug 4, 2023 · 1 comment

Comments

@gmulhearn-anonyome
Copy link
Contributor

Possibly relates to; #834. Or atleast it's in the same code area to be reworked.

Problem

Currently the implementation of build_rev_states_json in prover_internal.rs forces that the same cred used on multiple referents must present the exact same timestamp in it's NRP. E.g. if "referent1" is being presented for interval to: 10 and "referent2" for to: 20, then build_rev_states_json will force both to the same timestamp for presentation (10 or 20, depending on ordering).

Bigger Problem?

This problem is possibly bigger than the main problem, but heavily related. In build_rev_states_json it looks like any credential that is revocable, is forced into creating a NRP, even if the proof request did not request it... Testing this against ACA-py 0.8.2 results in a verification failure, with the following error: "VALUE_ERROR::Timestamp on sub-proof #0 is superfluous vs. requested attribute {referent-here}". We are creating a NRP that is not necessary, and ACA-py sees this as superfluous.

Expected Behaviour

@gmulhearn-anonyome
Copy link
Contributor Author

Happy to take this one on if we agree it is a problem; i think prover_internal may just need a fresh lookover

@gmulhearn-anonyome gmulhearn-anonyome changed the title Presenting same credential with different revocation timestamps (or lack thereof) Cannot present same credential with different revocation timestamps (or lack thereof) Aug 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant