QENEX Lab
Cryptographic provenance for UK research outputs. Researchers authenticate via their institutional identity (UK Access Management Federation), submit a research artifact, and receive an Ed25519-signed receipt that is independently verifiable against three external rails: a qualified RFC 3161 timestamp from the Belgian BOSA TSA, an OpenTimestamps Bitcoin proof, and a private Sigstore Rekor transparency-log entry.
1. System identity (for UKAMF reviewers and procurement)
| Property | Value |
|---|---|
| SAML SP entityID | https://lab.qenex.ai/sp |
| Assertion Consumer Service (ACS) | https://auth.qenex.ai/realms/qenex/broker/ukamf/endpoint |
| NameID format | urn:oasis:names:tc:SAML:2.0:nameid-format:persistent |
| SAML binding | HTTP-POST |
| SP signing certificate | ECDSA P-256, 2-year validity (2026-05-19 → 2028-05-18) |
| SP signing cert SHA-256 | F9:BD:1F:69:9B:A3:59:06:3F:68:FB:FC:A9:74:DA:E9:9D:56:65:6F:6F:AF:52:67:85:7C:BC:10:11:2E:EF:4F |
| UKAMF membership | Application submitted to Jisc via the federation member sign-up form 2026-05-19; metadata XML and SP cert published. Review timeline ~2 weeks. Until approval, the IdP broker accepts the UKAMF test-federation hub for integration testing. |
| Attribute release expected from member IdPs | eduPersonScopedAffiliation (required), mail (required), eduPersonPrincipalName, cn, eduPersonOrcid (all optional). Minimal release supported; richer release improves receipt identity binding. |
2. What a receipt asserts
Every research output anchored through QENEX Lab produces a JSON receipt containing the artifact hash, the operator Ed25519 signature, a hash chain link to the previous receipt, and three external timestamp / transparency proofs.
| Field | Meaning | What it proves without trusting QENEX |
|---|---|---|
sha256 | SHA-256 of the canonical research-output bytes | The artifact is binary-identical to what the researcher submitted (computable by anyone with a copy). |
ed25519_signature_b64 | Ed25519 signature by the QENEX operator key over the canonical receipt JSON | The receipt was issued by the holder of the operator private key. Pubkey is published; fingerprint below. |
previous_entry_sha256 | SHA-256 of the prior receipt under the same canonical form | The chain is tamper-evident; altering any historical receipt breaks the next link. |
rfc3161_tsr_sha256 | SHA-256 of an RFC 3161 TimeStampResp issued by the Belgian BOSA TSA | The receipt SHA-256 existed at or before the TSR's gen_time, attested by an EU Trust-Listed qualified TSP under eIDAS Article 41(2). |
ots_proof_sha256 | SHA-256 of an OpenTimestamps proof anchored to the Bitcoin chain | Permissionless decentralised existence proof, verifiable offline against a Bitcoin block header. |
rekor_url | URL of the corresponding entry in rekor.qenex.ai (private Sigstore transparency log) | Transparency-log inclusion; supplements the external rails with a tamper-evident operator log. |
identities (schema v1.1) | Array of researcher identities released by the UKAMF IdP (EPPN, ORCID, affiliation, institution) | The submitter authenticated to a UKAMF-member institution at the moment of anchoring; the identity is bound to the receipt by the same Ed25519 signature. |
3. Researcher workflow (for first-paid-pilot PIs)
- Authenticate via your institutional identity provider through the UK Access Management Federation. After UKAMF approval, this is a one-click flow from your institution's IdP discovery page.
- POST the artifact metadata to
https://lab.qenex.ai/api/v1/lab/discoverieswith a Bearer token from thelab-researcherOIDC scope. The endpoint accepts a discovery_id and an arbitrary payload; the payload is SHA-256-hashed at ingest and the hash (not the payload) is what gets anchored. - Receive an anchor_id in under 5 ms. The receipt is written to the deploy-log immediately; the three external rails (TSR + OTS + Rekor) backfill asynchronously within 15 minutes via a host-side timer.
- Retrieve the receipt via
GET https://lab.qenex.ai/api/v1/lab/receipt/{anchor_id}. The receipt is world-readable; pre-publication artifacts only release the hash, not the content. Anyone with the artifact can independently verify the receipt against the rails. - Cite the receipt alongside your publication. Recommended citation format includes the anchor_id, the receipt SHA-256, and the BOSA
gen_timefrom the TSR. Citation grammar is described at /legal/evidence/.
4. Independent verification
Every claim on this page is reproducible by a third party without contacting QENEX. The verification chain has two layers.
Layer 1 — operator infrastructure discipline
Every deploy of qenex.ai itself produces an Ed25519-signed hash-chained entry in /.well-known/deploy-log.json. The 60-line Python verifier at /docs/deploy-verification/ independently verifies every signature + chain link + RFC 3161 TSR + OpenTimestamps proof. Any byte that ships to production is auditable; any tamper after-the-fact breaks the chain.
Layer 2 — research-output receipt verifier (Apache 2.0)
The qenex-verifier reference implementation is open source under Apache 2.0. It accepts a receipt and an operator pubkey, and returns OK / INVALID for each rail independently.
- GitHub: github.com/qenex-ai/qenex-verifier
- Zenodo (v2 open verifier subset, Apache 2.0): 10.5281/zenodo.20083483
- Zenodo (v1 full sovereign platform, restricted access): 10.5281/zenodo.19157750
5. Open posture
| Legal entity | QENEX LTD — UK Companies House #16523814 |
| Registered office | 20 Wenlock Road, London, N1 7GU, United Kingdom |
| Operator (Director, single signatory) | Abdulrahman Sameer R Almutairi — ORCID 0009-0004-4797-2226 |
| Hosting | OVH UK bare-metal, London (Erith). No hyperscaler in the production data path. |
| Authoritative DNS | Self-hosted CoreDNS at ns1.qenex.ai. |
| Trust posture | /trust/ — live signed scorecard. |
| Business continuity | /trust/business-continuity/ — honest key-person risk disclosure, deputy onboarding scheduled 2026 Q3. |
| Contact | ceo@qenex.ai · UKAMF technical contact: admin@qenex.ai |
| Responsible disclosure | /legal/responsible-disclosure/ |