One startup model
Cold start is specified to run through attestation, verification, config retrieval, secure installation, and activation.
Public architecture whitepaper
Backend-authoritative trust bootstrap for mobile applications.
This page condenses the Digitalis RFC suite into a readable architecture summary. It describes the intended control model, where authority resides, and how conforming implementations should behave when startup conditions are acceptable, degraded, or unsafe.
Executive summary
Digitalis is designed as a trust bootstrap runtime for mobile applications. Its intended 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 align around one core principle: the backend is the source of truth. A conforming client gathers signals and enforces outcomes, but it does not make final trust decisions on its own. That design is intended to support both managed and customer-operated backends without changing the security model exposed to client integrations.
One control plane
Policy, TTL, degradation rules, and config authorization are assigned to the backend rather than the device.
One outcome model
Success and failure map into a small set of deterministic startup outcomes intended for testing and audit.
Canonical system model
The normalization plan describes the suite as a layered control system. The host app invokes a client SDK or integration layer. That client is expected to orchestrate provider-specific attestation, communicate with a backend control plane, receive policy and protected configuration, install approved material locally, and enforce startup outcomes.
Local secure storage is not treated as the root of trust. It becomes useful only after backend verification and authorization complete successfully.
RFC suite summary
The six current RFCs define the intended 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
Defines 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 startup results into six outcome classes so conforming client implementations can behave 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 unavailable for policy-compliant startup.
Practical implication
Taken together, the RFCs do not merely describe a wrapper around Apple App Attest and Google Play Integrity. They define an intended mobile trust system with explicit trust boundaries, a backend control plane, governed config delivery, and deterministic behavior under failure.
That makes a conforming implementation more operationally demanding, but also more suitable for protected features, customer-managed deployments, and formal conformance testing.
Conclusion
A security posture expressed as startup architecture.
The Digitalis RFC suite defines an intended mobile client and backend system shaped like a control system rather than a helper library. Trust decisions remain backend-authoritative, protected features remain off by default, and protected configuration activates only after a verified flow.
That is the central idea across the RFC set and the basis for the public architecture, prototype work, and future release program.