Trust Center

Verify Everything Yourself

Every signed record is independently verifiable. No phone-home, no proprietary tooling, no Originary dependency. Here is exactly how the system works and what you can audit.

Verification Model

Every interaction record is a signed JSON Web Signature (JWS). When a record is issued, the issuer signs the claims payload with their private key. Any verifier, your code, a third-party auditor, or an offline script, can verify the signature using the issuer's published public key.

Verification never calls home. There is no Originary API in the verification path. The verifier fetches the public key from the issuer's standard JWKS endpoint once, then validates signatures locally. If the issuer is offline, cached keys still work. The signed record carries all the evidence needed to confirm what happened, when, and who attested to it.

Records are self-contained. Verification is local. No network dependency on Originary or any third party at verification time.

Cryptography and Key Management

All signatures use Ed25519 (RFC 8032), a modern elliptic-curve algorithm with no known practical attacks and deterministic signing (no nonce reuse risk). Keys are compact (32-byte public keys) and verification is fast.

You bring your own keys. Generate them locally, store them in your KMS (AWS KMS, GCP Cloud KMS, Azure Key Vault, HashiCorp Vault), or use hardware security modules. Originary never holds or accesses your private signing keys. Public keys are published at standard JWKS endpoints (/.well-known/jwks.json) so any verifier can resolve them without proprietary tooling.

Ed25519 only. Bring-your-own keys. Originary never touches your private key material.

Portability and Offline Verification

Signed records are standard JWS tokens. They are not stored in a proprietary database or locked to an Originary account. You can export them, archive them, move them between systems, or store them in your own infrastructure. Any system that understands JWS and Ed25519 can verify them.

Offline verification works by design. Once you have the issuer's public key (from their JWKS endpoint or cached locally), you can verify any record without network access. There is no license server, no token refresh, and no API call required to confirm a signature.

The PEAC protocol is designed for multiple independent implementations. Your records are not tied to Originary's software. Any conformant implementation can issue, verify, and process the same records.

Standard JWS format. Verify offline with cached keys. No vendor lock-in. Records are yours.

Data Handling Boundaries

Originary's tooling operates locally by default. The signing libraries, verification functions, and protocol SDK run in your environment. They do not send interaction data, record contents, or business payloads to Originary servers.

Stays in your environment

•Private signing keys
•Interaction payloads and business data
•Record contents and claims
•Verification results and decisions

Published by you (public endpoints)

•Public keys (JWKS endpoint)
•Issuer configuration (peac-issuer.json)
•Policy metadata (peac.txt)
•Signed records you choose to share

If you use Originary's optional managed services (hosted verification, dashboards), those services process only the records you explicitly send to them. Managed service data handling is covered in our Privacy Policy.

Responsible Disclosure

If you discover a security vulnerability in the PEAC protocol, any Originary product, or this website, please report it to security@originary.xyz. We acknowledge reports within 5 business days and coordinate fixes before public disclosure.

Our machine-readable security policy is published at /.well-known/security.txt per RFC 9116. The PEAC protocol repository accepts security reports through GitHub Security Advisories.

Report vulnerabilities to security@originary.xyz. We follow responsible disclosure practices with coordinated timelines.

Legal Identity and Stewardship

Originary is a product of Poem, Inc., a Delaware corporation. We are the current steward of the PEAC protocol, not its gatekeeper. The protocol specification, reference implementation, conformance suite, and all core tooling are published under the Apache-2.0 license.

Stewardship means we maintain the specification, publish test vectors, and ensure interoperability. It does not mean we control who can implement, extend, or build on the protocol. Anyone can build a conformant implementation without permission, payment, or partnership with Originary.

The protocol is designed to reach 1.0 with multiple independent implementations. Our goal is a standard that outlasts any single company, including ours.

Poem, Inc., Delaware. PEAC is open source (Apache-2.0). Stewardship, not gatekeeping.