Problem

When using the Prover handler to create a presentation for a verifier, lots of calls are made to assemble the data that is ultimately passed into the BaseAnonCreds::prover_create_proof method. generate_indy_proof does most of this data construction.

Part of the data construction for data that prover_create_proof needs, is the revoc_states_json. Where generate_indy_proof assembles revoc_states_json as a JSON string of:

Map<String(rev_reg_id), Map<String(timestamp), String(anoncreds_revocation_state_json)>>

So it's "revocation_state by timestamp by the revocation_registry_id".

The problem with this is that if we want to create a proof (non-revokable proof), for say "reft-A & reft-B", and we use "cred-1" for "reft-A" and "cred-2" for "reft-B", and "cred1" & "cred2" are from the same revocation_registry_id "rev-reg-1", then only 1 revocation state is created for "rev-reg-1" (since revocation_registry_id is the unique key in the revoc_states map). And therefore, prover_create_proof only creates a proof of the revocation state for 1 of the credentials..

Potential Solution

Part of the problem is that Anoncreds::prover_create_proof does not specify in its documentation what it expects the revoc_states_json String to be shaped as. But drilling down into the Indy/vdrtools implementation of prover_create_proof, they appear to have solved this problem by defining revoc_states_json as follows:

    /// rev_states_json: all revocation states participating in the proof request
    ///     {
    ///         "rev_reg_def1_id or credential_1_id": {
    ///             "timestamp1": <rev_state1>,
    ///             "timestamp2": <rev_state2>,
    ///         },
    ///         "rev_reg_def2_id or credential_1_id"": {
    ///             "timestamp3": <rev_state3>
    ///         },
    ///         "rev_reg_def3_id or credential_1_id"": {
    ///             "timestamp4": <rev_state4>
    ///         },
    ///     }

The big difference is that this structure's map uses String(rev_reg_id OR cred_id) as the first key, rather than JUST rev_reg_id. Using cred_id as the key fixes the use-case I described above, and is in-general less restrictive I believe.

So we could potentially solve this by:

better define the input for prover_create_proof (at least with documentation)
have generate_indy_proof create the revoc_states_json using cred_id as the key (cred_info.referent I believe)
update CredxAnonCreds implementation to support the new revoc_states_json structure (where rev_reg_id OR cred_id can be the key).

hyperledger / aries-vcx

Cannot create a revocation proof with two credentials with the same revocation registry ID #834

Problem

Potential Solution

Other Problems