End-to-End Encryption of Case Content

The model

What the Platform Can and Cannot Read

Without E2EE, case content is encrypted in transit and readable by the platform: Connect renders it in the web app, sanitizes it, and stores it as text. End-to-end encryption removes the platform's ability to read a named set of fields. The keys live at each member's own connector. Connect's part is to store two extra fields, return everything exactly as it was submitted, and stay out of the cryptography.

The field list above is what the one implementation protects. A draft specification from the TSANet E2EE workgroup defines the authoritative list, the encryption and manifest profile, a per-relationship opt-in model, and test vectors. It is not public, so this page is read from the implementation and the API, which are.

The API contract

Two Fields, Stored and Never Read

The platform's whole contribution is two optional fields on collaboration requests and notes. manifest is an opaque Compact JWS that the receiving connector uses to verify what it got. encrypted says whether the content is encrypted. Connect stores both and returns them exactly as submitted. It never parses or changes them, and it does no cryptography.

• Every read surface carries them: the POST response, GET …/{token}, the list endpoints, and the notes timeline, for sender and receiver alike.
• A non-boolean encrypted is a 400, and nothing is created. A manifest that is not a JWS is stored anyway, because the platform does not look.
• The case keeps its fields through its whole life: information request and response, approval, rejection, closure. The system notes those transitions generate are always encrypted: false with no manifest.
• Webhooks carry nothing to protect. v2 events hold tokens only, so a receiver fetches by token as usual and the manifest comes back with the content.

The one implementation

How the Dynamics PoC Encrypts, Signs and Verifies

The Dynamics connector carries the only working implementation, in TSANETBasePlugins/E2ee. It names its profile tsanet-e2ee-1. Read here at main 0586c96 as a worked example of the shape, not as the specification.

• 1Each protected field becomes its own JWE, in general JSON serialization: a fresh 256-bit content key, A256GCM. The protected header binds the profile, the manifest's jti and the field's name (tsa_ver, tsa_jti, tsa_fld), so a ciphertext cannot be moved to another field or replayed onto another request.
• 2The content key is wrapped twice with RSA-OAEP-256: once for the partner, and once for the sender's own key, so the sender can still read its own outbound case.
• 3One manifest signs the lot. A Compact JWS, ES256, typ: tsanet-manifest+jws, holding a SHA-256 digest of each encrypted value exactly as sent. That means one signature per request or note rather than one per field, and a single record of who sent what to whom.
• 4The receiver verifies before it decrypts: the signature against the sender's published key, then the recipient binding, then that the set of fields matches the manifest, then each digest against the value Connect returned. Only then does it unwrap and decrypt. Any failure stops processing with a named reason. It never falls back to showing the raw value.

// manifest claims, decoded (values illustrative)
{
  "ver": "tsanet-e2ee-1",
  "iss": "<sending member>",   "aud": "<receiving member>",
  "jti": "<unique per request or note>",  "iat": 1761600000,
  "ref": "<sender's case number>",
  "fields": [
    { "name": "problemSummary",     "alg": "S256", "dig": "<base64url>" },
    { "name": "problemDescription", "alg": "S256", "dig": "<base64url>" }
  ]
}

Keys. The private keys live in Azure Key Vault. The plugin asks the vault to sign and to unwrap, so the private key material never enters Dynamics. The two key ids are set as the environment variables ap_SigningKeyId and ap_UnwrapKeyId. Partners' public keys come from their JWKS URLs, configured as settings: one encryptedRecipient for the partner it encrypts to, and a signingKeyCounterParty for each sender it accepts.

Its failure reasons give a checklist for any receiver you build: ManifestMissing, SignatureInvalid, BindingMismatch, FieldSetMismatch, FingerprintMismatch, NoMatchingRecipient, AeadFailure, HeaderBindingMismatch.

Adoption

Where Each Connector Stands

Both members on a case need E2EE support for it to work. Nothing in the platform checks that the receiver can decrypt before an encrypted case is sent.

Sharp edges

What Breaks First

• The API rewrites some ciphertext on create. Connect runs problemDescription and note summary and description through its HTML sanitizer whatever encrypted says. The sanitizer stores every " as ", so the value is no longer JSON and its digest no longer matches the manifest. Observed on Development on 2026-10-23 for problemDescription; problemSummary came back intact, and the note paths call the same sanitizer in the source. A fix is requested from the platform. Until it lands, a receiver has to HTML-decode a protected value that starts {" before computing its digest, as the Dynamics PoC does in PayloadFieldMap.cs. It is the same rewrite behind note content coming back as HTML.
• Encrypted values outgrow the spec's limits. A JWE runs to roughly 1,200 characters even for an empty field. The spec caps problemSummary and note summary at 500 characters, yet Development accepted a 1,237-character encrypted problemSummary. The spec and the server disagree, and the note limit has not been tested. needs probe
• The PoC encrypts to one partner, for every case. Its encryptedRecipient setting is a single record, and the plugin does not compare it with the case's receiver. An org with it set encrypts every outbound case and note to that one partner's key, whoever the case is addressed to. Configure it only in an org that sends to that partner alone. Source-read, not probed.
• Decide what an unencrypted note means. On an encrypted case, the notes Connect writes are legitimately plaintext. A partner note with no manifest is unauthenticated by definition, because only the platform could have vouched for it, and it holds no keys. Your receiver needs a rule for that case, not a default.
• Treat the manifest as bytes. Trimming, re-encoding or re-serializing it, or any protected value, breaks verification at the far end. The platform does not change it; make sure your own stack doesn't either. The spec sets no maximum size for manifest.
• The web app shows what is stored. Anyone viewing an encrypted case in the Connect web app sees ciphertext in the protected fields. That is the point, and it also means the web app is no longer a fallback for reading the case.

Verified against

Sources, with the Dates That Were Read