PSP-1 Capability Model and Grammar - and associated structure

[CMCDragonkai]

Description

This starts the first protocol proposal with PSP-1. PSP stands for "Polykey Standards Proposal".

The first PSP is about Capability Model and Grammar.

Issues Fixed

• Fixes #...

Tasks

• 1. ...
• 2. ...
• 3. ...

Final checklist

• Domain specific tests
• Full tests
• Updated inline-comment documentation
• Lint fixed
• Squash and rebased
• Sanity check the final build

[CMCDragonkai]

Executive Decision for PSP‑1 v0.1 (after OT/acceptance review)

Decision: Keep PSP‑1 a compact authorization grammar. Incorporate only minimal hooks needed by OT wedges; push operational security and acceptance complexity to TAP/RAM/PSP‑4. No expansion of CPL/0 beyond the checks‑only kernel.

What we lock for PSP‑1 v0.1

• Language

  • CPL/0 remains checks‑only, ground terms, pure builtins. No user atoms, variables, rules, recursion, or caveats.
  • PairSet is the only declaration kind in core. ActionSet/ResourceSet can be a PSP‑4 profile later.

• Pinning

  • Grants MUST pin lang_version and builtins_id; channel_lattice_id only if channel_geq is used. Resource schemes by name. Verbs as strings.

• Registries

  • Builtins/Channel Lattices/Schemes live in PSP‑4. Unknowns fail closed.

• Program identity

  • PCF normalization (sort/dedup) + PSP‑3 canonical bytes + program_id. Mismatch ⇒ fail.

• Biscuit alignment

  • Add an informative note: CPL/0 is the checks‑only fragment mapping 1:1 to Biscuit checks; rules/derivations are out of core and may be added as a TAP‑gated profile later (off‑path AOT or compiled guards).

Minimal additions to cover OT‑driven needs (no new lattices, no core state)

• Environment facts (optional, TAP‑gated)

  • enforcer_assurance: Str (e.g., “L2‑E187”).
  • enforcer_jurisdiction: Str (e.g., “TW”, “EU‑NIS2”).
  • current_use_count: Int (read‑only projection if TAP requires; informative only).

• Expression pattern (use existing primitives)

  • Use ctx_eq to assert assurance/jurisdiction claims: ctx_eq("assurance","L2‑E187"), ctx_eq("jurisdiction","TW").
  • Enforcer targeting via ctx_eq("enforcer_did","did:…") or presenter_is where applicable.
  • Integration hygiene/KYB proofs are verified off‑path; CEP injects non‑PII digests/flags in ctx; Programs assert via ctx_eq.

• Explicitly defer from core

  • No assurance lattice (assurance_geq) in v0.1; if needed, define via PSP‑4 profile later.
  • No maxUses/stateful counters in CPL/0; use CEP/TAP policy (rate‑limit/deny). current_use_count exposure is optional and non‑normative.

Scope boundaries (to avoid creep)

• PSP‑1 stays an authorization construct:
  • Who/what/when/where/conditions expressed as CPL/0 checks over env facts + finite declarations.
• TAP/RAM own operational security and acceptance:
  • E187/E188 alignment, time‑source tolerances, SIEM/SOC formats, incident coordination, KYB verification policy, payout rules, regulatory reporting, insurance hooks.
• PSP‑2 owns receipts; PSP‑3 owns bytes/envelopes.

Edits to apply (succinct)

• Registries: keep as finalized (pin lang_version, builtins_id, channel_lattice_id when used; fail‑closed rules).
• Data Model
  • 6.2.2 Evaluation Environment: add optional enforcer_assurance, enforcer_jurisdiction, current_use_count (TAP‑gated).
  • 6.2.3 Builtins and Registries: state that assurance/jurisdiction constraints SHOULD be expressed via ctx_eq; new lattices can be PSP‑4 profiles; stateful policies are TAP/CEP concerns.
  • 6.2.5 Relationship to Biscuit: include the checks‑only mapping note.
• Optional (Overview): one informative sentence acknowledging the “Settlement/Acceptance” layer (PSP‑2/TAP/RAM) as the cross‑boundary interface; PSP‑1 feeds it.

Next steps

• Lock Builtins v1 in PSP‑4 (in_pairset, within_time, ttl_ok, channel_geq, ctx_eq, presenter_is).
• Produce two test vectors (Program → PCF bytes → program_id) and one self‑contained Presentation chain.
• Add a TAP‑OT profile draft (separate doc) for E187/E188 alignment, time sync tolerances, and assurance labels, using ctx claims and receipts—not new PSP‑1 constructs.

This preserves PSP‑1’s clean, portable authorization kernel while giving OT wedges the minimal hooks they need.