Skip to content

Cryptographic Exchange Editor

What this screen is for

A cryptographic exchange is one directed relationship: an origin and a destination, each one of your applications or an external counterparty, inside one exchange context, with the capability grants that say which identities may do what, with which keys, under which limits. The editor composes it in five steps and gives the whole relationship one lifecycle: activate, suspend, resume and revoke act on every grant the exchange owns.

Calling the cryptographic API takes a credential, an operation permission carried in the token, and a grant. A grant of an active exchange supplies the permission as well, so activation is what makes the exchange callable.

What must exist first

This screen is for tenants that compose authorization by hand. It is not offered to SIMPLE tenants, which use Internal Use Cases.

Before you work here:

  • The permission to read cryptographic exchanges and the permission to create one. Updating, activating, suspending, revoking and discarding are further permissions. Adding a grant also needs the permission to create capability grants, and revoking one the permission to revoke them.
  • The applications at the endpoints, and an actor of one of them for each grant. An exchange context can be created from the editor with New Exchange Context.

Decisions you make here

The five steps, and what is saved when

The steps are Overview, Endpoints, Exchange Context, Grants and Review and activate. The draft is saved once both endpoints and a context are chosen, and grants are added to the saved exchange. A draft authorizes nothing.

Overview — naming the relationship

Name (required) identifies the exchange in lists and in the audit trail. Business purpose is what a later reader uses to judge whether the exchange is still justified.

The optional validity window is a decision. You enter Effective from and Effective until, exclusive in your display time zone, which the fields name. Every operation outside the window is refused when it is made, and reaching the end ends the exchange for good.

Endpoints — who sends and who receives

Choose the Origin and the Destination: each is One of your applications or an External counterparty, named, with an optional counterparty type. At least one end must be one of your applications. The editor shows the derived Relationship: Same application (A → A), Internal (A → B), Outbound (A → external) or Inbound (external → A). Direction is enforced: a grant authorizes its operations from origin to destination only.

Exchange Context — the governed frame

The context is the business scope this exchange, and every grant in it, operates in: its purpose, sensitivity and regulatory regime. Suspending or closing the context stops all of them. A context that an internal use case owns cannot be used here. The context cannot change while the exchange has grants: revoke them first, or create a new exchange in the other context.

Grants — who may do what

Add grant opens a form: the Cryptographic Actor, chosen among the actors of the endpoint applications, and what the grant authorizes. Operations on a key takes one or more of encrypt, decrypt, sign and verify over one Key. Re-encrypt or re-sign takes one Operation over one or more Key pairs (source → target); data under each source key moves to its target key, in that direction only, and the target must be active. Constraint Policy (optional) sets the limits. The grant pins the policy's current version.

Each grant in the list shows its actor, operations, key or pairs, policy and version, and its state: Live, Consumed or Revoked. A grant with several operations has one usage budget, which the list says.

A grant that would overlap a live grant of the same actor, in any context, is refused, and the conflicting grants are listed as links. An actor outside both endpoint applications is refused.

The step also shows whether each actor can authenticate. Where an actor holds no credential, Issue a credential issues one, and its secret is shown once.

Changing a grant's version, and revoking one

Change version pins a grant to another version of any constraint policy, from its next request on. When the grant had no usage limit, uses made before do not count toward the new limit; otherwise the grant keeps the uses it has already counted.

Revoke grant asks you to type the actor's name back and give a Reason, which is required and recorded in the audit trail. The exchange keeps its other grants. The last live grant of an active or suspended exchange cannot be revoked alone: add another grant first, or revoke the exchange.

Review and activate

Validate (DRAFT to READY) checks that every reference resolves; it creates nothing. Activate (every live grant, in one write) opens a confirmation that lists each grant with its capabilities, keys or key pairs, policy, and the operation permission activation will confer. Activating makes every live grant authorize; an exchange with no live grant cannot be activated. A token already issued keeps its old permissions for up to 900 seconds, plus up to 300 seconds of grant cache.

Once active, the endpoints and the context are read-only. Grants can still be added, revoked and re-pinned. To change an endpoint, clone the exchange.

Suspending, resuming and revoking

Suspend stops every operation of the exchange and is reversible; resume restores the same grants. Revoke is terminal and retires every grant. Suspend and revoke each require a Reason, recorded in the audit trail against your account; resume asks for none. None takes effect instantly: allow up to 900 seconds of token life plus 300 seconds of grant cache.

An ended exchange opens read-only with Clone only. It shows why it ended, when, and the reason recorded.

How it relates to other screens

Where to read more