SIP 428 Use Identity Header: prove policy and signing authority

Read 428 as a verifier policy result

RFC 8224 permits zero, one or more Identity header fields in a SIP request. A verification service sends 428 Use Identity Header only when it cannot use any of them because they are absent or carry unsupported ppt parameters, and local policy requires a usable Identity header. Preserve the request method, Request-URI, Call-ID, CSeq, top Via branch, From, P-Asserted-Identity, Date, every Identity value, responding element and exact leg.

Do not translate 428 into 'bad caller ID,' 'spam,' failed SIP digest authentication or a failed media offer. It does not by itself identify who was supposed to sign the request, whether another network leg carried an Identity header or whether the call would pass an authorization or reputation policy after identity verification.

Assign the authentication-service owner

An RFC 8224 authentication service must be authoritative for the identity it signs and authenticate the originator. It forms a PASSporT, signs it with a valid credential and places it in the Identity header with information that lets a verifier obtain the credential. That job belongs at a service boundary with signing authority; copying an Identity value, inventing an attestation level or adding a header with a generic SIP-header function is not equivalent.

Record the originating identity, Date value, signer, credential URL, PASSporT type and network owner expected to authenticate the caller. An endpoint, PBX and upstream carrier can each own different legs, so repair the place that originates the rejected request rather than every device that displays the number.

Separate absence from verification failure

A verifier first determines whether it supports the optional ppt, then canonicalizes the originator identity, obtains appropriate validation material, checks freshness and validates the signature. Those later failures have different RFC 8224 outcomes: 436 concerns unusable Identity information, 437 an unsupported credential and 438 an invalid Identity header. A 428 instead says that no Identity header was usable at the first policy boundary.

Multiple Identity fields are possible. Preserve every field and the verifier's evidence instead of deleting all but one. RFC 9410 also allows a network that continues the call to report STIR errors in a Reason header on a later provisional or final response; absence of a final 428 therefore does not prove identity verification succeeded.

Keep verification and authorization separate

A valid Identity signature does not dictate forwarding, display, blocking or reputation policy. RFC 8224 leaves authorization to local policy, including the handling of valid, invalid, absent and stale identities. Likewise, 428 does not grant permission to upgrade attestation, substitute another calling number or retry indefinitely.

Correct only the demonstrated owner, preserve the previous profile and policy, and verify through the responsible provider's authorized test path. Confirm the exact outgoing request, returned response or Reason field and expected signing boundary. The Asterisk PJSIP investigation maps that evidence to current Asterisk profiles without representing a certificate or provider relationship as validated.

Map a required Identity header to the loaded Asterisk signer

For Asterisk, the STIR/SHAKEN operations guide traces the PJSIP endpoint's effective profile, channel caller number, TN object, signing authority, key and public certificate URL before changing the response policy.