#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:

{
  "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:

{
  "policy": "not-before"
}

#schema

Validates credential data against a JSON Schema.

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

Example:

{
  "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:

{
  "policy": "signature"
}

#allowed-issuer

Validates that the credential issuer is in an allowed list.

Use case: Restrict credentials to trusted issuers only.

Example:

{
  "policy": "allowed-issuer",
  "allowed_issuer": "did:example:issuer123"
}

Multiple issuers:

{
  "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:

{
  "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):

{
  "policy": "credential-status",
  "argument": {
    "discriminator": "w3c",
    "value": 0,
    "purpose": "revocation",
    "type": "StatusList2021"
  }
}

Example (TokenStatusList):

{
  "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.

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

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

Example (Multiple BitstringStatusList entries):

{
  "policy": "credential-status",
  "argument": {
    "discriminator": "w3c-list",
    "list" : [
      {
        "value": 0,
        "purpose": "revocation",
        "type": "BitstringStatusList"
      },
      {
        "value": 0,
        "purpose": "suspension",
        "type": "BitstringStatusList"
      }
    ]
  }
}

#revoked-status-list

Checks revocation status using W3C StatusList2021 format.

Use case: Quick revocation check for StatusList2021 credentials.

Example:

{
  "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).

#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)

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

#Example: VICAL URL (Recommended)

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

#webhook

Calls an external HTTP endpoint to verify the credential.

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

Example:

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

Bearer token authentication:

{
  "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:

{
  "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:

{
  "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:

{
  "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:

{
  "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:

{
  "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:

{
  "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:

{
  "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:

{
  "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:

{
  "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:

{
  "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:

{
  "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:

{
  "policy": "mso_mdoc/mso"
}