Indy-sdk support for '=' predicate


Currently, I get an error if I use = or == in preditcate_type. Is this not supported yet? and also it would be helpful to know if string value can also be used to predicate comparison apart from int value.

For example - ptype: ‘=’ and pvalue: “sometext” // This is errors out with invalid structure error.

Thanks in advance.

= ist not supported yet. Here is the corresponding sdk-doc. Pay attention to p_type:

         "name": attribute name, (case insensitive and ignore spaces)
          "p_type": predicate type (Currently {@code ">=" } only)
          "p_value": predicate value
         "restrictions": Optional[{filter}], // see filter above
                          // if specified, credential must satisfy to one of the given restriction.
          "non_revoked": Optional[{non_revoc_interval}], // see below,
                         // If specified prover must proof non-revocation
                       // for date in this interval this attribute
                        // (overrides proof level interval)
1 Like

Support for equal as a predicate is interesting - there is a discussion going on right now about that in the indy-sdk Hyperledger rocketchat channel.

On the one hand, proving in zero knowledge that a value is equal to a specific value is not really useful from a privacy perspective, because a “true” result means that you already know the value. You can achieve the same result just by just showing the value. That’s the reason that equal may not ever be available as a predicate. You could argue that a “false” result in the predicate means you just know it’s not what you thought, so that is a bit more privacy preserving.

On the other hand, what you may be intending is “prove a credential that has this value in this claim” - that is using the value as a selector to choose on credential from a set of the same credential a holder might have. For example, if you have a number of “Contact” credentials, prove to me the one that has a “type” of “mailing”. If they don’t have a credential with that type, you don’t want the result. That is conveying to the holder what you what in the proof coming back. That’s different from a predicate - that’s a restriction, but that restriction is also not (yet) supported. The team I’m on (BC Gov) is considering adding support for that as a restriction.

It kind of depends on why you are asking for that. Is it just because you wanted to try a predicate and don’t really have a need for that, or some other reason?

One thing we’ve talked about and would like to see in the future, but is not there yet - prove to me that two claims you posses have the same value, but don’t tell me the value. The use case is prove to me that that you are over 18 from driver’s licence credential and that your name in that driver’s licence credential matches the name in the credit card credential you are using to pay for something.

Hope that helps with some context.


I think that one of a set would be a useful predicate. For example, I am aware of a desire to know if a credential shows that the prover lives in one of a subset of US states. It this type of predicate were implemented, equals would just be a degenerate case of it.


Thanks for shedding more light on this. I agree with your thoughts on ‘=’ predicate and i am trying to achieve something that falls under “restriction” type i believe. Since this kind of restriction is not yet available i am doing a simple validation check after receiving the proof as in whether the proof contains the interested data if yes then i go and validate it against ledger otherwise display mismatch message. But here also there is slight pitfall as the data comes in encoded form and only if the proof data is number then encoding may not be required. So currently i am just using number data but would be happy to know if there is way to handle strings data also like this.

I agree this kind of predicate would help in many use cases.

Can you explain more on the restrictions field or point me to some references on this?


Here is a short example:

  "name": "szenario_4",
  "requested_attributes": {},
  "version": "0.1",
  "nonce": "123432421212",
  "requested_predicates": {
    "pred1_referent": {
      "p_value": 3,
      "name": "matrikelnummer",
      "p_type": ">=",
      "restrictions": {
        "cred_def_id": "RbaLZNXxJKBGm6RX56MAAf:3:CL:183:Studentenausweis"

The proof request requests a predicate in which the proover mus show that an attribute called “matrikelnummer” ist greater than 3. The prover can only use a credential which corresponds to the credential definition mentioned in the restriction field. Instead restricting the credential definition it is also possible to restrict the issuer, schema definition etc. For more details about the possible restrictions compare e.g. the javadoc for proverGetCredentialsForProofReq in Here is a short excerpt:

	         "schema_id": string, (Optional)
	         "schema_issuer_did": string, (Optional)
	         "schema_name": string, (Optional)
	         "schema_version": string, (Optional)
	         "issuer_did": string, (Optional)
	         "cred_def_id": string, (Optional)

This are exactly the restrictions you can specify.