RFC 9970 — Connected Identity for STIR — library

RFC 9970 (Peterson, Wendt — June 2026) adapts the connected identity concepts of RFC 4916 to the STIR signing model. I co-author with Jon Peterson. Proposed Standard, published from the working-group draft draft-ietf-stir-rfc4916-update-07.

RFC 4916 (2007) defined how SIP could carry identity in the backwards direction, from called to calling party, using the SIP Identity header field of RFC 4474. RFC 4474 was obsoleted by RFC 8224, and this document brings the mechanism forward to PASSporT-based signing. It does not obsolete RFC 4916, and it does not deprecate the from-change behavior RFC 4916 defines — §10 leaves an update to that for future work.

What it specifies

The rsp PASSporT type. A PASSporT type sent only in SIP responses; an rsp PASSporT received in a request MUST be ignored. The payload looks like an ordinary PASSporT — the difference is semantic, in that the signature authenticates the dest claim rather than the orig, the same inversion div uses. The specification adds the 100, 180, 183 and 200 responses to the set of messages that may carry an Identity header field. A terminating side without a credential for the dest value MUST NOT sign and send an rsp.

div chain validation back to the rsp. When a call is retargeted, the party reached no longer matches the original dest. A UAS sending an rsp MAY also return the div PASSporTs (RFC 8946) it received in the INVITE, and where the rsp signs a different dest than the dialog-forming request did, it MUST carry at least one div with it. If no div PASSporTs arrived, rsp MUST NOT be used. div is not universally supported, so a retargeted call may simply have no usable connected identity. Whether to trust any div or rsp remains relying-party local policy.

Mid-dialog and dialog-terminating requests. Once a dialog carries connected identity, re-INVITEs from either side and BYE requests SHOULD carry valid PASSporTs. The named fraud pattern is “call stretching” — an intermediary makes one side believe the call ended while telling the other it is still up, creating a billing discrepancy it can pocket. Authenticated BYE in both directions closes that vector, along with denial-of-service teardowns. The specification does not recommend PASSporTs for dialog requests other than INVITE, UPDATE and BYE, and notes that CANCEL can be generated by forking proxies, so recipients should not expect a PASSporT on one.

Authorization policy for callers. The document assumes users have a way to mark a call as requiring verified connected identity, per call or per destination, and that the call should not complete if it reaches an unexpected or unauthenticated party. The analogy drawn is SRTP negotiation failing when media keys do not match the fingerprints exchanged at the signaling layer.

Pre-association with destinations. §8 covers learning before the call whether a destination supports connected identity — a directory service advertising support, or a device log of prior support. It specifies a media-less dialog for probing: an INVITE with an Identity header field, no SDP, and 100rel in Require, to which a supporting UAS SHOULD return a provisional response carrying a PASSporT.

Two-factor authentication. §3 names telephone-number-based TFA as a motivating use case, because connected identity gives the calling party assurance it reached the telephone for the called number.

What’s out of scope

Conferencing, especially meshed conferencing, is out of scope; the mechanism covers two-party communications and multiparty sharing of connected identity is left for future work. Failure responses (4XX, 5XX, 6XX) and redirects (3XX) do not form dialogs and are excluded. Media substitution after answer is not addressed — RFC 4916 already observed that call transfer, park and retrieval can replace the connected party, and a back-to-back user agent can hide that from the caller. Connected identity validates the signaling, not the media or the person speaking.

Privacy

§12 notes that sending connected identity reveals information about the called party, and that rich call data in particular should not be sent in the backwards direction where the called party does not wish to be identified. It must be an opt-in choice. §5 adds a second exposure: returning div PASSporTs to the caller reveals the called party’s service logic, which is why the called party controls whether they are reflected back.

Status

RFC 9970 (June 2026, Proposed Standard), from draft-ietf-stir-rfc4916-update. IANA has registered rsp in the PASSporT Extensions registry.