P1 governance: T2 publisher admission, capability approval and emergency removal

[marcohost33-maker]

Purpose

Define the policy boundary between T1 owner-controlled packages and T2 curated third-party packages before any third-party package can be admitted. This issue governs publisher trust, review, capability approval, continuous support and emergency removal; it must not treat signature validity as admission or harmlessness.

Blocked by T1 runtime/package evidence in #23 and #24. Depends on the acquisition-mode taxonomy in #30. Advances #21.

Required lifecycle states

Every package/version must have explicit, independently auditable states:

1. signature-valid — package bytes and declared identity verified;
2. publisher-admitted — key/publisher authorized for a namespace and trust class;
3. reviewed — source/build/package/privacy/security evidence assessed;
4. capability-approved — exact native/network/device grants approved;
5. installed — atomically placed and integrity-read back;
6. enabled — permitted to execute for a user/profile;
7. quarantined — execution blocked while preserving evidence and user data where safe;
8. revoked — publisher key/package/version no longer trusted;
9. removed — package removed with defined data-retention/export behavior.

No state may be inferred automatically from another. In particular, signature-valid does not imply publisher-admitted, reviewed, capability-approved or enabled.

Publisher identity and delegated trust

Require:

• independent verification of publisher identity and public-key control;
• namespace ownership and collision policy;
• TUF-style delegated target roles or equivalent narrowly scoped publisher authorization;
• threshold/offline root trust for high-impact changes;
• documented signing-key generation, custody, rotation, revocation, loss and compromise recovery;
• explicit handling of package identity when .swbn/IWA bundle IDs derive from signing keys;
• transparent record of admitted keys, scopes, expiry and replacement lineage;
• prevention of one publisher signing into another publisher's namespace.

Admission evidence

Mandatory controls include:

• source and release-repository provenance;
• reproducible or independently rebuildable artifact evidence where feasible;
• SBOM and third-party component inventory;
• package/verifier output from P0 package and secure-update spike: .swbn/IWA vs minimal signed package #24;
• declared network destinations and data flows;
• privacy purpose, retention and user-control declaration;
• license and redistribution rights;
• capability request with least-privilege rationale;
• security-support period, vulnerability intake and patch SLA;
• incident contact and emergency-update/removal agreement;
• accessibility and platform-compatibility evidence appropriate to the package;
• known residual risks and user-visible disclosures.

Review and package signing must never be represented as proof that code is harmless.

Capability approval

• use a typed risk taxonomy for filesystem, shell/process, devices, clipboard, downloads, external protocols, camera/microphone, location, notifications and network access;
• bind approval to publisher, package identity, version/range, acquisition mode, app/site origin and user profile;
• compare capability delta between releases;
• any privilege expansion is a material change requiring explicit re-review and user consent;
• broker enforcement must bind app ID, origin/site, frame/SiteInstance, renderer process and user action;
• packages default to no native capability and the minimum network scope.

Continuous review and update obligations

• review staleness and material-change triggers;
• monitored vulnerability/advisory intake;
• maximum patch latency by severity;
• expiry of unsupported publisher/package versions;
• update authenticity, rollback/freeze and repository-consistency evidence from P0 package and secure-update spike: .swbn/IWA vs minimal signed package #24;
• periodic key-rotation and revocation drills;
• periodic re-review of permissions, privacy/data flows, dependencies and ownership changes;
• clear response when the publisher disappears or stops maintaining the package.

Emergency quarantine and removal

Define and test:

• signed emergency quarantine/revocation distribution;
• behavior while fully offline and after prolonged offline periods;
• disabling execution without corrupting unrelated apps or shared runtime state;
• preservation/export/deletion policy for user-created local data;
• installed-version notification and remediation guidance;
• rollback to a known-safe package only when policy permits;
• forensic evidence retention and audit trail;
• recovery from false-positive quarantine or compromised revocation metadata;
• maximum removal/quarantine propagation time by risk class.

A remote kill mechanism must not silently destroy user data or become an unaudited universal control channel.

Quantitative controls

• admission completeness passed mandatory controls / mandatory controls, with any hard fail overriding the ratio;
• review staleness now - last_material_review;
• capability delta between releases;
• patch latency from fix disclosure to verified package availability;
• unresolved critical/high vulnerability count;
• unsupported-version field population;
• quarantine/revocation propagation latency;
• removal-drill recovery time;
• false-positive quarantine and successful-appeal rate;
• key-rotation/revocation drill success rate.

Hard fails

• unverifiable publisher/key ownership;
• namespace collision or cross-publisher signing ambiguity;
• missing rights to distribute or run the package in the selected mode;
• undeclared sensitive data flow or native capability;
• unresolved critical vulnerability without bounded compensating control;
• no credible patch/support path;
• rollback/freeze/revocation controls untested;
• emergency removal that risks silent user-data destruction;
• signature validity used as a substitute for admission/review.

Acceptance

• lifecycle-state machine and transition authority defined;
• T2 admission template;
• publisher/namespace and delegated-key policy;
• permission-risk taxonomy and capability-delta review;
• material-change definition;
• secure update, rotation and revocation policy aligned with P0 package and secure-update spike: .swbn/IWA vs minimal signed package #24;
• incident, quarantine and emergency-removal drill;
• local data preservation/export/deletion policy;
• privacy, legal and license review triggers;
• appeal/dispute and audit-trail process;
• accountable owner approval;
• independent security/privacy review.

Primary references

• TUF specification: https://theupdateframework.github.io/specification/latest/
• ChromeOS Isolated Web Apps: https://chromeos.dev/en/web/isolated-web-apps
• WICG Web Package: https://github.com/WICG/webpackage

No third-party package may be admitted until this policy and the blocking runtime/package evidence are accepted.

[marcohost33-maker]

Triage 2026-07-17 — verdict: STILL-VALID · BLOCKED-ON T1 evidence

The T2 publisher-admission lifecycle (signature-valid → publisher-admitted → reviewed → capability-approved → installed/enabled/quarantined/revoked/removed, with "signature ≠ admission ≠ harmlessness") is sound and unaffected by the standalone reframe. Its own body already declares it blocked by #23/#24 (T1 runtime/package evidence) and dependent on #30 (acquisition modes).

Position: not on the immediate critical path — no third-party package can be admitted before a T1 runtime + package verifier exist. Next action: keep as the T2 policy spec; begin drafting the admission template + publisher/namespace/delegated-key policy in parallel (paper design is not blocked), but do not admit any package until #23/#24 land. Priority: P1. Kept open.