Cryptographic Exchanges
What this screen is for
A cryptographic exchange is one application's authorization to use one key for one operation, composed with a cryptographic actor, an exchange context and an optional constraint policy, and managed as a single lifecycle. This screen lists every exchange in your tenant in every state, from the draft you left half-composed to the one revoked long ago. From here you see which relationships are live, open one to work on it, and start a new one.
The composing happens elsewhere. Opening a row or pressing New exchange takes you to the editor, which is where an exchange is named, validated, activated, suspended and revoked:
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. The sidebar entry is shown whether or not you hold it, so without it the screen opens and reports the refusal where the list would be.
- The permission to create cryptographic exchanges, for New exchange. Without it the control is shown disabled and says which permission to ask for. On a RAPIDAPI tenant, where the platform creates the exchanges, the control is not shown at all.
- Nothing else. Every reference an exchange needs can be picked from what the tenant already has, or created inside the editor.
Decisions you make here
Reading the list
Each row shows the exchange's name, its status, the counterparty, the application, the validity window and when it was last modified. The counterparty is read from the exchange context the row references and the application from the application it references, so a draft that has not chosen them yet shows a dash. A draft you discarded in the editor no longer appears.
The status is the exchange's own lifecycle: DRAFT while it is being composed, READY once validated, ACTIVE while its capability grant authorizes operations, SUSPENDED while that is paused, and EXPIRED, CONSUMED or REVOKED once it has ended for good. None of the last three can be reopened.
CONSUMED means the grant was used up: its single use was taken, or its maximum number of uses reached. It is fulfilled authority, not a revocation. An ended exchange shows why it ended in place of the bare status: Expired, Consumed — grant used up, Revoked by an operator, Revoked — key destroyed, Revoked — tenant closed or Revoked — application deleted.
Four things end an exchange without anyone pressing a button on it. An exchange stops working at its effective until instant: from then on every operation is refused, and the expiry job, which by default runs every hour, then shows the active exchange as EXPIRED, so the status can lag the end by up to a run.
A suspended exchange past that date stays SUSPENDED and expires only after it is resumed.
An exchange whose grant is used up becomes CONSUMED, usually within seconds of the use that exhausted it; the grant is refused from that use on, even while the status still says ACTIVE. Deleting an application revokes every exchange that belongs to it. Destroying the key an exchange names revokes the exchange in any status that has not ended — draft, ready, active or suspended.
The status does not reflect the state of the exchange context. Suspending or closing the context, on its own screen or from the topology, stops every operation bound to it, but the exchange keeps saying ACTIVE here. Read the context's status before concluding that a relationship is live.
Filtering and sorting
The three filters combine. All statuses narrows the list to one status, CONSUMED included. Counterparty matches part of the counterparty name, ignoring case, against the referenced context: a draft with no context, or a context with no counterparty recorded, never matches. Search by name matches part of the exchange's name, ignoring case.
The list is sorted by last modified, newest first. You can sort by name, status, effective until or creation date instead, or click a sortable column header to toggle it. Pages hold twenty rows. When a filter leaves nothing, the screen says which filters are applied and offers to clear them, so an empty page is not mistaken for an empty tenant.
Opening an exchange
Clicking a row opens that exchange in the editor, whatever its status. What the editor offers depends on the status: a draft can be completed, validated, activated or discarded; an active exchange suspended or revoked; a suspended one resumed or revoked; an expired, consumed or revoked one only read. Any exchange can be cloned into a new draft. For an ended exchange the editor also says why it ended, when, the reason recorded and, when a key's destruction ended it, the identity of that key, which tells it apart from any key that holds the same identifier today.
Creating an exchange
New exchange opens the editor on a new exchange. It is saved as a draft as soon as its first step is complete and appears in this list from then on, so leaving the editor loses nothing. A draft grants nothing until it is activated.
How it relates to other screens
The counterparty column comes from the exchange context. The context, its counterparty and its status are managed on their own screen, and suspending it there is what stops an exchange's operations without changing the exchange's status here:
Activating an exchange creates exactly one capability grant, which is listed with the others and stays bound to the exchange:
The topology draws the exchange contexts your exchanges are composed on, with the actors, capabilities and keys their grants cover:
Deleting an application revokes its exchanges:
Destroying a key revokes the exchanges that name it, and the Key Inventory says how many before you confirm: