How it works

Create. Carry. Verify.

A BioSeal is a small, self-contained proof of trust. Here is what happens across its lifecycle — and what is actually inside the code.

The lifecycle of a seal
01
Create

Sign the data at the source

An authorized issuer assembles the use-case data according to the applicable manifest, optionally captures and encodes a biometric (a face portrait or fingerprint template), and signs the resulting payload with its private key using ECDSA. BioSeal renders the signed payload as a QR Code or Data Matrix. This happens through the hosted API or the embeddable SDK.

REST APISDKECDSA signing
02
Carry

Attach it to the world

The 2D code is printed on a card, certificate or product tag, embedded in a digital document such as a PDF, image or wallet pass, or written to an RFID/NFC tag. The seal is now self-contained — it carries its own proof and travels with the item, online or off.

PrintPDF / walletNFC / RFID
03
Verify

Prove it — anywhere

A reader (SDK, CLI or API) decodes the symbology, resolves the manifest reference, and walks the trust chain — from the scheme's Scheme List to the Trust Service List to locate the accredited CA and validate the signing certificate, including revocation. It then recomputes the hash and checks the ECDSA signature. For biometric seals, it decodes the embedded template and matches it against the person presenting the document. Every step is runnable locally once the trust material is cached.

DecodeChain of trustBiometric match
Inside the code

The anatomy of a BioSeal

A seal has three logical parts. Certificate and manifest are referenced, not embedded, to keep the code compact.

Payload

The compact use-case fields, encoded with MessagePack, optionally including a biometric template packaged per CBEFF.

Manifest reference

A compact pointer in the header to the external manifest that defines the use case's schema, constraints and policies.

ECDSA signature

A signature computed over the header and payload with the issuer's private key. Any change invalidates it.

The chain of trust

How a verifier decides to trust a seal

Verification is strict and sequential — any failed step invalidates the whole seal. A trusted verifier must never present data from a failed seal as valid.

  1. 1

    Scheme List (LoTL)

    The scheme operator signs and publishes a Scheme List as the trust anchor the verifier chains to.

  2. 2

    Trust Service Lists (TSLs)

    TSLs enumerate the accredited Certificate Authorities and their valid signing certificates.

  3. 3

    Certificate validation

    The signing certificate is located and validated, including revocation via CRL, OCSP or a VDS Revocation List.

  4. 4

    Signature & biometric

    The signature is verified; for biometric seals, the embedded template is matched against the holder.

Seal trust into everything you issue

Talk to our team about issuing biometric, tamper-evident Visible Digital Seals — verifiable anywhere, even offline.

Contact our team Try the live demo