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

Revocation List Model #37

Merged
merged 6 commits into from
Jan 9, 2023

Conversation

whalelephant
Copy link
Contributor

@whalelephant whalelephant commented Dec 27, 2022

This is the first PR introducing RevocationList model outlined in hyperledger/anoncreds-spec#108 and #24.

  • introduce RevocationList struct with serde to match outlined json, with tests
  • update create_or_update_revocation_state function for prover and FFI. This now takes in either 1 RevocationList to create or optionally an old one, does a comparison and update the revocation state.
  • initial end to end test in anoncreds_demo

Additional documentation is added to highlight the unchecked interval, which I am looking into for #36 and #41

@whalelephant whalelephant force-pushed the feat/revocation-list branch 8 times, most recently from 629ba44 to b16c197 Compare January 3, 2023 09:41
@whalelephant whalelephant changed the title wip: draft create_or_update_rev_state Revocation List Model Jan 3, 2023
@whalelephant whalelephant marked this pull request as ready for review January 3, 2023 14:18
@whalelephant
Copy link
Contributor Author

whalelephant commented Jan 5, 2023

Hey @TimoGlastra actually, I have just checked the specs on your PR
https://github.com/hyperledger/anoncreds-spec/pull/125/files#diff-16b69490a805effe319857540a2709114190895ffc75700d9776487de9ca5e2bR602

Are these the field names that should be used instead? If so I will need to update this PR.

Copy link
Member

@TimoGlastra TimoGlastra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think overall this looks good to me, but I would like @blu3beri to also take a close look at this PR

@TimoGlastra
Copy link
Member

Are these the field names that should be used instead? If so I will need to update this PR.

I think the only difference is the currentAccumulator field right?

@whalelephant
Copy link
Contributor Author

I think the only difference is the currentAccumulator field right?

yep, but that struct serialisation is done in Ursa.

Copy link
Contributor

@berendsliedrecht berendsliedrecht left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just some small cleanup thingies, nothing major. Also not too familiar with the revocation changes, but I think combined with @TimoGlastra we have a full code and spec review :).

self.revocation_list.clone()
}

pub fn new(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: I prefer to use try_new when it returns a Result<T>. A bit more explicit for the caller.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Following the pattern in impl_anoncreds_object_identifier for new() here, I don't mind either way but we might want to align similar methods?
@blu3beri

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah we can just keep it at new. Consistency is more important IMO.

Comment on lines 109 to 112
let e = match *element.as_ref() {
true => 1,
false => 0,
};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
let e = match *element.as_ref() {
true => 1,
false => 0,
};
let e = element as i32;

Not 100% sure what e is supposed to be. But casting to a number will convert it to 0/1.

Comment on lines 127 to 129
fn expecting(&self, formatter: &mut std::fmt::Formatter) -> std::fmt::Result {
formatter.write_str("a seq containing revoation state, i.e. [1, 0, 1]")
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
fn expecting(&self, formatter: &mut std::fmt::Formatter) -> std::fmt::Result {
formatter.write_str("a seq containing revoation state, i.e. [1, 0, 1]")
}
fn expecting(&self, formatter: &mut std::fmt::Formatter) -> std::fmt::Result {
write!(f, "a seq containing revoation state, i.e. [1, 0, 1]")
}

Do you know if there is a difference or will this only add string interpolation? Never used formatter.write_str like this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

anoncreds/src/data_types/anoncreds/rev_reg.rs Show resolved Hide resolved
Comment on lines 304 to 309
IssuanceType::ISSUANCE_ON_DEMAND => {
bitvec![1; list_size]
}
IssuanceType::ISSUANCE_BY_DEFAULT => {
bitvec![0; list_size]
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might be good to implement Into<u8> for IssuanceType to do the conversion to 1 or 0 there.


Ok(CredentialRevocationState {
witness,
rev_reg: CryptoRevocationRegistry::from(rev_reg_delta.value.clone()),
timestamp,
rev_reg: rev_reg_list.into(),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we not change the type of the state to contain just the rev_reg_list? Now we have the timestamp in there twice.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The rev_reg_list is of type RevocationList which fields such as the revocation_list which is not needed.
CredentialRevocationState does not contain RevocationList so the timestamp is only there once.

@TimoGlastra
Copy link
Member

yep, but that struct serialisation is done in Ursa.

Ah okay, would it be easy to just assign it to a different key? (that's what I would do in JS, but rust is different lol)

@whalelephant
Copy link
Contributor Author

@TimoGlastra ,
we do not have direct access to the underlying accum value because it is a private field in the RevocationRegistry struct managed by Ursa, so the serde is also handled there as well.
@blu3beri if you have any ideas?

@whalelephant whalelephant requested review from berendsliedrecht and TimoGlastra and removed request for berendsliedrecht and TimoGlastra January 5, 2023 10:22
@berendsliedrecht
Copy link
Contributor

@TimoGlastra ,
we do not have direct access to the underlying accum value because it is a private field in the RevocationRegistry struct managed by Ursa, so the serde is also handled there as well.
@blu3beri if you have any ideas?

We can create PRs for Ursa with the fixes, but creating a new release would be rather difficult as the pipeline is kind of dead. We can use a git within cargo, but that is a bit nasty.

@TimoGlastra
Copy link
Member

But as the accum is just a property, isn't there a way to just pick the accum key from object a and place it as key currentAccumulator in object b? It sounds like that should be possible?

@whalelephant
Copy link
Contributor Author

whalelephant commented Jan 6, 2023

Because the Struct RevocationRegisty did not specify the field accum is public, we cannot access it.

What we could do is to serialise the struct into string, deserialise into another struct that we have in this repo from string and make that field public. thoughts?

@TimoGlastra
Copy link
Member

What we could do is to serialise the struct into string, deserialise into another struct that we have in this repo from string and make that field public. thoughts?

That sounds fine to me 👍

@whalelephant
Copy link
Contributor Author

What we could do is to serialise the struct into string, deserialise into another struct that we have in this repo from string and make that field public. thoughts?

@TimoGlastra actually we cannot construct RevocationRegisty in anoncreds-rs which is needed for Ursa because it does not provide a public constructor either. So I think if we want to rename the field we might be back to forking the repo as @blu3beri mentioned.

@TimoGlastra
Copy link
Member

Hmm ok. Let's keep it at accum for now and get this PR merged. Can you create a new issue to track this. We might just use accum, or we might find a way to use currentAccumulator.

@whalelephant any other outstanding things, or can the PR be merged?

@whalelephant
Copy link
Contributor Author

whalelephant commented Jan 9, 2023

Can merge I think, issue at #51

@TimoGlastra TimoGlastra merged commit b99a7ee into hyperledger:main Jan 9, 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

Successfully merging this pull request may close these issues.

3 participants