Cryptographic Actors
What this screen is for
A cryptographic actor is the identity that calls the platform on behalf of an application: an internal service, a batch job, an integration channel or a third party. Authorization decisions, audit events and rate limits are anchored on the actor. This screen lists your tenant's actors and is where you give each one a way to authenticate and the operations it may request.
What must exist first
This screen is for tenants that compose authorization by hand. It is not offered to SIMPLE tenants: a SIMPLE tenant uses Internal Use Cases, which compose the actor, its credential and its grants for it.
Before you work here:
- An application. Every actor belongs to one, and creating an application already creates its Default Cryptographic Actor.
- The permission to list actors, which is what shows this screen. Creating and deleting actors, reading, issuing, rotating and revoking credentials, reading and changing roles, and reading or binding federated identities are each a further permission. A tab you are not permitted to read is disabled.
Decisions you make here
Creating an actor
With the permission to create actors, New Actor opens a wizard. You choose the Application the actor belongs to, its type (Internal, Third-Party or Partner), its name, display name, description and purpose, and an optional validity window.
The actor is saved as soon as that first step is complete. The wizard then offers its first credential and its roles, and you may skip either. An actor cannot operate until it has a way to authenticate, which is a credential or a bound external identity, and at least one role. Its detail says so, and offers the missing steps, until both exist.
Issuing and rotating credentials
On the actor's Credentials tab, Issue Credential offers two modes:
- Add, with the permission to issue credentials: a new credential beside the active ones, which keep working.
- Rotate, with the permission to rotate credentials: a new credential, while the active ones keep authenticating for the Grace window (hours) you set and are then revoked. The default is 24 hours and the maximum 720. A grace window of 0 revokes them at once, so every workload still presenting them stops authenticating immediately.
When you add a credential you choose its kind, and a rotation keeps the kind it replaces:
- Shared secret: the platform generates the secret, shows it once and keeps only a hash of it. Store it before you close the dialog; if it is lost, rotate to obtain a new one.
- Registered key pair: the workload keeps its private key and signs an assertion with it. You paste only the public key as a JWK, so no secret exists for anyone to leak.
A credential can also carry a validity window. Left blank, it is valid from now with no expiry.
Revoking a credential
With the permission to revoke credentials, revoking a credential is permanent. A process authenticating with it is denied on its next request.
Assigning roles
With the permission to read roles, the Roles tab shows the roles the actor carries. Roles are the API permissions that decide which operations the actor may request. With the permission to assign or unassign roles, Manage lets you tick roles, and Save replaces the actor's whole set with exactly what is ticked.
A role lets the actor request a kind of operation; a capability grant decides which keys that operation may use. An actor needs both.
Binding a federated identity
On the Federated identities tab, Bind an external identity lets a subject vouched for by a trusted issuer authenticate as this actor, with no secret held here. It needs the permission to write workload identities, a tenant entitled to workload identity federation, and the issuer declared in your tenant's Settings. The tab says which of these is missing.
A binding conveys identity only: roles and grants still decide what the actor may do. Removing a binding is permanent.
Deleting an actor
With the permission to delete actors, Delete Actor removes an actor once you type its name. It is refused while active credentials, capability grants or cryptographic exchanges still reference the actor, so revoke those first. A Default Actor cannot be deleted on its own; it is disabled when its application is deleted.
How it relates to other screens
Every actor belongs to an application, and the application column of the list opens it:
Which keys an actor's operations may use is decided by capability grants, and exchange contexts scope those grants to a business relationship. A STANDARD tenant composes both on their own screens. Because audit events are anchored on the actor, the audit trail attributes every operation to the actor that performed it.