Cryptographic Exchange Editor
What this screen is for
You are not editing six entities here. You are letting one of your systems call the cryptographic API. The wizard composes an application, a cryptographic actor, a key, an exchange context and an optional constraint policy into one cryptographic exchange. Calling it takes three things: a credential to authenticate with, an operation permission carried in the token, and a capability grant naming that actor, that key and that context. Activating the exchange creates the grant, and an active grant also confers the matching operation permission, so activation is what makes the exchange callable.
Each of those five things is reusable and has its own screen. What the exchange adds is a single managed lifecycle over the set: activate, suspend, resume and revoke act on the exchange and reach the grant underneath it, so one action stops or resumes the whole relationship instead of five.
The wizard is finished when your job is: an active exchange, an identity that can authenticate, and a capability the chosen key can actually perform. You never assign the operation permission by hand: the active grant carries it, and it goes when the grant goes.
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:
- The permission to read cryptographic exchanges, which is what shows this screen, and the permission to create one. Updating, activating, suspending, resuming, revoking and discarding an exchange are further permissions, each held separately. Activation needs one more where the grant would give the actor an operation permission it does not already hold: the permission to assign actor roles. Without it activation is refused and says which permission is missing.
- Nothing else has to exist in advance. Every reference the wizard asks for can be picked from what your tenant already has, or created without leaving the wizard with + New. That inline control needs both the permission to update the exchange and the permission to create that kind of thing; without either it is not offered, and you choose from the existing list.
Decisions you make here
The seven steps, and what is saved when
The tabs are 1. Overview, 2. Application, 3. Cryptographic Actor, 4. Cryptographic Asset, 5. Exchange Context, 6. Constraints, which is marked optional, and 7. Review and activate.
The exchange is saved as a draft as soon as it is created, and each later choice is written onto that draft, so you can leave and come back. If you create a related resource from another tab before naming the exchange, it is saved under the placeholder name Untitled Exchange and the wizard tells you so — open Overview and give it a real name.
A draft grants nothing. Until you activate, no capability grant exists and no request is authorized by this exchange.
1. Overview — naming the relationship
The Name is how the exchange is identified in lists and in the audit trail, so name it after the relationship rather than after the key. Business purpose is free text and is what a later reader will use to judge whether the exchange is still justified.
The optional validity window is a decision, not a label. You enter Effective from and Effective until in your display time zone, which the fields name, and the console sends them as exact instants; reopening the exchange shows them in your display time zone again. The exchange works from the start instant up to, but not including, the end instant, and every operation outside that window is refused at the moment it is made.
Reaching effective until ends the exchange by itself, terminally: it is then shown as EXPIRED and cannot be reactivated. Leave it blank unless the engagement genuinely ends on a known date.
2. Application — whose work this is
The application is the business system on whose behalf the work is done. It owns the relationship and it never authenticates.
3. Actor — the identity, and its credential
This is the step the wizard exists to get right.
The actor is the identity that will authenticate and call the platform, and its UUID is the client_id your integration will present. Naming an actor is not the same as giving it a way to authenticate: an application's Default Actor is created with no credential at all, so an exchange that names it could be active and still uncallable. An actor that belongs to an internal use case acts only for that use case: saving an exchange that names it is refused, and the refusal names the use case so you can choose another actor.
The step therefore shows the actor's credential state rather than leaving you to assume it — no credential, at least one (with how many), or that the list could not be read. Where there is none, it offers to issue one here.
- Shared secret: the platform generates the secret and shows it once, at that moment, keeping only a hash of it. Store it before you close the panel; 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, so no secret exists for anyone to lose.
Nothing is issued implicitly. A credential exists only where someone asked for one, here or on the actor's own Credentials tab, and both reach the same place.
Under support impersonation the issue and rotate actions are visible and disabled, with the reason stated: credential issuance is refused while an operator is acting as someone else, so no credential in your tenant can be attributed to a session that is not the account's own.
4. Asset — the key, and what it decides
The asset is the key the operations will use, chosen by its key identifier. The choice reaches further than this step: what the key is allowed to do is what step 7 will let you activate, so a key that can only encrypt and decrypt is a decision not to sign.
5. Context — the governed relationship
The exchange context records the counterparty, the direction the data flows and the business purpose, and it carries those into the audit trail of every operation performed inside it. Suspending the context stops all of the work bound to it, whichever grant would otherwise authorize it.
6. Constraints — the usage restrictions
The constraint policy is the set of usage restrictions the grant is created under: a validity window, a usage ceiling, a rate limit, single use. It is the one step you may leave empty. An exchange with no policy is activated with a grant that carries no usage limits — the summary and the review say so in those words — and that is a decision, not an omission; the platform accepts it as such. Bind a policy when the relationship should be bounded, and leave it empty when the credential and the key are the whole of the control you intend.
Activation pins the version of the policy current at that moment: a later edit of the policy does not change this exchange's limits. A single-use or usage-capped exchange becomes CONSUMED when its grant is used up.
7. Review & Activate — the capability, and the commitment
Validate checks that every required reference — application, actor, key and context — resolves and that they agree with each other; a constraint policy is not required. When they do, the exchange becomes READY. Until the four are chosen the control stays closed and names the steps still owed. Validation creates no grant and authorizes nothing.
The key must be a live key of your tenant (not deleted or destroyed; a suspended key, or one scheduled for destruction, still counts), and validating binds the exchange to that key. Activating and resuming check that the key identifier still names the same key and are refused if it now names a different one: a key destroyed and re-created under the same identifier is a different key. Validating a ready exchange again binds it to the key the identifier names now, and changing any reference returns it to draft.
Activate asks for one capability, and that capability is what the grant will authorize.
Activation accepts four capabilities: encrypt, decrypt, sign and verify. The two cross-kid operations — re-encrypt and re-sign — are not activatable from an exchange, because an exchange names one key and a cross-kid operation binds a pair of them; you grant those directly on the Capability Grants screen, naming both keys. Sending anything else to activation is refused.
Within those four, the list is read from the server: the wizard asks what activating this exchange would do and shows the answer, rather than working it out from the key. A capability the chosen key cannot perform stays in the list marked not available — selecting it shows the server's own reason and keeps Activate disabled — a silently shorter list would tell you nothing about why. Nothing is preselected: the permission activation confers follows from the capability you pick. If that read fails the wizard says so and offers none, without claiming none is available.
That read is not a separate opinion; it is the same check the write performs. Activation validates the capability against the key's stored operations and refuses one the key cannot perform, so the mismatch is caught here rather than at the first request. Activation is also refused while an operator is acting as someone else — that is checked before anything else — and refused when the actor is not active.
Activating is the commitment. It creates the capability grant and, for as long as that grant is active, the actor's tokens carry the matching operation permission — no role is written, so there is nothing to clean up afterwards. The exchange's references become read-only from that moment: only a draft or a ready exchange can be edited; an active, suspended, expired, consumed or revoked one cannot be re-pointed at a different application, actor, key, context or policy. To change one of them, revoke this exchange and compose another — cloning it is the shortcut.
Suspending, resuming and revoking
Suspend stops every operation the exchange authorizes and is reversible; resume puts it back. Revoke is terminal and cannot be undone. Neither takes effect the instant you click it: a token the actor already holds stays valid for the rest of its life, up to 900 seconds by default, and the platform's grant cache can serve a withdrawn grant for up to 300 seconds more. Plan for the sum of the two, and use the audit trail rather than a probe to confirm.
Suspend and revoke each require a written reason, which is recorded in the audit trail against your account and cannot be edited afterwards. Resume asks for none: restoring a capability raises no question that the trail has to answer. A suspended exchange cannot be validated again, so when resume is refused because its key identifier now names a different key, revoke it and validate a clone.
An ended exchange — expired, consumed or revoked — opens read-only: no save, suspend, resume, revoke or discard, only Clone. It shows why it ended, when, the reason recorded and, when a key's destruction ended it, the identity of that key. A consumed exchange shows Consumed — grant used up; to continue the relationship, clone it and activate the clone, which takes a fresh grant under the policy's current version.
How it relates to other screens
The five things this wizard composes each have their own screen, and anything created here appears there:
Activating an exchange creates exactly one capability grant, which is listed with the others and stays bound to this exchange:
Every operation performed under an active exchange is attributed to its actor and carries its context: