[Question] How to get revocation status list for a prover? about anoncreds-rs HOT 8 OPEN

This is the biggest change in the AnonCreds implementation between Credx (indy-shared-rs, indy-sdk) and AnonCreds Rust. As you note, in Indy, deltas are passed in, more or less directly as retrieved from the Indy Ledger. In AnonCreds Rust, the full state of the credentials (0/1 for the state of each credential in the registry) is passed in, and the client has to provide that state. For some ledgers, that is how the state is stored, in Indy, it has be updated based on the deltas from the ledger. revocation status list means that — the full state.

I’m not sure where best to see the data structures for what must be passed in — the updates to go from the Indy data to the full state. Not sure if others can help with that.

from anoncreds-rs.

I see. revocation status list is a new thing introduced by Anoncreds. Indy-sdk creates revocation state from revocation registry delta which can be retrieved from the indy ledger, while Anoncreds creates revocation state from revocation status list.

What's unclear is how a prover can get revocation status list. There should be some document about this.
Will the next version of indy-node provide this?

from anoncreds-rs.

I found this spec by searching this repo.
hyperledger/anoncreds-spec#108

I think there should be some guide on how to create revocation status list from revocation registry delta because indy-vdr does not provide revocation status list.

I found out that create_or_update_revocation_state() gets revocation status list and then changes it to revocation registry delta before creating revocation state. So, it will be possible to make another function that takes revocation registry delta as an argument. I think I can do this myself because I'm working with rust code for uniffi.

I'm still looking for other comments.

from anoncreds-rs.

Sorry for being slow to respond.

This is being done in Aries Framework JavaScript, so perhaps @berendsliedrecht or @genaris could describe how it is done/point out the code that does this. In AFJ, there is also code that retrieves revocation data from other ledgers (e.g., cheqd.io and Cardano) that store the full state of the revocation registry on the ledger rather than deltas. This is a much preferred approach, since it means that the ledger does not have to have special handling code to dynamically respond to requests -- the ledger just returns the transaction requested.

@andrewwhitehead -- would it make sense for Indy VDR to add a method (and for the proxy, an endpoint) that returns the revocation state? It could do that by having the caller pass in it's previous revocation state/time and update it, or (I suppose) could query Indy to request the delta from start of time. Or, I guess it would have to do both, as the first time it is called, the caller wouldn't have a previous state :-).

from anoncreds-rs.

This is the code in AFJ that does the transformation: https://github.com/hyperledger/aries-framework-javascript/blob/main/packages/indy-vdr/src/anoncreds/utils/transform.ts

from anoncreds-rs.

Thank you for the comments.

I found out that create_or_update_revocation_state() gets revocation status list and then changes it to revocation registry delta before creating revocation state. So, it will be possible to make another function that takes revocation registry delta as an argument. I think I can do this myself because I'm working with rust code for uniffi.

I've done this as follows though I've not tested yet:
https://github.com/hyperledger/aries-uniffi-wrappers/blob/main/anoncreds/src/uffi/prover.rs#L150

from anoncreds-rs.

So, it will be possible to make another function that takes revocation registry delta as an argument. I think I can do this myself because I'm working with rust code for uniffi.

Yes that should be possible. We deliberately chose to not add this as it is the old interface, and although it is still used internally, we didn't want to expose it.

I like the suggestion from @swcurran to add it to the indy-vdr library more, as it's indy that has a different data model as defined in the AnonCreds spec, not the other way around.

from anoncreds-rs.

I see. I agree it will be better if indy-vdr has a function to return a revocation state or a revocation status list.

from anoncreds-rs.