One startup model
Cold start runs through attestation, verification, config retrieval, secure installation, and activation.
Whitepaper
Backend-authoritative trust bootstrap for mobile applications.
This page condenses the Project Digitalis RFC suite into one readable architecture summary. It explains what the system does, where trust lives, and how the SDK behaves when startup conditions are good, degraded, or unsafe.
Executive summary
Project Digitalis is designed as a trust bootstrap runtime for mobile applications. Its role is to keep protected capabilities off until the app has collected attestation evidence, submitted it to a backend, received a policy decision, fetched approved protected configuration, installed that material into secure storage, and reached a trusted active state.
The RFCs are aligned around one core principle: the backend is the source of truth. The client gathers signals and enforces outcomes, but it does not make final trust decisions on its own. That design supports both Digitalis-operated and customer-managed backends without changing the security model exposed to the SDK.
One control plane
Policy, TTL, degradation rules, and config authorization live with the backend rather than the device.
One outcome model
Success and failure map into a small set of deterministic startup outcomes that can be tested and audited.
Canonical system model
The normalization plan describes the suite as a layered control system. The host app invokes the SDK. The SDK orchestrates provider-specific attestation, talks to a backend control plane, receives policy and protected configuration, installs approved material locally, and then enforces startup outcomes.
This matters because local secure storage is not treated as the root of trust. It becomes useful only after backend verification and authorization have completed successfully.
RFC suite summary
The six current RFCs define the v1 trust bootstrap architecture from startup sequencing through policy enforcement.
Trust bootstrap architecture
Establishes the normative startup flow: attest, verify, fetch configuration, install securely, then activate. Sensitive features must fail closed when required steps fail.
Backend abstraction and conformance
Defines the backend as the control plane and requires custom backends to preserve equivalent trust decisions, contract versioning, and capability semantics.
Unified provider abstraction
Creates one orchestration interface for Apple and Google while preserving raw evidence, provider capabilities, and deterministic error classes for backend policy.
Protected configuration lifecycle
Treats configuration as a security-governed asset with integrity validation, secure storage, versioning, rotation, revocation, and anti-rollback controls.
Native protection boundaries
Allows obfuscated native code as defense in depth, but rejects it as a trust anchor. Native helpers may raise reverse-engineering cost without becoming the policy authority.
Startup policy and failure handling
Defines the canonical outcome model that keeps protected features off by default and makes retries, blocking states, and hard exits explicit and policy-driven.
Key architectural themes
Backend authority over client optimism
The client may sanity-check data and enforce outcomes, but the backend remains authoritative for allow, deny, degrade, and TTL decisions.
No silent downgrade
Capability negotiation and fallback behavior must remain explicit. Unsupported environments should not quietly weaken the trust posture.
Configuration as a control asset
Protected config is tied to policy and integrity state. It is not generic app settings delivered without trust context.
Canonical startup outcomes
RFC-0006 reduces all startup results into six outcome classes so the SDK can be implemented consistently across platforms.
ALLOW
Trust bootstrap succeeded, protected config is valid, and protected features may be enabled.
ALLOW_DEGRADED
Only explicitly approved non-sensitive behavior may continue while protected features remain disabled.
RETRYABLE_FAILURE
Temporary conditions such as timeout or backend interruption justify controlled retry logic.
DENY_POLICY
The backend rejected the presented environment or rule profile and the app remains contained.
DENY_INTEGRITY
Integrity, signature, rollback, or revocation failures make trusted operation unsafe.
UNSUPPORTED_ENVIRONMENT
The required provider, contract, or secure storage capability is not available for policy-compliant startup.
Practical implication
Taken together, the RFCs are not just describing an SDK wrapper around Apple App Attest and Google Play Integrity. They describe a mobile trust system with explicit trust boundaries, a backend control plane, governed config delivery, and deterministic behavior under failure.
That makes the proposal more operationally demanding, but it also makes it more suitable for real protected features, customer-managed deployments, and formal conformance testing.
Conclusion
A security posture expressed as startup architecture.
The Project Digitalis RFC suite defines a mobile SDK shaped like a control system rather than a helper library. Trust decisions stay backend-authoritative, protected features stay off by default, and protected configuration only activates after a full verified flow.
That is the central idea running through the full RFC set, and it is the basis for the landing page, product positioning, and future implementation work.