---
title: "Available Policies"
description: "Checks if a credential has expired based on its notAfter claim."
stack: "Community Stack (open source) — version 0.21.0"
stack_version: "0.21.0"
stack_comparison: https://docs.walt.id/community-vs-enterprise.md
canonical_url: https://docs.walt.id/community-stack/verifier2/policies/available-policies
generated: 2026-07-20
---
# Available Policies

## Available Policies (VC) 

### `expiration`
Checks if a credential has expired based on its `notAfter` claim.

**Use case:** Ensure credentials are still valid and haven't expired.

**Example:**
```json
{
  "policy": "expiration"
}
```

---

### `not-before`
Validates that a credential is not being used before its `notBefore` or `issuedAt` date.

**Use case:** Prevent premature use of credentials that have future validity dates.

**Example:**
```json
{
  "policy": "not-before"
}
```

---

### `schema`
Validates credential data against a JSON Schema.

**Use case:** Ensure credential structure and data types match expected schema.

**Example:**
```json
{
  "policy": "schema",
  "schema": {
    "type": "object",
    "properties": {
      "credentialSubject": {
        "type": "object",
        "properties": {
          "name": { "type": "string" }
        }
      }
    }
  },
  "defaultType": null
}
```

---

### `signature`
Verifies the cryptographic signature of a credential.

**Use case:** Ensure credential authenticity and integrity.

**Example:**
```json
{
  "policy": "signature"
}
```

---

### `allowed-issuer`
Validates that the credential issuer is in an allowed list.

**Use case:** Restrict credentials to trusted issuers only.

**Example:**
```json
{
  "policy": "allowed-issuer",
  "allowed_issuer": "did:example:issuer123"
}
```

**Multiple issuers:**
```json
{
  "policy": "allowed-issuer",
  "allowed_issuer": ["did:example:issuer1", "did:example:issuer2"]
}
```

---

### `regex`
Validates credential data at a specific path using a regular expression.

**Use case:** Pattern matching for specific credential fields (e.g., email format, ID numbers).

**Example:**
```json
{
  "policy": "regex",
  "path": "$.credentialSubject.email",
  "regex": "^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$",
  "regex_options": ["IGNORE_CASE"],
  "allowNull": false
}
```

---

### `credential-status`
Checks credential status for different status list formats.

**Use case:** Verify credential hasn't been revoked or suspended.

**Example (W3C StatusList2021):**
```json
{
  "policy": "credential-status",
  "argument": {
    "discriminator": "w3c",
    "value": 0,
    "purpose": "revocation",
    "type": "StatusList2021"
  }
}
```

**Example (TokenStatusList):**
```json
{
  "policy": "credential-status",
  "argument": {
    "discriminator": "ietf",
    "value": 0
  }
}
```

**Example (Multiple allowed status values):**

You can specify multiple allowed status values using the `values` field. This is useful when you want to accept credentials that are in any of several valid states.

```json
{
  "policy": "credential-status",
  "argument": {
    "discriminator": "ietf",
    "values": [0, 1]
  }
}
```

```json
{
  "policy": "credential-status",
  "argument": {
    "discriminator": "w3c",
    "values": [0, 1],
    "purpose": "revocation",
    "type": "BitstringStatusList"
  }
}
```

**Example (Multiple BitstringStatusList entries):**
```json
{
  "policy": "credential-status",
  "argument": {
    "discriminator": "w3c-list",
    "list" : [
      {
        "value": 0,
        "purpose": "revocation",
        "type": "BitstringStatusList"
      },
      {
        "value": 0,
        "purpose": "suspension",
        "type": "BitstringStatusList"
      }
    ]
  }
}
```

**Note:**

**Note:** You can use either `value` (single value) or `values` (array of values), but at least one must be provided. When using `values`, the credential status is considered valid if it matches any of the specified values.

---

### `revoked-status-list`
Checks revocation status using W3C StatusList2021 format.

**Use case:** Quick revocation check for StatusList2021 credentials.

**Example:**
```json
{
  "policy": "revoked-status-list"
}
```

---

### `vical`
Validates mdoc credentials using VICAL (Verified Issuer Certificate Authority List) data.

**Use case:** Verify mdoc/mDL authenticity and certificate chain using trusted VICAL data. This policy validates the credential's X.509 certificate chain against a list of trusted Issuing Authority Certificate Authorities (IACAs).

**Note:**

**Background:** VICAL is part of the ISO/IEC 18013-5 standard trust infrastructure for mobile documents. It provides a cryptographically signed list of trusted issuer certificate authorities. Learn more about [VICALs and IACAs in the concepts section](https://docs.walt.id/concepts/trust-systems/iso-trust-vicals.md).

**Info:**

**mdoc/mDL Only:** This policy can currently only be applied to mdoc credentials (ISO 18013-5 format). It will fail if applied to other credential formats like JWT or SD-JWT.

#### Configuration Parameters

The VICAL policy requires either `vical` or `vicalUrl` (exactly one must be provided):

**VICAL Source (choose one):**

- `vical`: _String_ - Base64-encoded VICAL CBOR data. Use this for inline trust lists embedded directly in the policy configuration.
- `vicalUrl`: _String (optional)_ - HTTP(S) URL from which to fetch the VICAL at verification time. The endpoint must return the raw VICAL CBOR bytes (either as binary `application/cbor` or hex-encoded text). This is the **preferred approach in production** as it decouples policy configuration from the trust list and allows updates without redeploying configuration.

**Validation Options:**

- `enableDocumentTypeValidation`: _Boolean_ - When `true`, filters VICAL trust anchors to only those that authorize the specific document type (e.g., `org.iso.18013.5.1.mDL`). When `false`, uses all trust anchors from the VICAL regardless of document type. Default: `false`.
- `enableTrustedChainRoot`: _Boolean_ - When `true`, requires the certificate chain to include a trusted self-signed root certificate. When `false`, chain validation is more lenient. Default: `false`.
- `enableSystemTrustAnchors`: _Boolean_ - When `true`, uses the system's built-in trust anchors (operating system certificate stores) in addition to VICAL trust anchors. When `false`, relies only on VICAL trust anchors. Default: `false`.
- `enableRevocation`: _Boolean_ - When `true`, performs revocation checks on certificates in the chain (requires network access to CRL/OCSP endpoints). When `false`, skips revocation checking. Default: `false`.

#### Example: Inline VICAL (Base64)

```json
{
  "policy": "vical",
  "vical": "o2d2ZXJzaW9uAWx2aWNhbERhdGGCpmhkb2NUeXBlgXhfb3JnLmlzby4xODAxMy41LjEubURMamNlcnRpZmljYXRlWQOuMIID...",
  "enableDocumentTypeValidation": true,
  "enableTrustedChainRoot": true
}
```

**Note:**

If you have a VICAL CBOR file, encode it using: `base64 < austroads.cbor`. Remove any newlines from the output before using it in JSON.

#### Example: VICAL URL (Recommended)

```json
{
  "policy": "vical",
  "vicalUrl": "https://vical.example.com/api/latest",
  "enableDocumentTypeValidation": true,
  "enableTrustedChainRoot": true,
  "enableSystemTrustAnchors": false,
  "enableRevocation": false
}
```

**Note:**

**Enterprise Stack:** If you're using the walt.id Enterprise Stack, the [VICAL Service](https://docs.walt.id/enterprise-stack/services/vical-service/overview.md) provides managed VICAL endpoints. Use the `/v1/{target}/vical-service-api/latest` endpoint as your `vicalUrl`.

---

### `webhook`
Calls an external HTTP endpoint to verify the credential.

**Use case:** Delegate verification to external systems or custom validation logic.

**Example:**
```json
{
  "policy": "webhook",
  "url": "https://api.example.com/verify",
  "basicauth_username": "user",
  "basicauth_password": "pass",
  "bearerauth_token": null
}
```

**Bearer token authentication:**
```json
{
  "policy": "webhook",
  "url": "https://api.example.com/verify",
  "bearerauth_token": "your-token-here"
}
```

## Available Policies (VP)

Policies are organized by presentation format. All policies can be referenced by their ID string or configured as JSON objects.

### JWT VC JSON Policies

#### `jwt_vc_json/audience-check`
Validates that the presentation audience matches the expected audience for the verification session.

**Use case:** Ensure the presentation is intended for the correct verifier.

**Example:**
```json
{
  "policy": "jwt_vc_json/audience-check"
}
```

---

#### `jwt_vc_json/nonce-check`
Validates that the presentation nonce matches the expected nonce for the verification session.

**Use case:** Prevent replay attacks by ensuring the presentation was created for this specific session.

**Example:**
```json
{
  "policy": "jwt_vc_json/nonce-check"
}
```

---

#### `jwt_vc_json/envelope_signature`
Verifies the presentation envelope signature using the holder's public key.

**Use case:** Ensure the presentation was signed by the holder and hasn't been tampered with.

**Example:**
```json
{
  "policy": "jwt_vc_json/envelope_signature"
}
```

---

### SD-JWT Policies

#### `dc+sd-jwt/audience-check`
Validates that the SD-JWT presentation audience matches the expected audience for the verification session.

**Use case:** Ensure the SD-JWT presentation is intended for the correct verifier.

**Example:**
```json
{
  "policy": "dc+sd-jwt/audience-check"
}
```

---

#### `dc+sd-jwt/nonce-check`
Validates that the SD-JWT presentation nonce matches the expected nonce for the verification session.

**Use case:** Prevent replay attacks by ensuring the presentation was created for this specific session.

**Example:**
```json
{
  "policy": "dc+sd-jwt/nonce-check"
}
```

---

#### `dc+sd-jwt/kb-jwt_signature`
Verifies the Key Binding JWT (KB-JWT) signature using the holder's public key.

**Use case:** Ensure the KB-JWT was signed by the holder and binds the presentation to the holder's key.

**Example:**
```json
{
  "policy": "dc+sd-jwt/kb-jwt_signature"
}
```

---

#### `dc+sd-jwt/sd_hash-check`
Verifies SD-JWT key binding by recalculating and comparing the SD hash.

**Use case:** Ensure the presentation hash matches the expected hash, validating key binding integrity.

**Example:**
```json
{
  "policy": "dc+sd-jwt/sd_hash-check"
}
```

---

### mdoc Policies

#### `mso_mdoc/device-auth`
Verifies device authentication using device signature or MAC.

**Use case:** Ensure the mdoc presentation was authenticated by the device that holds the credential.

**Example:**
```json
{
  "policy": "mso_mdoc/device-auth"
}
```

---

#### `mso_mdoc/device_key_auth`
Verifies holder-verified data authorization using KeyAuthorization from the MSO.

**Use case:** Ensure holder-verified data elements are authorized according to the issuer's KeyAuthorization.

**Example:**
```json
{
  "policy": "mso_mdoc/device_key_auth"
}
```

---

#### `mso_mdoc/issuer_auth`
Verifies issuer authentication by validating the COSE_Sign1 signature using the issuer's certificate chain.

**Use case:** Ensure the issuer-signed data was authenticated by the credential issuer.

**Example:**
```json
{
  "policy": "mso_mdoc/issuer_auth"
}
```

---

#### `mso_mdoc/issuer_signed_integrity`
Verifies issuer-signed data integrity by comparing value digests with the MSO.

**Use case:** Ensure issuer-signed data hasn't been tampered with by validating digest hashes.

**Example:**
```json
{
  "policy": "mso_mdoc/issuer_signed_integrity"
}
```

---

#### `mso_mdoc/mso`
Verifies the Mobile Security Object (MSO) validity, including timestamps and digest algorithm support.

**Use case:** Ensure the MSO is valid and within its validity period.

**Example:**
```json
{
  "policy": "mso_mdoc/mso"
}
```