Authentication
TCF supports multiple authentication mechanisms, negotiated during connection:
- Bearer tokens (JWT or opaque) — most common for client connections
- mTLS — for server-to-server communication
- OAuth 2.0 — for third-party integrations
All connections must use TLS 1.3 (i.e., wss://, https://).
End-to-End Encryption (E2EE)
TCF provides an optional E2EE envelope using the MLS (Messaging Layer Security) protocol or Double Ratchet for smaller groups.
"content": {
"type": "encrypted",
"scheme": "mls/v1",
"group_id": "group:abc123",
"epoch": 42,
"ciphertext": "base64-encoded..."
}
Message Signing
Messages can be cryptographically signed for non‑repudiation. Signatures use Ed25519 keys and are placed in the optional signature field of the envelope.
"signature": {
"algorithm": "ed25519",
"key_id": "key:alice-ed25519-2026",
"signature": "base64url-encoded..."
}
Threat Model
TCF assumes the following threat actors:
- Network observers — mitigated by mandatory TLS
- Compromised servers — mitigated by E2EE
- Impersonation — mitigated by signed messages
- Replay attacks — mitigated by unique message IDs and timestamps
Best Practices
- Always validate
tcf_version before processing
- Reject messages with future timestamps (allow clock skew ≤ 30s)
- Rate limit per sender ID
- Sanitize HTML content to prevent XSS
- Log all authentication failures