STIR/SHAKEN Identity Header Decoder (PASSporT)

Short answer: Paste the SIP Identity header from an INVITE, or the PASSporT token on its own, and the decoder shows the attestation level (A, B or C), the calling and called numbers, when it was signed (iat) and how long ago, the origination ID, the certificate URL (x5u and info=) and the algorithm. It only decodes the token: it does not fetch the certificate or verify the signature.

Built and tested in Chromium on 6 Oct 2026; runs entirely in your browser.

How to use the decoder

1. Capture the INVITE with sngrep, the Asterisk PJSIP logger (pjsip set logger on) or tcpdump.
2. Copy the whole Identity: header, including any continuation lines. Folded lines and the backslash folding used in RFC examples are joined for you.
3. Paste it and press Decode. Type example to decode the sample from RFC 8588.
4. Read the attestation, numbers and age, then compare them with the From or P-Asserted-Identity header of the same INVITE.

What the output means

Field	Meaning
Attestation	A (full): the signing provider knows the customer and that they may use the number. B (partial): it knows the customer but not their right to the number. C (gateway): it only knows where the call entered its network.
Calling number (orig)	The number the signer vouches for. It should match the caller ID in the INVITE.
Called number (dest)	The number or numbers the call was signed for.
Signed at (iat)	Signing time in UTC and its age. RFC 8224 recommends that verifiers reject requests whose iat is more than 60 seconds old.
Origination ID (origid)	A UUID the signing provider uses for traceback.
Certificate URL (x5u) and info=	Where the verifier downloads the signer’s certificate. The two should match.
Algorithm, typ, ppt	SHAKEN PASSporTs use ES256, typ passport and ppt shaken.
Decoded JSON	The full header and payload, so you can see any extra claims such as div for diverted calls.

Examples

The sample from RFC 8588 decodes to this header and payload:

{ "alg": "ES256", "ppt": "shaken", "typ": "passport", "x5u": "https://cert.example.org/passport.cer" }
{ "attest": "A", "dest": { "tn": ["12155550131"] }, "iat": 1443208345,
  "orig": { "tn": "12155550121" }, "origid": "123e4567-e89b-12d3-a456-426655440000" }

A compact-form header starts with two dots (..signature): the header and payload are left out and rebuilt by the verifier from the SIP message. RFC 8224 allows it, but there is nothing to decode, and SHAKEN as defined in RFC 8588 does not use it.

Common mistakes

• Copying only the first line. Identity headers are long and often wrap. If the decoder reports two parts instead of three, the copy was cut short.
• Treating a decoded header as verified. Anyone can build a token that decodes. Only signature verification against the certificate, done by the terminating carrier or Asterisk’s STIR/SHAKEN module, proves it.
• Reading an old capture as a stale call. iat is the signing time, so a header copied from yesterday’s capture is a day old. In a live call an old iat means a replayed header or a wrong clock.
• Expecting A attestation on every call. Calls from international gateways or older networks often arrive with C, or with no Identity header at all.
• Mismatched numbers. If orig differs from the caller ID you send, verifiers may mark the call as failed even though the signature is valid.

Official documentation: RFC 8224: SIP Identity · RFC 8225: PASSporT · RFC 8588: SHAKEN PASSporT extension · docs.asterisk.org: STIR/SHAKEN

Related: SIP Trace Analyzer: Find NAT, Codec and Dropped-Call Problems in a SIP Log · Troubleshoot SIP Calls with sngrep and the Asterisk PJSIP Logger · SIP Response Codes: Lookup for Every SIP Error, With Causes and Fixes · Port Phone Number to VoIP: 6 Steps and Common Rejections Explained · Migrate PBX to Cloud: 8-Step Plan From 3CX or Asterisk

See also: STIR/SHAKEN for Asterisk and FreePBX: Attestation and Who Signs

Frequently asked questions