Link Search Menu Expand Document
tsrct documentation

Confidential Information Exchange (CIX)

The Tsrct protocol allows organizations to share highly sensitive information—such as medical records, financial histories, or compliance reports—in a decentralized yet strictly permissioned manner. We call this architecture the Confidential Information Exchange (CIX).

While standard private documents (using acl: acl_pri and tgt: <UID>) restrict access to a single, known recipient, CIX enables a more powerful paradigm: Role-Based or Credential-Based Access Control.

Instead of specifying exactly who can read the document, the publisher specifies what credentials the reader must possess to unlock it.

The CIX Concept

In a CIX workflow, a document is published with acl: acl_pri, but the tgt field is completely omitted. Instead, the document’s header includes a cix (CIX Policy Pointer) field.

Because T-Docs are cryptographically immutable, hardcoding access rules directly into a document’s header means the access policy can never be changed. By using a Policy Pointer, the confidential document remains immutable, but the publisher can update the access rules by publishing a new version of the Policy Document.

If an agent or user requests the document, the Tsrct network resolves the pointer to the latest active Policy Document. It then checks if the requester’s X-TSRCT-AUTH JWT proves they possess a valid, non-revoked DDX matching the rules defined in that policy.

1. Defining the Policy Document

To define access rules, you must publish a standalone T-Doc with the class cls: cix. This document contains the actual logical rules (any or all) detailing which DDX credentials grant access.

Example cls: cix Document Body 

{
  "any": [
    {
      "type": "ddx",
      "iss": "2222222222222222222222222", 
      "scm": "2222222222222222222222222.ddx-super-schema-v1",
      "sub": "tsrct:compliance-auditor"
    },
    {
      "type": "ddx",
      "iss": "3333333333333333333333333", 
      "scm": "3333333333333333333333333.partner-schema",
      "sub": "partner:senior-investigator"
    }
  ]
}

Field Breakdown:

  • any / all: Logical grouping. any grants access if at least one credential matches. all requires the requester to hold all listed credentials.
  • type: The type of credential required (currently, ddx is the standard).
  • iss (Issuer): The exact 25-digit UID of the organization that must have issued the DDX.
  • scm (Schema): The schema the DDX must conform to.
  • sub (Subject): The specific subject or role the DDX must grant.

In the example above, access is granted if the requester holds an auditor DDX from Org 222… OR an investigator DDX from Org 333…

2. Publishing a CIX Document

To publish the confidential document, you prepare your payload as normal. However, you will include the --cix flag pointing to the UID of the Policy Document you created in Step 1, and you will explicitly omit the --tgt flag.

Step A: Prepare Payload

confidential-audit-log.json:

{
  "auditId": "AUD-2026-X99",
  "findings": [
    "Critical vulnerability found in legacy subsystem.",
    "Unencrypted data resting in volume 4."
  ]
}

Step B: Execute CLI Command 

tsrct tdoc doc-create \
  --typ json \
  --cty application/json \
  --input confidential-audit-log.json \
  --src <YOUR_ORG_UID> \
  --uid confidential-audit-log-001 \
  --dsc "Q1 Internal Audit Log" \
  --acl acl_pri \
  --lst false \
  --cix <YOUR_ORG_UID>.my-audit-policy-001 \
  --key <YOUR_KEY_ID> \
  --key-host gcp \
  --sig-key-resource <YOUR_GCP_KMS_SIGNATURE_KEY_RESOURCE_PATH>

3. Retrieving a CIX Document

When a party wishes to retrieve this CIX document, they utilize the standard Tsrct retrieval endpoints (e.g., GET https://api.tsrct.io/<DOCUMENT_UID>).

They must provide a valid X-TSRCT-AUTH JWT.

The Evaluation Process

Unlike standard private documents where the API simply checks if jwt.iss == document.tgt, the CIX evaluation is a multi-step resolution process:

  1. JWT Authentication: Tsrct validates the caller’s JWT signature and expiration.
  2. Policy Resolution: Tsrct detects the cix pointer in the requested document’s header. It queries the Datastore to resolve this pointer to the latest active sequence of the Policy Document.
  3. DDX Resolution: Tsrct queries its internal Datastore for all active, non-revoked DDX credentials where tgt == jwt.iss (credentials held by the caller).
  4. Matching: Tsrct evaluates the caller’s active DDX credentials against the logical any / all rules defined in the resolved Policy Document.
  5. Delivery: If the policy rules are satisfied, the caller is granted access and the document is served. If the rules are not met, the request is rejected with 401 Unauthorized.

This flow ensures that highly confidential data can be securely staged on the Tsrct network, accessed instantly by authorized parties based on dynamic, updatable policies—without breaking the immutability of the underlying data payload.