@agenticprimitives/contracts 1.0.0-alpha.11 → 1.0.0-alpha.13

package/src/registry/IRegistryMembershipPolicy.sol

@@ -0,0 +1,30 @@
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.28;
+
+/**
+ * @title IRegistryMembershipPolicy
+ * @notice Pluggable membership/validation hook for {AgentRegistryBase} (spec 279 §4.2). It answers two
+ *         yes/no questions and NOTHING else:
+ *
+ *           - `canRegister`     — may `subjectAgent` create `entryId` in `registryId` with these claims?
+ *           - `canAdminister`   — may a NON-subject `actor` suspend / revoke / update `entryId`?
+ *
+ *         Implementations live OUTSIDE Ring 0 (issuer-attested, stake/bond, quorum-approved,
+ *         domain-control-proof, skill-claim-proof, …) — they MUST NOT push vertical business logic into
+ *         the registry base. Both methods are `view`, so {AgentRegistryBase} reaches them via STATICCALL
+ *         (no state mutation, no reentrancy). A policy that returns `false` OR reverts is treated as a
+ *         denial: the base fails closed (ADR-0013) — there is no second, weaker authorization path.
+ */
+interface IRegistryMembershipPolicy {
+    /// @return ok whether `subjectAgent` may register `entryId` in `registryId` with `cardHash`/`claimHashes`.
+    function canRegister(
+        bytes32 registryId,
+        bytes32 entryId,
+        address subjectAgent,
+        bytes32 cardHash,
+        bytes32[] calldata claimHashes
+    ) external view returns (bool ok);
+
+    /// @return ok whether `actor` (not the entry's subject) may administer (suspend / revoke / update) the entry.
+    function canAdminister(bytes32 registryId, bytes32 entryId, address actor) external view returns (bool ok);
+}