The SIP header, defined in RFC 8224, that carries a signed PASSporT and a pointer to the signing certificate along with a call.
The Identity header is how a STIR/SHAKEN signature travels with a call. It contains the PASSporT in its compact JWT form (header, claims, and signature, each base64url encoded) followed by parameters. The "info" parameter points to the URL where the verifier can retrieve the signer's certificate, and the "ppt" parameter identifies the PASSporT extension in use, such as "shaken".
A single INVITE can carry more than one Identity header. This happens, for example, when a call is diverted and an additional "div" PASSporT is added to record the redirection, or when a Rich Call Data PASSporT travels alongside the base SHAKEN token. Verifiers are expected to evaluate each header and reconcile the results.
Because the header is long, it is a common casualty of misconfigured equipment. Session border controllers with header size limits, header normalization rules, or TDM interworking can strip or truncate it, which turns a signed call into an unsigned one by the time it reaches the terminating network. Testing interconnects with signed test calls, and checking what actually arrives at the far side, is the only reliable way to confirm the header is preserved end to end.
Why it matters to carriers
If you transit or terminate traffic, the Identity header is the thing you must not break. Dropped or mangled headers erase the originating provider's attestation and make legitimate calls look suspicious to analytics. Routinely sampling inbound and outbound INVITEs to confirm the header survives each hop is one of the cheapest STIR/SHAKEN health checks a carrier can run.