TBAC Registry

Original Prompt: New Governance Tools Needed for Capabilities v. Identity access control

Requirements Document

Introduction

The TBAC Registry is a central repository system that enables enterprise IT departments to automatically extract, version, discover, and govern both capabilities and their supporting token evidence in a Token Based Access Control (TBAC) environment while ensuring compliance with enterprise security standards and managing security and operational risks. This system bridges the gap between traditional identity-based governance and capabilities-based access control by automatically extracting action+resource combinations from developer-written Cedar policies, managing token types and trusted issuers, orchestrating approval workflows, and providing comprehensive risk assessment and policy analysis capabilities with built-in compliance verification against specific security requirements within frameworks like SOC 2 (e.g., CC6.1 - Logical Access Controls), ISO 27001 (e.g., A.9.1.2 - Access to Networks), NIST, and other regulatory standards.

The registry manages the complete TBAC ecosystem by governing both capabilities (what actions are permitted on which resources) and the token evidence that authorizes those capabilities (signed JWTs, X.509 certificates, HTTP message signatures, and Verifiable Credentials with JSON-LD signatures). It leverages Cedar's formal verification capabilities and integrates with Cedar Analysis tools to provide mathematical guarantees about policy behavior, automatically verify compliance with specific security requirements, validate token evidence from trusted issuers, and identify potential security risks before they reach production. It serves as the foundational risk management and compliance governance tool that allows organizations to transition from role-based access control (RBAC) to capabilities-based models while maintaining enterprise-grade risk assessment, token validation, automated compliance verification against granular security requirements, security governance, auditability, and regulatory requirements through automated policy extraction, formal analysis, universal security statement verification, token issuer management, risk evaluation, and comprehensive audit trails that satisfy enterprise compliance needs.

Requirements

Requirement 1

User Story: As an Application Developer, I want the system to automatically extract capabilities from my Cedar policies and provide immediate feedback about potential issues, so that I can identify and fix policy problems before submitting them for approval.

Acceptance Criteria

WHEN a developer submits Cedar policies THEN the system SHALL automatically parse and extract all action+resource combinations as capabilities while performing real-time validation, issue detection, and preliminary security classification
WHEN capabilities are extracted THEN the system SHALL automatically assign unique identifiers, semantic URIs, and version numbers following consistent naming conventions
WHEN parsing Cedar policies THEN the system SHALL validate the syntax, extract complete capability definitions including conditions and constraints, identify potential policy violations, conflicts, or security issues, and flag capabilities that may involve sensitive data or high-risk operations
IF policy analysis detects problems THEN the system SHALL provide immediate feedback including syntax errors, logical conflicts, security violations, overly permissive policies, potential security framework violations, and recommendations for fixes before allowing submission
IF an extracted capability matches an existing one THEN the system SHALL create a new version while preserving existing versions and highlight any behavioral differences and changes in security classification
WHEN capabilities are successfully extracted and validated THEN the system SHALL record the source policy file, creation timestamp, developer identity, validation results, preliminary security classifications, and set initial approval status to "pending"

Requirement 2

User Story: As an Application Developer, I want my policies to go through automated security classification and risk-based peer review, so that security requirements are properly identified before CISO approval.

Acceptance Criteria

WHEN capabilities are automatically extracted from Cedar policies THEN the system SHALL present them to the developer for review and annotation with application context and business purpose
WHEN a developer submits annotated capabilities THEN the system SHALL automatically classify them against specific security requirements within frameworks (e.g., SOC 2 CC6.1, ISO 27001 A.9.1.2) by analyzing resource types, action patterns, and data sensitivity indicators to identify which specific security requirements and line items apply
WHEN security classification is complete THEN the system SHALL initiate a risk-based peer review workflow requiring validation from other developers, automatic risk scoring, and verification of security classifications with specific mapping to security framework line items
WHEN peer review validates the extracted capabilities, risk assessments, and security classifications THEN the system SHALL route capabilities based on CISO-configured review preferences, allowing CISOs to specify they only want to review capabilities that impact specific security requirements (e.g., SOC 2 CC6.1 - Logical Access Controls, ISO 27001 A.9.1.2 - Access to Networks) while delegating others to standard approval workflows
IF the CISO rejects capabilities due to unacceptable risk levels or security requirement concerns THEN the system SHALL provide detailed feedback including which specific security requirements (e.g., SOC 2 CC6.1, ISO 27001 A.9.1.2) are violated and allow the developer to modify the source Cedar policies
WHEN capabilities are approved THEN the system SHALL activate them in the registry with their approved risk levels, security classifications, applicable universal security statements, and specific security requirement mappings (e.g., SOC 2 CC6.1, ISO 27001 A.9.1.2)

Requirement 3

User Story: As a System Architect, I want to track dependencies between capabilities and external systems while assessing associated risks, so that I can understand the security and operational risks of system interactions and ensure proper risk-based governance.

Acceptance Criteria

WHEN a capability is extracted from Cedar policies THEN the system SHALL identify dependencies on external systems, databases, APIs, and services referenced in the policies and assess the risk level of each dependency
WHEN external system dependencies are identified THEN the system SHALL allow architects to annotate them with relationship types (authenticates_with, reads_from, writes_to, depends_on) and risk classifications (high, medium, low) based on data sensitivity and system criticality
WHEN viewing a capability THEN the system SHALL display a dependency graph showing all external system dependencies, related capabilities, and associated risk levels with visual risk indicators
IF an external system is modified or becomes unavailable THEN the system SHALL identify all capabilities that depend on that system and calculate the aggregate risk impact across dependent applications
WHEN analyzing capability relationships THEN the system SHALL detect and report potential security risks including privilege escalation paths, data exposure risks, and system interaction conflicts that could compromise security
WHEN risk thresholds are exceeded THEN the system SHALL automatically flag high-risk capability combinations and require additional security review before approval
WHEN dependencies span security boundaries THEN the system SHALL identify cross-domain risks and enforce additional governance controls for inter-system communications

Requirement 4

User Story: As a Compliance Officer, I want to define universal security statements and verify them against capability definitions, so that I can ensure all policies comply with regulatory frameworks like SOC 2, ISO 27001, and other security standards through formal verification.

Acceptance Criteria

WHEN defining compliance requirements THEN the system SHALL allow compliance officers to create universal security statements using Cedar's formal verification capabilities to express requirements like "no capability shall allow access to sensitive data without strong authentication" or "all administrative capabilities must require multi-factor authentication"
WHEN universal statements are defined THEN the system SHALL automatically verify all existing and new capabilities against these statements using Cedar Analysis tools and provide mathematical proof of compliance or identify violations
WHEN a capability is modified THEN the system SHALL create a new version while maintaining all previous versions and automatically re-verify against all applicable universal security statements
WHEN capability versions are created THEN the system SHALL record the change reason, approver, impact assessment, and compliance verification results for each universal statement
WHEN viewing capability history THEN the system SHALL display a complete audit trail of all changes with timestamps, actors, and compliance verification status for each regulatory framework
IF a capability version is deprecated THEN the system SHALL prevent new assignments while maintaining existing ones until migration and ensure universal statements remain satisfied during the transition
WHEN a compliance audit is requested THEN the system SHALL generate reports showing capability usage, approvals, change history, and formal verification results proving compliance with specific regulatory frameworks like SOC 2 Type II or ISO 27001

Requirement 5

User Story: As a Compliance System or AI Agent, I want to search and analyze capabilities through APIs, so that I can perform automated risk assessment, governance monitoring, and policy compliance checking.

Acceptance Criteria

WHEN a compliance system queries the registry THEN the system SHALL provide REST APIs for searching capabilities by action type, resource patterns, approval status, risk levels, and risk categories
WHEN searching capabilities THEN the system SHALL support filtering by application, developer, approval date, external system dependencies, risk scores, and compliance tags
WHEN a capability is retrieved THEN the system SHALL return the complete definition including extracted Cedar policy fragments, approval history, risk assessments, and dependency metadata
IF an AI agent requests risk analysis THEN the system SHALL provide APIs to bulk export capability data with risk metrics for machine learning-based risk pattern analysis and anomaly detection
WHEN integrating with governance tools THEN the system SHALL support standard protocols for automated risk monitoring, compliance checking, and risk-based alerting

Requirement 6

User Story: As a Policy Administrator or AI agent, I want to see capability lifecycle states and security-aware approval workflows, so that I can report on which capabilities are available for use and ensure proper risk-based governance.

Acceptance Criteria

WHEN capabilities are extracted from developer Cedar policies THEN the system SHALL set the initial state to "draft" requiring security classification and appropriate approval workflows before activation
WHEN a capability state changes THEN the system SHALL enforce workflow rules requiring appropriate approvals for each transition based on security classifications and risk levels
IF a capability needs to be retired THEN the system SHALL support "deprecated" and "retired" states with controlled migration paths that maintain compliance with security requirements during transition
WHEN security classifications change THEN the system SHALL automatically re-route capabilities through appropriate approval workflows and re-verify against applicable universal security statements

Requirement 7

User Story: As a CISO, I want to configure which specific security requirements trigger my personal review, so that I can focus my attention on the most critical security decisions while delegating routine approvals.

Acceptance Criteria

WHEN configuring review preferences THEN the system SHALL allow the CISO to specify which security framework line items require personal review (e.g., SOC 2 CC6.1, ISO 27001 A.9.1.2) while allowing other classifications to proceed through standard approval workflows
WHEN capabilities are classified against security frameworks THEN the system SHALL automatically route only those matching CISO-specified criteria for personal review while sending others to designated approval delegates
WHEN CISO review preferences change THEN the system SHALL automatically re-evaluate pending capabilities and adjust routing accordingly without losing approval progress
IF a capability impacts multiple security requirements THEN the system SHALL route to CISO review if any of the requirements match the configured criteria
WHEN delegating approvals THEN the system SHALL allow the CISO to specify different approval authorities for different security requirement categories while maintaining audit trails of delegation decisions

Requirement 7

User Story: As a Compliance System or AI Agent, I want to retrieve aggregated Cedar policies that are currently in effect or were in effect at a specific time, so that I can perform comprehensive policy analysis and compliance auditing.

Acceptance Criteria

WHEN requesting current policies THEN the system SHALL aggregate all active Cedar policies from approved capabilities and return them as a complete policy set
WHEN requesting historical policies THEN the system SHALL support point-in-time queries to retrieve the exact policy set that was in effect at any specified timestamp
WHEN aggregating policies THEN the system SHALL include metadata about policy sources, approval dates, and capability relationships for audit trail purposes
IF policies have dependencies or conflicts THEN the system SHALL include dependency information and conflict resolution details in the aggregated output
WHEN exporting policy sets THEN the system SHALL provide multiple formats including native Cedar syntax, JSON, and structured data for analysis tools

Requirement 8

User Story: As a Security Analyst, I want to run Cedar Analysis tools against the capability registry's policy sets, so that I can verify policy correctness, detect conflicts, and ensure authorization policies behave as intended.

Acceptance Criteria

WHEN integrating with Cedar Analysis tools THEN the system SHALL provide APIs to export policy sets in formats compatible with the Cedar Symbolic Compiler
WHEN running policy analysis THEN the system SHALL support integration with Cedar Analysis CLI for comparing policy sets, detecting conflicts, and identifying redundancies
WHEN policy changes are proposed THEN the system SHALL enable automated analysis to compare new policies against existing ones and identify permission changes
IF policy analysis detects issues THEN the system SHALL capture and store analysis results including shadowed permits, impossible conditions, and complete denials
WHEN analysis is complete THEN the system SHALL provide detailed reports on policy equivalence, permission changes, and potential security implications###

Requirement 9

User Story: As a Security Administrator, I want to register and manage different types of tokens that serve as evidence for capabilities, so that the system can validate which tokens are authorized to provide evidence for specific capabilities.

Acceptance Criteria

WHEN registering token types THEN the system SHALL support multiple token formats including signed JWTs, X.509 certificates, HTTP message signatures, and Verifiable Credentials with JSON-LD signatures
WHEN a token type is registered THEN the system SHALL require specification of the token format, validation method, required claims structure, and cryptographic signature verification requirements
WHEN configuring token validation THEN the system SHALL allow specification of required claims (e.g., issuer, subject, audience, expiration) and optional claims that may influence capability authorization decisions
IF a token type supports custom claims THEN the system SHALL allow administrators to define claim validation rules and mapping between token claims and capability parameters
WHEN token types are registered THEN the system SHALL store validation schemas, cryptographic requirements, and claim structures for automated token verification during capability authorization

Requirement 11

User Story: As a Security Administrator, I want to manage trusted token issuers and their domains, so that the system only accepts tokens from authorized sources and can validate cross-domain trust relationships.

Acceptance Criteria

WHEN registering token issuers THEN the system SHALL require specification of the issuer domain, issuer identifier, public key or certificate information, and supported token types
WHEN configuring issuer trust THEN the system SHALL allow specification of which capabilities each issuer is authorized to provide evidence for, including capability-specific restrictions
WHEN managing cross-domain trust THEN the system SHALL support federation scenarios where external domains can issue tokens for specific capability sets with appropriate trust boundaries
IF an issuer's credentials are compromised THEN the system SHALL support immediate revocation of issuer trust and invalidation of all tokens from that issuer
WHEN validating tokens THEN the system SHALL verify that the token issuer is authorized to provide evidence for the requested capability and that the issuer's cryptographic credentials are valid and not revoked

Requirement 12

User Story: As a Compliance Officer, I want to audit token usage and issuer relationships, so that I can ensure token-based evidence meets regulatory requirements and maintain proper audit trails for compliance frameworks.

Acceptance Criteria

WHEN tokens are used as evidence THEN the system SHALL log the token type, issuer, claims presented, capability requested, and authorization decision with timestamps
WHEN auditing token usage THEN the system SHALL provide reports showing which issuers provided evidence for which capabilities over specified time periods
WHEN compliance audits are requested THEN the system SHALL generate reports mapping token evidence to specific security requirements (e.g., SOC 2 CC6.1) and demonstrate proper token validation
IF token validation fails THEN the system SHALL log the failure reason, attempted capability access, and token details for security analysis
WHEN reviewing issuer relationships THEN the system SHALL provide visibility into cross-domain trust relationships and their impact on capability authorization decisions

TBAC Registry Design Document

Overview

The TBAC Registry is designed as a microservices-based system that provides centralized governance for Token Based Access Control (TBAC) environments. The system automatically extracts capabilities from Cedar policies, manages token types and trusted issuers, enforces risk-based approval workflows, and provides formal verification capabilities for compliance with security frameworks.

The architecture emphasizes security, scalability, and compliance automation while supporting the transition from traditional RBAC to capabilities-based access control. The system integrates with Cedar Analysis tools to provide mathematical guarantees about policy behavior and automated compliance verification.

Architecture

High-Level Architecture

The TBAC Registry follows a microservices architecture with the following core components:

graph TB
    subgraph "External Systems"
        DEV[Developers]
        CISO[CISO/Security Team]
        COMP[Compliance Systems]
        AI[AI Agents]
        EXT[External Applications]
    end
    
    subgraph "API Gateway Layer"
        GW[API Gateway]
        AUTH[Authentication Service]
    end
    
    subgraph "Core Services"
        PE[Policy Extraction Service]
        CA[Capability Analysis Service]
        WF[Workflow Engine]
        TR[Token Registry Service]
        CR[Compliance & Risk Service]
    end
    
    subgraph "Cedar Integration"
        CP[Cedar Policy Parser]
        CV[Cedar Verification Engine]
        CAT[Cedar Analysis Tools]
    end
    
    subgraph "Data Layer"
        CDB[(Capability Database)]
        TDB[(Token Database)]
        ADB[(Audit Database)]
        CACHE[(Redis Cache)]
    end
    
    subgraph "External Integrations"
        SMT[SMT Solvers]
        PKI[PKI Infrastructure]
        IAM[Legacy IAM Systems]
    end
    
    DEV --> GW
    CISO --> GW
    COMP --> GW
    AI --> GW
    EXT --> GW
    
    GW --> AUTH
    GW --> PE
    GW --> CA
    GW --> WF
    GW --> TR
    GW --> CR
    
    PE --> CP
    CA --> CV
    CA --> CAT
    CR --> SMT
    
    PE --> CDB
    CA --> CDB
    WF --> CDB
    TR --> TDB
    CR --> ADB
    
    PE --> CACHE
    CA --> CACHE
    WF --> CACHE
    TR --> CACHE
    CR --> CACHE
    TR --> PKI
    WF --> IAM

Component Responsibilities

Policy Extraction Service

Parses Cedar policies submitted by developers
Extracts action+resource combinations as capabilities
Performs initial syntax validation and security classification
Provides real-time feedback on policy issues
Integrates with Cedar Policy Parser for accurate extraction

Capability Analysis Service

Performs deep analysis of extracted capabilities using Cedar Analysis tools
Identifies security risks, conflicts, and compliance violations
Maps capabilities to specific security requirements (SOC 2, ISO 27001)
Provides formal verification of policy correctness
Generates risk scores and security classifications

Workflow Engine

Manages approval workflows based on security classifications
Routes capabilities to appropriate reviewers (peers, CISO, delegates)
Enforces CISO-configured review preferences for specific security requirements
Tracks approval status and manages lifecycle states
Provides delegation and escalation capabilities

Token Registry Service

Manages registration of token types (JWT, X.509, HTTP signatures, Verifiable Credentials)
Maintains trusted issuer registry with domain validation
Handles token validation schemas and claim structures
Manages cross-domain trust relationships
Provides token verification APIs for runtime use

Compliance & Risk Service

Defines and manages universal security statements
Performs automated compliance verification against security frameworks
Generates compliance reports and audit trails
Manages risk assessments and thresholds
Integrates with SMT solvers for formal verification

Components and Interfaces

Core Data Models

Capability Model

interface Capability {
  id: string;
  semanticUri: string;
  version: string;
  name: string;
  description: string;
  
  // Extracted from Cedar policies
  actions: string[];
  resources: ResourcePattern[];
  conditions: ConditionExpression[];
  
  // Metadata
  sourcePolicy: PolicyReference;
  developer: DeveloperInfo;
  createdAt: Date;
  
  // Security & Risk
  riskLevel: RiskLevel;
  securityClassifications: SecurityClassification[];
  complianceRequirements: ComplianceRequirement[];
  
  // Lifecycle
  status: CapabilityStatus;
  approvalHistory: ApprovalRecord[];
  
  // Dependencies
  externalDependencies: ExternalDependency[];
  relatedCapabilities: string[];
}

enum CapabilityStatus {
  DRAFT = "draft",
  PENDING_PEER_REVIEW = "pending_peer_review",
  PENDING_CISO_REVIEW = "pending_ciso_review",
  ACTIVE = "active",
  DEPRECATED = "deprecated",
  RETIRED = "retired"
}

enum RiskLevel {
  LOW = "low",
  MEDIUM = "medium",
  HIGH = "high",
  CRITICAL = "critical"
}

Token Type Model

interface TokenType {
  id: string;
  name: string;
  format: TokenFormat;
  
  // Validation requirements
  validationSchema: ValidationSchema;
  requiredClaims: ClaimRequirement[];
  optionalClaims: ClaimRequirement[];
  
  // Cryptographic requirements
  signatureAlgorithms: string[];
  keyRequirements: KeyRequirement;
  
  // Capabilities this token type can authorize
  authorizedCapabilities: string[];
  
  createdAt: Date;
  updatedAt: Date;
}

enum TokenFormat {
  JWT = "jwt",
  X509_CERTIFICATE = "x509_certificate",
  HTTP_MESSAGE_SIGNATURE = "http_message_signature",
  VERIFIABLE_CREDENTIAL = "verifiable_credential"
}

Token Issuer Model

interface TokenIssuer {
  id: string;
  domain: string;
  issuerIdentifier: string;
  name: string;
  
  // Trust configuration
  trustLevel: TrustLevel;
  authorizedTokenTypes: string[];
  authorizedCapabilities: CapabilityAuthorization[];
  
  // Cryptographic validation
  publicKeys: PublicKeyInfo[];
  certificates: CertificateInfo[];
  
  // Cross-domain trust
  federationRules: FederationRule[];
  
  // Status
  status: IssuerStatus;
  validFrom: Date;
  validUntil?: Date;
  
  createdAt: Date;
  updatedAt: Date;
}

enum IssuerStatus {
  ACTIVE = "active",
  SUSPENDED = "suspended",
  REVOKED = "revoked"
}

Universal Security Statement Model

interface UniversalSecurityStatement {
  id: string;
  name: string;
  description: string;
  
  // Compliance framework mapping
  framework: ComplianceFramework;
  requirementId: string; // e.g., "CC6.1", "A.9.1.2"
  
  // Cedar-based formal statement
  cedarStatement: string;
  formalExpression: string;
  
  // Verification
  verificationStatus: VerificationStatus;
  lastVerified: Date;
  
  // Scope
  applicableCapabilities: CapabilityFilter;
  
  createdAt: Date;
  updatedAt: Date;
}

enum ComplianceFramework {
  SOC2 = "soc2",
  ISO27001 = "iso27001",
  NIST = "nist",
  GDPR = "gdpr",
  HIPAA = "hipaa"
}

API Interfaces

Policy Extraction API

interface PolicyExtractionAPI {
  // Submit Cedar policies for capability extraction
  extractCapabilities(request: {
    policies: CedarPolicy[];
    applicationContext: ApplicationContext;
    developerInfo: DeveloperInfo;
  }): Promise<ExtractionResult>;
  
  // Get real-time validation feedback
  validatePolicies(policies: CedarPolicy[]): Promise<ValidationResult>;
  
  // Preview capability extraction without submission
  previewExtraction(policies: CedarPolicy[]): Promise<CapabilityPreview[]>;
}

interface ExtractionResult {
  capabilities: Capability[];
  validationResults: ValidationResult;
  securityClassifications: SecurityClassification[];
  riskAssessment: RiskAssessment;
  recommendedActions: RecommendedAction[];
}

Capability Management API

interface CapabilityManagementAPI {
  // Search and discovery
  searchCapabilities(query: CapabilityQuery): Promise<CapabilitySearchResult>;
  getCapability(id: string): Promise<Capability>;
  
  // Lifecycle management
  updateCapabilityStatus(id: string, status: CapabilityStatus, reason: string): Promise<void>;
  approveCapability(id: string, approval: ApprovalDecision): Promise<void>;
  
  // Dependency analysis
  getDependencyGraph(id: string): Promise<DependencyGraph>;
  analyzeImpact(id: string, proposedChanges: CapabilityChange[]): Promise<ImpactAnalysis>;
}

Token Registry API

interface TokenRegistryAPI {
  // Token type management
  registerTokenType(tokenType: TokenTypeRegistration): Promise<TokenType>;
  getTokenTypes(filter?: TokenTypeFilter): Promise<TokenType[]>;
  
  // Issuer management
  registerIssuer(issuer: IssuerRegistration): Promise<TokenIssuer>;
  getIssuers(filter?: IssuerFilter): Promise<TokenIssuer[]>;
  revokeIssuer(issuerId: string, reason: string): Promise<void>;
  
  // Token validation
  validateToken(token: string, capabilityId: string): Promise<TokenValidationResult>;
  getValidationSchema(tokenTypeId: string): Promise<ValidationSchema>;
}

Compliance API

interface ComplianceAPI {
  // Universal security statements
  createUniversalStatement(statement: UniversalSecurityStatementRequest): Promise<UniversalSecurityStatement>;
  verifyCompliance(capabilityIds: string[], frameworkId: string): Promise<ComplianceVerificationResult>;
  
  // Policy aggregation
  getCurrentPolicySet(): Promise<PolicySet>;
  getHistoricalPolicySet(timestamp: Date): Promise<PolicySet>;
  
  // Cedar Analysis integration
  analyzePolicy(policySet: PolicySet, analysisType: AnalysisType): Promise<AnalysisResult>;
  comparePolicySets(oldSet: PolicySet, newSet: PolicySet): Promise<PolicyComparisonResult>;
  
  // Audit and reporting
  generateComplianceReport(framework: ComplianceFramework, timeRange: TimeRange): Promise<ComplianceReport>;
  getAuditTrail(filter: AuditFilter): Promise<AuditRecord[]>;
}

Data Models

Database Schema Design

Capabilities Table

CREATE TABLE capabilities (
    id UUID PRIMARY KEY,
    semantic_uri VARCHAR(500) UNIQUE NOT NULL,
    version VARCHAR(50) NOT NULL,
    name VARCHAR(200) NOT NULL,
    description TEXT,
    
    -- Cedar policy extraction
    actions JSONB NOT NULL,
    resources JSONB NOT NULL,
    conditions JSONB,
    source_policy_id UUID NOT NULL,
    
    -- Developer info
    developer_id UUID NOT NULL,
    application_context JSONB,
    
    -- Security & Risk
    risk_level risk_level_enum NOT NULL,
    security_classifications JSONB NOT NULL,
    compliance_requirements JSONB NOT NULL,
    
    -- Lifecycle
    status capability_status_enum NOT NULL DEFAULT 'draft',
    
    -- Timestamps
    created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW(),
    updated_at TIMESTAMP WITH TIME ZONE DEFAULT NOW(),
    
    -- Indexes
    CONSTRAINT fk_source_policy FOREIGN KEY (source_policy_id) REFERENCES cedar_policies(id),
    CONSTRAINT fk_developer FOREIGN KEY (developer_id) REFERENCES developers(id)
);

CREATE INDEX idx_capabilities_status ON capabilities(status);
CREATE INDEX idx_capabilities_risk_level ON capabilities(risk_level);
CREATE INDEX idx_capabilities_developer ON capabilities(developer_id);
CREATE INDEX idx_capabilities_semantic_uri ON capabilities(semantic_uri);
CREATE INDEX idx_capabilities_security_classifications ON capabilities USING GIN(security_classifications);

Token Types Table

CREATE TABLE token_types (
    id UUID PRIMARY KEY,
    name VARCHAR(200) UNIQUE NOT NULL,
    format token_format_enum NOT NULL,
    
    -- Validation
    validation_schema JSONB NOT NULL,
    required_claims JSONB NOT NULL,
    optional_claims JSONB,
    
    -- Cryptographic requirements
    signature_algorithms JSONB NOT NULL,
    key_requirements JSONB NOT NULL,
    
    -- Authorization scope
    authorized_capabilities JSONB,
    
    -- Timestamps
    created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW(),
    updated_at TIMESTAMP WITH TIME ZONE DEFAULT NOW()
);

CREATE INDEX idx_token_types_format ON token_types(format);

Token Issuers Table

CREATE TABLE token_issuers (
    id UUID PRIMARY KEY,
    domain VARCHAR(500) NOT NULL,
    issuer_identifier VARCHAR(500) NOT NULL,
    name VARCHAR(200) NOT NULL,
    
    -- Trust configuration
    trust_level trust_level_enum NOT NULL,
    authorized_token_types JSONB NOT NULL,
    authorized_capabilities JSONB NOT NULL,
    
    -- Cryptographic validation
    public_keys JSONB NOT NULL,
    certificates JSONB,
    
    -- Federation
    federation_rules JSONB,
    
    -- Status
    status issuer_status_enum NOT NULL DEFAULT 'active',
    valid_from TIMESTAMP WITH TIME ZONE NOT NULL,
    valid_until TIMESTAMP WITH TIME ZONE,
    
    -- Timestamps
    created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW(),
    updated_at TIMESTAMP WITH TIME ZONE DEFAULT NOW(),
    
    UNIQUE(domain, issuer_identifier)
);

CREATE INDEX idx_token_issuers_domain ON token_issuers(domain);
CREATE INDEX idx_token_issuers_status ON token_issuers(status);

Universal Security Statements Table

CREATE TABLE universal_security_statements (
    id UUID PRIMARY KEY,
    name VARCHAR(200) NOT NULL,
    description TEXT,
    
    -- Compliance framework
    framework compliance_framework_enum NOT NULL,
    requirement_id VARCHAR(50) NOT NULL,
    
    -- Cedar formal statement
    cedar_statement TEXT NOT NULL,
    formal_expression TEXT NOT NULL,
    
    -- Verification
    verification_status verification_status_enum NOT NULL DEFAULT 'pending',
    last_verified TIMESTAMP WITH TIME ZONE,
    
    -- Scope
    applicable_capabilities JSONB,
    
    -- Timestamps
    created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW(),
    updated_at TIMESTAMP WITH TIME ZONE DEFAULT NOW(),
    
    UNIQUE(framework, requirement_id)
);

CREATE INDEX idx_universal_statements_framework ON universal_security_statements(framework);
CREATE INDEX idx_universal_statements_verification ON universal_security_statements(verification_status);

Caching Strategy

Redis Cache Structure

// Capability cache keys
const CACHE_KEYS = {
  capability: (id: string) => `capability:${id}`,
  capabilityByUri: (uri: string) => `capability:uri:${uri}`,
  capabilitiesByDeveloper: (developerId: string) => `capabilities:developer:${developerId}`,
  capabilitiesByStatus: (status: string) => `capabilities:status:${status}`,
  
  // Token cache keys
  tokenType: (id: string) => `token_type:${id}`,
  issuer: (id: string) => `issuer:${id}`,
  issuerByDomain: (domain: string) => `issuer:domain:${domain}`,
  
  // Validation cache
  tokenValidation: (tokenHash: string) => `token_validation:${tokenHash}`,
  policyValidation: (policyHash: string) => `policy_validation:${policyHash}`,
  
  // Compliance cache
  complianceVerification: (capabilityId: string, framework: string) => 
    `compliance:${capabilityId}:${framework}`,
  universalStatements: (framework: string) => `universal_statements:${framework}`
};

// Cache TTL configuration
const CACHE_TTL = {
  capability: 3600, // 1 hour
  tokenType: 7200, // 2 hours
  issuer: 3600, // 1 hour
  validation: 300, // 5 minutes
  compliance: 1800 // 30 minutes
};

Error Handling

Error Classification

System Errors

enum SystemErrorCode {
  POLICY_PARSE_ERROR = "POLICY_PARSE_ERROR",
  CEDAR_ANALYSIS_ERROR = "CEDAR_ANALYSIS_ERROR",
  SMT_SOLVER_ERROR = "SMT_SOLVER_ERROR",
  DATABASE_ERROR = "DATABASE_ERROR",
  CACHE_ERROR = "CACHE_ERROR",
  EXTERNAL_SERVICE_ERROR = "EXTERNAL_SERVICE_ERROR"
}

Business Logic Errors

enum BusinessErrorCode {
  CAPABILITY_NOT_FOUND = "CAPABILITY_NOT_FOUND",
  INVALID_CAPABILITY_STATUS = "INVALID_CAPABILITY_STATUS",
  UNAUTHORIZED_APPROVAL = "UNAUTHORIZED_APPROVAL",
  COMPLIANCE_VIOLATION = "COMPLIANCE_VIOLATION",
  SECURITY_RISK_TOO_HIGH = "SECURITY_RISK_TOO_HIGH",
  TOKEN_VALIDATION_FAILED = "TOKEN_VALIDATION_FAILED",
  ISSUER_NOT_TRUSTED = "ISSUER_NOT_TRUSTED",
  UNIVERSAL_STATEMENT_VIOLATION = "UNIVERSAL_STATEMENT_VIOLATION"
}

Validation Errors

enum ValidationErrorCode {
  INVALID_CEDAR_SYNTAX = "INVALID_CEDAR_SYNTAX",
  MISSING_REQUIRED_FIELD = "MISSING_REQUIRED_FIELD",
  INVALID_TOKEN_FORMAT = "INVALID_TOKEN_FORMAT",
  INVALID_CLAIM_STRUCTURE = "INVALID_CLAIM_STRUCTURE",
  CRYPTOGRAPHIC_VALIDATION_FAILED = "CRYPTOGRAPHIC_VALIDATION_FAILED"
}

Error Response Format

interface ErrorResponse {
  error: {
    code: string;
    message: string;
    details?: any;
    timestamp: string;
    requestId: string;
    
    // For validation errors
    validationErrors?: ValidationError[];
    
    // For policy analysis errors
    policyErrors?: PolicyError[];
    
    // For compliance violations
    complianceViolations?: ComplianceViolation[];
  };
}

interface ValidationError {
  field: string;
  code: string;
  message: string;
  value?: any;
}

interface PolicyError {
  line?: number;
  column?: number;
  code: string;
  message: string;
  suggestion?: string;
}

interface ComplianceViolation {
  framework: string;
  requirementId: string;
  description: string;
  severity: "low" | "medium" | "high" | "critical";
  remediation?: string;
}

Testing Strategy

Unit Testing

Policy Extraction Service: Test Cedar policy parsing, capability extraction accuracy, and validation logic
Capability Analysis Service: Test risk scoring algorithms, security classification logic, and Cedar Analysis integration
Token Registry Service: Test token validation, issuer management, and cryptographic verification
Compliance Service: Test universal statement verification, formal verification integration, and compliance reporting

Integration Testing

Cedar Analysis Integration: Test integration with Cedar Symbolic Compiler and CLI tools
SMT Solver Integration: Test formal verification workflows and mathematical proof generation
Database Integration: Test data consistency, transaction handling, and performance
Cache Integration: Test cache invalidation, consistency, and performance

Security Testing

Token Validation: Test cryptographic signature verification, claim validation, and issuer trust verification
Policy Analysis: Test detection of security vulnerabilities, privilege escalation paths, and overly permissive policies
Access Control: Test API authentication, authorization, and role-based access controls
Compliance Verification: Test formal verification of universal security statements and compliance reporting accuracy

Performance Testing

Policy Extraction: Test performance with large Cedar policy sets and concurrent extraction requests
Capability Search: Test search performance with large capability datasets and complex queries
Token Validation: Test token validation performance under high load
Compliance Analysis: Test performance of formal verification and SMT solver integration

End-to-End Testing

Developer Workflow: Test complete flow from policy submission to capability activation
Approval Workflows: Test peer review, CISO approval, and delegation workflows
Compliance Reporting: Test generation of compliance reports for various frameworks
Token Lifecycle: Test complete token type and issuer management workflows

Design Decisions and Rationales

Microservices Architecture

Decision: Use microservices architecture with separate services for policy extraction, capability analysis, workflow management, token registry, and compliance.

Rationale:

Enables independent scaling of compute-intensive operations (Cedar Analysis, SMT solving)
Allows different teams to own different aspects of TBAC governance
Facilitates integration with external systems (Cedar tools, PKI, legacy IAM)
Supports gradual rollout and feature development

Cedar Analysis Integration

Decision: Integrate directly with Cedar Symbolic Compiler and Analysis CLI rather than reimplementing analysis logic.

Rationale:

Leverages formal verification proofs provided by Cedar team
Ensures consistency with Cedar's mathematical guarantees
Reduces maintenance burden and keeps up with Cedar improvements
Provides access to cutting-edge policy analysis capabilities

Token-First Design

Decision: Design the system around token types and issuers as first-class entities alongside capabilities.

Rationale:

TBAC fundamentally requires token evidence for capability authorization
Enterprise environments need governance over token issuers and trust relationships
Cross-domain federation requires explicit issuer management
Compliance frameworks require audit trails for token usage

Risk-Based Approval Routing

Decision: Automatically route capabilities through different approval workflows based on security classifications and risk levels.

Rationale:

Reduces CISO workload by focusing attention on high-risk capabilities
Enables faster approval for low-risk capabilities
Supports compliance requirements for security review processes
Allows customization based on organizational risk tolerance

Formal Verification for Compliance

Decision: Use Cedar's formal verification capabilities to provide mathematical proofs of compliance with security frameworks.

Rationale:

Provides stronger compliance guarantees than manual auditing
Enables continuous compliance monitoring as policies evolve
Reduces compliance audit burden through automated verification
Supports regulatory requirements for access control governance

This design provides a comprehensive, scalable, and secure foundation for enterprise TBAC adoption while maintaining the formal verification guarantees that make Cedar uniquely powerful for authorization policy management.

Uh oh!

TBAC Registry

Requirements Document

Introduction

Requirements

Requirement 1

Acceptance Criteria

Requirement 2

Acceptance Criteria

Requirement 3

Acceptance Criteria

Requirement 4

Acceptance Criteria

Requirement 5

Acceptance Criteria

Requirement 6

Acceptance Criteria

Requirement 7

Acceptance Criteria

Requirement 7

Acceptance Criteria

Requirement 8

Acceptance Criteria

Requirement 9

Acceptance Criteria

Requirement 11

Acceptance Criteria

Requirement 12

Acceptance Criteria

TBAC Registry Design Document

Overview

Architecture

High-Level Architecture

Component Responsibilities

Policy Extraction Service

Capability Analysis Service

Workflow Engine

Token Registry Service

Compliance & Risk Service

Components and Interfaces

Core Data Models

Capability Model

Token Type Model

Token Issuer Model

Universal Security Statement Model

API Interfaces

Policy Extraction API

Capability Management API

Token Registry API

Compliance API

Data Models

Database Schema Design

Capabilities Table

Token Types Table

Token Issuers Table

Universal Security Statements Table

Caching Strategy

Redis Cache Structure

Error Handling

Error Classification

System Errors

Business Logic Errors

Validation Errors

Error Response Format

Testing Strategy

Unit Testing

Integration Testing

Security Testing

Performance Testing

End-to-End Testing

Design Decisions and Rationales

Microservices Architecture

Cedar Analysis Integration

Token-First Design

Risk-Based Approval Routing

Formal Verification for Compliance

Implementation Plan

Uh oh!

Uh oh!

Uh oh!