Summary

  • P-Preferred-Identity let a user suggest which valid identity a trusted proxy should assert; it was not authenticated evidence, and the proxy had to remove the hint from every forwarded message.
  • P-Asserted-Identity gained meaning only after a trusted proxy authenticated the originator and constructed or accepted the value under the trust-domain rules; an untrusted submitted assertion had to be replaced or removed.

Three similar-looking fields, three different authorities

SIP already had From, but RFC 3325 began from the fact that From could contain the alias a user wanted to present. A service provider might need another value for calling identity delivery, trace or other closed-network functions. At the same time, a caller might want the recipient not to learn that value. The result was not one stronger name field. It was a sequence of fields owned by different actors.

From remained user-presented identity. P-Preferred-Identity was also supplied by the user agent, but only to a directly trusted proxy. It carried a preference: if an authenticated user had several valid identities, which one should the network select? P-Asserted-Identity was the network's claim after authentication. The names resemble one another, yet they represented presentation, selection and assertion.

RFC 3325 made that separation executable. A P-Preferred-Identity received from an untrusted entity could be used only as a hint. The proxy had to compare it with the identities valid for the authenticated user. If the hint matched none, the proxy could construct a different assertion or reject the request. Whatever the result, it had to remove the user-provided P-Preferred-Identity before forwarding.

That removal prevented provenance collapse. A downstream node would see the assertion the trusted network chose, not the unverified selection that influenced the choice. If the hint traveled beside the assertion, a logger or application could later mistake user input for a second piece of corroboration. RFC 3325 allowed the preference to affect a decision, but denied it an independent afterlife.

The proxy had to destroy counterfeit authority

The same boundary applied more forcefully to P-Asserted-Identity arriving from an untrusted element. A user agent could spell the header correctly; spelling did not grant authority. If the proxy wanted to add an assertion, it first had to authenticate the originator and use the identity resulting from that process.

When an untrusted input already contained a SIP or SIPS asserted identity, the proxy had to replace that value with one SIP or SIPS identity of its own construction or remove the header. A submitted telephone identity faced the same rule. The proxy could not forward the value unchanged and merely attach a trust label. The old assertion had to disappear or be rebuilt from evidence the proxy controlled.

By contrast, a P-Asserted-Identity received from a node the proxy trusted could be used as if the proxy had authenticated the user itself. That shortcut inherited all the assumptions described by RFC 3324: secure receipt, configured membership and a Spec(T) defining authentication, channel protection, membership, privacy defaults and compliance. It did not make the header a cryptographic certificate.

The applicability statement was explicit. The asserted identities were not cryptographically certified and did not identify the specific party making the assertion; the Trust Domain as a whole had to be assumed to assert them. Outside an architecture satisfying the trust requirements, the values were exposed to forgery, replay and falsification. RFC 3325 did not provide a general Internet identity model.

Privacy was a second destructive boundary

After the ingress proxy constructed an assertion, a later proxy still had to classify the next hop. If it trusted the destination, it preserved assertions generated locally or received from a trusted source. If it did not trust the destination, it examined the Privacy header.

The new id token required removal of every P-Asserted-Identity value before forwarding to the untrusted element. The opposite value, none, required the proxy not to remove the asserted identities. With no Privacy header, the decision was a domain-policy matter that had to be stated in Spec(T). The RFC recommended retaining the identity unless privacy policy prevented it because removal could break services, yet warned that forwarding could disclose information users had not requested and could not prevent if suitable privacy services were unavailable.

That tension made the boundary consequential. The header could carry one SIP, SIPS or telephone URI, or two values only when one was SIP/SIPS and the other telephone. When privacy applied, all values had to be removed. Partial stripping would disclose another representation of the same party.

A receiving user agent had a similarly strict rule. If the previous element was not trusted, it must not use P-Asserted-Identity in any way. If it received the value within the appropriate Trust Domain, implementation or service policy could decide how to render it. RFC 3325 did not mandate how to reconcile multiple typed values.

RFC 5876 later updated details of RFC 3325. RFC 4474, RFC 8224 and RFC 8225 pursued different authenticated-identity and PASSporT designs; RFC 4916 addressed connected identity during a dialog. These later mechanisms do not erase the older architecture's lesson. Authority did not come from a privileged-looking header name. It came from a controlled transformation: authenticate, constrain the valid set, select, reconstruct, delete the hint, classify the next hop, and strip the assertion when privacy required.

The historical insight is therefore about evidence hygiene. A user's preference was legitimate input to a decision, but it was not a receipt. The proxy created the receipt only by refusing to let the input masquerade as its output.

Sources