Skip to content

Exchange Contexts

What this screen is for

An exchange context models one governed business scenario in which cryptographic work happens: card embossing with a card brand, collections with an outsourcing provider, reporting to a regulator, or an internal pipeline. It records the scenario's business purpose, how sensitive its data is and, when one applies, its regulatory regime. It belongs to your tenant, not to an application, and names no counterparty or direction: those belong to the exchanges created in it.

Every cryptographic exchange and every capability grant belongs to exactly one context, so one action on the context stops or ends all of that work at once.

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 create the context each use case needs.

Before you work here you need the permission to list exchange contexts, which shows this screen. Creating, editing, suspending, reactivating, closing and deleting a context are further permissions, each held separately.

Decisions you make here

Creating a context

With the permission to create exchange contexts, New Exchange Context asks for:

  • Name * (slug), required: lowercase letters, digits and hyphens, unique among your tenant's contexts. It cannot be changed afterwards.
  • Display Name, a Business Purpose and a Sensitivity: the classification of the data, PUBLIC, INTERNAL, RESTRICTED or CONFIDENTIAL. Sensitivity is a label for the people reading the screens; no authorization decision reads it.
  • Regulatory regime, optional free text such as PCI DSS.

The context is active as soon as it is created.

Opening a context

Selecting a context opens its detail beside the list, with the tabs Info, Edit, Lifecycle and Activity. Info shows the context's record and its Owner: This tenant, or the internal use case that owns it. A context an internal use case owns admits only that use case's grants: it cannot be chosen for an exchange or a standalone grant, and it ends only when the use case is revoked.

Edit changes the display name, description, business purpose, sensitivity and regulatory regime. The name never changes.

Suspending and reactivating

Suspend on the Lifecycle tab stops the scenario at once: every grant in the context is refused, whatever owns it. You must give a Reason for suspension, which is recorded in the audit trail against your account. Nothing is revoked: Reactivate returns the context to active, and the same grants authorize again.

Closing a context

Close (terminal) ends the scenario for good. The confirmation lists What closing ends: the exchanges that will be revoked and how many grants in force will be retired, whatever owns them. Type the context's name back and give a Reason for closing, which is required and recorded in the audit trail. A closed context can never be reactivated, and its exchanges, grants and history stay readable.

Suspend when the scenario will resume. Close when it has ended.

Deleting a context

Delete (permanent) is offered for a closed context, and you confirm it by typing the context's name. A deleted context cannot be restored.

Reviewing activity

The Activity tab shows the operations performed inside the context and the changes made to it. All, Administration and Usage choose between both, the changes only, and the operations only. View in Audit Log opens the Audit Log narrowed to this context.

How it relates to other screens

Exchanges and grants are placed in a context when they are created:

The topology lists exchanges grouped by context:

Where to read more