A signature should come with an explanation. Here is what Mark binds together, what a verifier checks and where the product stands today.
A personal Mark connects ZOREAL-verified proof of human to a specific statement or file, a stated context and evidence of when the person signed. They choose a site persona or a legal-name credential.
Liveness and biometric verification establish human presence. Hardware-bound keys, PKI certificates and signed presence attestations bind that evidence to the signer and the content they approve. The proof comes from these checks working together; a certificate alone does not establish live human presence.
A Mark does not prove that a human wrote every word, that the content contains no AI, or that a statement is true. It does not by itself establish a job title, platform account ownership or the signer’s freedom from coercion.
The extension prepares the content and context, creates a sign order and displays a QR code. Your ZOREAL ID app scans the request, shows what you are signing and asks which identity to use. Biometric approval authorizes that specific personal signature.
The hardware-bound private key stays on the phone. The browser has no standing signing credential. ZOREAL countersigns the device signature hash with a presence attestation; it cannot substitute its countersignature for the holder’s device signature.
A recent liveness capture can cover a 15-minute signing window. Each personal Mark still requires biometric approval. The evidence carries the actual presence grade, such as recent; it must not imply a new liveness capture for each post.
Planned delegated Marks are a different operation: an agent signs under a time-limited human authorization, using a distinct ::ZOREAL-DELEGATED:: marker. They must be identified as agent activity, not personal review of every post.
The default credential uses a pseudonymous identifier derived for the site’s registrable domain. It stays consistent within that site; other sites receive different personas. This limits direct cross-site linking through the identifier. It does not make the person anonymous to ZOREAL, or prevent people identifying themselves through what they post.
A named badge shows the signer’s name without adding email or contact details. The badge is not the entire public record. The included legal-name certificate contains the legal name and document number, and may contain other certificate metadata. This public evidence is more revealing than the compact badge.
A legal-name Mark publishes identity permanently. The signing experience must explain the full disclosure before approval. Planned withdrawal will add a dated status; it will not erase the published name or certificate.
Application-based validation of a title, position or account association is planned. These will be additional, separately reviewed claims, not conclusions drawn from an ordinary identity certificate.
Verification depends on trusted issuer keys, validated certificates and signatures, content matching and context. A site drawing a Mark badge is not performing these checks on behalf of a reader’s trusted tool.
::ZOREAL-MARK::
The statement I stand behind.
::ZOREAL-SIGNATURE:<record-id>::Parse the markers and the 24-character Crockford Base32 record ID. The ID locates an evidence bundle; it is not the signature. Retrieve the bundle or a cached copy. If it cannot be retrieved, report “Cannot verify now”.
Validate both the classical and post-quantum certificate chains against pinned root SubjectPublicKeyInfo digests. A root supplied in a record is not trusted merely because it is included. Verify the paired-chain hashes and the holder leaves’ matching public keys. Reject unknown critical extensions.
Require contentCommitment key usage and id-kp-documentSigning extended key usage. An authentication certificate is insufficient. Validate both embedded Token Status List JWTs and the holder’s status at the trusted signing time; a live status lookup does not replace that historical check.
Verify both signatures in the General JWS: ES256 and ML-DSA-65, with the presence-signing certificate purpose and trusted chains. Require the Mark audience, the same order nonce and device key, a native_attested channel, and the stated recent or live presence grade.
Re-create the canonical payload hash and verify the ECDSA P-256/SHA-256 signature over H(payload) || UTF-8(order) || UTF-8(aud). The device signature is raw r || s, 64 bytes, encoded as base64url. Check payload.cert against the SHA-256 digest of the exact classical leaf certificate DER.
Check that zoreal.countersig_over in the signed presence attestation equals the SHA-256 of the device signature bytes. The attestation’s key thumbprint, subject certificate digest and order must bind to the same request and signer.
Validate the RFC 3161 timestamp and its TSA chain. Recompute the record’s Merkle inclusion proof and compare SHA-256(root_bytes) with the token’s message imprint. The token’s genTime is authoritative. Check presence expiry and certificate status against that time.
Compute the visible content hash using the specified canonicalization and match both payload.visible.hash and payload.data.hash. Compare the normalized page or channel URL, or the specified email context. An absent binding is explicitly labeled. A signature alone does not establish that the surrounding page is the signed content.
The payload is serialized with RFC 8785 JSON Canonicalization Scheme (JCS), then SHA-256 hashed. payload.cert is the base64url SHA-256 digest of the classical leaf certificate’s DER bytes. The audience is https://zoreal.com/mark.
The immutable record core excludes the fields timestamp, withdrawn, co_signers, reports and log. The timestamp batch uses these hashes:
core_hash = SHA-256(JCS(core))
leaf = SHA-256(0x00 || UTF-8(id) || core_hash)
node = SHA-256(0x01 || left || right)
TSA imprint = SHA-256(root_bytes)Inclusion verification uses the leaf index, tree size and audit path. It is a timestamp batch proof; the planned public transparency log is a separate capability.
A certificate chain connects the signing key to a root the verifier already trusts. ZOREAL uses two parallel chains: one rooted in classical ECDSA, the other in post-quantum ML-DSA. Each certificate carries one signature. The paired-chain extension links the corresponding certificates by their SHA-256 digests.
Classical
ZOREAL Root CA 1 · ECDSA P-384
→ Human Identity CA
→ Holder certificate · device P-256 public key
Post-quantum
ZOREAL Post-Quantum Root CA 1 · ML-DSA-87
→ Post-Quantum Human Identity CA
→ Paired holder certificate · same device public keyBoth holder certificates contain the same phone public key. Verification follows each chain to its pinned root, checks every certificate signature and validity period, enforces CA constraints and signing purpose, and checks the pairing. A missing or invalid post-quantum chain cannot fall back to a classical-only success.
Presence has its own purpose-specific certificate paths under these roots. The presence service signs the same claims with ES256 and ML-DSA-65. Those claims include the device-key thumbprint, order, audience and hash of the phone’s exact signature. Both presence signatures must verify.
ML-DSA is the post-quantum signature algorithm standardized in NIST FIPS 204. It adds a post-quantum verification path at the certificate-issuer and presence-attestation layers, alongside the classical checks.
The phone’s hardware-bound P-256 signing key remains classical, as does the current timestamping chain. The ML-DSA presence signature binds to the phone’s signature; it does not turn that phone key into a post-quantum key. This is a combined verification design, with the algorithms and their roles available for inspection.
These trust anchors are compiled into the extension and never fetched from the page or record service. Compare them with the values on the ZOREAL ID app’s About screen and the verifier’s published trust-anchor source.
Each fingerprint below is Base64(SHA-256(DER(SubjectPublicKeyInfo))): a digest of the root’s public-key structure, not of the whole certificate. The timestamping anchor validates the independent time evidence; the ZOREAL roots validate ZOREAL’s certificate chains.
Q6N1FDet9QG5T9UztVKbsXvQylB3eNiN5UIKxDp1p3k=rxr4sieLvSvCB/jCnoA56LaZQdqNuC7nq01uHuDnm/0=Wd8xe/qfTwq3ylFNd3IpaqLHZbh2ZNCLluVzmeNkcpw=The short ID after ::ZOREAL-SIGNATURE: points to a public evidence bundle. The production address follows this format:
https://zoreal.com/mark/XCTZ18HAB05B5RJB938NB20JThe record address locates the proof. payload.data.url identifies the page the person signed. They serve different purposes: opening a record does not establish that content on some other page matches it.
id · kindpayloadpresencerecent presence grade and native_attested channel, bound to the same order and device signature.signature.devicesignature.certificate_chainsignature.paired_chainsignature.revocationassurancetimestamp2026-09-09T02:49:03Z as its timestamp time. A batch containing one record has an empty audit path; the leaf is already the root. The token’s signature, chain and imprint must still verify.created_at · withdrawnFields such as timestamp.status: "confirmed" describe the record; they are not a substitute for verification. A reader’s tool checks the cryptographic evidence, the actual visible content and its context before showing a result.
Clients request the production record without reader credentials. Availability is reported separately from whether the evidence passes verification.
curl --header 'Accept: application/json' \
'https://zoreal.com/mark/XCTZ18HAB05B5RJB938NB20J'The record ID is a lookup key, not a secret. Moving a signed record between environments does not change its original content or page binding.
Signers and verifiers apply the same normalization before hashing, allowing specified punctuation and spacing changes made by publishing tools:
Letters, case, digits and word order are not folded. Formatting and punctuation differences covered by these rules can remain valid; this is a canonical text comparison, not a byte-for-byte comparison of the original text box.
Normalize the scheme and hostname to lowercase, remove default ports and fragments, remove tracking query parameters (utm_*, fbclid, gclid, si, ref, feature), sort remaining parameters, and remove a trailing slash except at the root. Compare the resulting address with the signed context.
Copying identical signed text within its bound page does not prove which platform account posted it. Moving it to another page produces a different-context result. If a platform removes the markers, a verifier cannot find that Mark.
The specified file check hashes the exact bytes. Re-encoding an image or clip can break the match even when it looks or sounds similar. A perceptual match, screenshot or listening result must not be presented as a cryptographic content match. Capture-based discovery and embedded stream signatures remain planned work.
Mark is available now. The examples on the product page are illustrative; use the browser extension or verifier to check actual Marks.
The verifier library, Chrome extension, sign orders, signed presence evidence, record service and minute timestamping work together to sign content and check its proof. The public record endpoint exists; the reader-facing record page is still planned.
Real Marks have been signed from the ZOREAL ID app through the Chrome extension and checked with the verifier, including posts created in embedded editors. Use your phone to review the content, choose how to identify yourself and approve each personal Mark.
Safari, the dedicated Mark app, capture and listening experiences, embedded media signatures, extended role validation, withdrawal, co-signing, reports, delegated and organization experiences, and the public transparency log.
Our transparency commitment is to explain what is signed, how results are reached, what is disclosed and which limitations remain. This guide describes the current protocol and implementation status. The open-source verifier makes the checks themselves available for review.
Mark is designed for verification from an evidence bundle using known trust anchors, without a reader account. The planned append-only transparency log and signed daily archives are not yet operating. Those are additional measures for public scrutiny and evidence availability, not a prerequisite for describing the mechanism honestly today.
The Mark verifier is open source under the MIT license. You are welcome to inspect how it validates certificate chains, binds human presence to a signature, checks timestamps and compares content. The Chrome extension uses this verifier in its background worker, separately from the page displaying the post.
The repository documents how to build and test the verifier, including examples that must fail verification. Open implementation and published trust anchors make the result reproducible and the trust decisions visible.
Proof of human spans document authentication, biometric presence, protected keys, PKI and content verification. These are the standards behind those layers, with the role of each made explicit. A protocol reference is not a claim that the entire product is certified under that standard.
The document establishes an identity source. Face matching and liveness connect that document to the person enrolling in ZOREAL ID.
Document formats, machine-readable zones and check digits. Parts 3–6 cover the document formats used to prepare chip access.
The contactless transport beneath the phone’s NFC communication with a compatible document.
APDU commands, file selection and data exchange with the document’s chip.
The chip’s data groups: DG1 for document details, DG2 for the portrait, and EF.SOD for the signed data-group hashes.
BAC and PACE establish access and secure messaging. Active Authentication and Chip Authentication provide additional chip evidence where the document supports them.
Passive Authentication checks the signed data against a Document Signer certificate and a trusted Country Signing CA. This government-document chain is separate from ZOREAL’s Mark certificate chains.
The PACE and Chip Authentication protocols used by supported identity documents. Available checks depend on the document; this does not imply access to restricted fingerprint or iris data.
The facial-image interchange format underlying document portraits, including the legacy formats encountered in DG2.
Testing and reporting terminology for evaluating biometric presentation attacks. ZOREAL’s liveness models, capture challenges and decision thresholds are implementation-specific; citing this standard is not a certification claim.
Certificates bind a public key to an issuer’s verified claims. A verifier also checks who issued them, which operations they permit and whether their status allowed the signature.
Certificate structure, validity, Basic Constraints, key usage, critical extensions and certification-path validation. Mark also carries signed Token Status Lists for historical holder status.
The notation used to define certificate and cryptographic message structures.
The exact binary representation used when hashing certificates and SubjectPublicKeyInfo. Hashing a PEM text file would produce a different value.
How elliptic-curve keys and their curve identifiers are represented in X.509 SubjectPublicKeyInfo.
Algorithm identifiers for the classical certificate signatures.
The post-quantum key and signature encodings used by the parallel ML-DSA certificate chain.
The id-kp-documentSigning purpose required for a holder’s Mark signing certificate, alongside contentCommitment key usage.
A reference for identity attribute and biometric-information structures used in certificate profiles. Use of these structures does not make an ordinary Mark a qualified electronic signature.
Signed-data containers used in document security objects and timestamp tokens. The Mark record itself is JSON.
Different keys have different jobs: the phone approves the content, certificate authorities issue credentials, and the presence service binds human presence to that exact approval.
ECDSA is the classical signature algorithm used by the phone and the classical side of the PKI.
P-256 for the holder’s device key and P-384 for the classical root key.
The standardized post-quantum signature family: ML-DSA-87 for ZOREAL’s post-quantum root and ML-DSA-65 for issuing and presence-signing roles.
SHA-256 and SHA-384 provide the hashes used across content commitments, certificate signatures, fingerprints and evidence bindings.
The SHAKE functions used within ML-DSA. This does not change Mark’s SHA-256 content hash.
RSA signature verification used by the independent timestamping certificate chain and signed token.
The keyed-hash construction used to derive site-specific pseudonymous identifiers.
AES-256 encrypts the signing-order payload for the phone.
GCM adds authentication to that encrypted payload, so a changed ciphertext is rejected.
Signed presence evidence links the device key, content approval, audience and order. Both the classical and post-quantum signatures must pass.
General JWS carries two signatures over the same presence claims. Compact JWS is used for the embedded signed status lists.
ES256 and the raw r || s representation of an ECDSA signature.
Issuer, audience and time claims. ZOREAL’s presence grade, order and countersignature bindings extend this claim set.
Algorithm identifiers for ML-DSA, including the ML-DSA-65 JWS signature paired with ES256.
Deterministic binary encoding of the key material used to calculate the device-key thumbprint.
The COSE_Key structure used for that thumbprint. The current Mark presence envelope uses JWS, rather than a COSE-signed envelope.
The cnf.ckt binding identifies the same device public key across presence evidence and the signing certificate.
Compressed, signed certificate-status evidence carried in the record and checked at the trusted signing time. This specification is still a draft, not a published RFC.
The compression format used to decode the status-list bit string.
A reader must calculate the same bytes and hashes as the signer. Independent time evidence makes the signing-time check reproducible.
The data format for the public evidence record and signed payload.
A deterministic JSON representation before hashing the payload and immutable record core.
Binary-to-text encoding for certificates, signatures and digests. The short record ID uses Crockford Base32, a different alphabet.
The UTC date-time representation used in record fields. A correctly formatted date alone is not trusted time evidence.
NFC normalization is one step in mark-text-v1. The additional punctuation and whitespace rules are defined by ZOREAL.
The browser URL parser beneath Mark’s page-context comparison. Tracking-parameter removal and the final binding rules are ZOREAL-specific.
An independent timestamp authority signs a message imprint derived from the record’s timestamp-batch root.
The inclusion-proof algorithm used to check membership in a timestamp batch. This use does not imply the separate public transparency log is already operating.
ZOREAL-specific protocol rules: the Mark markers and record ID, mark-text-v1, page-binding normalization, paired-chain extension, certificate policies, presence grades and countersignature bindings are defined by ZOREAL. Their implementation is available in the verifier source; they should not be mistaken for separate ISO or IETF standards.
For questions about the protocol or a discrepancy in this guide, contact our team.
Explore ZOREAL Mark