Delegation and Revocation Trade-Offs in Capability-Based Multi-Tenant Access Control
A completed computer science study comparing delegation and revocation mechanisms for capability-based multi-tenant access control across connected, offline, partitioned, and compromised-delegate conditions.
Software compatibility
The study uses declared evidence positions, 20,000 uncertainty draws per mechanism and random seed 20260830. The September revision adds executable delegation semantics and cache-timing analysis. Tested locally on macOS and reproduced in Linux Docker; Windows setup instructions are included.
Project definition
Problem statement
Capability-based access control can express narrow authority and support decentralized verification, but delegation and revocation mechanisms differ in stale-privilege windows, state, availability, lineage, tenant isolation, and operational complexity.
The engineering problem is to choose lifecycle semantics for a multi-tenant system without assuming that a valid token is always current, that every verifier is connected, or that one mechanism is best for every application context.
Project objectives
- Compare ten delegation and revocation mechanism families across eight governing risk drivers.
- Apply hard gates for tenant binding, attenuation, revocation, and disconnected verification.
- Evaluate SaaS, service API, IoT or edge, and multi-agent application contexts.
- Compare connected validation, offline verification, control-plane outage, and compromised-delegate evidence cases.
- Map fourteen validation criteria across eleven authority lifecycle stages.
- Execute tenant binding, action attenuation, delegation depth, expiry and ancestor-revocation checks.
- Calculate stale-access windows under explicit lease and cache-refresh assumptions.
- Quantify evidence-position uncertainty with 20,000 fixed-seed draws per mechanism.
Project structure
Project components
Mechanism register
Compares online monitors, bounded leases, caveats, signed chains, revocation trees, epochs, status lists, brokers, verifiable credentials, and a non-revocable baseline.
Risk-driver model
Tests cross-tenant confusion, unbounded re-delegation, stale privilege, offline verification, recursive revocation, scale, audit lineage, and context attenuation.
Decision framework
Scores twelve declared evidence dimensions and rejects mechanisms that fail the governing hard gates.
Scenario analysis
Changes weights and gates for balanced, security-first, revocation-first and edge decision contexts.
Authority chains
Runs parent-child attenuation, tenant isolation, direct and recursive revocation, expiry and independent-proof examples. Cryptographic verification is an explicit assumption.
Cache timing
Compares 216 policy cases to calculate when a cached authorization can outlive revocation or lease expiry.
Lifecycle assurance
Maps 154 stage-criterion cells using 45 declared links. These are qualitative review prompts, not failure probabilities or FMEA risk-priority numbers.
Verification pipeline
Regenerates results, tests the model, validates the documents, audits dependencies, and reproduces the study in Docker.
Methodology
Project workflow
- 01Define authority
Declare tenants, principals, resources, actions, purposes, duration, delegation depth, and trust boundaries.
- 02Choose lifecycle semantics
Select issuance, attenuation, lineage, expiry, direct revocation, recursive revocation, and offline behaviour.
- 03Run the comparison
Generate the deterministic mechanism, driver, context, evidence-case, and scenario results.
- 04Inspect failures and uncertainty
Trace authority-chain decisions, calculate stale-access windows, then review failed gates, qualitative assurance gaps, scenario reversals and sensitivity.
- 05Plan validation
Translate the retained mechanism into topology, protocol, load, partition, recovery, security, and usability tests.
Demonstration scenario
Start with a root, child and leaf authority chain. Revoke the parent and compare direct and recursive checks, then try an independent proof. In a separate declared timing example, per-request expiry checks allow 25 seconds of stale access while a cached decision allows 55 seconds. Change the lease and refresh interval to explain the difference.
Engineering
Tools and method
- Declared inputs
- Python data structures retain every mechanism position, risk-driver link, application context, evidence case, gate, and boundary.
- Deterministic analysis
- NumPy and pandas generate all 1,280 comparison cells and the supporting crosswalks.
- Lifecycle assurance
- Named criterion and requirement mappings make tenant confusion, stale caches, lineage breaks, recovery and operator checks explicit without claiming quantitative reliability.
- Uncertainty
- Fixed-seed Monte Carlo and one-factor sensitivity test the stability of literature-informed evidence positions.
- Evidence
- CSV, JSON, PNG, PDF, and Word files retain the full analysis, source catalogue, figures, and project report.
- Release verification
- Tests, linting, vulnerability audit, document QA, repository validation, and Docker verify the handover.
Testing
Evaluation
Evaluation measures
- Screening score and hard-gate result by mechanism, risk driver, application context, and evidence case
- Least authority, attenuation, revocation completeness, propagation, tenant isolation, auditability, usability, and maintenance positions
- Mechanism reversals across balanced, security-first, revocation-first and edge scenarios
- Qualitative lifecycle coverage and explicitly mapped assurance gaps
- Direct versus recursive revocation and independent-proof decisions
- Stale-access windows with exact integer-time checks for both cache policies
- Assurance requirement crosswalk by mechanism
- Monte Carlo intervals and evidence-position sensitivity
Project boundaries
- Comparison scores use declared literature-informed positions, not measured security performance. Timing outputs are exact consequences of the stated discrete model, not deployment measurements.
- The executable model assumes authentic grants, trusted roots and a trusted clock. It does not implement signatures, key management or a distributed revocation service.
- The study does not implement or certify a production identity provider, policy engine, capability service, or zero-trust architecture.
- It does not claim measured breach reduction, production latency, implementation cost, or universal mechanism superiority.
- Public standards are cited by identifier and metadata without reproducing protected clauses or tables.
- A receiving team must replace declared positions with its own topology, workloads, operator tasks, protocol tests, and independent security review.
Included
- 01Complete Python source, declared inputs and an executable authority-chain example
- 021,280 mechanism, risk-driver, application-context and evidence cases
- 03Ten delegation and revocation mechanism families
- 04Four decision scenarios with explicit hard gates
- 05216 cache-timing cases comparing cached decisions with per-request expiry checks
- 06Fourteen validation criteria, a 154-cell qualitative lifecycle map and a 130-cell assurance crosswalk
- 07Thirteen generated figures and one attributed government literature figure
- 0894-page project report in PDF and editable Word formats
- 09Six-page setup and usage guide in PDF and editable Word formats
- 10Fifty annotated references with evidence boundaries and source matrix
- 11Automated tests, repository validation and Docker reproduction
Project record
No information is collected on this page.
- Permanent project ID
- GP-CS-10EADL0
- Catalogued
- 21 Aug 2026
- Completed
- 02 Sept 2026
- Verified
- 07 Sept 2026
- Demonstration
- Included in repository
Handover
After purchase
- 01Payment is confirmed
The project is marked unavailable and cannot be purchased again.
- 02Repository access is granted
The buyer's submitted GitHub account receives access to the private repository.
- 03The purchase record is delivered
The certification sheet is prepared from the reviewed buyer details and sent privately by email.