Skip to main content

​
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 and the glossary terms 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. 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 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 — 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 — 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) — 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 — 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 — 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 surface counts cause-attributed downgrades per window.
See the Tenant compliance posture map 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.
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 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 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, delegate-certificate registration and revocation record their own registry events, and the audit-log surface exports or streams the entries for review. Where below-target calls are flagged alert over monitor, the downgrade also lands in voice signature review and the audit ledger alongside any recording-consent artifact your agents capture on the same traffic.