Skip to main content

​
The PASSporT token model

Every STIR/SHAKEN call carries a PASSporT (Personal Assertion Token) — a compact signed JWT — and understanding exactly what travels inside that token is what makes the attestation levels, the delegate-certificate registry, and the inbound verification floors fit together. The STIR/SHAKEN attestation model page is the framework-level story; this page is the token itself: what it carries, how its level is set, and how inbound calls read it.
This page describes how Orbit resolves and surfaces the signed claim. It is not legal advice — which level your programme must hold is a judgement for you and your counsel, and Orbit never gates your calls on one.

​
1. What a PASSporT is

A PASSporT is the signed object the STIR/SHAKEN framework (ATIS-1000074) moves through the network. The framework names two halves — authentication (the originating provider signs at call setup) and verification (the terminating carrier checks the signature before deciding how to render the call) — and the PASSporT is the object both halves pass between them. The carriage is the SIP Identity header on the INVITE: a compact, base64url-encoded JWT whose signature the receiving side verifies against the signing certificate. Because the verified claim arrives from the carrier, not from the caller, the level you see on your inbound floors is a network signal, not a caller-supplied label. The inbound half has its own reporting mirror — RFC 8588’s Verstat / P-Attestation-Indicator values — covered in section 5.

​
2. What the token actually carries

The signed payload is small by design — exactly enough to bind the caller-ID claim to one call, at one time: The JWT header points at the signing certificate (the x5u reference), which is how the verifying carrier locates the public key. Anything a carrier infers beyond those four fields — spam likelihood, branded display, blocking — is downstream policy on top of a verified signature, not part of the token.

​
3. How the level inside the token is resolved

The PASSporT only ever asserts what the resolved ownership evidence supports: Resolution fails open to C: if the ownership lookups behind the dial path fail — a numbering-record read times out, a lease check errors — the call still places, signed at gateway level rather than blocked. The alternative fails closed on call placement, which turns an internal lookup outage into a voice outage; Orbit instead degrades the claim while the call completes, and the attestation posture page’s target and floor levers report every such fold-back as a below-target call, so the degradation is measured, never hidden. Fail-open always degrades to the weakest level — a failed lookup never resolves upward to A or B.

​
4. BYON and the delegate-certificate lift to B

For a bring-your-own-number (BYON) caller ID, the ownership lookup cannot be satisfied from Orbit’s numbering records. The delegated-attestation path (ATIS-1000092) covers that case: a carrier authorizes your provider to sign for specific numbers via a delegate certificate, and the resolved level for covered numbers rises from C to B for the certificate’s registered validity window. What the certificate actually covers is a list of telephone numbers — the covered-number list — and coverage is what the registry levels against: a covered number resolves B; an uncovered BYON number stays C. Register the certificate with the delegate-certificate registry, and per-number coverage applies from the registration you make. B is the deliberate ceiling, and the reason is what A asserts. Level A claims provider-verified right-to-use: the provider checked the number against its own numbering records. A delegate certificate reverses the evidence direction — its covered-number list is free-form input the provider receives from you rather than independently verifies. The platform can still assert “caller authenticated” (the shared core of B), but it cannot assert the right-to-use half. If a self-registered artifact could sign at A, then A would stop meaning “verified” and any caller could self-assert full attestation — the exact spoof STIR/SHAKEN exists to kill. When a certificate expires or is revoked, coverage stops on the next call and the numbers fold back to their ownership-based level.

​
5. Inbound: verified claims, not raw tokens

Inbound, the flow reverses. Devotel’s wholesale softswitch normally verifies the upstream PASSporT and forwards the result as a Verstat / P-Attestation-Indicator value (TN-Validation-Passed-A/B/C, TN-Validation-Failed, or No-TN-Validation). The decode-vs-verify caveat: when only a raw Identity header arrives with no upstream verification result, the platform decodes the token — it reads the claims without re-running the signature and certificate check — and labels the output as a claim, not a verification. Read the two labels differently: a decoded-as-claim token is caller-supplied evidence, so a decoded A never outranks a verified B. Your inbound routing rules and per-DID minimum floors admit or decline on the parsed result, and the label is what tells you which kind of evidence they consumed.