How to use the tools, and the reference detail behind each.
The tools are built to stay focused when you are validating or debugging — paste, decode, read the result. This page holds the deeper educational and reference material so the tools do not have to carry it inline. On each tool, a ? next to a control opens a short explanation and links to the matching section here. New to the underlying standards? The STIR/SHAKEN topic and the certificate hierarchy page are the place to start.
Decodes one or more SIP Identity headers or bare PASSporT JWTs, shows the header and payload, lints each against the STIR/SHAKEN specs, and — for a diverted call — validates that the diversion chain links up. Paste each Identity header on its own line; a diverted call carries several.
Carries a signed PASSporT plus parameters: info = the x5u URL of the signing certificate, alg (always ES256 for SHAKEN), and ppt = the PASSporT type extension. A single call can carry multiple Identity headers. See RFC 8224.
A JWT with typ:"passport". The protected header names the certificate (x5u by reference, or x5c embedded) and the type (ppt); the payload carries orig/dest (calling/called numbers), iat (issued-at / replay window), and type-specific claims. See RFC 8225.
Adds attest — A (full), B (partial), or C (gateway) — and origid, an opaque originator UUID for traceback. See attestation levels and SHAKEN.
ppt:"rcd")Adds an rcd claim (caller name nam, logo/JCard jcd/jcl) and often a crn (call reason) — the basis for branded calling. See rich call data and RFC 9795. Note: "delegate" is a certificate concept (RFC 9060), not a PASSporT type — it lives in the cert's TNAuthList; decode that in the certificate decoder.
ppt:"div", RFC 8946)When a call is retargeted (forwarded), the diverting party adds a second div PASSporT — it does not replace the original SHAKEN PASSporT, it extends the chain. The div claim records the number that diverted; each hop adds another header, and verifiers walk them all. The tool prints the chain and validates that it links up: each diversion's div must match the prior hop's destination, and the original caller (orig) must carry through. Try the "Diversion (2 hops)" and "Diversion (broken)" examples for a valid and a failing chain to test an implementation against.
Each PASSporT is linted against RFC 8224 / 8225 / 8588 and ATIS-1000074: it flags a wrong alg, unknown or missing ppt, a bad attest, non-E.164 numbers, a NANP number missing the leading "1", a stale iat (outside the ~60s replay window), a non-HTTPS x5u, and similar. It does not verify the signature or validate the certificate chain — decode the signing certificate in the certificate decoder and check its trust in the STI-CA validator.
Decodes a STIR/SHAKEN X.509 certificate and interprets the part that carries the authorization — the TNAuthList extension — then runs a structural policy lint. Paste a PEM, a base64 x5c value, or an x5u URL, or drag a .pem / .cer / .der file onto the page.
A PASSporT's x5u points at a certificate; a verifier fetches it, checks the signature, and — the part that matters — checks what the certificate is authorized for via the TNAuthList extension (OID 1.3.6.1.5.5.7.1.26, RFC 8226). There are two shapes:
origid in the PASSporT. See carrier identity and the glossary.The end-to-end picture — roots, the STI-PA/STI-CA hierarchy, and how this certificate model works — is on the certificate hierarchy page.
A public HTTPS x5u is fetched by a small proxy on this site — STI certificate repositories generally do not send CORS headers, so the browser cannot read them directly, and the proxy fetches the (public) certificate for you. The proxy only fetches public HTTPS targets and blocks loopback, private, and cloud-metadata addresses (an SSRF safeguard).
http://localhost, http://127.0.0.1, or ::1 — is instead fetched directly in your browser (developer mode). For that to work, your local server must send an Access-Control-Allow-Origin: * (or https://appliedbits.com) header, and you may need to approve a browser local-network permission prompt. LAN addresses (192.168.x, 10.x) are not supported. This is a testing affordance only — a real PASSporT x5u must be a public HTTPS URL, and the PASSporT decoder flags a non-HTTPS x5u as invalid.The lint checks the certificate's structure against the applicable national SHAKEN Certificate Policy — resolved from the certificate's country (C=US → US SHAKEN CP, ATIS-1000080 / CP v1.4; C=CA → Canadian CST-GA CP). It flags things like a missing or malformed TNAuthList, a subject that does not match the authorized SPC, a missing CRL distribution point, and similar policy requirements. It is structural only: verifying that the certificate chains to a valid trusted root and is not revoked is a separate step — use the STI-CA validator.
The rule set was adapted from and inspired by Martini Security's ZLint shaken lints (their zlint fork — the STIR/SHAKEN lints are not in upstream zlint), used as the baseline and then extended for CP v1.4 and multi-jurisdiction support.
The lint is jurisdiction-aware: it resolves a national profile from the certificate's country (C=) and applies that regime's Certificate Policy. A US certificate (C=US) is checked against the US SHAKEN CP; a Canadian certificate (C=CA) is checked against the CST-GA CP, so it no longer trips the country rule (e_sti_subject_c). The regimes differ mainly in two places: the country attribute, and the certificate-policy OID. The US CP pins a specific policy OID (2.16.840.1.114569.1.1.4), while the Canadian CST-GA CP requires a policy to be present but defers the exact OID to each STI-CA's CPS — so the lint accepts any OID under the CST-GA arc and flags an unexpected value only as a notice. The remaining structural rules (TNAuthList/SPC, key usage, CRL distribution, EC P-256, and so on) are shared. Adding another country — for example France, whose framework uses a single CA under the GA/PA — is a data-only change to the jurisdiction registry.
Takes a certificate or full chain (by PEM, x5c, or x5u) and checks it against the published STI-PA trusted STI-CA list and the CRL — chain-to-root and revocation. This is the step the certificate decoder does not do: that tool reads a single certificate's structure and lints it against the policy; this one confirms the certificate actually chains to a trusted STIR/SHAKEN root and is not revoked.
The tool also browses the approved STI-CAs and the trusted roots they anchor — the same public STI-PA trust list a verifier honors. The end-to-end model (STI-GA → STI-PA → STI-CA → provider / delegate certificates) is on the certificate hierarchy page.
As with the certificate decoder, a public HTTPS x5u is fetched through the site proxy — the certificate is public, and validation stays in your browser. For a local or test chain, paste it directly.
Looks up a US carrier across the Robocall Mitigation Database and Form 499 filer data, keyed by FRN, with OCN and name. It downloads a directory file and searches it entirely in your browser, so nothing you type is sent to the site — the certificate/PASSporT decoders record submissions, but this one does not. For the identifier background (OCN, RespOrgID, Filer ID, RMD), see carrier identity.