> ## Documentation Index > Fetch the complete documentation index at: https://framework.freysa.ai/llms.txt > Use this file to discover all available pages before exploring further. # Technical Architecture > Connecting public and private data. A two-part solution to this problem is using signed API data when available, and otherwise using Notary TEEs as trusted intermediaries. These TEEs observe web content directly and provide signed attestations, enabling agents to get verifiable data from any website without requiring changes to existing infrastructure. Each attestation feed includes: * Content hash * Timestamp * TEE attestation * TLS session proof ```mermaid theme={"system"} sequenceDiagram participant Website participant Notary as Notary TEE participant Agent as Agent TEE Notary->>Website: TLS Handshake Website->>Notary: Server Certificate rect rgb(240, 240, 240) Note over Notary: Generate Session Proof Note over Notary: Capture Website Data Note over Notary: Create Attestation end Notary->>Agent: Authenticated Data Feed Note over Agent: Verify Attestation Note over Agent: Process Data ``` ## Extension architecture The attestation system implementation for private web data is based on a three-tier architecture: a browser-based client, a WebAssembly (WASM) module, and a trusted AWS Nitro Enclave. The system establishes two parallel WebSocket connections - one for secure communication with the Notary service running in the AWS Nitro Enclave, and another as a proxy to the target web server. This architecture ensures that all data flows through the trusted execution environment while maintaining end-to-end encryption. ***The*** [***extension***](https://link.freysa.ai/esper) ***and all the relevant*** [***code***](https://github.com/0xfreysa/esper) ***was released*** [***recently***](https://x.com/freysa_ai/status/1883241261651693851)***.*** The attestation process begins when the client initiates a request through the WASM module, which manages the TLS handshake and encryption parameters via the Notary service. As data flows between the client and target server, the Notary service, running in the secure AWS Nitro Enclave, maintains access to the TLS keys and can decrypt the proxied data to verify its integrity. When attestation is requested, the Notary examines the decrypted data for specified attributes and, if present, generates a cryptographic signature that serves as a tamper-proof attestation of the observed web content. This design ensures that attestations can only be generated within the secure hardware environment, providing strong guarantees about the authenticity of the attested data. ```mermaid theme={"system"} sequenceDiagram participant Client as Client (Browser) participant WASM as WASM in Extension participant WS1 as WebSocket Connection 1 participant Notary as Notary (AWS Nitro Enclave) participant WS2 as WebSocket Connection 2 (Proxy) participant Target as Target Server rect rgb(200, 220, 240) note right of Client: Browser Environment note right of Notary: AWS EC2 Instance note right of Notary: Enclave Environment end Client->>WASM: Initialize WASM->>Notary: Create session Notary-->>WASM: Return session ID WASM->>WS1: Establish WebSocket connection (with session ID) WS1->>Notary: Connect to Notary Note over WASM,Notary: WebSocket for all Notary communications established WASM->>WS2: Establish WebSocket connection WS2->>Target: Connect to Target Server (via websockify) Note over WASM,Target: WebSocket proxy established WASM->>Notary: Request TLS parameters (over WS1) Notary-->>WASM: Provide TLS parameters (over WS1) WASM->>Target: Initiate TLS handshake (over WS2) Target-->>WASM: TLS handshake response (over WS2) WASM->>Notary: Verify TLS handshake (over WS1) Note over WASM,Target: Encrypted TLS stream established Client->>WASM: Send request data WASM->>Notary: Get encryption parameters (over WS1) WASM->>Target: Send encrypted data (over WS2) Target-->>WASM: Send encrypted response (over WS2) WASM->>Notary: Get decryption parameters (over WS1) WASM-->>Client: Return decrypted response Note over Client,Target: Continuous encrypted communication Client->>WASM: Request attestation WASM->>Notary: Request attestation (over WS1) Note over Notary: Access stored TLS key Note over Notary: Decrypt proxied data Note over Notary: Check for attributes Note over Notary: Sign if attributes present Notary-->>WASM: Return signature as attestation (over WS1) WASM-->>Client: Provide attestation ``` The system implements a secure TLS attestation architecture that enables verifiable attestations through AWS Nitro Enclaves, utilizing WebSocket connections and WASM-based processing. Here's a detailed breakdown of the components and their operations: ### Client-Side Components * The browser environment serves as the primary interface where users initiate secure browsing sessions and receive attestations, acting as the front-end gateway to the entire system. * The WASM extension functions as a sophisticated processing unit that manages cryptographic operations and orchestrates all communication channels, serving as the critical bridge between the browser, Notary, and target servers. ### Server-Side Components * The Notary Service operates within a secure TEE - AWS Nitro Enclave environment, providing hardware-level isolation while managing sessions, generating cryptographic parameters, and producing trusted attestations. * The communication infrastructure utilizes two distinct WebSocket connections: one dedicated to Notary communications and another for proxied connections to target servers, ensuring persistent and secure data transmission. ### Session Initialization * The initialization process begins when the client activates the WASM extension, which establishes a secure session with the Notary and receives a unique identifier for subsequent communications. * The TLS handshake workflow involves requesting parameters from the Notary, executing the handshake with the target server, and establishing a verified encrypted stream for secure data exchange. ### Data Flow and Encryption * Request processing follows a careful sequence where client data is encrypted using Notary-provided parameters before transmission to the target server, with responses following a reverse process for secure delivery. * The attestation generation can be triggered at any point, involving the Notary accessing stored TLS keys, decrypting proxied data, and producing signed attestations after verifying required attributes. ### Security Features * The AWS Nitro Enclave provides hardware-level isolation and secure key management, creating an impenetrable environment for sensitive cryptographic operations and data handling. * The dual WebSocket architecture implements end-to-end encryption and TLS parameter verification, while proxied connections prevent direct server exposure and maintain a secure communication chain. * The attestation mechanism ensures data integrity through cryptographic signing and attribute-based verification, creating an unbroken chain of trust from request to response. ### Implementation Considerations * Performance optimization leverages persistent connections and efficient caching strategies, while the WASM compilation is optimized for minimal latency in client-side processing. * The error handling system implements comprehensive recovery mechanisms for session failures, connection dropouts, and invalid attestation requests, ensuring system resilience. * The scalability architecture enables independent enclave instances and horizontal scaling, allowing the system to grow while maintaining security and performance standards.