Cryptographic Playground

What this screen is for

The Playground proves, in one action, that a flow your tenant configured works on Runtime, the platform's cryptographic service. A flow is everything one Exchange or Internal Use Case configures on one key: encrypt and decrypt, sign and verify, and re-encrypt or re-sign from that key.

Each run is a real operation on Runtime, run as the Actor the configuration names. It is the request your application would send, so you see the same answer: the Key ID, the material version and the algorithm Runtime really used. The screen creates and changes no key, credential, Exchange, Internal Use Case or authorization. To see crypto-agility at work, run a flow, rotate its key on the Keys screen, come back and compare the two runs.

What must exist first

A STANDARD or SIMPLE tenant. RAPIDAPI tenants are not offered this screen.
The tenant administrator or key manager role itself. Both carry the Playground permission, and only they do: a custom role cannot include it.
An Exchange or an Internal Use Case with operations on a key. A SIMPLE tenant works from Internal Use Cases only.
At most 10,000 readable authorizations on the tenant's Exchanges and Internal Use Cases, the most the Playground lists. Above that the list does not load until the unused ones are revoked.

You need no token and no credential of the Actor. The Playground never creates, recovers or reveals a credential. You can arrive here from an Exchange, an Internal Use Case, a key or the Get started card. A link opens the list searched for that item and grants nothing.

Decisions you make here

Finding a flow

Each card is one Exchange or Internal Use Case, with one section per key. It names the parties in words, such as IDEMIA sends to card-issuance or Within fraud-prevention, and each section offers one action per leg, naming the operation and the Actor that runs it, such as Decrypt as card-issuance-decryptor, and for a re-encryption or a re-signature the key it moves to: Re-encrypt as key-rotator → my-key-2.

Run round trip appears when the flow can both produce and consume on that key, and Test migration (re-encrypt) or Test migration (re-sign) beside each re-encryption or re-signature you can run when the flow can also encrypt or sign on its source key. When the target key is the next section, the migration test sits between the two. A section with nothing you can run shows only its reasons.

Search matches a key, a configuration, an application, a counterparty or an Actor name, and part of a name is enough: my-key also lists my-key-2. A listed card keeps all its keys, and each section names its exact key, so pick the one you mean.

Exchanges and use cases with nothing you can run now sit behind Show Exchanges and use cases that cannot run (on a SIMPLE tenant, Show use cases that cannot run), which gives their number in brackets, each with its reason in one sentence. A wildcard capability grant belongs to no configuration, so it is not listed here. To try one, use the SDK or the CLI with that Actor's own credential.

Running one operation

An operation opens a side panel with the operation, the Actor it runs as and the key. The panel says that the run is made under your delegation, for this run only.

Encrypt and sign open with sample text you can change. Decrypt, verify, re-encrypt and re-sign need an artifact. When the flow can encrypt or sign on the key the operation reads, an action such as Encrypt as card-issuance-encryptor runs that operation on the sample text, as the Actor of that leg, which can be another Actor than the one of your operation, and places its output as the input. Otherwise only Paste my own is offered, for an artifact you already have. With no input, the run button, such as Run Decrypt, stays disabled and says why.

This screen takes text only: it has no file upload and no streaming. When you encrypt or sign on its own, a counter shows the bytes of your text against the limit. The round trip and the migration test show no counter: text above the limit is refused with a sentence and nothing is sent. An artifact is held to the size limit of the whole request.

An operation limited in uses asks you to confirm first, because a run spends a use. Each person has a limit of run requests per minute. Every request counts, also one refused afterwards, for example because the configuration changed. When it is reached, wait the time the message states.

Running the round trip

Run round trip encrypts and then decrypts, or signs and then verifies, the same text, as two runs. It ends with one verdict: The flow works: the text came back unchanged., The flow works: the signature verified., The text that came back is not the text that went in., The signature did not verify., or a failed step, such as Step 2 failed: Decrypt as card-issuance-decryptor., with that step's reason under it. Each step keeps its own correlation id, history entry and HTTP exchange, and the round trip counts as two runs against your limit.

Testing a migration

Test migration (re-encrypt) and Test migration (re-sign) prove that a re-encryption or a re-signature leaves the content usable under the target key. The content moves between two keys that already exist, and no key version is created. The test runs up to three steps on the same text, each as its own Actor: encrypt on the source key, re-encrypt to the target key, then decrypt on the target key; or sign, re-sign, then verify under the target key.

The third step is looked for among the flows of the target key. When the target key has no decrypt or verify you can run, the panel says so before you start, and the test runs the first two steps only. When too many flows match the target key to find it, the test cannot run: narrow the key names, or run each leg on its own. A migration test is two or three runs. Each keeps its own correlation id, history entry and HTTP exchange, and each counts against your limit.

Keys, before and after shows the key, version and algorithm each step used. The verdict is The text came back unchanged, now protected by my-key-2. or The signature verified under my-key-2.; The migration ran. No Decrypt is configured on my-key-2, so the result was not opened. That is not a failure of the migration.; or a failed step, such as Step 2 failed: Re-encrypt as key-rotator., with that step's reason under it.

Running as an Actor

You never handle the Actor's token. For each run the platform issues a token for that Actor, valid for at most 60 seconds, and uses it for that one request. It never reaches your browser and is never shown. Both roles that hold this permission, the tenant administrator and the key manager, can run operations as any Actor of the tenant. They already hold that authority, because they can create and rotate an Actor's credential. The Playground records it: every run names you as the administrator and the Actor it ran as.

In a support-access session, only a platform super administrator, acting as the tenant administrator, reaches this screen. On a private cloud or on-premises deployment the runs are available: each one is recorded under your name, beside the Actor it ran as and the sign-in you opened support access from. On a deployment ANKATech operates, the flows are listed and runs are not available: a tenant administrator or key manager of the tenant runs them. A support session with any other platform role does not reach the screen, and an emergency-access sign-in never runs an operation.

Reading the result

The result shows first the outcome in words, then the Key ID, the version, the algorithm and Runtime's status. A value Runtime did not report says Not reported: it is never filled in from the configuration. Decrypted content is shown as plain text and never runs. A long value is cut on screen: Copy the whole value copies all of it.

Operation not authorized: Runtime refused the run. A configured operation does not override its decision.
Refresh the flow; nothing ran and … is not active, so nothing ran: the configuration changed after you read it, or the Actor that runs the operation is suspended or disabled. A suspended Exchange or Internal Use Case shows Refresh the flow; nothing ran.
Not executed: Runtime was never reached, or the authentication service failed or could not be reached. It is safe to run it again.
Not run: too many runs and Not run from this session: nothing ran. Too many runs were delegated in a short time, so wait a moment; or the session cannot run it: support access runs only on private cloud and on-premises deployments, and an emergency-access sign-in never runs an operation.
Not available for this session: Runtime did not accept the run's temporary access, or your session cannot run as an Actor, so running it again is refused the same way. Your console session is unaffected.
Execution status unknown: the run may have happened and no answer arrived. Trace its correlation id before you run it again. Nothing is ever retried for you.

A failure from Runtime after it admitted the run warns that a use may have been spent. In a SIMPLE tenant, Operation not authorized comes without Runtime's reason. In HTTP exchange, the Response tab replaces the body of any answer outside 2xx with a notice, because Runtime's text can name objects this tenant type does not use. The status, the correlation id and the Request tab stay, so the run can still be traced.

Developer tools

HTTP exchange and Copy as cURL are folded under the result. They show the request sent to Runtime and its answer, sanitised: the token appears as $ACTOR_TOKEN. The cURL text carries $RUNTIME_URL and $ACTOR_TOKEN for you to fill in, with a token your application obtains with the Actor's own credential.

Run history, beside the filters, opens the runs in a side panel with Compare executions: two runs side by side, with each run's Status. A run is compared by default with the latest earlier run of the same operation on the same key, which is the comparison that shows what a change such as a key rotation did. With none, the panel says so instead of comparing unrelated runs, and you can still pick another run.

The panel lists every run the history holds, the run being compared marked Latest run (or This run when you opened it on an older run), and only earlier runs can be picked. Changed marks a fact that differs and applies only to facts both runs reported. A result offers Compare with previous run when such an earlier run exists. The history keeps the last 20 runs as metadata only, never their content, and it ends on sign-out, on a tenant change and on reload.

Tracing a run

Each run has its own correlation id. It joins your record, which names you, the operation and the Actor, to Runtime's record of the operation, which names the Actor and you as the administrator who delegated it. The audit trace shows them together as run by you as the Actor. If an application calling Runtime directly reuses that correlation id, more than one Runtime record matches. The trace then shows the match as ambiguous rather than guess.

How it relates to other screens

The configurations are the ones you manage on the Exchanges and Internal Use Cases screens, and a correction is made there. Rotation stays on the Keys screen, and the audit trace shows every run: