> ## 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 STIR/SHAKEN attestation model > The end-to-end model behind caller-ID trust: what attestation levels A/B/C assert, why a BYON caller might get a lower level, how PASSporT signing actually travels, where Orbit surfaces the levels, and what to do when a downgrade is flagged. # The STIR/SHAKEN attestation model STIR/SHAKEN signs every outbound voice call with an **attestation level — A, B, or C** — and every inbound PSTN call arriving at your numbers carries one back too. The [compliance surfaces](/compliance/attestation) and the [glossary terms](/reference/glossary) each cover one corner of the story; this page is the model behind all of them. Read it once and the attestation posture pages, the branded-calling page, the pre-send gate chain, and the inbound routing rules all fit together. This page describes the model and your own attestation controls. It is **not legal advice**, and Orbit neither mandates a level for you nor gates your calls on one — everything here is tenant-owned configuration and reporting. Regulatory judgement about which level your programme must hold stays with you and your counsel. *** ## 1. What STIR/SHAKEN is STIR/SHAKEN (ATIS-1000074) is the framework the US telecom industry uses to stop caller-ID spoofing at the network layer. The originating provider cryptographically signs the call's asserted caller ID at setup time, and the terminating provider — the carrier that rings the recipient — verifies that signature before it decides how to render the call. The signature travels in a SIP `Identity` header carrying a **PASSporT** (Personal Assertion Token), a signed JWT whose payload records the calling number, the called number, a timestamp, and one attestation level. There are two families of attestation. **Genuine attestation** is what the framework means by the "originating provider": the carrier authenticates its own customer and, at the top level, verifies that customer's right to use the calling number against its own numbering records. **Delegated attestation** (ATIS-1000092) is the standard's answer for a number you legitimately control but that a provider cannot independently verify — a carrier hands your provider a delegate certificate authorising specific numbers, and the provider signs calls from those numbers at partial attestation instead of gateway. BYON (bring-your-own-number) and hosted caller IDs live in this delegated family, which is why the level you get depends on which of the two applies. *** ## 2. Attestation levels A/B/C, with rules The level asserts exactly two things: whether the provider authenticated **you**, and whether it verified **your right to the calling number**. | Level | Name | Asserts | Which callers reach it | | ----- | ------- | --------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | | **A** | Full | Caller authenticated **and** the number's right-to-use verified | The caller ID is a number your organization owns through Orbit — purchased or ported in, active | | **B** | Partial | Caller authenticated; number verification not provider-verified | A leased pool number with an active assignment, **or** a BYON/external number covered by an active delegate certificate | | **C** | Gateway | The provider knows where the call entered, nothing more | A caller ID not attributable to your organization, an uncovered BYON number, or the platform default fallback | Worked examples to make the rules concrete: * **Orbit-hosted number (owned).** Your org purchased the DID or ported it into Orbit. The calling number belongs to your organization's own numbering records, so the right-to-use check is satisfied — **A**. * **Leased pool number.** The number belongs to Orbit's pool and your assignment is active. The platform can authenticate your org but it cannot treat pool ownership as your verified right-to-use — **B**. * **BYON with a delegate certificate.** The number is yours but Orbit cannot verify that from its own records. Your registered [delegate certificate](/compliance/attestation) covers the number for the active validity window — that is the delegated-attestation path, and it reaches **B**. It can never reach A: the chain is tenant-supplied and its coverage list is free-form input, so a self-registered artifact must never spoof full attestation. * **BYON without a certificate.** The platform can authenticate your org but the number is not attributable to it — **C**, and downstream carriers treat that as the weakest caller-identity signal. (A note on rules vs reach: the delegate-certificate ceiling at B is deliberate, and the failure-mode fallback is fail-open — if the ownership lookups behind level resolution fail, the resolution folds to C rather than blocking the call.) *** ## 3. Where the gate surfaces in Orbit STIR/SHAKEN is resolved and recorded on every call, so the surfaces it appears on span most of the voice product: * **[Channels → Voice → STIR/SHAKEN](/channels/voice/stir-shaken)** — the long-form page on outbound level assignment, inbound attestation parsing (`A`/`B`/`C`, `failed`, `none`, `unknown`), and per-DID inbound minimum floors. Most configuration knobs live here. * **[Compliance → Attestation posture](/compliance/attestation)** — the tenant policy surface: your target level, downgrade handling, inbound verification floor, spoof-risk flag, delegate-certificate registry, and the posture snapshot that reads every originating number against that policy. * **[Compliance → Branded calling (RCD)](/compliance/branded-calling)** — brand presentation rides on the attestation prerequisite. Full (A) attestation is the gate for Rich Call Data; a B- or C-attested call falls back to plain attestation plus any CNAM name on file. * **[Inbound voice routing](/concepts/inbound-voice-routing)** — inbound caller screening parses the attestation result before routing; the minimum policy an organization sets per rule admits or declines. * **[Voice pre-send gate chain](/concepts/voice-pre-send-gate-chain)** — attestation assignment is step 7 of the outbound dial path — a resolution surface, not a gate, and the last thing stamped before the call leaves. * **The per-call record.** Every outbound call stores its assigned level, and the [attestation analytics](/api-reference/endpoints/numbers) surface counts cause-attributed downgrades per window. See the [Tenant compliance posture map](/compliance/posture-overview) for the tenant-side controls index — which surface owns which switch and what defaults apply. *** ## 4. The PASSporT / SIP Identity flow Signing never happens inside Orbit the platform — it happens on Devotel's carrier-of-record network, and the platform only computes the level and signals it onward. The asymmetric split keeps a stolen or spoofed platform credential from being able to sign arbitrary attestations. ``` ┌──────────┐ computes level (A/B/C) ┌─────────────────────────┐ │ Orbit │ ───────────────────────► │ Devotel wholesale │ │ dial │ X-Devotel-Attest: │ softswitch (carrier of │ │ path │ │ record) │ └──────────┘ └──────────┬──────────────┘ │ signs PASSporT │ (never higher than │ the attested level) ▼ ┌─────────────────┐ │ Identity header │ │ carries the JWT │ │ + at=claimed │ └────────┬─────────┘ │ ▼ ┌─────────────────────────┐ │ Terminating carrier │ │ verifies signature │ │ → A/B/C result, or │ │ 'failed', or none │ └─────────────────────────┘ ``` Outbound, the platform resolves the caller ID against your ownership, leases, and any registered delegate certificates, and stamps that level on the outbound INVITE as `X-Devotel-Attest`. The softswitch reads the header, signs the PASSporT at exactly that level, and the receiving carrier verifies it. Inbound, the flow runs the reverse direction: Devotel's softswitch verifies the upstream PASSporT and forwards the result as an RFC 8588 `Verstat` / `P-Attestation-Indicator` value (`TN-Validation-Passed-A/B/C`, `TN-Validation-Failed`, `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. *** ## 5. Downgrade and remediation A downgrade is anything below your policy's target — not always a dropped level. Two families trip the flag: * **Ownership-shape downgrades** — the level the number legitimately reaches is below your target (a leased number against an A target, a BYON number that lost its certificate, a fallback caller ID). The [compliance posture](/compliance/attestation) page's per-number table names the held-back identifier and which level it attests at. * **Explicit `cli_attestation_downgrade`** — a pre-check on the outbound campaign/journey dial path (BYO number imported without a verified compliance bundle) flips this flag when the number is owned but lacks attested provenance. The voice service reads the flag and forces the level to C at call creation; the [attestation analytics](/api-reference/endpoints/numbers) surface counts it per window as a cause-attributed downgrade. Remediation paths differ per family. Ownership-shape: move traffic onto an owned, active DID, or register a delegate certificate to lift a BYON number from C to B, or accept that the target sits above the level those numbers can reach. Explicit-flag: a provenance-bundle cleanup for imported BYO numbers re-earns the compliance registration, and the flag stops firing. Policy rewrites never change what gets signed — they only change what your reporting calls below target. Every movement lands in your audit ledger, so the gap is reconstructable after the fact. Policy updates record [`compliance.attestation.policy_updated`](/compliance/audit-export), delegate-certificate registration and revocation record their own registry events, and the [audit-log surface](/compliance/audit-export) exports or streams the entries for review. Where below-target calls are flagged `alert` over `monitor`, the downgrade also lands in [voice signature review](/compliance/voice-signatures) and the audit ledger alongside any recording-consent artifact your agents capture on the same traffic. *** ## 6. Cross-links * [Attestation posture settings](/compliance/attestation) — your target, downgrade handling, inbound floor, and delegate registry. * [Branded calling (RCD)](/compliance/branded-calling) — the attestation prerequisite for verified brand presentation. * [STIR/SHAKEN on the voice channel](/channels/voice/stir-shaken) — outbound assignment plus inbound parsing floors per DID. * Glossary — [Attestation (A,B,C)](https://orbit.devotel.io/glossary/attestation-a-b-c), [STIR/SHAKEN](https://orbit.devotel.io/glossary/stir-shaken), and [Rich Call Data](https://orbit.devotel.io/glossary/rich-call-data) for term definitions. * [Omnichannel fallback compliance matrix](/concepts/omnichannel-compliance-matrix) — where the voice plane's attestation posture sits next to the registration and quiet-hours planes. * [Voice data residency](/compliance/voice-data-residency) — where attested calls' identity artifacts rest and how residency frames them. * [Tenant posture toggle map](/compliance/posture-overview) — the controls index; the one exception to tenant-owned compliance is the federal TCPA window, and attestation never touches that.