Problem with verify-presentation

[krzosa]

Hello, I have been battling the present-proof protocol for some time now and I finally nailed the schema down to this simple form which passes the request proof and present proof but I can't pass the verification phase to fully complete the proof exchange because of a CommonInvalidStructure error, could someone perhaps help me out here? I'm not sure exactly how to structure the schema in order to pass the verification.

Acapy version: 0.5.4

Request:

{
  "proof_request": {
    "version": "1.0",
    "name": "Proof request",
    "requested_attributes": {
      "data_dri": {
        "non_revoked": {
          "from": 1500000000,
          "to": 1800758817
        },
        "restrictions": [
          {
            "cred_def_id": 12345,
          }
        ],
        "name": "data_dri"
      },
    },
    "requested_predicates": {
    }
  },
  "connection_id": 12345,
}

Send Presentation:

{
  "requested_attributes": {
    "data_dri": {
      "cred_id": 12345,
        "revealed": True
    },
  },
   "requested_predicates": {
  },
  "self_attested_attributes": {

  }
}

Error:

agent2.localhost_1   | 2020-09-24 11:32:25,024 indy.libindy DEBUG _get_error_details: >>>
agent2.localhost_1   | 2020-09-24 11:32:25,025 indy.libindy DEBUG _get_error_details: <<< error_details: {'backtrace': '', 'message': 'Error: Invalid structure\n'}
agent2.localhost_1   | 2020-09-24 11:32:25,025 indy.libindy DEBUG _indy_callback: >>> command_handle: 87, err , args: (False,)
agent2.localhost_1   | 2020-09-24 11:32:25,025 indy.libindy DEBUG _indy_callback: <<<
agent2.localhost_1   | 2020-09-24 11:32:25,025 indy.libindy DEBUG _indy_loop_callback: >>> command_handle: 87, err , args: (False,)
agent2.localhost_1   | 2020-09-24 11:32:25,025 indy.libindy WARNING _indy_loop_callback: Function returned error 
agent2.localhost_1   | 2020-09-24 11:32:25,025 indy.libindy DEBUG _indy_loop_callback <<<
agent2.localhost_1   | 2020-09-24 11:32:25,025 aries_cloudagent.verifier.indy ERROR Validation of presentation on nonce=1109036237540744595954642 failed with error
agent2.localhost_1   | Traceback (most recent call last):
agent2.localhost_1   |   File "/home/indy/aries_cloudagent/verifier/indy.py", line 211, in verify_presentation
agent2.localhost_1   |     json.dumps(rev_reg_entries),
agent2.localhost_1   |   File "/home/indy/.pyenv/versions/3.6.9/lib/python3.6/site-packages/indy/anoncreds.py", line 1705, in verifier_verify_proof
agent2.localhost_1   |     verifier_verify_proof.cb)
agent2.localhost_1   | indy.error.CommonInvalidStructure

[sklump]

The cred def id should look something like

WgWxqztrNooG92RXvxSTWv:3:CL:20:tag

i.e.,

• issuer DID
• colon (delimiter)
• 3 (marks a cred def id)
• colon (delimiter)
• CL (identifies signature type)
• colon (delimiter)
• a positive integer (identifying, by sequence number, the ledger transaction with the schema id)
• colon (delimiter)
• a tag (typically for aca-py, a UUID4).

The cred def id is the template on which the issuer issues credentials; it links the issuer (by public DID) to the schema as the schema-issuer registers on the ledger.

[krzosa]

Hi, sorry for being a bit lazy there, here is the schema I would actually send (without the simplified ids) using the request endpoint:

{
  "proof_request": {
    "version": "1.0",
    "name": "Proof request",
    "requested_attributes": {
      "data_dri": {
        "non_revoked": {
          "from_epoch": 1500000000,
          "to_epoch": 1700758817
        },
        "restrictions": [
          {
            "cred_def_id": "X4agLLcTnLMT1bRnmb64Xj:3:CL:1249:consent_schema",
          }
        ],
        "name": "data_dri"
      },
    },
    "requested_predicates": {
    }
  },
  "connection_id": "255742b3-711f-4c9a-95fd-ed70950b4caf",
  "comment": "string",
  "nonce": "1234567890"
}

[sklump]

Could you kindly post the credential from the holder's wallet that you expect to find? E.g., via GET ​/credentials against holder agent's admin API

[sklump]

... also, I see that the nonce is outside the proof request here: that's wrong

[sklump]

... furthermore, "from_epoch" and "to_epoch" should be "from" and "to".

Moreover, JSON is not forgiving of trailing commas as per

"cred_def_id": "X4agLLcTnLMT1bRnmb64Xj:3:CL:1249:consent_schema",

and the last trailing comma on line 17 after the closing brace for "data_dri".

I advise you to put your JSON into a JSON formatter as per https://jsonformatter.org/ to make sure it's not hopeless.

[krzosa]

GET /credentials

{'results': [{'attrs': {'data_dri': 'zQmPsU57nqWY8jzndU9AE2RK4EXvjMLGmytVpUNxfRpm18G',
                        'oca_schema_dri': 'fArVHJTQSKHu2CeXJocQmH3HHxzZXsuQD7kzyHJhQ49s',
                        'oca_schema_namespace': 'consent'},
              'cred_def_id': 'CdgEtEDKxER8cPgtnrx6rM:3:CL:1279:consent_schema',
              'cred_rev_id': None,
              'referent': '836ab1f4-5d72-439a-9542-e16ea3d2c712',
              'rev_reg_id': None,
              'schema_id': 'CdgEtEDKxER8cPgtnrx6rM:2:consent_schema:1.0'}]}

Sorry I have 2 versions of acapy (0.5.14 and 0.5.1) and I mispasted the proper version of send request, I'm also not filling the nonce field here:

{
  "proof_request": {
    "version": "1.0",
    "name": "Proof request",
    "requested_attributes": {
      "data_dri": {
        "non_revoked": {
          "from": 1500000000,
          "to": 1800758817
        },
        "restrictions": [
          {
            "cred_def_id": "X4agLLcTnLMT1bRnmb64Xj:3:CL:1249:consent_schema",
          }
        ],
        "name": "data_dri"
      },
    },
    "requested_predicates": {
    }
  },
  "connection_id": "255742b3-711f-4c9a-95fd-ed70950b4caf",
}

Json formatting seems to be okay, it doesn't complain about it, I battled the formatting for some time and I think it's okay now, after all I would assume that would get caught on the "send request" stage not on the "verify" stage or am I wrong here? Also the code I pasted is a python dictionary that goes through a python json formatter so it should theoretically be standard compliant.

[sklump]

Try with current master. The problem here is that a requested attribute specifies a non-revocation interval but the credential is not revocable. Current master adjusts proof requests accordingly just prior to verification when the selected credentials are non-revocable.

[krzosa]

Thanks a lot for help, I managed to get through the verification phase on the v0.5.4 by removing the said non_revocation interval and adding the nonce field:

{
  "proof_request": {
    "version": "1.0",
    "name": "Proof request",
    "requested_attributes": {
      "data_dri": {
        "restrictions": [
          {
            "cred_def_id": credentials['results'][0]['cred_def_id'],
          }
        ],
        "name": "data_dri"
      },
    },
    "requested_predicates": {
    },
    "nonce": "12345"
  },
  "connection_id": connection[1],
}

Sadly for now I can't test the master cause it breaks my test plugin and I will have to update it, but again thanks a lot for help. :+1:

[swcurran]

Sounds good - closing.