registrystack / registrystack/registry-stack

Define safeguard profiles and compile an explainable per-field control plan

オープン
#593 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る
area:docs area:platform area:registryctl area:relay criticality:p2 enhancement post-1.0 rust triage:roadmap
主要言語
Rust
スター
2
フォーク
0
平均マージ
2時間 55分
マージ済み PR(30日)
130

説明

Tracked by #590. Depends on #592.

## Outcome

A deployment can select a versioned, digest-pinned safeguard profile and deterministically compile reviewed field classifications into an explainable per-field minimum-control plan. This issue is report and explanation only; it does not change request-time enforcement.

## Requirements

- Define a versioned safeguard-profile artifact with identity, version, review state, digest, supported classification terms, rule identifiers, and minimum-control requirements.
- Keep the safeguard profile separate from semantic profiles and descriptive Manifest ODRL.
- Model controls at the level Registry Stack can reason about, including exposure projection, purpose/PDP requirements, filter restrictions, relationship expansion, aggregation, attribute release, audit handling, and redaction requirements.
- Classify each outcome as `enforceable`, `declared_external`, or `unsupported` for the selected Registry Stack version and feature set.
- Compile classifications, selected profiles, existing explicit Relay controls, and feature availability into one deterministic per-field plan.
- Preserve monotonicity: derived requirements and explicit configuration may add restrictions, but no derived rule may remove an existing restriction.
- Reject ambiguous precedence, unknown policy-driving terms, conflicting rules, unsupported required controls, and digest mismatches.
- Produce stable rule IDs, a canonical policy hash, and value-free explanation output suitable for review and audit.
- Add `registryctl` report or explain output without exposing source field values, secrets, environment contents, or credentials.
- Keep report mode visibly non-enforcing and prevent it from being presented as compliance evidence.

## Acceptance criteria

- [ ] A golden classified Manifest and pinned safeguard profile compile into deterministic per-field controls.
- [ ] Explanation output identifies every classification, profile rule, explicit control, effective requirement, and enforcement status.
- [ ] Most-restrictive-wins behavior is tested independently of rule order and display names.
- [ ] Unknown, ambiguous, conflicting, and unsupported required rules fail with stable field-addressed diagnostics.
- [ ] The compiler cannot turn an existing purpose, scope, filter, redaction, or audit requirement off.
- [ ] Explanation output is bounded and redaction-tested.
- [ ] Report-only deployments cannot claim that the control plan is enforced.

## Non-goals

- Request-time PDP changes
- Route-specific enforcement
- A legal compliance verdict
- Runtime fetching of safeguard profiles
- Treating a framework principle as a field-classification namespace

コントリビューションガイド

コントリビューションガイドを開く

調査の方向性

まず追跡対象の issue #590 と dependency #592 を読み、次に既存の Registry Stack プロファイルと、そこに記載されている制御の概念を確認します。golden に分類された Manifest、固定された safeguard プロファイル、および registryctl の report または explain エントリポイントを統合対象として使用します。完了条件は、フィールド単位の決定論的な制御、安定した診断と説明、範囲が制限されレダクションされた出力、そして明確に強制を行わない report の動作です。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
rust
領域
backend-api-design, cli, security
issue の種類
機能追加
難易度
5/5
見積もり時間
1週間以上
活発さ
静か
明瞭さ
おおむね明確
初心者へのやさしさ
28/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。