#Rate Limiting

The Verifier2 Service applies request rate limits to its OpenID4VP wallet interaction endpoints. These limits protect the verification flow from automated abuse while still allowing normal wallet verification traffic.

Rate limiting is configured in the unified rate-limit.conf file, which contains:

• Persistence settings — Optionally configures Redis for progressive failure backoff shared across Enterprise Service instances.
• Verifier2 endpoint limits — Defines request limits and failure-backoff thresholds for the request and response endpoints.
• Issuer2 endpoint limits — Defines request limits for the issuer service (see Issuer2 Rate Limiting).

#Rate Limited Endpoints

The following public wallet interaction endpoints are rate limited:

#Default Behavior

The service enforces endpoint request limits per verifier service, endpoint, and caller IP.

By default, the persistence section uses type = "memory". For verifier2 rate limiting this means Redis is not configured:

• Basic request-volume limits still work.
• Progressive failure backoff is disabled.
• Failure counters are not stored in memory by verifier2.
• Ktor request counters are local to each Enterprise Service instance.
• Restarting an Enterprise Service instance clears its in-process request counters.

For production deployments with multiple Enterprise Service instances, configure Redis so repeated failures are blocked consistently across the cluster.

#Configure Endpoint Limits

Use the verifier2_request_endpoint and verifier2_response_endpoint sections in rate-limit.conf to configure the wallet interaction endpoint limits.

# Verifier2 OpenID4VP rate limits
verifier2_request_endpoint {
  requestsPerMinute = 10
  failureWindowSeconds = 60
  failureThreshold = 5
  failureBlockSeconds = 300
}

verifier2_response_endpoint {
  requestsPerMinute = 5
  failureWindowSeconds = 60
  failureThreshold = 5
  failureBlockSeconds = 300
}

#Fields

#requestsPerMinute

Integer — Maximum number of requests allowed per minute for the same verifier service, endpoint, and caller IP.

• verifier2_request_endpoint.requestsPerMinute defaults to 10.
• verifier2_response_endpoint.requestsPerMinute defaults to 5.

When the threshold is exceeded, verifier2 returns 429 Too Many Requests with a Retry-After header.

#failureWindowSeconds

Integer — Time window in seconds for counting failed endpoint responses.

The default is 60. With the default settings, verifier2 counts failures during a rolling 60-second window.

#failureThreshold

Integer — Number of failed requests in the failure window required to create a temporary block.

The default is 5. With Redis enabled, the fifth failed request in the window creates a temporary backoff block.

#failureBlockSeconds

Integer — Duration in seconds for the temporary block after the failure threshold is reached.

The default is 300. Blocked requests return 429 Too Many Requests with a Retry-After header and a JSON error body:

{
  "error": "temporarily_unavailable",
  "error_description": "Too many failed requests"
}

#Configure Redis Backoff

Use the persistence section in rate-limit.conf to enable Redis-backed progressive failure backoff. This configuration is shared between issuer2 and verifier2 services.

persistence {
  type = "redis"
  nodes = [
    { host = "redis", port = 6379 }
  ]

  # Optional Redis authentication:
  # user = "default"
  # password = "change-me"
}

Redis cluster deployments can use type = "redis-cluster":

persistence {
  type = "redis-cluster"
  nodes = [
    { host = "redis-node-1", port = 6379 },
    { host = "redis-node-2", port = 6379 },
    { host = "redis-node-3", port = 6379 }
  ]
}

When Redis is configured, progressive failure backoff is shared across Enterprise Service instances using the same Redis deployment.

#Monitoring

Verifier2 exposes Prometheus counters for request outcomes and failure backoff. Use these metrics to alert on automated attacks or abnormal client behavior: