Verify a TeleVerify compliance record

Every compliance record TeleVerify generates is signed with our Ed25519 private key. Insurers, regulators, and auditors can verify a record's authenticity independently using our public key — no TeleVerify account needed.

1. What is a signed compliance record?

When TeleVerify confirms a telehealth session's licensing status, we produce a canonical JSON record (the "compliance packet") containing the provider snapshot, patient location evidence, the compliance determination, regulatory context, and a SHA-256 record hash. That packet is then signed with our Ed25519 private key. The signature, together with the published public key below, lets anyone independently confirm that:

• The packet was produced by TeleVerify (authenticity)
• The packet has not been altered after signing (integrity)
• The signature was generated with a key we still recognize (revocation status)

The private signing key never leaves our servers. Publishing the public key does not expose any customer data — it only enables verification of our signatures.

2. Our public key

To confirm the key you downloaded matches the one published, compute its SHA-256 fingerprint and compare it against the value shown alongside the key on /api/compliance/keys:

openssl dgst -sha256 -hex televerify-verification-key.pem

3. Verify a record in your browser

Paste the signed Compliance Verification Record JSON below, or upload the .json file. Verification runs against our published public key on the server; no record contents are stored.

Verify

4. How to verify a packet from the command line

You'll need three things: the canonical JSON of the packet, the base64url signature, and the public key file from above. Then:

1. Save the canonical JSON to packet.json exactly as TeleVerify produced it — no whitespace changes, no key reordering. The signature is computed over canonical JSON; any byte-level change invalidates it.
2. Save the base64url-encoded signature to signature.b64.
3. Run the openssl command below, or POST to our reference verifier endpoint (recommended for bulk verification).

Option A — openssl (single packet)

# Convert base64url to raw bytes
tr -- '-_' '+/' < signature.b64 | base64 -d > signature.bin

# Verify
openssl pkeyutl -verify -pubin -inkey televerify-verification-key.pem \
  -rawin -in packet.json -sigfile signature.bin

Exit code 0 + "Signature Verified Successfully" means the packet is authentic and unaltered.

Option B — TeleVerify reference verifier (bulk-friendly)

curl -X POST https://www.televerify.org/api/compliance/verify-packet \
  -H 'Content-Type: application/json' \
  -d '{"packet": { ... }, "signature": "..."}'

Returns { valid: true, key_id } on success or { valid: false, reason } with a stable, machine-readable reason string (unknown_key, revoked_key, invalid_signature, malformed_packet). Rate-limited at 100 requests per minute per IP.

5. What a successful verification means

• Authenticity: the packet was issued by TeleVerify, signed with a key we recognize.
• Integrity: the canonical JSON has not been modified since signing — not a single byte.
• What it does NOT prove: the verification is over the record, not the underlying clinical reality. TeleVerify attests to the inputs it received (provider snapshot, location evidence, time of check) and the determination it produced. Whether the patient was actually at the location, or whether the licensing rules were the correct ones to apply, is the auditor's downstream call.

6. FAQ

Does this prove the patient was actually in that state?

It proves TeleVerify's location-evidence inputs (GPS coordinates, patient-entered address, etc.) and the resulting state determination were what we received and acted on at the time stamped on the packet. It does not, by itself, prove the patient was physically present at that location. The packet records the evidence the patient presented; the signature locks the record so the inputs can be audited later.

What if the signature verification fails?

The most common causes are (a) the packet JSON has been re-serialized non-canonically (whitespace or key-order changes invalidate the signature), (b) the wrong public key is being used (a packet signed with a rotated key still verifies against the historical key — check /api/compliance/keys for all keys we've ever issued), or (c) the packet has been altered. Use the /api/compliance/verify-packet endpoint — its reason field distinguishes between these cases.

Can I verify in bulk?

Yes — the POST /api/compliance/verify-packet endpoint is the bulk path. Rate-limited at 100/minute per IP via standard RFC 6585 headers, so your client can self-throttle. For very large batches, contact sales@televerify.org.

How do you handle key rotation?

Each signing key has a key_id. Old keys remain published indefinitely at /api/compliance/keys with their rotation timestamp; their corresponding packets keep verifying using the historical key. The .well-known/verification-key.pem URL always returns the current active key; for historical packets, look up the key by signing_key_id on the packet itself.

What if a key is revoked?

If we ever revoke a key (compromise, deprecation), the corresponding entry on /api/compliance/keys is marked is_revoked: true with a revoked_at timestamp. The reference verifier returns { valid: false, reason: 'revoked_key' }. Packets signed before the revocation date may still be honored at your discretion; packets signed afterward should be treated as suspect.

Where can I report a verification problem?

Email support@televerify.org with the packet ID and the verification output. Include the openssl version or your reference-verifier response so we can reproduce.

Reference information — not legal advice. Always confirm current requirements with your compliance officer, state licensing board, or a telehealth attorney before relying on this for clinical or business decisions.