Trust model
Three-state verifier output
DOMAIN_VERIFIED_SIGNATURE, DEMO_DOMAIN_VERIFIED_SIGNATURE, or
UNVERIFIED — each with explicit caveats about what is and isn't being asserted.
Vision
The Let's Encrypt moment
for credentials
Credentials should be as easy to verify as HTTPS certificates — open standards, no lock-in, and strong cryptographic proof by default.
Current state
Fragmented platforms
Credentials are trapped in closed networks and difficult to validate independently. Verification requires trusting the platform, not the proof.
Target state
Portable trust
A badge is portable JSON with explicit issuer-domain proof and machine-verifiable signatures. Verification needs no account or platform access.
Method
Open trust rails
Build free primitives anyone can deploy — not another centralized authority gate. Domain ownership is the trust anchor, not platform membership.
What's here now
Live primitives you can use today.
Security posture
Public verifier hardening
SSRF protections, request limits, trust-write rate limits, and cooldown controls make the public API resistant to abuse without requiring authentication.
Interfaces
API, CLI, MCP, llms.txt
Human and agent workflows share the same trust primitives and verification semantics — one contract, every interface.
How issuer identity works
Three principles that define what "verified" means here.
01
Canonical identity is the domain
The issuer is identified as issued by <domain>. Domain ownership is the primary trust anchor — not a platform account or issuer name.
02
Claimed names are secondary
Issuer profile names from the credential JSON are displayed as claims, not as canonical trust anchors. The domain speaks louder than the display name.
03
TLS org fields are metadata only
Certificate org/CN fields often describe a hosting provider, not the actual issuer. Domain ownership remains the trust anchor regardless of TLS metadata.
Now, next, later
Where this is going, and in what order.
Now
Domain/key trust
Public verification, trust discovery APIs, signed demo credentials, and prompt-to-badge activation for early adopters and agent workflows.
Next
Issuer onboarding UX
Guided flows for non-technical institutions: key generation, well-known hosting, and issuing a first verifiable badge without touching the CLI.
Later
Circles of trust
Vouching networks for higher-order reputation, layered on top of domain-bound signature trust without replacing it.
Build on open trust primitives
Start by verifying a badge, then issue one with your own domain and keys.