SHAKEN — the operational profile and governance framework
SHAKEN — Signature-based Handling of Asserted information using toKENs — is the North American operational profile of STIR. Where STIR specifies the cryptographic protocol at the IETF (see STIR), SHAKEN specifies the deployment: who issues certificates, what trust anchors verifiers honor, what attestation levels mean, how the framework is governed, how it interfaces with regulatory mandates. The documents are written at ATIS rather than the IETF, reflecting the fact that operational profiles are jurisdictionally scoped in a way that the underlying cryptographic protocol is not.
I co-chair the ATIS IP-NNI Task Force, the committee within ATIS that produces SHAKEN’s specifications. I’m a primary author of RFC 8588 (the SHAKEN PASSporT extension that anchors the operational profile in the IETF protocol), and I’ve served as principal architect on the framework’s deployment across North American networks. The framing in this page is from the inside.
What SHAKEN is, and isn’t
SHAKEN is the answer to several deployment questions the IETF STIR specifications deliberately leave open. STIR says: a calling provider can sign a PASSporT asserting a calling identity, and a verifying provider can validate it cryptographically. STIR does not say which party is authorized to issue STIR certificates, which certificate authorities a verifier should trust, what “attestation” means in practice, or what regulators expect from deployed implementations. Those questions are jurisdictionally specific. SHAKEN answers them for the North American carrier ecosystem.
The boundary between STIR and SHAKEN is worth holding clearly.
SHAKEN does not introduce new cryptography. It does introduce a
new PASSporT extension (RFC 8588) that adds two claims (attest
and origid) — but RFC 8588 is itself an IETF document, not an
ATIS one. Everything operational about SHAKEN — the governance
arrangement, the certificate authority list, the attestation
semantics, the FCC compliance mapping — lives in the ATIS
specifications.
The governance triangle
SHAKEN’s trust hierarchy is built on three roles, distributed across three different organizations to prevent any single party from controlling the trust framework end to end. This separation is one of SHAKEN’s most consequential design decisions.
STI-GA — Secure Telephone Identity Governance Authority. The policy-making body. STI-GA decides what the rules are: who can be a certificate authority, what the certificate policies say, what the audit and compliance requirements are, what kind of evidence a service provider needs to provide to be issued a certificate. STI-GA is operated by an industry consortium that brings together carriers, regulators, and other stakeholders. It does not issue certificates itself, and it does not maintain operational infrastructure — its output is policy.
STI-PA — Secure Telephone Identity Policy Administrator. The operational authority that enforces the rules STI-GA establishes. STI-PA maintains the list of approved STI-CAs, distributes the trust list to verifiers, manages the lifecycle of certificate authority approvals, and adjudicates compliance. The STI-PA is a single contracted operator at any given time, currently iconectiv; the contract is competitively bid, with STI-GA as the contracting authority.
STI-CA — Secure Telephone Identity Certificate Authority. The certificate issuers themselves. Multiple STI-CAs operate concurrently; service providers choose which CA to source their certificates from based on commercial relationships and operational fit. STI-CAs operate under the policies STI-GA sets and the oversight STI-PA enforces. The TNAuthList extension (defined in RFC 8226) is the authority encoding STI-CAs use when issuing certificates to service providers.
The triangle’s logic: policy is separated from enforcement, and enforcement is separated from issuance. A failure or capture at any one corner doesn’t compromise the others. This separation is what makes the framework auditable in a way the alternative — a single trust authority issuing certificates directly — would not be.
┌───────────────────────────────┐
│ STI-GA │
│ POLICY-MAKING │
│ (industry consortium) │
│ │
│ Defines policy: who may be │
│ a CA, certification rules, │
│ audit requirements │
└───────────────┬───────────────┘
│
sets rules and
policies
│
▼
┌───────────────────────────────┐
│ STI-PA │
│ ENFORCEMENT │
│ (iconectiv, single │
│ contracted operator) │
│ │
│ Maintains trust list, │
│ approves CAs, enforces │
│ compliance │
└───────────────┬───────────────┘
│
approves and oversees
│
▼
┌───────────────────────────────┐
│ STI-CAs │
│ ISSUANCE │
│ (multiple operators) │
│ │
│ Issue SHAKEN certificates │
│ to service providers via │
│ ACME (RFC 9448) │
└───────────────────────────────┘
The certificate hierarchy in deployment
A SHAKEN certificate is issued by an STI-CA to a service provider that has been authorized by the STI-PA. The certificate carries a TNAuthList extension naming the service provider code (SPC), the telephone number ranges, or the specific telephone numbers the certificate authorizes signing for. The certificate is rooted in the STI-PA-managed trust anchors, so any verifier configured with the SHAKEN trust list will accept signatures from any properly issued certificate.
Issuance is automated through the ACME protocol, with the TNAuthList ACME profile (RFC 9448) defining how a service provider proves its authority over a number range during certificate issuance. The authority token (RFC 9447) carries the proof from the STI-PA-designated token authority to the STI-CA. This automation is essential at scale — manual certificate issuance would not be sustainable for an ecosystem with thousands of service providers and millions of certificate issuances per year.
For the customer-of-customer case — an enterprise originating calls under telephone numbers it has acquired from a carrier — the delegate certificate model in RFC 9060 lets the carrier issue a constrained certificate covering some subset of the carrier’s authorized numbers. The constraint is encoded in the delegate certificate’s TNAuthList using the JWT Claim Constraints mechanism (originally RFC 8226, enhanced by RFC 9118). See delegate certificates for the operational detail.
┌───────────────────────────────┐
│ STI-PA Trust Anchors │
│ (managed trust list) │
│ │
│ Root certs distributed to │
│ all SHAKEN verifiers │
└───────────────┬───────────────┘
│ trusts
▼
┌───────────────────────────────┐
│ STI-CA │
│ (one of several approved │
│ by STI-PA) │
│ │
│ Issues SP certs via ACME, │
│ receives authority token │
│ from the STI-PA-designated │
│ token authority │
└───────────────┬───────────────┘
│ issues
▼
┌───────────────────────────────┐
│ Service Provider Cert │
│ (end-entity signing cert) │
│ │
│ TNAuthList carries: │
│ - SPC, or │
│ - TN ranges, or │
│ - specific TNs │
└───────────────┬───────────────┘
│ may issue
│ delegate cert
▼
┌───────────────────────────────┐
│ Delegate Certificate │
│ (constrained subset of SP's │
│ authority, issued to │
│ an enterprise customer) │
│ │
│ TNAuthList constrained via │
│ JWT Claim Constraints │
│ (RFC 8226 / RFC 9118) │
└───────────────────────────────┘
The attestation model, briefly
The SHAKEN PASSporT extension (RFC 8588) adds an attest claim
with one of three values:
A — Full attestation. The originating provider knows the customer and confirms that the customer is authorized to use the calling number being asserted.
B — Partial attestation. The originating provider knows the customer but cannot confirm authorization for the specific number.
C — Gateway attestation. The originating provider does not know the customer; the call is being signed because it transited through the provider’s gateway, but no statement is being made about origin.
What these distinctions mean operationally — how analytics engines weight them, what regulators have said about them, what the line between B and C looks like in practice — is its own page. Attestation levels covers it.
The regulatory framework
SHAKEN exists as more than an industry effort because of regulatory mandate. The United States TRACED Act of December 2019 directed the FCC to require carrier-level caller authentication. The FCC’s March 2020 Report and Order mandated SHAKEN deployment for IP-based voice service by June 2021 for carriers above a size threshold, with extensions for smaller carriers and a separate framework for non-IP segments. Subsequent FCC orders have expanded the mandate to cover gateway providers, intermediate providers, and certain enterprise scenarios.
In Canada, the CRTC followed a parallel path with mandated SHAKEN deployment for major Canadian carriers. The two regulators coordinate through industry groups, and the underlying SHAKEN specifications are shared across both jurisdictions — though the trust anchors differ, since the STI-PA arrangements are nationally scoped.
The regulatory mandate is what gives SHAKEN its operational significance. Carriers are not deploying STIR/SHAKEN voluntarily; they are doing so under a compliance regime, and the FCC continues to evolve the rules through ongoing rulemakings.
The ATIS specifications
The ATIS-1000xxx series specifies SHAKEN’s operational details. Two foundational documents anchor the series:
- ATIS-1000074 (currently at v003) — the SHAKEN base specification itself. Defines the framework’s role architecture, its use of STIR, the attestation model, and the certificate profile.
- ATIS-1000080 (v006) — SHAKEN governance and certificate management. Specifies the STI-GA / STI-PA / STI-CA arrangement, the certificate lifecycle, and the policy administration procedures.
Beyond these, the series spans operational considerations for certificate authorities and policy administrators (1000084), the attestation and origination-identifier framework (1000088), the display-of-verified-caller framework (1000081), delegate certificates (1000092 — the operational profile of RFC 9060), calling name and rich call data handling (1000094), cross-border and international SHAKEN coordination (1000087, 1000091), and a substantial set of specifications addressing TDM and non-IP call paths (1000095, 1000096, 1000097, 1000105, 1000106, 1000107).
ATIS/SIP Forum IP-NNI Joint Task Force catalogs the full series with version notation and direct links to each document, alongside framing on the joint working group itself. Per-spec pages will fill in detail individually as they’re written.
Where this fits
SHAKEN sits between two layers. Underneath, the IETF protocol specifications (see STIR and the IETF catalog) provide the cryptographic primitives that SHAKEN profiles. Above, regulatory frameworks (FCC orders, CRTC mandates, ongoing rulemakings) provide the compliance regime that makes deployment mandatory rather than voluntary.
The framework is not finished. Active work spans enterprise delegated authority at scale, non-IP call paths, display-layer trust (rich call data), and cross-border arrangements (see trust governance). Each of those threads has its own dynamics — operational, technical, and political.