You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A privacy reviewer or operator assessing a Registry Notary deployment. Per RS-DM-CLAIM §4 / §9, a source binding MAY carry a matching policy that gates a read on purpose, relationship, and sufficient-input constraints (enforced by REQ-DM-CLAIM-004 where declared). But:
With no matching policy, a binding falls back to unrestricted, identifier-only resolution — no purpose, relationship, or input-minimization gating.
This means a binding authored without a matching policy silently has none of the purpose/relationship/minimization protections, and nothing in the tooling currently flags that a privacy-relevant control is simply absent. The "off" state looks identical to a correctly-configured-but-permissive one.
Proposed Behavior
Make the unprotected fallback visible, and make a stricter posture available to deployments that want it:
Have registryctl doctor (or config load) warn when a source binding has no matching policy, naming the binding — so the absence is an explicit, reviewable signal rather than a silent default.
Offer an opt-in deployment gate (e.g. "require matching policy on every source binding") so purpose-bound deployments can make the absence a hard error rather than relying on author discipline.
Boundaries
REQ-DM-CLAIM-004 enforces purpose/relationship/sufficient-input constraints only where a matching policy is declared; the unrestricted fallback for the unconfigured case is the documented current behavior. This request is about surfacing it and offering an optional stricter mode — not changing the default semantics unilaterally.
Governance/privacy constraint is central: the goal is to prevent a deployment from unknowingly running purpose-ungated identifier resolution.
Use Case
A privacy reviewer or operator assessing a Registry Notary deployment. Per RS-DM-CLAIM §4 / §9, a source binding MAY carry a matching policy that gates a read on purpose, relationship, and sufficient-input constraints (enforced by REQ-DM-CLAIM-004 where declared). But:
This means a binding authored without a matching policy silently has none of the purpose/relationship/minimization protections, and nothing in the tooling currently flags that a privacy-relevant control is simply absent. The "off" state looks identical to a correctly-configured-but-permissive one.
Proposed Behavior
Make the unprotected fallback visible, and make a stricter posture available to deployments that want it:
registryctl doctor(or config load) warn when a source binding has no matching policy, naming the binding — so the absence is an explicit, reviewable signal rather than a silent default.Boundaries
Surfaced while reviewing the Stage-1 data-minimization / limitations documentation against RS-DM-CLAIM §4 and §9.