Skip to content

Latest commit

 

History

History
203 lines (166 loc) · 9.85 KB

verification.md

File metadata and controls

203 lines (166 loc) · 9.85 KB
Raw

Verification, Validation, and Veracity

This attempts a general description of the process whereby a relying party checks whether they will accept Verifiable Credential or Verifiable Presentation. An additional goal is to provide a framework and context for the “verification” steps provided in the vc-api repository.

This process is broken into three sub-processes called Verification, Validation, and Veracity (“3V”).

Table of contents

Definitions

Definitions of the first two terms come from the VC-DATA-MODEL. The third is a replacement/repurposing of what the VC-DATA-MODEL calls “Validity”. (Renaming due to insufficient distinction between the words “validation” and “validity”.)

3V Procedure

The input to the 3V procedure is a Verifiable Presentation (VP), which:

  • Contains a list of VCs
  • May contain a separate proof

At a high level, the 3V procedure involves:

  1. 3V each VC in the VP
    • See "Verify(VC)"
  2. 3V VP outer layer
    • See "Verify(VP)"

Verification

Verify (VC)

  1. Check well-formed according to VC-DATA-MODEL
    • E.g., required fields are present
  2. Check proof (DID resolver provided by verifier)
    • Credential hasn’t been tampered with: signed with an expected issuer DID/key (per document loader provided by caller)
    • Signed by key authorized for the purposes of signing
    • Expected properties are present (per proof data model)
  3. Check timeliness and status (per callbacks provided by verifier)

Verify (VP)

Same as Verify (VC), with these additions/changes:

  1. VP proof is optional, but if present it must pass checks.
  2. Make sure the domain and challenge values are ones the verifier was expecting

Validation

These are categories of validation checks, but do not prescribe specific ways of checking. The verifier may determine how these checks are performed by providing callbacks to the “Verification” layer. This interface is described in "Interfaces between Validation and Verification".

  • Timeliness and Status (callback to verification)
    • issuanceDate isn’t in the future, not past expiration date
    • Status is “current”, e.g., not revoked, not expired, etc.
  • Credential Holder/Subject is expected party
    • Authenticate
      • Including DID auth, traditional auth method
    • Other checks
      • Public key material (TODO: check this doesn't conflict with another category)
      • Subject attributes listed in the credential
  • Issuer is expected party
    • The value associated with the issuer property identifies an issuer that is known to and trusted by the verifier.
      • E.g., Check the issuer DID against an allow-list
  • Proof attributes (TODO: still teasing apart this from DID checks.)
    • From: https://www.w3.org/TR/vc-data-model/#proofs-signatures-0
    • Acceptably recent metadata regarding the public key associated with the signature is available. For example, the metadata might include properties related to expiration, key owner, or key purpose.
    • The key is not suspended, revoked, or expired.
  • DID and DID Document Check (Issuer and Holder)
    • A more complete list of considerations should be provided in the context of the DID spec (or related docs). Here are some examples:
      • Check to make sure the signing keys are not marked revoked in the latest version of the DID document (or have not been removed).
        • If the keys are currently revoked, try and determine whether they were valid at the time the VC was issued, and whether to accept it. (This is very much usecase/threat-model specific).
        • Different DID methods and Key types have different ways of marking key expiration/revocation.
      • Check to make sure the issuer DID has not been revoked.

Veracity

Perform any other application-specific or domain-specific validation around fitness for purpose.

Veracity checks do not fall within the scope of vc-api, but we call it out as a general bucket for additional checks, which serve one of these purposes.

Assume it means that verifiers that have better policies / higher bars for verification are better than verifiers that put less effort in... some verifiers will take credentials in any shape or form, other have stricter preferences.

  1. Verifiers or relying parties choosing to restrict the credentials accepted. They may do this to enforce policies or additional standards. Examples include:
    1. Accept credentials with specific accreditations
    2. Checking nested signatures/proofs
  2. Verifiers or relying parties choosing to relax the credentials accepted: e.g., override a previous “failed” status, to accept a broader range of credentials. Examples may include:
    1. Accept issuanceDate in the future (post-dated checks)
    2. Accept another institution’s expired credentials (e.g., if the issuing institution went out of business)

Interfaces between Validation and Verification

There are two relevant interfaces between Validation and Verification:

  • Callbacks to determine credential timeliness and status
    • This provides flexibility for verifier to make their own judgment about whether they’ll accept a credential; e.g., some parties may accept an issuanceDate that falls in the future, while others won’t
  • Document loaders to DID resolution, JSON-LD contexts, or any other document needed at runtime

Sources

Sources include the VC Data Model, emerging specifications, and implementations, including: