Release identity and reproducible test evidence
Inspector v0.1.2 uses the vendored @secoya/pq-sdk 0.4.0-rc.6 verifier. Requires Node.js 24.7 or later for the supported preview experience, including native ML-DSA-65 verification. Package metadata still declares Node >=22; that lower declaration is not the supported hybrid-preview requirement.
Locally reproduced: 20 tests passed, 0 failed on Node.js 24.18.0. Coverage includes real Ed25519 and ML-DSA-65 verification, invalid signatures, altered payloads, missing trust, strict parsing, replay and predecessor presentation, and input-race regressions.
Node.js 24.19.0 reproduction is reported in the supplied copy blueprint. Its execution log was not supplied for this review, so it is not represented here as a locally reproduced result.
The offline test disables fetch and checks local assets; it does not establish OS-level network isolation. Reports are printable HTML with browser Save as PDF. The Inspector does not issue records, authenticate imported identities, export an authenticated evidence package or integrate historical-continuity and external timestamp receipts.
npm.cmd test npm.cmd start
Open http://127.0.0.1:4173 after starting the downloaded local application. Request the preview package or inspect a synthetic sample report.
One product. Separately versioned evidence format and implementations.
Secoya One is the product boundary. The Trust Record format remains the portable authority, while the TypeScript, Python and Rust implementations are versioned and tested separately.
Product, format and implementations are distinct.
A verifier binds to the record format and applicable profile. Secoya One packages the operational boundary; no individual implementation becomes the protocol authority.
- Name
- Secoya One
- Company
- Secoya Systems Ltd
- Role
- Evidence engine, verifier, integration interfaces and deployment packaging
- Status
- Developer preview
- Authority
- Secoya Trust Record
/3RC1 · ratified - Record
secoya-trust-record/3- Canonical
- RFC 8785
- Policies
pq-only·hybrid-required·classical- Result
secoya-verification-result/1- Profile
secoya-verification-profile/1
- TypeScript
- Reference implementation 0.4.0-rc.6
- Python
- Verifier 0.1.0rc2
- Rust
- Interoperability harness 0.1.0
- Status
- Developer preview
- Distribution
- Technical review material supplied directly
NIST-standardised algorithms. Customer-selected policy. Deployment-specific assurance.
The record carries the selected policy explicitly. A customer chooses the production policy according to its regulatory, interoperability and assurance requirements; the pilot validates that choice in its environment.
PQ-only
ML-DSA-65 is standardised in NIST FIPS 204. This policy requires a trusted post-quantum signature.
Hybrid-required
ML-DSA-65 and Ed25519 signatures must both verify. NIST guidance accommodates dual-signature operation when its applicable conditions are satisfied.
Classical-only
Ed25519/EdDSA is specified under NIST FIPS 186-5 and may support transitional interoperability where post-quantum processing is not yet available.
Secoya does not present its record format as FIPS certified. Any production FIPS-validation claim depends on the selected KMS or HSM, its validated cryptographic module, approved operating mode and deployment configuration.
Use the published format. Verify with a compatible implementation.
Published formats and compatible implementations sit beneath the chosen sidecar, webhook/message-route or embedded integration pattern. A verifier uses the record and independently accepted trust material rather than relying on the originating system.
Published format
The record structure, protected fields, canonical bytes, algorithm identifiers and verification semantics form the compatibility authority.
Conformance material
Language-neutral schemas, committed vectors and expected results let another implementation test the same bytes and decisions.
Independent trust
Offline verification still requires the applicable published trust material, policy artifacts and a trust anchor independently accepted by the verifier.
A verifier does not need an operational Secoya service or the originating application. It does still need authentic trust material and an independently accepted basis for trusting the authority.
Cryptographic validity, authority at the relevant time, policy acceptance, continuity and replay, rollback or omission controls are separate evaluations. A single “verified” label must not imply that every layer was established.
What the current implementation provides.
- recordsCreation, signing, verification and linked renewal for versioned Trust Records.
- signaturesML-DSA-65 and Ed25519 under customer-selected
pq-only,hybrid-requiredorclassicalpolicy. - trust checksKey status, validity windows, revocation, authority and fingerprint evaluation.
- envelopes
secoya-hybrid-v1: X25519, ML-KEM-768, HKDF-SHA-384 and AES-256-GCM protected evidence. - schemasStrict Draft 2020-12 schemas, runtime validators and versioned verification results.
- integrationSynchronous and asynchronous signing/verification with vendor-neutral registry, KMS, trusted-time and replay interfaces.
- provider limitsAlgorithm support and provider-declared RAW-message limits are enforced before remote signing calls.
No vendor-specific KMS, durable replay database, managed registry, trusted-time provider or production monitoring service ships in this release.
Secoya One uses one core across embedded, service and event-driven deployment profiles. Customer-specific connectors and controls remain deployment work. The implementation does not itself establish identity authority, production key custody, durable replay prevention, workflow enforcement or completeness.
Implementation evidence, with boundaries stated.
100 passed · 0 failed
RC6 source suite reproduced on Node.js 24.18.0, 17 September 2026, including issuance, verification, encryption envelopes, async providers, schemas, canonicalisation, adversarial cases, property tests and 2,000 deterministic malformed inputs. The Inspector has a separate 20-test suite described above.
25 tests · 538 subtests
A separate verifier reproduces verification, malformed-input, policy and trust expectations. It does not issue records or perform encrypted-envelope operations.
12/12 · three languages
TypeScript, Python and Rust reproduce the committed canonicalisation and Trust Record expectations through separate implementations.
17/17 · two internal implementations
The reference implementation and a separately authored internal clean-room verifier reproduce historical trust decisions through key, policy and trust-anchor change with Secoya and the originating application unavailable.
These are implementation, conformance and interoperability results. ML-DSA-65 and Ed25519 are NIST-standardised algorithms; that does not make the Secoya format or developer implementation FIPS validated. Production FIPS status depends on the selected validated module and operating configuration. No independent external cryptographic audit, production penetration test, legal-admissibility opinion or customer deployment assurance is claimed. The clean-room Gate 6 reproduction remains internal.
Runtime requirements are explicit.
Technical review material and reproducible test instructions are supplied directly to qualified reviewers and design partners.
Complete encryption path
Node.js 24.7 or later is required for the complete native hybrid encryption path. The full suite has been reproduced on Node.js 24.18.0.
Node.js 22 behaviour
Non-native core paths remain testable; native encryption cases report an explicit version skip rather than a misleading cryptographic error.
Evidence available for diligence.
The frozen RC1 authority and its subordinate publication aids are available in the public specification repository. The frozen protocol is public. The Inspector and implementation material are supplied directly for agreed technical evaluation.
- Public specificationFrozen Trust Record authority, ratification statement, schema and illustrative record on GitHub.
- FormatRatified Trust Record authority and profile material.
- ConformanceLanguage-neutral schemas, committed vectors and expected results.
- ImplementationsTypeScript reference implementation plus Python and Rust verification material.
- IntegrityVersioned reports and SHA-256 checksum manifests supplied with the review set.
Developer preview and review material, not production assurance or certification. Production key custody, operational integration and customer acceptance remain engagement work. Reports do not replace the underlying evidence or establish the truth of its assertions.