fix: report presentation result

[dbluhm]

This PR ensures that the result of verifying the presentation for JSON-LD Credentials is factored into the final verified status.

cc @andrewwhitehead @swcurran

[dbluhm]

I'm expecting the integration tests to fail; I believe the challenge was not being correctly used by the holder side of the exchange previously. I will monitor and address this.

[dbluhm]

Once this PR is ready (pending a couple more anticipated fixes to get the integration tests failing/succeeding as expected), I will prepare a backport for 0.10.x.

[dbluhm]

Well shoot, tests passed... I'll look into this

[dbluhm]

The reason the tests passed when I expected them to fail was the testing I was performing outside of the integration tests happened to hit a slightly different path.

Where the integration tests call the send-presentation endpoint with a request body like the following:

{'dif': {'record_ids': {'citizenship_input_1': ['c02fc3be1ec74cb58d9c54f451caa2d2']}}}

My testing scenario was using:

{
  "dif": {
    "presentation_definition": {
      "format": {
        "ldp_vp": {
          "proof_type": [
            "BbsBlsSignature2020"
          ]
        }
      },
      "id": "461937c8-d69d-4f5b-9c39-dfa8d9622ea4",
      "input_descriptors": [
        {
          "constraints": {
            "fields": [
              {
                "id": "1f44d55f-f161-4938-a659-f8026467f126",
                "path": [
                  "$.credentialSubject.clearance"
                ],
                "purpose": "Get clearance"
              }
            ],
            "is_holder": [
              {
                "directive": "required",
                "field_id": [
                  "1f44d55f-f161-4938-a659-f8026467f126"
                ]
              }
            ],
            "limit_disclosure": "required"
          },
          "id": "building_access_1",
          "name": "BuildingAccess",
          "schema": [
            {
              "uri": "https://www.w3.org/2018/credentials#VerifiableCredential"
            },
            {
              "uri": "https://example.com/examples#Employment"
            }
          ]
        }
      ]
    }
  }
}

This resulted in hitting a buggy branch in the create_pres method of the dif format handler which caused the generated presentation to be based off of a newly generated random challenge instead of the one sent in the request. This behavior is what I witnessed that alerted me to this issue; even while the challenge was different, the presentation.verified was set to true. In my testing, the fixes in this PR caused the verified status to correctly come back as false and then the small correction I made to the create_pres handler fixed the other issue of using a bad challenge nonce.

I think the changes of this PR should stop here; however, the integration tests for JSON-LD creds are insufficient to get good coverage of the handler code. We should flesh out the JSON-LD tests further.

[dbluhm]

I need to revert my "fix" for the integration test "then" step. Turns out the verification was being performed elsewhere.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[dbluhm]

@swcurran this PR is ready for review

[swcurran]

@andrewwhitehead — could you please look at this? I think it looks good, but you should verify.

@esune — you could look as well, as it doesn’t need a lot of context to review.

@ianco — I originally tagged you to review, but removed — you have too much to do. :-)

[esune]

Changes look good to me 👍🏻

[swcurran]

LGTM and @esune

[dbluhm]

I'll prepare a backport to 0.10.x and will make some noise when it's ready