Summary

  • RFC 9970 lets a SIP party provide signed connected-identity evidence in provisional or final responses. It addresses a limitation of ordinary STIR: an authenticated caller does not by itself establish the identity of the party that answered.
  • A response PASSporT and a diverted-call PASSporT answer different, bounded questions. They can record an endpoint assertion or a retargeting step; neither proves that an unexpected route is acceptable for every caller, workflow or risk level.
  • Keep requested destination, response identity, diversion evidence, local criticality policy, call outcome and exception ownership as distinct records. Interoperable signalling can inform a decision without silently becoming the decision-maker.

The connection is a fact. The destination is still a question.

Someone calling a bank, clinic, emergency service or a routine supplier usually experiences only a binary result: the call rings, or it does not. The network sees a more complicated chain. The original request names a destination. A carrier or service may forward it, a local application may retarget it, a number may terminate at an intermediary, and a different party may ultimately answer. Most of those paths are legitimate. A forwarded desk phone and an after-hours service should not automatically look like an attack.

But ordinary legitimacy is not the same thing as proof. An adversary who can influence routing may aim to have a call reach an attacker-controlled resource, especially where a caller will disclose a one-time code, customer data or an emergency instruction merely because it believes it dialled the right number. The caller needs a way to distinguish “the network connected something” from “the expected party, or an authorised substitute, has supplied evidence about this connection.”

RFC 9970, Connected Identity for Secure Telephone Identity Revisited, is an IETF Proposed Standard published in June 2026. It adapts earlier connected identity work to STIR. The narrow advance is important: the SIP Identity header, previously centred on a request originator, may also appear in provisional and final SIP responses. A reached party that supports the mechanism can sign a response identity; RFC 9970 calls the usual response PASSporT type rsp.

This does not create a global directory of trustworthy telephone destinations. It does not say that any party receiving a call must sign. It does not identify a person, validate an off-network business relationship or establish that media heard after answer has not been substituted. It carries an attributable signalling assertion. That is valuable precisely because it has a stated scope.

A return-path signature is evidence, not a command

In a simple SIP call, the address of record reached by the INVITE corresponds to the dest claim in the initiating PASSporT. Without identity information travelling in the backwards direction, the caller does not obtain secure assurance that the party reached is the intended party. A signed provisional or final response gives the caller a new evidence object: a party that can sign for the reached identity has made an assertion in this dialog.

It is tempting to turn that result into a green light: signature valid, call safe. That shortcut loses the very distinctions the protocol preserves.

First, verification can establish cryptographic and profile facts about the response. It can establish neither that the original destination was correct for the caller's purpose nor that the caller should accept a different identity without warning. A restaurant booking line and a wire-transfer callback may both use SIP; a rational tolerance for unexpected forwarding is not the same.

Second, a valid assertion does not eliminate a local policy choice. RFC 9970 assumes that callers may express a criticality posture for a call or a destination: when connected identity is unavailable or differs from what is expected, the device can be instructed not to complete the call. The RFC does not dictate the interface, the threshold or the fallback. That restraint is a feature. The operator that bears the fraud, safety, customer and availability consequences must retain authority to decide which evidence is sufficient.

Third, verification does not make all failures identical. A missing identity response might be normal for a non-participating destination. An identity change might be an expected delegated service. A malformed PASSporT might be a configuration fault. A cryptographically valid but unexpected identity might be the signal that calls for a separate authentication channel. Each condition should have an owner and a remedy; none is well handled by one undifferentiated “authentication failed” label.

Retargeting needs a chain, not a story told after the fact

Diversion makes the boundary sharper. A call initially aimed at one telephone number may acquire a new target during transit. RFC 8946 defines the div PASSporT extension to record a retargeting step. That evidence can help a terminating verification service understand why a call reached its eventual destination. RFC 9970 explains an awkward but important limit: in ordinary retargeting, the calling party does not automatically receive those diversion PASSporTs. A SIP 3XX redirection, rather than concealed retargeting, is the currently defined route for secure redirection information to reach the caller.

No cryptographic object can settle the policy question on its own. A div claim can say that one authority asserted a move from an earlier destination to a later one. It does not tell every caller whether that authority was expected for a payroll approval, a customer-support case or an emergency request. It does not decide whether a concealed forwarding rule is acceptable. It does not prove that the new party is permitted to solicit secrets from the caller.

The responsible operational record therefore remains divisible:

  1. The originating context records the destination requested and why the call is being made.
  2. The signalling record retains the initiating PASSporT, response identity when present, and any diversion evidence that was actually available.
  3. The expectation record states whether a destination, delegate or redirect path was known in advance and which changes are tolerable.
  4. The decision record says which policy evaluated the evidence, whether the call completed, was warned, was stopped or moved to another channel, and who approved an exception.
  5. The review record can later compare a policy result with observed routing and signalling without rewriting the facts that were visible at the time.

These layers may share an identifier. They should not collapse into an assertion that “the call was authenticated.” A caller can receive a valid response identity and still decline the call. A terminating network can have a valid diversion chain and still fail to provide the caller with a backwards signal. A completed call can still be outside the originating organisation's acceptable risk posture. Keeping those states separate is how a later review can tell whether a control failed, a policy chose an exception, or the mechanism was never available.

Dialog integrity is narrower than human trust

RFC 9970 also reaches beyond the initial response. Once connected identity has been established, it recommends Identity header fields carrying valid PASSporTs on re-INVITE and BYE requests. That makes it harder for a third party to impersonate one side in a mid-dialog update or to send a forged teardown. It is a concrete reduction in the signalling attack surface; it is not an all-purpose statement that the conversation, media or human relationship is trustworthy.

The distinction matters in practice. A protected BYE may help prevent an attacker from ending a call to create a billing discrepancy or steer a session. It does not establish that an answered voice belongs to the expected employee. RFC 9970 itself keeps media substitution outside its scope, and limits the connected-identity mechanism to two-party communications. A system should not advertise more assurance to its users than the layer actually supplies.

This is where an operating system needs more than a standards checkbox. The team responsible for SIP profile conformance can validate the header. The team responsible for a sensitive business process must decide whether a verified header permits disclosure, release or instruction. The team responsible for incident response needs the contemporaneous headers, policy version and call outcome. Conflating those functions makes every later investigation depend on memory rather than evidence.

Support is an invitation to decide, not a central mandate

RFC 9970 suggests that a directory-like service might advertise that a destination supports connected identity, or that a device might remember prior support and warn if it later disappears. It describes a useful idea, not a new universal authority. A directory can publish a capability statement; it cannot make an originating user accept a response, prevent a local operator from changing risk policy, or prove a business relationship that is not in the signalling exchange.

That is the right division of responsibility. A shared protocol should make the minimum facts portable: what identity was asserted, which response or diversion carried it, and whether a verifier can check the assertion. It should leave future local decisions with the actors who can observe the context and bear the consequences. An institution can choose gradual adoption, different thresholds for different call types and a reversible fallback. It should publish what it expects, observe real results, and improve only the common piece that evidence proves must be shared.

The alternative is semantic inflation. A response signature becomes a claim to own routing policy; a capability directory becomes a global permission list; a signalling success becomes a waiver of customer protection. RFC 9970 avoids that mistake by adding a bounded means of connected identity rather than a remote command plane.

Privacy belongs in the same decision record

There is no free direction for identity data. Connected identity travelling backwards can reveal information about the reached party. Rich call data makes that disclosure more consequential, especially in business-to-consumer calls. The RFC therefore treats sharing as an opt-in choice. A security policy that requires an identity response for a high-risk callback may be justified, while the same response for every ordinary call can expose more information than the calling context warrants.

The practical test is not whether a feature exists but whether a decision is proportionate and reviewable. Record the purpose for which connected identity was requested, the minimum response data used, the retention boundary, the decision outcome and the accountable owner. A mechanism intended to detect route substitution should not quietly become a broad surveillance feed merely because its evidence is easy to log.

Sources