Skip to main content

Verification

KILT lets a Verifier 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. For example, 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 the following things to the Verifier:

  • The credential is valid (i.e., not revoked by its Attester)
  • The attributes in the credential actually refer to it's Presenter
  • The credential contains information relevant for the Verifier for this use case
  • That an Attester ensured the correct and trustworthy-ness of the Claimer's attributes

Requesting a credential from a Claimer​

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

  • cTypeHash: Which CType hashes the Verifier can work with for the use case. They can provide multiple options, to regard as alternatives.

  • trustedAttesters: Which Attesters to consider trusted for each specified CType.

  • requiredProperties: Which properties for each specified CType must at least be revealed for the Verifier to consider the presentation sufficient.

    info

    Read more on selective disclosure.

  • challenge: A nonce, which the Verifier can use to ensure that the presentation generated by the Claimer is fresh and not replayed by some other older interactions.

Example​

{
   "body": {
      "content": {
         "cTypes": [
            {
               "cTypeHash": "0x3291bb126e33b4862d421bfaa1d2f272e6cdfc4f96658988fbcffea8914bd9ac",
               "trustedAttesters": [
                  "did:kilt:4pehddkhEanexVTTzWAtrrfo2R7xPnePpuiJLC7shQU894aY"
               ],
               "requiredProperties": [
                  "Email"
               ]
            }
         ],
         "challenge": "0x5a1a17eca9ddf6b4d14dffb2abd1411fe9235927975a246b3963db86dfb7de5f"
      },
      "type": "request-credential"
   }
}

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.

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.

For example, 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 required in the specific context.

info

For a detailed developer-oriented guide to KILT presentation creation, read the presentation creation cookbook section.

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 won't match any attestation on the chain. On the other hand, if the Verifier can find an attestation with the calculated hash on the chain and hasn't been revoked, the credential is valid.

However, this doesn't give the Verifier the guarantee that the Claimer is the rightful/legitimate owner of the credential presented.

Verifying the owner of the presented credential​

When issued, a credential is linked to the KILT decentralized identifier (DID) of the original Claimer. The Verifier can resolve the DID 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 isn't shared across users. Therefore, when requesting the Claimer to generate a presentation, the Verifier challenges the Claimer to sign a nonce (a random number 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 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 need to verify that they have received all the required information. This is to verify that the presentation received contains the right values and the right semantics.

For example, the age property could have different meanings depending on whether it's 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 includes all the properties requested for that CType presentation.

info

For a detailed developer-oriented guide to KILT credential verification, read the verification cookbook section.