MasterDB Public Verification API (1.0.0)

Returns the ADL certificate of a business or an AI company — a DSSE envelope signed by MasterDB's issuance key — with its status, the date that status took effect, and the statement in plain words ("Verified by MasterDB on 25 June 2026."). The certificate says who the subject is, its legal name and country, that MasterDB verified it and since when, and its status — never how it was verified. A certificate revoked for compromise says so with the effective date; a closed business says closed on, and its history stays valid. A certificate MasterDB withdrew (withdrawn, with its status_reason, e.g. approval_reversed — a reversed verification approval) no longer stands from its effective date; it is not a compromise, and seals made before it stay valid. Every earlier issuance comes with it, newest first, each with its cert_id: a seal names the issuance it was made under and is judged against the one in force at sealed_at, and a revocation's effective date may precede its issue. Public by design.

For a person (not part of the API). A browser sending Accept: text/html, or ?format=html, receives a human-readable page instead; this is not part of the API, and the response below is always the JSON. The page is a simple one: the legal name, the country, the verification status and since when (and nothing on how the subject was verified, and no trading name, which MasterDB does not verify), the certificate id, the issuer and its validity, and how to check the certificate (a link to the JSON and to docs.masterdb.ai). The page is one self-contained document: inline CSS, no script and no external request, served with a content-security-policy that allows nothing else. Every other caller — no Accept, */*, application/json, or ?format=json — gets the JSON below, byte for byte as it was before the page existed. The response varies by Accept. A browser that asks for the page of an unknown certificate gets a short HTML page with the same 404.

A business's public keys beside its certificate, so a seal can be verified offline from public data alone: every sealing passkey and integration key its register has held, current and past — an old seal is judged against the key as it was at sealed_at — each with its key_id (the RFC 7638 thumbprint of the key), purpose (sealing: a person's passkey; integration: a business system's key), kind, the public key as a JWK (a passkey also as registered, COSE) and the instants that bound it. Nothing names a person. signed is a DSSE envelope (business-keys.v1) by MasterDB's statement key over {v: 1, uuid, cert_id, issued_at, keys}; it is the only part a verifier trusts (the verifier libraries' verifyPublishedKeys / verify_published_keys, and publishedKeys / published_keys on the seal check). An AI company's uuid answers 404, as an unknown one does.

MasterDB's signed word on who holds the private half of each of a business's keys, beside its certificate: hosted — the key MasterDB issued to the verified business and holds for it (standard publishing: a seal by it proves MasterDB signed on a confirmed request of a person with a grant, not that a person of the business signed) — or self, a key the business holds (a person's passkey, an integration key). Each statement is a DSSE envelope (key-custody.v1) signed, like the certificate, by both halves of MasterDB's issuance key over {v: 1, business_uuid, key_id, custody, issued_at, effective_from}; it is the only part a verifier trusts (the verifier libraries' verifyKeyCustodyStatements / verify_key_custody_statements, and keyCustody / key_custody on the seal check, which then names the custody of the seal's key at sealed_at). Every issuance is listed, newest first, each served byte for byte as issued: a statement is re-issued, never edited, when a key's custody changes, and the one in force at an instant is the latest effective_from at or before it. A key with no statement is not listed, and a verifier reports it unstated. A business with none yet answers an empty list; an AI company's uuid answers 404, as an unknown one does. Custody is a statement of its own because certificate.v1 admits no new member; certificate v2 carries it (verifier 1.1).

Checks a record you hold against its seal: the seal's signature against the business's key register as it stood at sealed_at, the hash over the exact bytes (or, for a pushed record, its inclusion proof in the sealed batch), the certificate in force at sealed_at, the AI policy version in force at sealed_at, and the scope — the key's mandate, or with the record's sidecar the person's grant at acceptance. Send an index row as well and it is checked too: its projection signature, that it came from these bytes, and — with the sidecar — a re-run of the published projection compared byte for byte. Send the business's sealed AI policy record (a fetch's ai_policy.record, its exact bytes, and ai_policy.seal) with the ai_policy_bits a search row carried, and the bits are checked against the sealed named booleans: the answer's ai_policy_bits. The answer is a statement signed by MasterDB's statement key; a check that fails is a 200 with valid: false and the reason, the same reason codes the open-source verifiers use. You must send the record itself; a bare id is never accepted, so nobody can use this to learn which records exist, and nothing here says whether a record is served. The log inclusion is the seal's own leaf in the transparency log — a seal leaf over the SHA-256 of the canonical seal object, as publish appends it — proven against a signed checkpoint; leaves are sequenced hourly, so a fresh seal is not_in_log for up to an hour. The seal key's own key_added leaf is checked too (checks.key_event): recomputed from the business's register and proven from the log, ok with key_event saying where it is, or missing with a line in warnings — the seal stands, unless the request says key_events: require, which refuses it (key_event_missing).

Or send an ad pool item alone, exactly as POST /v1/ads/pool served it (ad_item): its sealed bytes, the seal inside its signed row and the row are checked as above, the answer's ad says whether every text and link the item would show is the sealed one, and ai_policy_bits checks the advertiser's AI policy the item carries.

Where a source line's verify URL lands (the specification is ): the one line of provenance an AI cites — record, origin, cert, served, verify. It answers whether the business published a record with this id and these exact bytes, whether that version was the one served at served_at, whether the line's certificate is the one the seal named, and the business's certificate today; for a Business & Brand Identity file served now, its authorised-endpoints section as MasterDB stands behind it today and when control of each domain was last confirmed. HTML for a person, JSON for a machine; the JSON carries the answer signed by the statement key as its own payload type, application/vnd.masterdb.verify-page.v1+json (never verify-statement, which is POST /v1/verify's answer alone). An unknown id and a hash that does not match answer the same 404, so the page is no oracle for which records exist. The full cryptographic check is POST /v1/verify with the record's bytes and its seal.

MasterDB's own public keys — root, issuance, projection, every region's receipt key, sidecar, statement and the log checkpoint key — past and present, each with its validity window and any compromise date, as a JWK Set that is itself a signed document, so an edited file cannot add a key. The signed payload {v, issued_at, keys, certificates} carries every key's certificate: roots certify roots (cross-certified succession) and issuance keys, issuance keys certify the working keys, so the whole chain to the pinned trust anchors travels in one document; long-lived links carry both signature slots, P-256 and ML-DSA-65. A verifier trusts only the signed payload — keys beside it is a convenience copy — and can check a receipt from any date against it.

The live retrieval public keys of the verified AI companies that chose to be listed (the AI Portal's setKeyDirectoryListing), with each company's name and certificate, so a business's site or firewall can recognise their fetches. A company is listed only while its certificate is active; a key until its revocation takes effect (a key in its rotation overlap shows when it stops); source: directory_import marks a key imported from the company's own signature directory. The body is signed by the statement key as its own payload type, application/vnd.masterdb.key-directory.v1+json.

The published, versioned, hash-pinned specification of how a record of one type becomes its index row: the field map, the canonical form and the row rule, the machine-readable definition whose RFC 8785 hash every row of that version carries as adl_proj, and the fields its row signature leaves out. Anyone can re-run it and compare byte for byte with a row they were served. The path is the one the pinned specification names (platform/projections/v1.json).

The key to ai_policy_bits, which every search row carries: for each blocked context its code (bc1–bc10), number, name, plain-English meaning, bit of the blocked mask and the ai_policy_schema it appeared in — and, beside them, every bit of the use and action masks by name. A code is never reused or renamed; a retired context keeps its number. The same key is in the developer documentation and in @masterdb/shared and the verifier libraries; this read is for a system that decodes bits without them. Public, unauthenticated, cacheable for a day.

What a verifier is written from: every envelope payload type MasterDB makes or accepts, and every hash-pinned document with its version, URL and hash — each projection type version (the hash every row of it carries as adl_proj, served at /v1/projections/{type}/{version}) and each vocabulary version. The index also lists the envelope formats' prose specifications, test vectors and the corpus of deliberately broken records; test_vectors_url is absent where they are not published.

One of the platform's controlled vocabularies — the product taxonomy, countries, currencies, time zones, languages — as a versioned document owned by MasterDB, the one source the publish service validates against and the portals and SDKs read: platform/vocabularies/{name}/v{N}.json (time_zones is the timezones file). The latest version unless you ask for another; conditional requests with the ETag (the RFC 8785 hash of the version).

The transparency log's latest signed checkpoint in the C2SP signed-note format — origin masterdb.ai/log/v1, tree size and root hash, signed by the masterdb-log key. Compare checkpoints over time and MasterDB cannot edit or truncate the log without it showing. A checkpoint is served only once its signature verifies under the log's key (the log_checkpoint key of /.well-known/keys); before the first one, 404.

The inclusion proof of a leaf in the log. For a receipt the proof has two levels: the receipt's path inside its region's one-minute batch, served from the stored leaf list, then that batch root's inclusion in the log. Leaves are typed: seal, receipt batch, certificate, key event, checkpoint.

The RFC 9162 consistency proof that the log of first leaves is a prefix of the log of second leaves (default: the latest checkpoint's size, whose signed note is then included). Anyone holding two checkpoints they fetched at different times can check, with the proof and the published log_checkpoint key, that MasterDB neither edited nor truncated the log between them. Fetch checkpoints at GET /v1/log/checkpoint; the verifier libraries check the proof (verifyLogConsistency / verify_log_consistency take the two notes and proof). 404 unless 1 ≤ first ≤ second ≤ the latest size; 400 for a size that is not a positive integer.