Indy Anoncreds verifier initialization

Verifier1 must first identify the credential definition ID from issuer1. This ID is available on website of the issuer1 or another public resource. It is similar to finding a public key of a certificate authority in the PKI system, except that a credential definition ID is permanent and recorded on the ledger.

For example, <cred-def-id> is the credential definition ID (the value of the id field in the previous response) used throughout this example.

During initialization, the verifier can optionally create a proof schema. The ID of this schema can be referenced for each verification. If you prefer not to create a schema during initialization, you can specify the proof request during each verification.

To create a proof schema for verifier1, use the following command:

curl --header 'Authorization: Bearer ${verifier_verifiable_credentials_access_token}' -X POST -d @proof_schema.json --location 'https://${service_url}/v1.0/diagency/proof_schemas -H 'Content-Type: application/json'

{
  "name": "proof-schema1",
  "version": "1.0",
  "requested_attributes": [
    {
      "names": ["class", "grade"],
      "restrictions": [{"cred_def_id": "<cred-def-id>"}]
    }, 
    {
      "name": "phone_number"
    }
  ],
  "requested_predicates": [
    {
      "name": "rank",
      "p_type": "<=",
      "p_value": 10,
      "restrictions": [{"cred_def_id": "<cred-def-id>"}]
    }
  ],
  "cred_filter": [
    {
       "attr_name": "class",
       "attr_values": ["Math 100"]
       "exclude": true
    },
    {
       "attr_name": "class",
       "attr_values": ["Math *"]
    }
  ]
}

• name and version: The combination of name and version must be unique for each proof schema.

• requested_attributes: This specifies the attributes. Each requested_attributes element must include a name or names field. If names is used with restrictions, all attribute names must originate from a single credential.

  To verify proofs, you need to ensure that class and grade attributes come from a single credential that is issued by a specific issuer that owns <cred-def-id>. Consider the following scenario:

  Faber College issues credentials with two attributes: class and grade. Alice holds two credentials from Faber College in her wallet:

  {"class":"Math 100", "grade":"A"}
  {"class":"Math 200", "grade":"D"}

  If requested_attributes are specified as follows, Alice can return a proof with the class value of Math 200 from the second credential and the grade value of A from the first credential.

  "requested_attributes": [
     {
       "name": "class",
       "restrictions": [{"cred_def_id": "<cred-def-id>"}]
     },
     {
       "name": "grade",
       "restrictions": [{"cred_def_id": "<cred-def-id>"}]
     }
   ]

  This scenario demonstrates why you must always use the names format when requiring multiple attributes to originate from a single credential, unless you intend to allow attributes from different credentials.

  A self-attested attribute can be requested by omitting the restrictions field from a requested_attributes element. In the previous example, a verifier requests the value of the phone_number attribute, but it does not have to come from an issued credential. The prover can:

  • Manually provide the attribute value (not from a credential in the wallet of the prover).
  • Use a value from a credential in the wallet of the prover, if available.

• requested_predicates: This allows you to request proof of an attribute without revealing its exact value. A typical use case is verifying whether someone is 21 years old or older without revealing their actual age.

  Each requested_predicates entry must include the following fields:

  • name: Indicates he attribute name.
  • p_type: Indicates the predicate operation (valid values are >, >=, <, <=).
  • p_value: Indicates the value to which the attribute is compared.

  In the example above, the value of the attribute rank must be less than or equal to 10.

  For each non-self-attested attribute or predicate, you must include a restrictions field that lists the criteria that must be met. The value of the restrictions field is an array, where:

  • Each element of the array is connected by a logical OR.
  • All keys within a single element are connected by a logical AND.

  Consider the following example of restrictions field:

  "restrictions": [{"schema_name": "myschema", "schema_version": "1.0"}, {"cred_def_id": "XXX"}]

  This can be interpreted as:

  (schema_name == 'myschema' AND schema_version == '1.0') OR
        cred_def_id == 'XXX'

  Supported restriction operators include:

  1. cred_def_id: The credential definition ID.

  2. schema_id: The DID of a credential schema.

  3. schema_issuer_did: The DID of the schema issuer.

  4. schema_name: The name of the schema.

  5. schema_version: The schema version.

  6. issuer_did: The DID of the credential issuer.

• cred_filter: cred_filter reduces the number of choices a prover has when selecting credentials. This reduction can be based on the value of one or more attributes in a credential.

  The cred_filter value is an array of rules. The first rule that matches determines whether the credential is included or excluded from the prover’s view.
  The fields of each element of the rule are:

  • attr_name: The name of an attribute in the credential (required).

  • attr_values: An array of strings, each of which may be a regular expression. A rule matches if the credential contains the attribute name and the value matches any of the regular expressions in the list (required).

  • exclude: A Boolean field that determines whether to include or exclude the credential if a rule matches. The default value is false (optional).

  In the following example, two rules are applied:

  1. Exclude credentials with a class attribute value of "Math 100":

     {
        "attr_name": "class",
        "attr_values": ["Math 100"]
        "exclude": true
     }

  2. Include credentials with a class attribute value beginning with "Math ":

     {
        "attr_name": "class",
        "attr_values": ["Math *"]
     }

The format of a proof schema is identical to that of a proof request. A proof schema serves as a reusable and referencable proof request. You can either create proof schemas or dynamically specify the proof request for each verification.