Skip to content

Trusted Issuer Already Trusted On Another Plane

URI: https://docs.ankatech.co/errors/trusted-issuer-cross-plane-conflict
HTTP Status: 409 Conflict

When you see this

The issuer URL is already trusted on the other plane, so declaring it here would put two rows for one issuer into the trust set a tenant actually resolves.

What a tenant resolves is the union of the deployment-wide declarations and its own. The two uniqueness indexes are partial and per plane, so a URL on both planes is representable in the database — and what it produces is not a duplicate an operator can see, but a total federated-authentication outage for that tenant, naming nothing.

The conflictingDeclarations extension member is a count, deliberately. On the deployment plane the conflicting rows belong to other customers, and naming them would tell a platform operator which of them federate with which provider.

Common Causes

  • Declaring an issuer for a tenant when the deployment already trusts it deployment-wide.
  • Declaring an issuer deployment-wide when one or more tenants already declared it for themselves.
  • Two spellings of one URL that canonicalise to the same value across the two planes.

Response Example

{
  "type": "https://docs.ankatech.co/errors/trusted-issuer-cross-plane-conflict",
  "title": "Trusted Issuer Already Trusted On Another Plane",
  "status": 409,
  "detail": "https://acme.eu.auth0.com is already trusted deployment-wide, so this tenant trusts it already. Declaring it again would put two rows for one issuer into the set this tenant resolves, and a trust set is a set: no rule says which of the two a token would be verified against. Bind your actors to the existing deployment-wide declaration instead.",
  "instance": "/api/v3/admin/tenants/3f9a1b62-5d47-4c8e-b0a2-91d7e4f60cc5/workload-identity/issuers",
  "timestamp": 1730000000,
  "extensions": {
    "conflictingDeclarations": 1,
    "requestId": "550e8400-e29b-41d4-a716-446655440000"
  }
}

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

How to Resolve

  1. On a tenant declaration refused by a deployment-wide row: do not declare it again. Bind your actors to the existing deployment-wide declaration — the tenant already trusts that issuer.
  2. On a deployment-wide declaration refused by tenant rows: conflictingDeclarations says how many stand in the way. Either have those tenants withdraw their own declaration first, or leave the issuer to the tenants that declared it.
  3. Do not retry the same declaration unchanged; the conflict is on state, not on the request.

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