STIR/SHAKEN Identity Decoder

Decode a SIP Identity header
and read the attestation

Paste the Identity: header from an INVITE. Get the PASSporT claims in plain terms — attestation level and what it means, orig and dest, how old the token is, who signed it — plus the RFC 8224 and 8588 structural checks a verifier runs before it looks at the signature.

No account · nothing stored · no AI call · signature not verified
What it checks

The structural checks a verifier runs first

Before any cryptography, a verification service rejects tokens that fail these. Most 438s in the field are one of them, not a bad signature.

CheckWhat a failure meansReference
alg = ES256SHAKEN PASSporTs are signed with ECDSA P-256. Anything else is rejected outright.RFC 8225 §8.1
typ / ppttyp must be passport; ppt=shaken selects the SHAKEN extension and must appear both in the JWS header and as a header parameter.RFC 8588 §4
x5u and info=The certificate URL in the JWS header and the info parameter must match and be fetchable; otherwise the verifier returns 436 Bad Identity-Info.RFC 8224 §7.2
attestMust be A, B or C. The level drives downstream analytics and the verstat value the called party sees.RFC 8588 §4
iat ageVerifiers reject tokens older than their freshness window, typically 60 s. Clock skew on the signing SBC or long trunk queueing produces 438 with nothing else wrong.RFC 8224 §6.2.1
orig / destBoth must be present and must match the calling and called numbers the verifier derives from P-Asserted-Identity/From and the Request-URI; a rewritten number after signing breaks the token.RFC 8225 §5.2
origidRequired by SHAKEN for traceback. Missing origid is a sign of a non-compliant signing service.RFC 8588 §5
Where it leads

Three questions this answers

Each has a guide for the full picture.

Why is my caller ID marked spam?
Decode what your carrier is signing. B or C attestation on your outbound calls is the usual answer, and the fix is on the number-assignment side, not the PBX. STIR/SHAKEN explained →
What does verstat mean?
The terminating side's verdict (TN-Validation-Passed, Failed, No-TN-Validation) is the output of exactly these checks plus the signature. verstat header guide →
Am I compliant?
Signing is one obligation; the Robocall Mitigation Database filing is the other. TRACED Act and the RMD → · SIP trunking →
FAQ

STIR/SHAKEN Identity header questions

What the token contains, what the levels mean, and what this tool does not do.

What is in a SIP Identity header?
A PASSporT: a compact JWS with a header (alg ES256, typ passport, ppt shaken, x5u pointing at the signing certificate), a payload (attest A/B/C, orig and dest telephone numbers, iat timestamp, origid), and an ES256 signature, followed by the info, alg and ppt header parameters. The originating service provider signs it; the terminating provider verifies it and may add a verstat parameter for the called party.
What do attestation levels A, B and C mean?
A (Full): the originating provider authenticated the customer and knows the customer is authorised to use the calling number. B (Partial): the customer is authenticated but the provider cannot vouch for the number, typical of enterprise PBXs sending numbers the carrier did not assign. C (Gateway): the call arrived from an untrusted interconnect such as an international gateway; only the entry point is attested. Analytics engines weight these differently when scoring spam likelihood.
Does this tool verify the signature?
No. It decodes and lints the PASSporT structurally: algorithm, claims, iat age, orig and dest presence, certificate URL consistency. Signature verification requires fetching the x5u certificate, validating it against the STI-CA trust list and checking the signed digest, which is the terminating provider’s verification service’s job. A verifier returns 438 Invalid Identity Header on a bad signature, 436 Bad Identity-Info when the certificate URL cannot be fetched, and 437 Unsupported Credential when the certificate is not trusted.
Why would a call get 438 Invalid Identity Header?
The verifier could not validate the PASSporT. Common causes: the iat is older than the verifier’s freshness window (typically 60 seconds, so clock skew or long queueing breaks it), orig or dest in the token does not match the From/P-Asserted-Identity or Request-URI numbers, the signature does not match, or the token was modified by an intermediary. Decoding the header shows which claim is wrong before you open a ticket with the originating carrier.
Is the Identity header I paste stored?
No. The decode runs on the SIPSymposium MCP endpoint as a deterministic function; the text is parsed, the result is returned, and nothing is kept. No AI model is involved and no account is needed. The same tool is available inside Claude, Cursor or VS Code through the SIPSymposium MCP server.

The token is one header. The call is the trace.

Whether the 438 came from the token, a rewritten number mid-path, or a verifier that never saw the header at all is in the full INVITE and its responses. The analyzer reads all of it.