Skip to content

Invalid Proof Material

URI: https://docs.ankatech.co/errors/invalid-proof-material
HTTP Status: 422 Unprocessable Entity

When you see this

A public key submitted as an actor's proof material was refused by one of the admission rules that govern what may become a verification key. The status is 422 rather than 400 because the document parsed and the request was well formed — what failed is a domain rule about the key itself.

Common Causes

  • A public JWK was submitted without a kind, or a JWK was sent for a credential that authenticates with a shared secret.
  • A PRIVATE_KEY_JWT credential was issued or rotated with no JWK at all.
  • A FEDERATED_JWT identity was requested from the credential endpoint, which mints no material for it — declare an issuer binding for the actor instead.
  • The submitted document is not a JSON object, is not a well-formed JWK, or exceeds the accepted document size.
  • A JWK Set was submitted where exactly one JWK is required.
  • The kty is absent or is not one of RSA, EC or OKP — a symmetric oct key is refused, because whoever holds it could mint assertions.
  • A required member for that key type is missing, or a member that is not admitted for a verification key is present.
  • The key carries private material.
  • The key does not declare use of sig, or its key_ops excludes verify.
  • An RSA key is below the minimum or above the maximum admitted size, or its public exponent is not odd and at least 3.
  • An EC key names a curve that is not admitted, or its point is invalid.
  • An OKP key uses a curve that cannot verify.

Response Example

{
  "type": "https://docs.ankatech.co/errors/invalid-proof-material",
  "title": "Invalid Proof Material",
  "status": 422,
  "detail": "a verification key must declare use 'sig'",
  "instance": "/api/v3/admin/tenants/7c9e6679-7425-40de-944b-e07fc1f90ae7/actors/2b1a7f34-9c05-4e3e-8f61-0d1c5a7b4e29/credentials",
  "timestamp": 1730000000,
  "extensions": {
    "requestId": "550e8400-e29b-41d4-a716-446655440000"
  }
}

Content-Type: application/problem+json — the response follows RFC 9457 Problem Details.

The detail is the rule that refused, and it never echoes a fragment of the submitted material — no modulus, no curve point, no kid. A problem body is rendered in consoles, written to logs and forwarded to SIEMs, and caller-controlled bytes do not belong in any of the three.

How to Resolve

  1. Read the detail: it states the rule, which is what identifies the repair.
  2. Submit exactly one public JWK, with kty of RSA, EC or OKP, declaring use of sig, and carrying only the members required for that key type.
  3. Strip every private member before submitting — the key is a verification key and the platform holds no private half of it.
  4. For an RSA key, confirm its size is within the deployment's admitted range and its public exponent is odd and at least 3.

For full schema definitions, examples, and interactive testing, see the Developer Hub Reference.