SDK packages

The Ratify Protocol ships reference SDKs in five languages. All five are byte-for-byte interoperable — they produce identical canonical JSON, identical hybrid signatures, and pass the same 63-fixture conformance suite.

Current published versions

Language	Registry	Package	Version	Install
Go	pkg.go.dev	`github.com/identities-ai/ratify-protocol`	v1.0.0-alpha.13	`go get github.com/identities-ai/[email protected]`
TypeScript	npm	`@identities-ai/ratify-protocol`	1.0.0-alpha.13	`npm install @identities-ai/[email protected]`
Python	PyPI	`ratify-protocol`	1.0.0a13	`pip install ratify-protocol==1.0.0a13`
Rust	crates.io	`ratify-protocol`	1.0.0-alpha.13	`cargo add [email protected]`
C/C++	GitHub Releases	`libratify_c.a` / `libratify_c.so`	1.0.0-alpha.13	Download pre-built archive or build from source — see C/C++ SDK

All five versions are released atomically — every tagged release of the protocol contains the same version of every SDK. A consumer using v1.0.0-alpha.13 in Go and v1.0.0-alpha.13 in Python is guaranteed to produce and verify byte-identical bundles.

What’s new in v1.0.0-alpha.13

Registry read binding (SPEC §13.1). The optional lookup contract behind registry-mode key discovery: GET /v1/registry/principals/{human_id} returns the principal’s current root key, the full key-rotation chain, and the optional anchor — so any registry (the managed Verify service or a third party) is interchangeable. TLS-mandatory, fail-closed resolver semantics, and explicit first-trust framing: rotation proves continuity after first trust; it never creates it.

Reference resolver. cmd/ratify-verifier gains --registry <https-url> (registry trust: operator + TLS) and --registry-pins + --registry-require-pinned (pin-plus-registry: only first-trusted principals and their rotation successors).

What was new in v1.0.0-alpha.12

No-expiry sentinel. A DelegationCert whose expires_at equals NO_EXPIRY_SENTINEL = 4070908799 (2099-12-31 23:59:59 UTC) means “no expiry (until revoked)”. Display and policy code must branch on the sentinel; every SDK ships a helper (IsNoExpiry() in Go, isNoExpiry() in TypeScript, is_no_expiry() in Python and Rust, ratify_expires_at_is_no_expiry() in C). Verification is unchanged; revocation is the sole termination mechanism for such certs.

presence:represent scope (sensitive). The canonical vocabulary grows to 54 scopes: an agent may attend and interact as a direct representative of the principal. No presence:* wildcard; does not imply identity:prove. See Scopes.

Verifier scope-vocabulary validation. A cert granting a scope that is not canonical, not a wildcard, and not a custom: extension is now rejected with the new identity status invalid_scope, before any effective-scope arithmetic.

Conformance suite grows to 63 canonical fixtures — four new fixtures pin the additions above; all pre-existing fixtures are byte-identical to the previous release.

What was new in v1.0.0-alpha.10

C/C++ SDK — full conformance-suite parity. All canonical fixture kinds now pass through the C ABI: verify, scope, revocation, revocation_push, key_rotation, session_token, transaction_receipt, and witness_entry. 13 new exported functions added to the C API (ratify_*_sign_bytes_hex, ratify_verify_streamed_turn, ratify_transaction_receipt_verify_full). Pre-built libraries for common targets now published as GitHub Release assets — no Rust toolchain required to use the C SDK.

What was new in v1.0.0-alpha.9

SDK README overhaul — consistent structure and cross-language framing across all five SDKs. npm Trusted Publisher (OIDC) configured; @identities-ai/ratify-protocol now available directly from npm.

What was new in v1.0.0-alpha.8

C/C++ SDK — libratify_c.a (static) and libratify_c.so (shared) with a cbindgen-generated ratify.h header (includes C++ extern "C" guards). Supports embedded RTOS targets (FreeRTOS, Zephyr) via custom entropy.

Provider hooks (SPEC §17) — the verifier’s deterministic core is bracketed by pluggable hooks:

RevocationProvider / PolicyProvider / AuditProvider (§17.1–§17.3)
VerificationReceipt (§17.5) — verifier-signed, hash-chained audit attestation
PolicyVerdict (§17.6) — HMAC-bound cached policy decision
ConstraintEvaluator registry (§17.7) — pluggable extension constraint evaluators
AnchorResolver (§17.8) — identity-bound receipt anchoring
IsRevoked closure deprecated (§17.1 RevocationProvider is the replacement; removal scheduled for v1.0.0-beta.1)

See Provider architecture for the full picture.

Verifying you’ve installed the real thing

Each registry exposes the source of every published version. To prove the package you installed matches the repo:

# Python — PyPI lets you download the wheel directly
pip download ratify-protocol==1.0.0a13 --no-deps -d /tmp
# Compare the wheel's sha256 against the GitHub Release's sha256

# Rust — crates.io publishes via the same git tag
cargo install --version 1.0.0-alpha.13 --git https://github.com/identities-ai/ratify-protocol
# Then run cargo test in the install dir → all 63 fixtures pass

# Go — the Go module proxy serves directly from the GitHub tag
GOPROXY=https://proxy.golang.org go get github.com/identities-ai/[email protected]
# pkg.go.dev shows the source view linked back to the GitHub repo

# C/C++ — build from source or download pre-built libraries from GitHub Releases
git clone https://github.com/identities-ai/ratify-protocol
cd ratify-protocol/sdks/c
cargo build --release
# → target/release/libratify_c.a + libratify_c.so + include/ratify.h

The conformance fixtures are the practical interop check: any SDK passing all 63 produces the same canonical bytes as every other SDK at that version.

Publishing process

All five SDKs are published from a single CI pipeline triggered by a v* tag:

   git tag v1.0.0-alpha.13
   git push origin v1.0.0-alpha.13
              │
              ▼
   ┌─────────────────────────────────────────────┐
   │  .github/workflows/release.yml fires        │
   │                                             │
   │  1. gate-tests:                             │
   │     - Go tests + race detector              │
   │     - Test vectors regenerate byte-ident.   │
   │     - Release-sync (versions aligned)       │
   │     - TS conformance (63 fixtures)          │
   │     - Python conformance (63 fixtures)      │
   │     - Rust conformance (63 fixtures)        │
   │     - C conformance (63 fixtures)           │
   │     - Tag ↔ SDK version coherence           │
   │                                             │
   │  2. If all pass:                            │
   │     - publish-pypi (Trusted Publisher OIDC) │
   │     - publish-crates (token)                │
   │     - publish-npm (token, when enabled)     │
   │     - publish-go (pkg.go.dev auto-warm)     │
   │     - github-release (notes + testvectors   │
   │         + pre-built C libraries)            │
   └─────────────────────────────────────────────┘

Any conformance failure blocks the entire release. There is no “publish Python but skip the broken Rust” path — versions stay aligned by design.

See the protocol repo’s docs/RELEASES.md for the full release process and recovery procedures.

Pre-release versions

During the alpha series, fixture bytes may change between versions. Each alpha release documents the diff in the GitHub Release notes. Consumers pinning to alpha.6 and alpha.7 should expect a small migration.

After 1.0.0 stable ships, fixture bytes are frozen for the entire v1 lifetime. Minor and patch releases add new optional fields and new scopes without changing existing byte representations.

Where to next

Per-language SDK quickstarts: Go · TypeScript · Python · Rust · C/C++
Versioning — full semver scheme + the alpha → stable ladder
Conformance suite — what the 63 fixtures check and how to add a new SDK