9190c75440
This commit completes Beat 3 of the SequentialThinkingForCHORUS implementation,
adding KACHING JWT policy enforcement with scope checking.
## Deliverables
### 1. JWT Validation Package (pkg/seqthink/policy/)
**jwt.go** (313 lines): Complete JWT validation system
- `Validator`: JWT token validation with JWKS fetching
- `Claims`: JWT claims structure with scope support
- JWKS fetching and caching (1-hour TTL)
- RSA public key parsing from JWK format
- Space-separated and array scope formats
- Automatic JWKS refresh on cache expiration
**Features**:
- RS256 signature verification
- Expiration and NotBefore validation
- Required scope checking
- JWKS caching to reduce API calls
- Thread-safe key cache with mutex
- Base64 URL encoding/decoding utilities
**jwt_test.go** (296 lines): Comprehensive test suite
- Valid token validation
- Expired token rejection
- Missing scope detection
- Space-separated scopes parsing
- Not-yet-valid token rejection
- JWKS caching behavior verification
- Invalid JWKS server handling
- 5 test scenarios, all passing
### 2. Authorization Middleware
**middleware.go** (75 lines): HTTP authorization middleware
- Bearer token extraction from Authorization header
- Token validation via Validator
- Policy denial metrics tracking
- Optional enforcement (disabled if no JWKS URL)
- Request logging with subject and scopes
- Clean error responses (401 Unauthorized)
**Integration**:
- Wraps `/mcp/tool` endpoint (both encrypted and plaintext)
- Wraps `/mcp/sse` endpoint (both encrypted and plaintext)
- Health and metrics endpoints remain open (no auth)
- Automatic mode detection based on configuration
### 3. Proxy Server Integration
**Updated server.go**:
- Policy middleware initialization in `NewServer()`
- Pre-fetches JWKS on startup
- Auth wrapper for protected endpoints
- Configuration-based enforcement
- Graceful fallback if JWKS unavailable
**Configuration**:
```go
ServerConfig{
KachingJWKSURL: "https://auth.kaching.services/jwks",
RequiredScope: "sequentialthinking.run",
}
```
If both fields are set → policy enforcement enabled
If either is empty → policy enforcement disabled (dev mode)
## Testing Results
### Unit Tests
```
PASS: TestValidateToken (5 scenarios)
- valid_token with required scope
- expired_token rejection
- missing_scope rejection
- space_separated_scopes parsing
- not_yet_valid rejection
PASS: TestJWKSCaching
- Verifies JWKS fetched only once within cache window
- Verifies JWKS re-fetched after cache expiration
PASS: TestParseScopes (5 scenarios)
- Single scope parsing
- Multiple scopes parsing
- Extra spaces handling
- Empty string handling
- Spaces-only handling
PASS: TestInvalidJWKS
- Handles JWKS server errors gracefully
PASS: TestGetCachedKeyCount
- Tracks cached key count correctly
```
**All 5 test groups passed (16 total test cases)**
### Integration Verification
**Without Policy** (development):
```bash
export KACHING_JWKS_URL=""
./build/seqthink-wrapper
# → "Policy enforcement disabled"
# → All requests allowed
```
**With Policy** (production):
```bash
export KACHING_JWKS_URL="https://auth.kaching.services/jwks"
export REQUIRED_SCOPE="sequentialthinking.run"
./build/seqthink-wrapper
# → "Policy enforcement enabled"
# → JWKS pre-fetched
# → Authorization: Bearer <token> required
```
## Security Properties
✅ **Authentication**: RS256 JWT signature verification
✅ **Authorization**: Scope-based access control
✅ **Token Validation**: Expiration and not-before checking
✅ **JWKS Security**: Automatic key rotation support
✅ **Metrics**: Policy denial tracking for monitoring
✅ **Graceful Degradation**: Works without JWKS in dev mode
✅ **Thread Safety**: Concurrent JWKS cache access safe
## API Flow with Policy
### Successful Request:
```
1. Client → POST /mcp/tool
Authorization: Bearer eyJhbGci...
Content-Type: application/age
Body: <encrypted request>
2. Middleware extracts Bearer token
3. Middleware validates JWT signature (JWKS)
4. Middleware checks required scope
5. Request forwarded to handler
6. Handler decrypts request
7. Handler calls MCP server
8. Handler encrypts response
9. Response sent to client
```
### Unauthorized Request:
```
1. Client → POST /mcp/tool
(missing Authorization header)
2. Middleware checks for header → NOT FOUND
3. Policy denial metric incremented
4. 401 Unauthorized response
5. Request rejected
```
## Configuration Modes
**Full Security** (Beat 2 + Beat 3):
```bash
export AGE_IDENT_PATH=/etc/seqthink/age.key
export AGE_RECIPS_PATH=/etc/seqthink/age.pub
export KACHING_JWKS_URL=https://auth.kaching.services/jwks
export REQUIRED_SCOPE=sequentialthinking.run
```
→ Encryption + Authentication + Authorization
**Development Mode**:
```bash
# No AGE_* or KACHING_* variables set
```
→ Plaintext, no authentication
## Next Steps (Beat 4)
Beat 4 will add deployment infrastructure:
- Docker Swarm service definition
- Network overlay configuration
- Secret management for age keys
- KACHING integration documentation
- End-to-end testing in swarm
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
CHORUS – Container-First Context Platform (Alpha)
CHORUS is the runtime that ties the CHORUS ecosystem together: libp2p mesh, DHT-backed storage, council/task coordination, and (eventually) SLURP contextual intelligence. The repository you are looking at is the in-progress container-first refactor. Several core systems boot today, but higher-level services (SLURP, SHHH, full HMMM routing) are still landing.
Current Status
| Area | Status | Notes |
|---|---|---|
| libp2p node + PubSub | ✅ Running | internal/runtime/shared.go spins up the mesh, hypercore logging, availability broadcasts. |
| DHT + DecisionPublisher | ✅ Running | Encrypted storage wired through pkg/dht; decisions written via ucxl.DecisionPublisher. |
| Leader Election System | ✅ FULLY FUNCTIONAL | 🎉 MILESTONE: Complete admin election with consensus, discovery protocol, heartbeats, and SLURP activation! |
| SLURP (context intelligence) | 🚧 Stubbed | pkg/slurp/slurp.go contains TODOs for resolver, temporal graphs, intelligence. Leader integration scaffolding exists but uses placeholder IDs/request forwarding. |
| SHHH (secrets sentinel) | 🚧 Sentinel live | pkg/shhh redacts hypercore + PubSub payloads with audit + metrics hooks (policy replay TBD). |
| HMMM routing | 🚧 Partial | PubSub topics join, but capability/role announcements and HMMM router wiring are placeholders (internal/runtime/agent_support.go). |
See docs/progress/CHORUS-WHOOSH-development-plan.md for the detailed build plan and docs/progress/CHORUS-WHOOSH-roadmap.md for sequencing.
Quick Start (Alpha)
The container-first workflows are still evolving; expect frequent changes.
git clone https://gitea.chorus.services/tony/CHORUS.git
cd CHORUS
cp docker/chorus.env.example docker/chorus.env
# adjust env vars (KACHING license, bootstrap peers, etc.)
docker compose -f docker/docker-compose.yml up --build
You’ll get a single agent container with:
- libp2p networking (mDNS + configured bootstrap peers)
- election heartbeat
- DHT storage (AGE-encrypted)
- HTTP API + health endpoints
Missing today: SLURP context resolution, advanced SHHH policy replay, HMMM per-issue routing. Expect log warnings/TODOs for those paths.
🎉 Leader Election System (NEW!)
CHORUS now features a complete, production-ready leader election system:
Core Features
- Consensus-based election with weighted scoring (uptime, capabilities, resources)
- Admin discovery protocol for network-wide leader identification
- Heartbeat system with automatic failover (15-second intervals)
- Concurrent election prevention with randomized delays
- SLURP activation on elected admin nodes
How It Works
- Bootstrap: Nodes start in idle state, no admin known
- Discovery: Nodes send discovery requests to find existing admin
- Election trigger: If no admin found after grace period, trigger election
- Candidacy: Eligible nodes announce themselves with capability scores
- Consensus: Network selects winner based on highest score
- Leadership: Winner starts heartbeats, activates SLURP functionality
- Monitoring: Nodes continuously verify admin health via heartbeats
Debugging
Use these log patterns to monitor election health:
# Monitor WHOAMI messages and leader identification
docker service logs CHORUS_chorus | grep "🤖 WHOAMI\|👑\|📡.*Discovered"
# Track election cycles
docker service logs CHORUS_chorus | grep "🗳️\|📢.*candidacy\|🏆.*winner"
# Watch discovery protocol
docker service logs CHORUS_chorus | grep "📩\|📤\|📥"
Roadmap Highlights
- Security substrate – land SHHH sentinel, finish SLURP leader-only operations, validate COOEE enrolment (see roadmap Phase 1).
- Autonomous teams – coordinate with WHOOSH for deployment telemetry + SLURP context export.
- UCXL + KACHING – hook runtime telemetry into KACHING and enforce UCXL validator.
Track progress via the shared roadmap and weekly burndown dashboards.
Related Projects
- WHOOSH – council/team orchestration
- KACHING – telemetry/licensing
- SLURP – contextual intelligence prototypes
- HMMM – meta-discussion layer
Contributing
This repo is still alpha. Please coordinate via the roadmap tickets before landing changes. Major security/runtime decisions should include a Decision Record with a UCXL address so SLURP/BUBBLE can ingest it later.