SIP 438 Invalid Identity Header: validate the PASSporT

Require every usable identity to fail

RFC 8224 defines 438 Invalid Identity Header when no Identity field in the request contains a valid and supported PASSporT, and the verification service's local policy rejects that condition. Preserve the complete request, responder, every Identity field, its ppt value, credential result and field-level verification outcome. If one trusted Identity field validates, an invalid sibling does not justify treating the whole request as invalid.

A 438 does not by itself prove caller spoofing, a particular signer fault or failed call authorization. A transit element can break the reconstructed signed identity, and a verifier can continue a call while reporting a STIR error through RFC 9410 Reason. Keep cryptographic validation, local rejection policy and later call treatment separate.

Reconstruct exactly what was signed

For a supported baseline PASSporT, record whether the Identity value carries compact or full form, then preserve the originator identity, destination identity, SIP Date, PASSporT iat, credential and signature bytes used by the verifier. Canonicalization of telephone numbers or SIP URIs, required protected headers and extension-specific claims can change the verification input. Do not normalize a captured request before comparison.

Credential acquisition and support precede this step. A URL retrieval failure remains 436; an acquired but unsupported or untrusted credential remains 437. A stale Date or iat can produce a policy-specific 403 rather than proving a 438 signature failure, so retain the exact response and verifier reason.

Distinguish signer fault from transit mutation

Compare the request leaving the authentication service with the request entering the verifier. A back-to-back user agent creates a new signaling leg, while a proxy or intermediary might alter Date, From, P-Asserted-Identity, Request-URI or other inputs. RFC 8224 specifically notes that changing Date in transit can break compact-form verification. The responsible owner is the first component that changed a protected value or produced a mismatched PASSporT.

Do not rewrite an Identity field, regenerate claims with an unrelated key or strip all identities to make the error disappear. Preserve each leg, Call-ID relationship and transformation policy. A valid signature still does not mandate display, routing, reputation or regulatory acceptance.

Use only the bounded repair path

When the authentication service originally sent compact form, RFC 8224 recommends one retry with the full-form PASSporT because it can repair some reconstruction failures and supplies better debugging evidence. It says not to retry more than once. Treat that as a signer-side, transaction-aware repair rather than a generic client retry loop.

If full form still fails, correct the demonstrated signing input, required claim, extension handling, key or transit transformation. Test through an authorized non-emergency provider path and retain the final field-level results. The Asterisk PJSIP investigation keeps that bounded retry separate from trust and local authorization.

Keep Asterisk's verifier inputs and documented limits visible

The Asterisk STIR/SHAKEN guide inventories the effective verification profile, Identity and Date headers, x5u fetch controls, CA and CRL inputs, cache, clock and individual results. It also records the verification limits Asterisk currently documents.