register

varwof-register

Part of the Varwof AIC suite — flagship repos: aic-agent · aic-verifier · aic-exec

Capability Registry — standard capability definition, validation, and authz.json generation for fine-grained AI Agent permission control.

⚠️ Preview — Not for production use. APIs and features may change before official release.

中文

What is varwof-register?

A registry of standard capability definitions for fine-grained AI Agent permission control. Capability specifications are carried by executable JSON files (capability.json), support PKCS#7 signatures, and can generate authz.json authorization policies (gen-authz tool).

Quick Start

cd register

# Capability data lives in the sibling capability module.
export CAPABILITY_DIR=../capability/data

# List all capabilities
go run ./cmd/gen-authz -list $CAPABILITY_DIR/varwof/core-v1/v1.json

# Generate authz.json
go run ./cmd/gen-authz -out /tmp/authz.json $CAPABILITY_DIR/varwof/core-v1/v1.json

# Validate / search capabilities
go run ./demo -data $CAPABILITY_DIR validate varwof/core-v1:cert:issue
go run ./demo -data $CAPABILITY_DIR search issue

Capability files are addressed as <vendor>/<product>-v<major>/v<major>.json, so the paths above carry the -v1 product suffix.

Installation

go get github.com/varwof/register@v0.10.0

Directory Structure

register/
├── semantics/        # CLC-v1 decision layer (grammar, entailment, decision)
├── schemeadmin/      # CLC-SCHEME-v1 administration (package, transition, confirm)
├── catalog/          # signed capability catalog plane (catalog, delta, discovery)
├── projection/       # foreign-evidence → CLC-REQUIREMENT-v1 projection (CLC-E)
├── ruleexec/         # execution layer (rules, conditions, flow, budgets, SQL)
├── schema.go / registry.go / validator.go / mincap.go
├── genauthz.go / gendocs.go / sign.go / loader.go / params_validate.go
├── cmd/              # tools and conformance runners (see the table below)
├── demo/             # capability demo (needs -data <capability data dir>)
├── demo/rule-exec/   # rule-exec e2e demo + rule.schema.json + TS mirror
├── docs/             # user docs
└── dev-docs/         # developer docs

cmd/ tools

Every runner reads its corpus from the environment and exits non-zero on any mismatch; see Conformance corpora.

Capability definitions themselves are not in this repository; they live in the separate varwof/capability module (data/<vendor>/<product>-v<major>/v<major>.json).

Provenance and licensing

semantics/ and the rest of this repository are written from published specifications and this project's own language text; no third-party code was copied. Where a specification's rule is normative here, it is cited by section and restated in this project's own words rather than reproduced, and the Internet-Drafts referred to are referenced as work in progress, not as normative sources. The conformance corpora live in varwof/capability (data/_vectors/clc-v1/).

CLC-v1 semantics (semantics/) and conformance runner

Two orthogonal axes, not a stack: the decision axis decides whether a call counts as doing something that was authorized, the execution axis decides whether to act now and what to record. CLC owns the decision axis; ruleexec/ owns the execution axis (see docs/capability-language-layers.md). Across both run the authorization face ("what may be done") and the evidence face ("what was done, and the evidence for it"). A draft such as ACA is a composition contract over these two axes, not a third layer.

semantics/ is the Go reference implementation of CLC-v1, in two groups:

Core semantics — required by the conformance classes:

Delegation containment (CLC-D) — the chain face, §13:

Input boundaries — what a params object must satisfy before any layer runs. Callers that skip these get no §9.3 protection:

Both parameter entry points apply the same §6.2 caps and the same invalid_params_number denial, so an integer outside the I-JSON interoperable range (magnitude above 2^53−1) is refused rather than rounded, at either entry.

Optional profile — carried, not required: a deployment that only decides online pays none of this. Everything here is off unless a caller turns it on:

Failures are fail-closed and carry stable reason codes (§9.4); when several conditions fail, the normative ordering (§9.3) selects the single reported code.

This implementation declares the revision named by the Go constant semantics.CLCRevision — the single source of truth for it — and applies the compatible reading of §12.1: an input whose declared major equals ours and whose declared minor is ≤ ours is evaluated normally; a higher minor fails closed with unsupported_language_revision. It is never silently downgraded.

Conformance corpora

Every corpus is published in varwof/capability under data/_vectors/, and every runner asserts verdict and normative reason and exits non-zero on any mismatch. Point a runner at a corpus with the environment variable it reads:

export CLC_VECTORS=../capability/data/_vectors/clc-v1/vectors.json
go run ./cmd/vectors-run/

The CLC-A set also carries the §7.1 UTF-8 collation (2) and §6.5 type-sensitive equality (11) cases, plus the property corpora (1184 P11 cases, 500 meet-invariant cases, 784 containment-closure cases) — those run from go test ./semantics/ rather than a standalone runner.

These corpora are portable: the same files are consumed by the other same-author implementations, so a divergence is visible from both sides —

CI (.github/workflows/clc-conformance.yml) clones varwof/capability and runs gofmt / go vet / go test plus every runner on each push and PR.

Input boundaries

Both parameter entry points apply the same §6.2 caps and the same invalid_params_number denial, so an integer outside the I-JSON interoperable range (magnitude above 2^53 − 1) is refused rather than rounded, at either entry. The bound reaches the max_rows constraint operand as well — §8.1 does not exempt it from layer-7 closure — and an over-bound ceiling is refused with invalid_constraint, the §8.1 reason code.

Byte budget of the optional artifacts is reproducible (record / envelope / challenge sizes, and the constraint strings that drive certificate size):

go run ./cmd/size-report/

Decision Records (semantics/record.go)

Record freezes what was decided — the canonical inputs, the CLC revision, the verdict, the reason and the residual obligations — behind a SHA-256 digest of the inputs, so a holder of the record alone can re-run the same revision and get the same answer. Verify does exactly that, and fails closed with record_input_digest_mismatch, record_verdict_mismatch, record_operation_count or record_unsupported_revision on anything that does not reproduce.

go run ./cmd/record input.json          # {"grants":[...],"operation":{...}} -> record
go run ./cmd/record -verify record.json # re-run the language over a record

Note: CanonicalJSON implements RFC 8785 (JCS) — object members ordered by UTF-16 code units, §3.2.2.2 string escaping, ECMAScript Number::toString — so clc-action: identifiers and Decision Record digests agree with any other JCS implementation. (Before rev CLC-1.6 it was json.Marshal, whose HTML escaping made &/</> digests non-JCS.) Constraint evaluation results and authorization source chains are not part of a record yet — see dev-docs/README.md.

Execution layer (ruleexec/)

ruleexec runs signed rules: op | if | seq control flow over runtime context conditions, a fixed budget (steps / depth / nesting) and fully parameterized SQL generation. The execution language deliberately contains no loops, no retries, no time-in and no contains — those belong to the caller/job orchestrator or to authorization constraints.

• docs/capability-language-layers.md — one language, two layers; the rule publication boundary (RuleWithinSignerGrant).
• docs/rule-authoring.md — how to write a rule file: fields, the closed operator set, the parameter contract, the gate matrix.
• docs/toolchain.md — end-to-end flow and every tool (gen-rule included) with its usage.
• docs/condition-semantics.md — null / type / case / SQL mapping rules and the shared test vectors.

Ecosystem

graph TB
    subgraph varwof["varwof Ecosystem"]
        core["core"]
        gw["gateway"]
        cap["capability<br/>JSON Data"]
        reg["register<br/>Capability Registry"]
    end
    reg -->|loads| cap
    core -->|validates against| reg
    gw -->|validates against| reg
    reg -.->|generates| core

register is the capability specification layer of the varwof ecosystem, connecting capability (data) with core/gateway (runtime validation). This project is a member of the Open Invention Network.

Related repositories

Links