RFC 8225 — PASSporT, the Personal Assertion Token
RFC 8225 (Wendt, Peterson — February 2018) defines PASSporT — short for Personal Assertion Token — the token format that STIR uses to carry signed identity claims. It is a constrained JSON Web Token (RFC 7519) with a claim set tailored to telephone identity and a header that carries the certificate URL the verifier needs to validate the signature. I am a primary author.
The document is short relative to its importance: most of what PASSporT does is structural, and the structure is straightforward once you’ve seen one. The longer arc of the work has been the extensions — every later development in STIR is a PASSporT extension rather than a parallel protocol — and the extensibility model defined here is what makes that possible.
What it specifies
A PASSporT has three parts, in JWT form:
- A header with two non-standard fields:
ppt(the PASSporT type, indicating which extension’s claim set is in use) andx5u(the URL where the verifier can retrieve the certificate chain authorizing the signature). The header also carries the signing algorithm — for STIR, ES256, which is ECDSA over the P-256 curve with SHA-256 as the digest. - A payload with three required claims:
orig(the originating identity, typically a telephone number expressed as a JSON object with atnfield),dest(the destination identity, similarly shaped, but allowing arrays for the conference / multi-destination case), andiat(the issued-at timestamp). Extensions add their own claims on top. - A signature computed over the base64url-encoded header and payload, joined by a period in the JWS compact serialization, using the algorithm named in the header.
The token is then placed in the SIP Identity header by RFC 8224’s
mechanism. The PASSporT itself is transport-agnostic: the same
token format works in-band (carried in SIP) and out-of-band
(published to a call placement service per RFC 8816).
Design choices worth knowing
The choice of ES256 was deliberate. RSA signatures over the
typical RSA key sizes produce signature blobs in the 256–512 byte
range; ECDSA over P-256 produces 64-byte signatures. SIP headers
have practical size limits in real networks (SBCs, soft switches,
and routers all impose their own constraints), and PASSporT’s
target was to fit comfortably inside a SIP Identity header
without forcing operational accommodations. ES256 was also a
reasonable cryptographic baseline — widely implemented in JOSE
libraries, well-understood in deployment, and not vulnerable to
the legacy-RSA failure modes that affected older signing schemes.
The claim set was kept minimal. The required claims are just enough to identify the call: who’s calling, who they’re calling, when. Deliberately not in the base claim set: anything about authority (that’s in the certificate, by way of the TNAuthList extension specified in RFC 8226), anything about call quality or context (that’s in extensions), anything that would put PII or arbitrary data in a signed token traveling through SIP. The token asserts identity, narrowly construed; everything else is a separate concern.
The extensibility model is the longest-lived design choice.
The ppt header field names which extension’s claim set is in
play, and verifiers reject tokens whose ppt they don’t recognize.
This was a deliberate choice over the alternative of “be lenient
about unknown claims” — the cost is that introducing a new
extension requires verifier upgrade, but the benefit is that
verifiers never silently ignore signed claims they don’t
understand. The model has held up: SHAKEN (RFC 8588), diverted
calls (RFC 8946), resource priority (RFC 9027), rich call data
(RFC 9795), and others all extend PASSporT through this mechanism
without requiring changes to the base specification.
What’s not in this document
PASSporT does not specify how the originator obtains the certificate that authorizes its signature, what the trust anchors are, what the verifier does with a successful or failed verification, or how the certificate URL is hosted. Those are left to:
- RFC 8226 (page forthcoming) for the certificate model,
- The governance documents — ATIS-1000080 and related — for the trust anchor and certificate authority arrangements (see SHAKEN),
- RFC 8224 for the SIP-side verification semantics.
PASSporT is a small, sharp-edged piece of cryptographic plumbing. It does its job well precisely because it tries to do only that job; the larger architecture grows around it.
Extensions referencing this document
Every PASSporT extension RFC depends on this base specification:
- RFC 8588 — PASSporT Extension for SHAKEN (page forthcoming)
- RFC 8946 — PASSporT Extension for Diverted Calls (page forthcoming)
- RFC 9027 — Resource Priority Header PASSporT Extension (page forthcoming)
- RFC 9795 — STIR PASSporT Extension for Rich Call Data (page forthcoming)
The extensibility story holds: each of these adds claims and a
ppt value while leaving the base unchanged.