Applications

A second team’s application can fetch a report’s Envelope but is initially refused its decryption material. The report remains in storage for six months. A later sharing decision changes the Policy to admit that team to the relevant historical reports. The application makes a fresh Retrograde request using the report’s Attribute Set and Lease Reference. The Key Service evaluates the requested operation and the caller’s established Claims against the revised Policy.

The stored Envelope has not changed. Within this arrangement, the newly authorised application can read the original report without a second storage service, another archive copy or re-encryption for that reader. The change concerns access to retained information, rather than a replacement delivery path.

Six months describes retention, not the lifetime of a Lease. The archive and Key Service must preserve the means to decrypt. This admits a reader through an existing Key Service; it neither adds an unprepared federation partner nor demonstrates revoking keys or plaintext already obtained.

The producer obtains an authorised Lease for each Attribute Set. With Non-Captive Lease Keys and valid cached Leases, it encrypts further Messages locally, using the same applicable Lease Key with the required per-Message encryption parameters. A short sequence of readings therefore does not require a fresh Prograde request for every event. Expiry or invalidation prompts new resolution; cached Leases do not promise an instantaneous transition during Rollover.

The broker carries the Envelopes without receiving the decryption keys. Each consumer requests access for its permitted product. The Key Service evaluates its Claims, the Attribute Set and the operation. This separates product permissions while amortising key resolution across frequent exchanges. Envelopes sharing usable key material still share that access boundary; the example makes no throughput or latency guarantee.

Each producer protects its contributions using the appropriate Attribute Set. Shared relays and storage carry the Envelopes to consuming applications. A field application may obtain keys for position reports and selected observations, while an analysis application also receives access to satellite products. The Key Service evaluates each request using that application’s established Claims, the contribution’s Attributes and the requested operation.

Any application correlating, fusing or displaying plaintext contributions is an authorised reader. The diagram places this work inside the consuming applications, not inside the encrypted relay. Those applications remain responsible for interpreting compatible reports and constructing their views.

CABE supplies a common Envelope and key access mechanism for independently developed applications. It does not translate Payload formats or reconcile independently chosen Attribute meanings. Contributions to a common operating picture can therefore have different audiences: a shared picture does not require every participant to read every underlying report or see an identical view.

The publisher prepares both products, digitally signs their content and application-level order identifiers and revisions, then protects them in CABE Envelopes under authorised Leases. A complete order is one opaque Payload: CABE does not selectively reveal its internal paragraphs. The publisher applies release rules when selecting each product’s content; shared messaging and storage services carry the Envelopes without decrypting or redacting them.

Recipients authenticate to the Key Service and request the material for their permitted products. Policy evaluates their established Claims, the Attributes and the requested operation. Retrieving an Envelope is not permission to read it. Separate Envelopes are not independent access boundaries where the same usable key material spans them.

When tasking changes, the publisher prepares a signed amendment for each affected product. It can be much smaller than the original order while using the same Envelope format and key access mechanism. The amendment identifies its order, base revision and resulting revision within the application’s signed content.

After recovering the protected information, the receiving application verifies the signature against its configured issuing-authority keys and checks that the issuer is authorised for that product. CABE’s symmetric authentication alone does not uniquely identify an issuer among holders of the same key. The application checks the amendment’s order and base revision against its local copy before applying it and updating its view; mismatches require reconciliation through the application’s workflow.

Tasking validation and supersession remain application responsibilities. Order identifiers and revision relationships are application data, not CABE fields or operations. Publishing a new revision does not erase earlier plaintext, recall obtained keys or guarantee that every recipient has the latest order.

Application responsibilities can use existing components. An ATO application can use an authorisation engine such as Cedar to decide whether an authenticated issuer may issue or amend a particular tasking product. The application supplies verified issuer information and relevant order context, then enforces the decision. This is separate from authorising access to key material, for which the reference Key Server khaled supports Cedar. Signature verification and maintaining, applying and reconciling revisions remain part of the surrounding application integration. CABE does not require a particular policy language.

Each producer obtains a Lease for the appropriate Attribute Set and protects the encoded media as CABE Messages before publication. While its cached Lease remains valid, it can encrypt further units with the same Attribute Set locally, using the required per-Message encryption parameters. A shared relay forwards the resulting Envelopes without receiving their decryption keys.

Receiving applications authenticate to the Key Service and request the material for the arriving Envelopes. Policy evaluates the caller’s established Claims, the channel Attributes and the requested operation. Authorised applications decrypt locally, recover the encoded media and pass it to their decoders. Key access is separate from the media delivery path; successive chunks can use a valid cached Lease without a Key Service round trip for every chunk.

Splitting a stream into units does not itself create independent permissions. Access boundaries follow the usable key material, and a later refusal cannot recall keys or media already obtained. A service performing plaintext mixing, transcoding or analysis would be an authorised processor with its own access arrangement; the relay shown here only forwards encrypted media.

This is an architectural use of CABE. Latency and throughput depend on the media applications, implementation and network, and require measurement in the system being built.

The producer assigns the agreed Attributes and obtains a Non-Captive Lease Key. It encrypts the observation before passing the Envelope to a shared delivery path. Brokers, gateways and caches forward the same protected object without being given its decryption key. They are intermediaries, distinct from the application entitled to read the report.

The field application requests decryption material using the Envelope’s Attribute Set and Lease Reference. The Key Service evaluates the caller’s established Claims and the requested operation under the configured Policy. If access is permitted, the application decrypts the observation locally.

The direct sharing relationship is between the publishing and consuming applications despite the intervening transport. This is an example design, not a deployed system or a promise of real-time delivery; the field application still needs a usable delivery path and the stated key access arrangement.

The sending application obtains an authorised Non-Captive Lease Key and encrypts each Message locally. A valid cached Lease can serve further Messages with the same Attribute Set. Radios and relays transport the resulting Envelopes between endpoints, but they do not receive the application decryption keys.

The receiving application authenticates to the Key Service and requests the material needed for the arriving Envelope. Its established Claims, the Message’s Attributes and the requested operation determine the access decision. Once authorised, it decrypts at the endpoint; the mesh continues to handle only the protected traffic.

This permits reuse of an available transport path without making every transport operator an authorised reader. The dashed relationships in the diagram represent key access, rather than a claim that key requests require physically separate radios. The surrounding network supplies connectivity; CABE supplies protection for the application objects carried over it.

During Prograde Resolution, the Origin Domain’s Key Service prepares a Federated Lease Package (FLP) for the included Target Domain. The producer attaches the applicable FLP to the Envelope. Both travel through the delivery path; the intermediary needs neither the plaintext nor the Lease Key.

After delivery, the recipient quotes the Origin Domain, Attribute Set, Lease Reference and FLP in a Retrograde request to its local Key Service. The service decrypts and verifies the package, checks that the identifiers match the request, and evaluates the recipient’s access. It can recover the same Lease Key material without contacting the Origin Domain.

The Origin Domain does not need to be online at the moment of reading. A prepared federation relationship, usable package and functioning local Key Service are still part of this design. The Target Domain’s service is trusted with recovered key material; it has a different role from the carrier transporting ciphertext.

The processing application requests access to the input Envelopes as its own authenticated Principal. The Key Service checks its Claims and requested operation against each input’s Attributes. With permitted Non-Captive key access, it decrypts the observations locally and performs the analysis inside an explicitly trusted processing boundary.

The application determines what may be released, including any required sanitisation or redaction, constructs a new Message, assigns that result its own Attribute Set and obtains an authorised output Lease. It encrypts the result into a separate Envelope. A recipient authorised for the result can request its key without being granted access to the restricted input material.

The processing system makes and enforces the release decision. CABE protects the separately published objects; it does not sanitise or declassify their Payloads, propagate policy automatically, or turn the original ciphertext into a releasable result by changing its labels.

The coordinator sends each worker a task and an object reference. The workers fetch protected inputs from shared storage and request the required material from the Key Service as their own Principals. A task reference locates an object; it is not itself an entitlement to decrypt it. Policy checks the worker’s established Claims, the input’s Attribute Set and the requested operation.

The diagram separates dotted task/reference traffic, solid encrypted delivery and dashed key access. The analysis worker is permitted observation access and refused equipment-status access; the maintenance worker has the converse permissions. Each permitted worker becomes a trusted plaintext-processing participant for its own inputs.

The coordinator does not need every input key to dispatch work. The surrounding workflow must still authorise tasks and constrain what workers do with their results. This example uses direct worker authentication, without claiming a CABE transitive identity protocol or protection against every misuse of a worker by a malicious coordinator.

A trusted task authority authenticates the analyst and checks the authority granted to the planning application and processing service for the requested observations. It issues a signed, short-lived task credential bound to the requester, task, scope and intended worker. The Key Service’s authentication integration verifies the issuer, signature, validity and worker binding, then maps the verified service, requester and task information into Claims on the authenticated Principal. Forwarded names or task identifiers alone supply no authority.

The worker fetches the protected observations and makes an ordinary CKAP Retrograde request with the Attribute Set and Lease Reference. Policy evaluates the established Claims, Attributes and requested operation. For the same processing service, Task A with permitted requester and scope is allowed; Task B outside that scope is refused. These are separate executions starting without the input material, not a sequence in which a worker forgets keys it has already obtained.

The task credential, authority checks and execution isolation are supporting integration choices, not CABE delegation fields or a new CKAP operation. Refusing a fresh request would not constrain a worker that already held usable input keys, CEKs or plaintext.

Records can associate the original task, acting services, requested information and key access decisions. Application-side events record local decryption or use separately. Key Service logs do not record every local decryption, and correlating these records does not by itself establish complete, tamper-proof provenance.

The producer encrypts both products before uploading their Envelopes to a common collection service. The supplier can fetch the collection’s protected objects, but its established Claims permit key access for fault records only. A request for operational-observation key material is refused. The operator’s application has the observation access required for its own work.

The Key Service applies the product distinction when evaluating each requested operation. The collection service stores and delivers ciphertext without holding either product’s decryption keys. Supplier access therefore does not require duplicating the whole collection system or giving the supplier the complete operational dataset.

Selecting the diagnostic content is an explicit publishing decision. CABE does not inspect an operational Payload and strip sensitive fields from it. The supplier is an authorised plaintext recipient for the fault records it obtains, so the example does not imply that those records can later be recalled from its possession.