> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# The PASSporT token model

> What a PASSporT is, what the signed token actually carries, how the attestation level inside it is resolved, and how BYON delegate certificates raise the claim from C to B — the transport-object companion to the STIR/SHAKEN attestation model.

# 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](/compliance/attestation), the
[delegate-certificate registry](/concepts/stir-shaken-attestation-model), and
the inbound verification floors fit together. The
[STIR/SHAKEN attestation model](/concepts/stir-shaken-attestation-model) page
is the framework-level story; this page is the token itself.

<Note>
  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.
</Note>

***

## 1. What a PASSporT is

A PASSporT is the signed object the STIR/SHAKEN framework (ATIS-1000074)
moves through the network. At call setup the originating provider signs a JWT
recording:

* the **calling number** and the **called number**,
* a **timestamp**,
* an **attestation level** claim — A, B, or C,

and attaches it to the SIP invite in the `Identity` header. The terminating
carrier verifies the signature against the signing certificate before it
decides how to render the call, so the claim you see on your inbound floors
is a verified signal, not a caller-supplied label.

***

## 2. How the level inside the token is resolved

The PASSporT only ever asserts what the resolved ownership evidence supports:

| Number shape                                                                                                   | Level the token carries                                                 |
| -------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------- |
| A DID your organization owns through Orbit (purchased or ported in, active)                                    | **A** — caller authenticated and right-to-use verified                  |
| A leased pool number with an active assignment, **or** a BYON number covered by an active delegate certificate | **B** — caller authenticated; number right-to-use not provider-verified |
| An unattributable caller ID, an uncovered BYON number, or the platform fallback                                | **C** — gateway-level claim only                                        |

Resolution fails open to C: if the ownership lookups behind the dial path
fail, the call still places, signed at gateway level rather than blocked. The
attestation posture page's [target and floor
levers](/compliance/attestation) measure and report against that resolved
level — they never change what gets signed.

***

## 3. 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: you register a delegate certificate naming
the numbers you legitimately control, and the resolved level for covered
numbers rises from C to B for the certificate's validity window.

B is the deliberate ceiling. The certificate is a tenant-supplied artifact —
its covered-number list is free-form input, so a self-registered artifact is
never allowed to sign at full (A). Reaching A requires the caller ID to
resolve to a number your organization actually owns. When a certificate
expires or is revoked, its coverage stops on the next call and the numbers
fold back to their ownership-based level.

***

## 4. Inbound: verified claims, not raw tokens

Inbound, the flow reverses. Devotel's wholesale softswitch 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`). When only a raw `Identity`
header is present, the platform decodes rather than verifies it, so the
result is labelled as a claim, not a verification. Your
[inbound routing rules](/concepts/inbound-voice-routing) and per-DID
minimum floors then admit or decline on that parsed result.

***

## 5. Cross-links

* [The STIR/SHAKEN attestation model](/concepts/stir-shaken-attestation-model) — the end-to-end framework story.
* [Attestation posture settings](/compliance/attestation) — the target level, inbound floor, and delegate-certificate registry.
* [STIR/SHAKEN on the voice channel](/channels/voice/stir-shaken) — outbound assignment and inbound parsing floors per DID.
* [Inbound voice routing](/concepts/inbound-voice-routing) — screening rules that consume the verified claim.
* Glossary — [PASSporT](https://orbit.devotel.io/glossary/passport), [STIR/SHAKEN attestation (A/B/C)](https://orbit.devotel.io/glossary/attestation-a-b-c), and [delegate certificate](https://orbit.devotel.io/glossary/delegate-certificate) definitions.