NUB-CLASS-2: User-approved explicit-origin posture (sub-track)

[dskvr]

Status: Draft
Parent: NUB-CLASS
Class number: 2

Summary

NUB-CLASS-2 is the posture for napplets that declare explicit direct-network origins and have received user consent for those origins. Shells emit a runtime CSP with connect-src <granted-origins>, prompt the user on first load, persist the decision keyed on (dTag, aggregateHash), and send class.assigned with class: 2 when approved. If the user denies the prompt, the napplet is served under the NUB-CLASS-1 posture instead (class: 1, connect-src 'none').

CSP Posture

connect-src <space-separated-list-of-granted-origins>

Shells emitting the NUB-CLASS-2 posture MUST include connect-src <granted-origins> where <granted-origins> is the user-approved origin list for the napplet identified by (dTag, aggregateHash). The origin list MUST be exactly the set the user approved — shells MUST NOT add, remove, or normalize origins between the approved set and the emitted directive.

If the approved set is empty (user approved zero origins on the prompt), the shell MUST emit connect-src 'none' and SHOULD downgrade the assignment to NUB-CLASS-1.

Scope

• Manifest Prerequisites — a napplet reaches NUB-CLASS-2 when it declares at least one tag from a class-contributing NUB whose trigger condition for NUB-CLASS-2 is met, AND the user has approved the napplet's request at first load. The specific manifest-tag shape is defined by the individual class-contributing NUB (e.g., ["connect", "<origin>"] — see NUB-CONNECT.md).
• Consent Flow — shells MUST prompt on first load per (dTag, aggregateHash), MUST persist the decision, MAY expose revocation affordance.
• Grant Persistence Key — (dTag, aggregateHash) composite. AggregateHash changes (via contributing-NUB synthetic xTags like connect:origins) MUST auto-invalidate prior grants.
• Shell Responsibilities — emit baseline CSP with connect-src set to the approved set, prompt + persist + optionally revoke, send terminal class.assigned with class: 2 after iframe-ready.
• Revocation UX — revoked grants MUST either reload with class.assigned class: 1 or trigger shell-side refusal-to-serve until user re-approves. Mid-session dynamic class change is out of scope.
• Security Considerations — once granted, the shell has zero visibility into post-grant traffic (browser enforces CSP transparently to the shell). Grants are a full trust vote for listed origins.

Non-Goals

• Per-origin partial grants — v1 is all-or-nothing per prompt.
• Wildcard subdomains — each subdomain is a separate tag requiring separate consent.
• Quota / rate-limiting / audit logging — browser gives the shell no hook in the sandboxed iframe model.

Implementations

(none yet)