Attestation Service
The Attestation Service is the cryptographic backbone of GLACIS. It consists of two core services — the Witness Service and the Receipt Service — that work together to create verifiable, ordered proofs of AI governance.
Overview
┌─────────────────────────────────────────────────────────────┐│ Attestation Service Architecture │├─────────────────────────────────────────────────────────────┤│ ││ ┌─────────────────┐ ┌─────────────────┐ ││ │ Witness Service │ │ Receipt Service │ ││ │ │ │ │ ││ │ • Epoch mgmt │◀─────▶│ • Validation │ ││ │ • Bearer tokens │ │ • Merkle tree │ ││ │ • Identity │ │ • Receipts │ ││ └────────┬────────┘ └────────┬────────┘ ││ │ │ ││ │ Cryptographic │ ││ │ Coordination │ ││ │ │ ││ ▼ ▼ ││ ┌─────────────────────────────────────────────────────┐ ││ │ Core Crypto Layer │ ││ │ • CBOR canonicalization • Ed25519 signatures │ ││ │ • HMAC-SHA256 commitments • Merkle proofs │ ││ └─────────────────────────────────────────────────────┘ ││ │└─────────────────────────────────────────────────────────────┘Witness Service
The Witness Service coordinates time epochs and issues bearer tokens to sidecars.
Purpose
- Epoch management: Defines discrete time periods (default: 1 hour)
- Bearer tokens: Issues tokens that bind attestations to epochs
- Identity verification: Maintains witness-derived binary identity
- Freshness guarantee: Ensures attestations are current
Heartbeat Endpoint
Sidecars call the heartbeat endpoint to obtain tokens:
// POST /api/v1/s3p/heartbeatconst response = await fetch('https://witness.glacis.io/api/v1/s3p/heartbeat', { method: 'POST', headers: { 'Authorization': 'Bearer ' + apiKey, 'Content-Type': 'application/json' }, body: JSON.stringify({ sidecarId: 'sidecar_abc123', organizationId: 'org_xyz789' })});
const { epochId, bearerToken, expiresAt, witnessId } = await response.json();// {// epochId: 'epoch_2024010112',// bearerToken: 'wt_...',// expiresAt: 1704110400000,// witnessId: 'witness_primary'// }Epoch Structure
interface Epoch { id: string; // e.g., 'epoch_2024010112' startTime: number; // Unix timestamp (ms) endTime: number; // Unix timestamp (ms) duration: number; // Default: 3600000 (1 hour) witnessId: string; // Witness that created this epoch merkleRoot?: string; // Set when epoch closes attestationCount: number;}Bearer Token Lifecycle
┌─────────────────────────────────────────────────────────────┐│ Bearer Token Lifecycle │├─────────────────────────────────────────────────────────────┤│ ││ 1. Sidecar requests token ││ Sidecar ─────▶ Witness ││ ││ 2. Witness issues epoch-bound token ││ Sidecar ◀───── { token, epochId, expiresAt } ││ ││ 3. Sidecar uses token for attestations ││ (Token valid only for current epoch) ││ ││ 4. Token expires with epoch ││ (Sidecar must request new token) ││ │└─────────────────────────────────────────────────────────────┘Receipt Service
The Receipt Service validates attestations and maintains the ordered transparency log.
Purpose
- Validation: 7-phase atomic validation pipeline
- Merkle tree: Ordered, verifiable attestation log
- Receipts: Cryptographic proofs of inclusion
- Persistence: Durable attestation storage
7-Phase Validation Pipeline
Every attestation passes through this pipeline:
┌─────────────────────────────────────────────────────────────┐│ Phase 1: Schema Validation (Fail Fast) ││ └─ Verify attestation structure matches expected schema ││ └─ Reject malformed attestations immediately │├─────────────────────────────────────────────────────────────┤│ Phase 2: Epoch Validation ││ └─ Verify epochId matches current active epoch ││ └─ Reject attestations from expired epochs │├─────────────────────────────────────────────────────────────┤│ Phase 3: Binary Identity Verification ││ └─ Verify sidecar public key matches signature ││ └─ Confirm sidecar is registered with organization │├─────────────────────────────────────────────────────────────┤│ Phase 4: Co-Epoch Network Attestation ││ └─ Cross-verify with witness service ││ └─ Confirm bearer token was issued for this epoch │├─────────────────────────────────────────────────────────────┤│ Phase 5: Monotonic Counter Validation ││ └─ Ensure attestation counter is strictly increasing ││ └─ Detect and reject replay attempts │├─────────────────────────────────────────────────────────────┤│ Phase 6: Atomic Transparency Log Append ││ └─ Add attestation to Merkle tree ││ └─ Uses Durable Objects for atomic operations │├─────────────────────────────────────────────────────────────┤│ Phase 7: Receipt Persistence ││ └─ Store attestation in database ││ └─ Return Merkle proof to sidecar │└─────────────────────────────────────────────────────────────┘Submission Endpoint
// POST /api/v1/attestationsconst response = await fetch('https://receipts.glacis.io/api/v1/attestations', { method: 'POST', headers: { 'Authorization': 'Bearer ' + bearerToken, 'Content-Type': 'application/json' }, body: JSON.stringify({ epochId: 'epoch_2024010112', level: 'L0', blindedId: base64Encode(blindedId), requestCommitment: requestCommitmentHash, encoderId: 'encoder_abc', signature: base64Encode(signature), // For L2 only: // evidenceCommitment: evidenceHash, // policyScores: { toxicity: 0.1, pii: false }, // prfTag: base64Encode(prfTag) })});
const receipt = await response.json();// {// attestationId: 'att_xyz789',// epochId: 'epoch_2024010112',// index: 1247,// merkleProof: {// root: '0x...',// siblings: ['0x...', '0x...'],// index: 1247// },// timestamp: 1704106800000// }Merkle Proof Structure
interface MerkleProof { // Current root hash of the tree root: string;
// Index of this attestation in the tree index: number;
// Sibling hashes for verification path siblings: string[];
// Epoch this proof belongs to epochId: string;}Verification
Anyone can verify a Merkle proof independently:
import { verifyMerkleProof } from '@glacis/core';
const isValid = verifyMerkleProof({ leaf: sha256(canonicalize(attestation)), proof: receipt.merkleProof, root: receipt.merkleProof.root});
console.log('Proof valid:', isValid); // trueCryptographic Primitives
CBOR Canonicalization
All attestation data is canonicalized using CBOR (RFC 8949):
import { canonicalize } from '@glacis/core';
// Ensures deterministic serialization across platformsconst canonical = canonicalize({ model: 'gpt-4', messages: [{ role: 'user', content: 'Hello' }], timestamp: 1704106800000});
// Same input always produces same bytesconst hash = sha256(canonical);Commitment Scheme
GLACIS uses HMAC-SHA256 for binding commitments:
import { createCommitment } from '@glacis/core';
// Request commitment (included in L0)const requestCommitment = createCommitment({ type: 'request', data: canonicalize(request), epochId: currentEpoch.id});
// Evidence commitment (included in L2)const evidenceCommitment = createCommitment({ type: 'evidence', data: canonicalize({ request, response, scores }), epochId: currentEpoch.id});Ed25519 Signatures
All attestations are signed:
import { sign, verify } from '@glacis/core';
// Sidecar signsconst signature = sign( canonicalize(attestation), sidecarPrivateKey);
// Anyone can verifyconst valid = verify( canonicalize(attestation), signature, sidecarPublicKey);Error Codes
The receipt service returns deterministic error codes for debugging:
| Code | Name | Description |
|---|---|---|
SCHEMA_INVALID | Schema Validation Failed | Attestation structure is malformed |
EPOCH_EXPIRED | Epoch Expired | Attestation references old epoch |
EPOCH_FUTURE | Future Epoch | Attestation references non-existent epoch |
IDENTITY_MISMATCH | Identity Mismatch | Signature doesn’t match sidecar |
COUNTER_REPLAY | Counter Replay | Monotonic counter violation |
TOKEN_INVALID | Token Invalid | Bearer token not recognized |
TOKEN_EXPIRED | Token Expired | Bearer token has expired |
RATE_LIMITED | Rate Limited | Too many requests |
Architecture Details
Witness Service Deployment
┌─────────────────────────────────────────────────────────────┐│ Cloudflare Workers (300+ PoPs) ││ ┌─────────────────────────────────────────────────────┐ ││ │ Witness Worker │ ││ │ • Runs at edge (low latency) │ ││ │ • Stateless (epoch state in KV) │ ││ │ • Sub-1ms cold start │ ││ └─────────────────────────────────────────────────────┘ ││ │ ││ ▼ ││ ┌─────────────────────────────────────────────────────┐ ││ │ Workers KV │ ││ │ • Epoch metadata │ ││ │ • Bearer token registry │ ││ │ • Eventually consistent (ok for reads) │ ││ └─────────────────────────────────────────────────────┘ │└─────────────────────────────────────────────────────────────┘Receipt Service Deployment
┌─────────────────────────────────────────────────────────────┐│ Cloudflare Workers + Durable Objects ││ ┌─────────────────────────────────────────────────────┐ ││ │ Receipt Worker │ ││ │ • Validation pipeline │ ││ │ • Routes to Durable Object │ ││ └─────────────────────────────────────────────────────┘ ││ │ ││ ▼ ││ ┌─────────────────────────────────────────────────────┐ ││ │ Merkle Tree Durable Object │ ││ │ • One per epoch │ ││ │ • Atomic tree operations │ ││ │ • Strong consistency │ ││ └─────────────────────────────────────────────────────┘ ││ │ ││ ▼ ││ ┌─────────────────────────────────────────────────────┐ ││ │ D1 Database │ ││ │ • Attestation persistence │ ││ │ • Receipt metadata │ ││ └─────────────────────────────────────────────────────┘ │└─────────────────────────────────────────────────────────────┘Sampling Protocol (S3P)
GLACIS uses the Sidecar Sampling Protocol (S3P) to determine which requests receive L2 attestations:
interface SamplingConfig { // Base sampling rate (1 in N) rate: number;
// Adaptive rules rules: SamplingRule[];}
interface SamplingRule { // Condition to match condition: { field: 'model' | 'user' | 'content_length'; operator: 'eq' | 'gt' | 'lt' | 'contains'; value: string | number; };
// Override rate when matched rate: number;}
// Example: Sample all GPT-4 requests, 1/100 for othersconst config: SamplingConfig = { rate: 100, rules: [ { condition: { field: 'model', operator: 'eq', value: 'gpt-4' }, rate: 1 // Sample every request } ]};Next Steps
Witness Service Details Deep dive into epoch management and bearer tokens.
Receipt Service Details Understanding the 7-phase validation pipeline.
Epochs & Sampling Configure sampling rates and epoch behavior.
Cryptographic Proofs Verify attestations and Merkle proofs.