W3C: Reworked predicates representation

[Artemkaaas]

Reworked predicates representation in presented credential to use boolean true value as the result of a predicate instead of custom object.

[TimoGlastra]

Sorry for my ignorance, I'm probably missing something here, but I still not quite understand why the change of predicate from an object to boolean has made it required to add the mapping back into the proof. We can still infer this based on the submitted proof itself and the proof request right? The proof contains proof for predicate X, while the proof request also contains a requirement for predicate x > 50 for example.

Won't it be possible to match these against each other? Why was it possible with the object structure?

[Artemkaaas]

Due to the corner case, Stephen mentioned here: hyperledger/anoncreds-spec#194 (comment)

The same name of attribute was requested twice, but different credentials were used for the proof .
Here is how the request will look like:

{
    "name":"test",
     "version": "1.0",
     "nonce": "1234556"
     "requested_predicates”: { 
     	 “predicate_1”: {
		“name”: “age”,
 		“p_type”: “>=”,
		“p_value”: 18
         },
     	 “predicate_2”: {
		“name”: “age”,
 		“p_type”: “>”,
		“p_value”: 20
         }
}

anoncreds-clsignatures requires passing of predicate name, type, value for doing verification. If we pass different value, verification will fail.

Here is a proof verification steps using anoncreds-clsignatures methods:

//  taken from proof request
//   pass predicate name/type/value   
let mut sub_proof_request_builder = Verifier::new_sub_proof_request_builder().unwrap();
sub_proof_request_builder.add_predicate("age", "GE", 18).unwrap();
let sub_proof_request = sub_proof_request_builder.finalize().unwrap();

// taken from presentation
let mut proof_verifier = Verifier::new_proof_verifier().unwrap();
proof_verifier.add_sub_proof_request(&sub_proof_request, &credential_schema, &non_credential_schema, &credential_pub_key,  None, None).unwrap();
proof_verifier.verify(&proof, &proof_request_nonce).unwrap()

[TimoGlastra]

Okay makes somewhat sense (I'll think about it a bit more what this has for implications in relation to DIF Presentation Exchange).

Does this mean the proof includes specific group names? Because in that case also need to define a mapping how proof group names should be defined based on a DIF presentation definition.

E.g. If I have the following DIF PE:

{
  "id": "5591656f-5b5d-40f8-ab5c-9041c8e3a6a0",
  "name": "Age Verification",
  "purpose": "We need to verify your age before entering a bar",
  "input_descriptors": [
    {
      "id": "age-verification",
      "name": "A specific type of VC + Issuer",
      "purpose": "We want a VC of this type generated by this issuer",
      "schema": [
        {
          "uri": "https://www.w3.org/2018/credentials/v1"
        }
      ],
      "constraints": {
        "limit_disclosure": "required",
        "fields": [
          {
            "path": ["$.credentialSubject.name"]
          },
          {
            "path": ["$.credentialSubject.age"],
            "predicate": "preferred",
            "filter": {
              "type": "number",
              "minimum": 18
            }
          }
        ]
      }
    },
    {
      "id": "age-verification2",
      "name": "A specific type of VC + Issuer",
      "purpose": "We want a VC of this type generated by this issuer",
      "schema": [
        {
          "uri": "https://www.w3.org/2018/credentials/v1"
        }
      ],
      "constraints": {
        "limit_disclosure": "required",
        "fields": [
          {
            "path": ["$.credentialSubject.age"],
            "predicate": "preferred",
            "filter": {
              "type": "number",
              "maximum": 21
            }
          }
        ]
      }
    }
  ],
  "format": {
    "di_vc": {
      "proof_type": ["DataIntegrityProof"],
      "cryptosuite": ["anoncredspresvc-2023", "eddsa-rdfc-2022"]
    }
  }
}

That could be mapped to the following AnonCreds request:

{
  "name": "pres_req_1",
  "non_revoked": {
    "from": 13,
    "to": 200
  },
  "nonce": "726216211516745824455642",
  "requested_attributes": {
	// input descriptor id + '_attributes'
    "age-verification_attributes": {
      "names": ["name"]
    }
  },
  "requested_predicates": {
    // input descriptor id + `_<attr-name>_predicate`
    "age-verification_age_predicate": {
      "name": "age",
      "p_type": ">=",
      "p_value": 18,
    },
    // input descriptor id + `_<attr-name>_predicate`
    "age-verification2_age_predicate": {
      "name": "age",
      "p_type": "<=",
      "p_value": 18,
    }
  },
  "ver": "1.0",
  "version": "0.1"
}

As otherwise the proof verification will fail if the dif PE <-> AnonCreds proof request is not consistent in group name generatation and these group names are included in the actual proof