Skip to main content

Verification

KILT allows a Verifier to check if the information in a credential presented by a Claimer is correct and valid. With the presentation of the credential, the Claimer also presents evidence that a third party (i.e., an Attester) ensured the correctness of the Claimer’s attributes.

The Verifier trusts this third party either because they trust their reputation directly or they trust a delegation structure that this Attester is part of (e.g., a State department issuing driving licenses).

For the verification process:

  • The Claimer needs their credential and the private key associated with their identifier
  • The Verifier needs the identifier of the trusted Attester

During the verification process the Claimer wants to prove three things to the Verifier:

  • The credential is valid (i.e., not revoked by its Attester)
  • The attributes in the credential actually refer to the Claimer
  • The credential contains information that is relevant for the Verifier in this use case

Requesting a Credential from a Claimer​

The Verifier may request a credential from a Claimer, providing the following data:

  • CTypes: which CTypes the Verifier can work with for the use case. They can provide multiple options, which have to be regarded as alternatives.
  • TrustedAttesters: which Attesters are considered trusted for each specified CType.
  • RequiredProperties: which properties for each specified CType must at least be revealed for the presentation to be considered sufficient. More on "selective disclosure" later.
  • Challenge: a nonce, which the Verifier can make use of to ensure that the presentation generated by the Claimer is fresh and is not being replayed by some other older interactions. More on that later.

Presenting a Credential with Selective Disclosure​

Given the RequiredProperties specified by the Verifier, the Claimer can decide how much of the information they wish to reveal before they generate the presentation and send it to the Verifier. If supported by the Verifier, they can choose to hide attributes and thus only disclose a subset of the original claim data.

For example, if verifying a driving license only requires the verification of the driver's name and picture, a Claimer can decide to hide additional information such as age and place of residence. This increases the privacy of the Claimer since they only need to show attributes that are required in the specific context.

For a detailed developer-oriented guide to KILT presentation creation, see our Presentation Cookbook section.

caution

The presentations can still be correlated, since the hash of the credential always stays the same, even when creating new presentations and selecting different attributes to show.

Verifying a Presentation​

The Verifier receives the presentation from the Claimer, re-calculates the root hash of the credential from which the presentation was generated, and queries the KILT blockchain to obtain the associated attestation information, including the revocation status of the credential.

If the Claimer tampered with the credential, the re-calculated root hash will not match any attestation on the chain. On the other hand, if an attestation with the calculated hash can be found on the chain and has not been revoked, the credential is valid.

However, this does not give the Verifier the guarantee that the Claimer is the rightful/legitimate owner of the credential presented. That problem is addressed in the next section.

Verifying the Owner of the Presented Credential​

When issued, a credential is linked to the KILT decentralized identifier (DID) of the original Claimer. The DID can be resolved to the public key of the Claimer according to the KILT DID specification.

The Verifier assumes that the private key for the DID public key is only known to the owner of the credential, and is not shared across users. Therefore, when requesting the Claimer to generate a presentation, the Verifier challenges the Claimer to sign a nonce (a random number that is used once) that the Verifier sends together with their request.

If the Claimer can sign both the nonce and the presentation with the private key that only the credential's owner should have knowledge of, the Verifier can be sure that the Claimer is indeed the legitimate owner of the credential.

Verifying the Content of the Presented Credential​

After the Verifier has checked that the credential is valid and belongs to the presenting Claimer, they still need to verify that they have received all the required information as the presentation received could contain the right values, but not the right semantics. For example, the age property could have different meanings depending on whether it is defined for a passport CType or a Whisky Certificate CType. Therefore, the Verifier has to check if the CType matches one of the requested CTypes, and that the properties disclosed in the presentation include at least all of the properties requested for that CType presentation.

For a detailed developer-oriented guide to KILT credential verification, see our Verification Cookbook section.