User-specified proof requests

Edit online

By default, users must generate proofs based on the verifier-specified proof request. However, there can be situations where it is not feasible for the verifier to predefine the exact attributes or issuers to be used in the proof.

For example, consider an employer looking to hire the best candidate. The employer wants the candidates to provide proof based on their degrees and work experience. The employer cannot create a one-size-fits-all proof request, the employer allows candidates to determine which proofs best represent them.

To allow the candidate to specify their own proof request, the verifier must enable the allow_proof_request_override option in their request.

verifier1 creates a proof request by specifying the proof schema and version and allow_proof_request_override that allows user1 to override the suggested attributes and predicates:
curl --header 'Authorization: Bearer ${verifier_verifiable_credentials_access_token}' -X POST -d '{"to": {"name": "user1"}, "state": "outbound_proof_request", "proof_schema_id": "proof-schema1:1.0", "allow_proof_request_override": true}' --location 'https://${service_url}/v1.0/diagency/verifications -H 'Content-Type: application/json'
user1 views all proof requests or a specific proof request:
curl --header 'Authorization: Bearer ${user1_verifiable_credentials_access_token}' --location 'https://${service_url}/v1.0/diagency/verifications?state=inbound_proof_request
curl --header 'Authorization: Bearer ${user1_verifiable_credentials_access_token}' --location 'https://${service_url}/v1.0/diagency/verifications/<id>
Replace <id> with the actual id of the verification.

In either case, user1 views proof_request.requested_attributes and proof_request.requested_predicates.

Since verifier1 specified the allow_proof_request_override option, user1 can optionally specify the proof request from which the proof is generated. This overrides the proof request that is suggested by verifier1.

The following command demonstrates how to override the proof request and provide your own. Replace <id> with the actual id of the verification.
curl --header 'Authorization: Bearer ${user1_verifiable_credentials_access_token}' -X PATCH -d @proof_gen.json --location 'https://${service_url}/v1.0/diagency/verifications/<id> -H 'Content-Type: application/json'

The following is an example of proof_gen.son file and both occurrences of <credential_definition_id> are replaced with the appropriate value.

{ 
  "state": "proof_generated",
  "proof_request": {
     "name": "user1-proof-request",
     "version": "1.0",
     "requested_attributes": {
       "attr1_referent": {
         "name": "attr1",
         "restrictions": [{"cred_def_id": "<credential_definition_id>"}]
       }
     },
     "requested_predicates": {
       "predicate1_referent": {
         "name": "attr3",
         "p_type": ">=",
         "p_value": 5,
         "restrictions": [{"cred_def_id": "<credential_definition_id>"}]
       }
     }
   }
}
Note: The format of the proof_gen.son file is the same as the proof_schema.json file described in the Creating a proof schema (Optional for JSONLD/BBS+ credentials) section.
After generating the proof, user1 can share it with verifier1 by changing the state to proof_shared:
curl --header 'Authorization: Bearer ${user1_verifiable_credentials_access_token}' -X PATCH -d '{"state":"proof_shared"}' --location 'https://${service_url}/v1.0/diagency/verifications/<id> -H 'Content-Type: application/json'

Agent of the verifier1 verifies cryptographic integrity of the proof and sends the verification result to agent of the user1. If the proof is successfully verified, the state of this verification changes to passed for both verifier1 and user1.

To check the state of the verification for verifier1, use the following command:
curl --header 'Authorization: Bearer ${verifier_verifiable_credentials_access_token}' --location 'https://${service_url}/v1.0/diagency/verifications/<id>
To view all verifications that are in the passed state, use the following command:
curl --header 'Authorization: Bearer ${user1_verifiable_credentials_access_token}' --location 'https://${service_url}/v1.0/diagency/verifications/<id>