ZKAC/docs/WHITEPAPER.md

Trustless Federated Authorization

Abstract

Internet services traditionally rely on trusted servers for authentication, authorization, and routing. Blockchains reduce server trust through global consensus, but impose substantial latency, replication, and operational cost. This whitepaper presents a third model: trustless federation. In this model, nodes still host registries and provide service endpoints, yet cryptographic protocol design limits what a malicious node can learn or forge. Authorization is proven with transcript-bound zero-knowledge credentials, credential transfer is end-to-end encrypted, and policy state is verifiable by clients. The result is a practical system positioned between classical TCP/IP client-server trust and blockchain-style distributed consensus.

1. Idea and Motivation

1.1 The gap between two worlds

Modern networking stacks solve transport and connectivity well, but application trust usually collapses to "trust the server operator." At the other extreme, blockchains attempt to remove this assumption by making consensus globally replicated and tamper-resistant.

Both models work, but both have trade-offs:

• Client-server model: efficient, low latency, but high operator trust.
• Blockchain model: low operator trust, but expensive consensus and reduced throughput.

The central idea of this protocol family is to provide an in-between layer:

• Federated nodes exist (for hosting registries and serving traffic).
• Those nodes are treated as potentially malicious.
• Cryptography prevents nodes from learning protected credential data or forging authorization.

1.2 Privacy-first motivation

For privacy-sensitive services, users want to prove permissions without exposing stable identity. If this protocol runs over anonymity overlays such as Tor or I2P, network-level identifiers become less meaningful, and the protocol can support anonymous service access with minimized trust in servers.

2. Design Goals

The system targets the following properties:

• Trustless authorization: a node should not be able to forge client permissions.
• MITM resistance: authentication material must be bound to the actual session.
• Anonymous authorization: verify "is authorized" without requiring real-world identity.
• End-to-end credential confidentiality: transfer should be unreadable to intermediaries.
• Federated practicality: avoid heavy global consensus for each interaction.
• Composability with existing Internet infrastructure: deploy over TCP today, anonymity overlays tomorrow.

3. Positioning Against Existing Protocol Families

3.1 Versus traditional Internet service protocols

In common web architectures, TLS protects transport, but servers still decide and observe most authentication/authorization details. This protocol reduces that trust requirement by moving proof validity into cryptographic verification that endpoints can perform independently.

3.2 Versus blockchain systems

Blockchains provide strong tamper resistance via global consensus and replication. This protocol intentionally does not replicate all state globally. It keeps consensus/governance lightweight and local to federated registry hosting, while ensuring malicious operators cannot violate core authorization integrity.

3.3 Intended operating point

This protocol is best viewed as:

• More trust-minimizing than standard centralized services.
• Lighter and more responsive than blockchain consensus systems.
• Suitable for private, federated service networks.

4. System Model

4.1 Roles

• Federated nodes: host registries and provide service endpoints.
• Issuers/Admins: create and authorize credential grants.
• Clients: receive credentials and authenticate to services.
• Recipients/Peers: participate in direct credential exchange.

4.2 Assumptions

• Nodes may be malicious, curious, censoring, or unreliable.
• Endpoints protect secret keys.
• Cryptographic primitives are assumed sound.
• Availability is not guaranteed by cryptography alone.

5. System Architecture

5.1 High-level architecture

The architecture separates concerns:

• Registry layer: federated nodes host verifiable authorization state.
• Session layer: peers establish encrypted channels with transcript material.
• Authorization layer: BBS+ presentations prove role/authority.
• Credential transport layer: credential payloads are transferred directly peer-to-peer under end-to-end encryption.

5.2 Direct credential grant flow

1. Sender and recipient establish a secure session.
2. Sender generates a transcript-bound BBS+ authorization proof.
3. Sender sends encrypted credential payload plus registry-state evidence.
4. Recipient verifies the certified registry state and validates sender admin proof against the live session transcript.
5. Recipient decrypts payload and enforces context binding checks (outer announced registry/role context must match inner decrypted fields).
6. Recipient verifies reconstructed credential material against certified registry role keys before local storage.

This design intentionally favors direct peer exchange over private mailbox retrieval constructions. In practice, PIR/ORAM-style mailbox systems can provide stronger access-pattern privacy, but they introduce high implementation complexity, high constant-factor costs, larger hint/material transfers, and operationally difficult performance tuning. For interactive service environments, direct end-to-end grant exchange offers a better complexity/performance trade-off while preserving the core trustless authorization properties.

6. Cryptographic Backbone

6.1 Session and channel security

• Key exchange: ephemeral X25519 Diffie-Hellman for forward-secret session establishment.
• Key schedule: HKDF-SHA256 domain-separated derivation of directional send/receive keys and transcript hash material.
• Record protection: ChaCha20-Poly1305 AEAD with associated data bound to message counters.
• Replay handling: monotonic counters plus replay-window checks for per-direction packet acceptance.
• Identity proofing: Schnorr signatures over transcript-derived context to authenticate peer/server identity keys when required by deployment policy.

6.2 Transcript binding

A transcript hash from the handshake/session is used as proof challenge material. This binds authorization proofs to the exact session and prevents replay across different channels.

6.3 Authorization proofs

BBS+ presentations provide zero-knowledge role/authority proofs with selective disclosure properties. Recipients verify proof validity against issuer/registry material without learning hidden witness data.

Operationally, proof verification is done against certified registry state (issuer keys, role identifiers, epoch/version constraints). This allows a verifier to accept an authorization claim without trusting the transport node's interpretation of policy.

6.4 Credential confidentiality

Credential payloads are encrypted end-to-end to recipient key material. Intermediate nodes may relay or host state, but cannot decrypt protected credential contents.

The credential issuance envelope uses ECDH-derived symmetric keys with AEAD integrity protection, so tampering causes decryption/validation failure rather than silent corruption. The concrete envelope is nonce || ciphertext, where nonce is a random 96-bit value per message. HKDF context is direction-separated for user->admin and admin->user traffic so both directions do not share one AEAD key domain.

6.5 Primitive suite (current profile)

• X25519 for ECDH key agreement.
• HKDF-SHA256 for key derivation and transcript-bound expansion.
• ChaCha20-Poly1305 for authenticated encryption.
• BBS+ (BLS12-381 ciphersuite) for anonymous authorization presentations.
• Schnorr signatures on Ristretto255 for transport identity proofs.
• BLAKE2-family hashing for role/identifier derivation and protocol-domain separation.

7. Security and Privacy Properties

7.1 What malicious nodes should not be able to do

• Forge valid authorization proofs.
• Decrypt end-to-end encrypted credential payloads.
• Rebind valid proofs to unrelated sessions.
• Extract hidden secrets from zero-knowledge presentations.

7.2 Residual risks and limits

• Censorship/DoS: nodes can refuse service or delay traffic.
• Metadata leakage: timing and routing metadata may persist unless anonymized transports are used.
• Operational key hygiene: endpoint compromise remains critical.

8. Threat Model and Attacker Games

This section states explicit adversarial games suitable for academic evaluation. Let A denote a PPT adversary controlling network scheduling and any subset of federated nodes unless otherwise stated.

8.1 Adversary classes

• Network adversary: full active MITM capabilities (intercept, modify, replay, inject).
• Malicious federation-node adversary: controls registry-hosting/service nodes.
• Endpoint compromise adversary: compromises sender or recipient endpoint keys (out of primary guarantee scope; used for limit analysis).

8.2 Security games

Game G1: Authorization Unforgeability

Goal: A convinces an honest verifier to accept an authorization proof for role/registry context without access to valid issuer/admin credential material.

Win condition: verifier accepts with non-negligible probability.

Target claim: advantage is negligible under BBS+ proof unforgeability and sound registry-state verification.

Game G2: Transcript Rebinding / MITM Relay

Goal: A relays or reuses a proof generated in session s1 to authenticate in distinct session s2.

Win condition: verifier in s2 accepts proof bound to transcript hash from s1.

Target claim: advantage is negligible when proof challenge includes session transcript hash and transcript computation is collision-resistant/domain-separated.

Game G3: Credential Payload Confidentiality

Goal: A distinguishes which of two equal-length credential payloads was transmitted to recipient.

Experiment: challenger encrypts one of two adversary-chosen messages under recipient-targeted envelope; A gets ciphertext plus all node-observable metadata.

Win condition: A guesses chosen message with non-negligible advantage over 1/2.

Target claim: IND-CPA/AEAD security inherited from ECDH + HKDF + ChaCha20-Poly1305 under standard assumptions.

Game G4: Payload Integrity Under Active Modification

Goal: A modifies in-transit encrypted payload so recipient accepts altered plaintext as valid credential material.

Win condition: recipient accepts altered semantics without detection.

Target claim: negligible advantage due to AEAD integrity, strict outer/inner context binding checks (registry and role), and credential verification against certified registry role keys before storage.

Game G5: Malicious Node Knowledge Gain

Goal: malicious node learns hidden credential witness data beyond explicitly disclosed proof attributes and unavoidable metadata.

Win condition: extraction of non-disclosed witness information from observed protocol transcripts.

Target claim: negligible advantage under zero-knowledge properties of BBS+ presentations and secure transport assumptions.

8.3 Out-of-scope and partial-scope properties

• Availability/censorship resistance: not guaranteed by core cryptography.
• Traffic-analysis resistance: improved only when deployed over anonymity networks (Tor/I2P); timing correlation may still exist.
• Endpoint key compromise: breaks guarantees for affected principal by definition.

9. Why This Matters for Private Internet Services

This model enables service architectures where users do not have to trust server operators with authorization truth. Combined with Tor/I2P-style deployment, it enables anonymous, trust-minimized service access with practical latency and operational cost.

In short: this is a lightweight trustless layer for federated Internet services, positioned between classic server trust and heavyweight blockchain consensus.

10. Conclusion

Trustless federation is a practical design point for privacy-preserving Internet systems. It preserves the deployability and performance of federated services while shifting security from operator trust to cryptographic verification. This architecture is not a replacement for blockchains or traditional protocols; it is a complementary middle layer for applications that need stronger privacy and weaker server trust without paying the cost of global consensus.