Skip to content

Actor Owned By Use Case

URI: https://docs.ankatech.co/errors/actor-owned-by-use-case
HTTP Status: 422 Unprocessable Content

When you see this

The request names, as the actor of a new authorization, a Cryptographic Actor that an Internal Crypto Use Case owns. An actor a use case owns acts only for that use case: the use case created it, conferred exactly its declared operations on it, and disables it when the use case is revoked. Authority attached to that actor from anywhere else would widen the use case beyond what it declares, and would end silently when the use case does.

Five operations refuse it, before anything is written:

  • createExchange and updateExchange — naming the actor as the actor of a Cryptographic Exchange;
  • createCapabilityGrant — a standalone grant on the actor;
  • previewCapabilityGrant — the same refusal as the create, returned as this 422 rather than inside the 200, because it is a refusal about the request and there is no conferral plan to describe;
  • assignActorRoles — replacing the actor's role set.

The owning use case's id is named in detail and travels as the useCaseId extension member, so a client can link to it without parsing prose.

Ownership is the use case's own record of its actor, not the actor's type. A use case creates an INTERNAL actor, and an INTERNAL actor you created yourself is not refused. A revoked use case still owns the actor it disabled.

This is not Actor Not Active: the actor is ACTIVE, and reactivating it changes nothing. Nor is it Terminal Actor State.

What stays available on an owned actor is what the use case itself uses: issuing or rotating its credential, binding it to an external identity provider, and removing one of its roles with unassignActorRole. None of those adds authority beyond what the use case conferred.

Common Causes

  • Picking the use case's actor (named <use-case-name>-actor) from the actor list when composing a Cryptographic Exchange or a grant.
  • A script that reuses one actor id across use cases and exchanges.
  • Adding a role to a use case's actor so it can perform an operation the use case does not declare.

Response Example

{
  "type": "https://docs.ankatech.co/errors/actor-owned-by-use-case",
  "title": "Actor Owned By Use Case",
  "status": 422,
  "detail": "This actor is owned by internal crypto use case d7b3e9a1-4c6f-4e28-8a15-3f0b2c9d6e74 and receives authority only through it. Choose an actor that no use case owns.",
  "instance": "/api/v3/admin/tenants/3f9a1b62-5d47-4c8e-b0a2-91d7e4f60cc5/capability-grants",
  "timestamp": 1730000000,
  "extensions": {
    "useCaseId": "d7b3e9a1-4c6f-4e28-8a15-3f0b2c9d6e74",
    "requestId": "550e8400-e29b-41d4-a716-446655440000"
  }
}

Content-Type: application/problem+json — the response follows RFC 9457 Problem Details. The use case is one of your own tenant's; nothing from another tenant is ever named.

How to Resolve

  1. Read extensions.useCaseId to find the use case that owns the actor.
  2. To authorize a different application or counterparty, name an actor no use case owns — create one for it if none exists — and compose the Exchange or grant over that actor.
  3. If the use case itself needs another operation, change what it declares: revoke it and create one whose operations include what it needs. A use case's authority is exactly its declared operations.

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