PrID · demo.prdid.com Demonstration — not production

Watch a PrID identity being verified

This page checks a demonstration identity the way a careful verifier would, live, in your browser. It fetches the identity's key from the website, then asks two independent DNS resolvers for the same key in DNSSEC-signed records, follows the chain of trust back to the root of the DNS, and checks every signature. Nothing is pre-recorded: each step queries the real internet. Choose a scenario, press Verify, and watch where each confirmation comes from.

The components

Your browserthe verifier (WebCrypto) Web serverdid.json, credentialHTTPS · Let's Encrypt Google DNSvalidating resolver Cloudflare DNSvalidating resolver Root zone "."IANA trust anchor .comVerisign prdid.comDNSSEC-signed zone _did.<host>URI + TLSA recordsdraft-carter §3 DNSSEC chain of trust → channel 1: HTTPS channel 2: DNSSEC
workingconfirmedrejected

The checks, step by step

    Who validates what: the interoperability tools

    No single tool is trusted alone. The same identity is checked by independent implementations, and each is responsible for a different protocol layer.

    Protocol layerStandardValidated byLatest result
    DNSSEC signatures on every recordRFC 4033–4035Google Public DNS and Cloudflare DNS (they return the AD "authenticated data" flag only after checking every RRSIG from the root down)AD=1 at both, every run of this page
    Chain of trust links (DS ↔ DNSKEY)RFC 4034, IANA root anchorThis page: your browser recomputes each delegation's DS digest from the child's key and compares it with the parentcomputed live below
    DID ↔ domain binding (URI + TLSA at _did)draft-carter-high-assurance-dids-with-dns-08 §3; draft-ranjbar-dane-did (3 1 1)This page; verify_dnssec.mjs (Node)PASS, all four identities (24 Sept 2026)
    DID document integrity proof, verified with the DNS-published keydraft-carter §5, §6 step 3; W3C Data Integrity eddsa-jcs-2022This page (WebCrypto); verify_dnssec.mjs; Digital Bazaar jsonld-signatures + eddsa-jcs-2022-cryptosuite (verify_diddoc_proof_db.mjs)PASS, all four; tamper rejected
    Verifiable CredentialW3C VC Data Model 2.0; eddsa-jcs-2022 and eddsa-rdfc-2022This page (jcs); Digital Bazaar @digitalbazaar/vc (verify.mjs --live, both cryptosuites)verified: true, both suites; tamper rejected

    Assurance per draft-carter §8: Controls 1–8 met (MEDIUM+, with DNSSEC signing). HIGH would need the issuer to hold its own zone-signing keys (Controls 9–10), which Cloudflare-managed DNSSEC doesn't allow. Both IETF drafts are individual submissions, so this is aligned with them, not conformance to a ratified standard. The identities here are demonstrations, not production PrIDs.