Attestation levels — A, B, and C in practice — library

SHAKEN attestation is network authentication. It is the structured statement an originating service provider — the network putting the call onto the telephone network — makes about what it can attest to knowing about the caller that initiated the SIP INVITE. The three attestation levels (A, B, and C) encode increasingly weak claims about what the provider knows and can confirm. The mechanism is precise; the operational meaning is more nuanced than the bare definitions suggest, which is what this page is for.

I was the primary editor of ATIS-1000074 — the SHAKEN base specification where the attestation model was originally defined — and a primary author of RFC 8588, the IETF formalization of the SHAKEN PASSporT extension that carries the attest claim on the wire. RFC 8588 came later to bring the operational profile’s PASSporT-level details into the IETF standards-track protocol family. The framing here is from the inside.

What attestation is, and what it isn’t

The attestation model — the three-level structure of A, B, and C — was originally defined in ATIS-1000074 as part of the SHAKEN operational profile. The model encodes a specific kind of assertion: the originating service provider’s statement about its relationship to the customer placing the call and to the calling telephone number being asserted. RFC 8588 came later to formalize the shaken PASSporT type in the IETF — defining the type itself along with the attest and origid claims and the required signing semantics — bringing SHAKEN’s operational profile into the IETF standards-track family. Today the two specs are read together: ATIS-1000074 for the operational meaning of each level, RFC 8588 for the IETF- formalized protocol structure that conveys it.

The model does not encode trust in the call overall. It does not encode whether the call is wanted. It does not encode whether the calling party’s identity is authentic in any deeper sense. It encodes a structured knowledge claim by the asserter, and that claim is exactly as strong as the asserter’s direct relationship with what’s being signed.

This distinction matters because the attestation model is often read more loaded than it is. “A-attestation” gets used as shorthand for “trustworthy call” and “C-attestation” for “suspicious call,” but neither shorthand is what the protocol actually says. A-attestation is a claim about the asserter’s position; what a terminating provider’s analytics engine does with that claim is a separate operational question that varies by network.

The asserter can only make claims about what they know. Calls move through multiple providers, and by the time a call reaches the called party, the structured knowledge of the originating provider has been forwarded — verified cryptographically, but not amplified. Attestation is a knowledge claim, not a trust verdict.

Network authentication, not user authentication

A useful framing for what SHAKEN attestation is and isn’t: it’s network authentication, not user authentication. The originating service provider — the network putting the call onto the telephone network — makes a structured claim about what it knows of the caller. There is a parallel concept of user authentication — the caller itself cryptographically signing on its own behalf — which delegate certificates support and which is operationally distinct.

The distinction maps to two questions and two responsible parties. Network authentication answers “what does the responsible provider know about this call?” — and the asserter is the originating network. User authentication answers “what can the responsible entity prove about its authority to use this calling number?” — and the asserter is the entity itself, typically the customer of the customer of the network. Both matter, and they’re complementary rather than substitutes: a call authenticated at both layers carries stronger trust signals than one authenticated at either layer alone. SHAKEN attestation identifies the responsible provider; delegate-certificate signing identifies the responsible entity.

The rest of this page treats SHAKEN attestation, network-side. The user-authentication side gets its own treatment on the delegate-certificates page.

The three levels

The three levels are defined in ATIS-1000074; RFC 8588 carries them on the wire as the permitted values of the attest claim. The text below paraphrases for clarity; the specs themselves are authoritative.

A — Full attestation. The originating service provider: (1) is responsible for the origination of the call onto the IP network, (2) has a direct authenticated relationship with the customer placing the call, and (3) has confirmed that the customer is authorized to use the calling telephone number being asserted. All three conditions must hold for an A-attestation.

B — Partial attestation. The provider has the first two — direct origination and an authenticated customer relationship — but cannot confirm the customer’s authorization to use the specific calling number. This is the case when, for example, an enterprise customer is permitted to originate calls under a range of numbers but the provider has not validated each specific number assignment.

C — Gateway attestation. The provider can confirm only that the call entered its network through a recognized peering arrangement. The provider does not have a direct authenticated relationship with the customer; it is signing because the call transited its gateway, not because it has knowledge of the call’s origin. C-attestation is the weakest claim the model supports.

       Originator with directly authenticated customer?
                              │
                  ┌───────────┴────────────┐
                YES                       NO (peering only)
                  │                        │
                  ▼                        ▼
        RTU for specific TN           ┌──────────────────┐
        verified?                     │   C — Gateway    │
                  │                   │                  │
        ┌─────────┴─────────┐         │ Provider attests │
      YES                  NO         │ only to peering  │
        │                   │         │ entry. Weakest   │
        ▼                   ▼         │ claim.           │
   ┌─────────────┐  ┌─────────────┐   └──────────────────┘
   │  A — Full   │  │ B — Partial │
   │             │  │             │
   │ All three   │  │ Customer    │
   │ conditions  │  │ confirmed   │
   │ confirmed.  │  │ but RTU for │
   │ Strongest.  │  │ specific TN │
   │             │  │ not verified│
   └─────────────┘  └─────────────┘

Who decides

The originating service provider — specifically, its authentication service — assigns the attestation level. The decision is policy-driven and based on the provider’s own data about the customer and the calling number. Two providers originating identical-looking calls might assign different attestation levels because their internal records and authentication policies differ.

Until late 2024, it was possible for a service provider to outsource SHAKEN signing to a third party, including the attestation decision itself. The FCC’s Eighth Report and Order (adopted November 2024) ended this practice in the United States: providers using third-party signing must now make all attestation level decisions themselves, and calls must be signed with the provider’s own certificate rather than the third party’s. The intent was to make accountability for attestation claims sit clearly with the provider whose name is in the Robocall Mitigation Database, rather than diffusing it across signing-as-a-service arrangements.

ATIS-1000088 — Framework for SHAKEN Attestation and Origination Identifier — is the SHAKEN-side spec that goes deepest on what each level requires operationally. It also covers the origination identifier (the origid claim, also defined in RFC 8588), which was designed to be opaque and referenceable only by the originating provider for traceback purposes. No prescribed values were defined; the OSP decides what origid means within its own systems, and uses it to correlate a problematic call back to its internal record of what placed it. Some terminating-side analytics try to overload origid with patterns inferred across calls, but that was not the design intent. The opaque-by-design choice was made before there was operational experience to draw from; we also thought the field might enable future uses that didn’t end up materializing.

What terminating providers do with the per-call signal

Attestation is one input among many in a terminating provider’s call treatment decision. Terminating networks combine the verified attestation level with reputation data, calling-number history, calling patterns, customer feedback signals, and the originating provider’s certificate identity. The treatment outcome — pass, label, block, divert to voicemail — emerges from the full combination rather than from attestation alone.

The original design intent assumed clean correlations: A- attestation calls receiving normal treatment because the provider has KYC-grounded confidence, C-attestation calls receiving heightened scrutiny. As How the system has evolved in practice below covers, deployment reality has been more mixed — the per-call signal has carried less weight than the original design implied, in part because of vendor practices that devalued A-attestation and the lack of enforced operational expectations. Specific analytics behavior is proprietary to each terminating provider; the same call can be treated differently across networks.

The B/C structural ambiguity

The B-attestation case — “customer known, number not verified” — covers a range of scenarios that the protocol cannot distinguish. At one end, it describes the legitimate enterprise scenario of a calling number outside the strictly verified range. At the other end, it can describe weak number-authorization controls at the provider. Both fit the same description; the protocol records both as B. ATIS-1000088 provides operational framing that narrows the cases, but the B/C boundary is fuzzier than the spec language alone suggests.

Where enterprise complications sit

Enterprise calls don’t always fit cleanly into the A/B/C model. A multi-homed enterprise that originates calls under numbers acquired from one carrier but routed through another faces a structural mismatch: the carrier doing the signing may be the one with the customer relationship but not the number assignment, or vice versa. ATIS-1000089 — Full Attestation Alternatives for Enterprises and Business Entities with Multi-Homing and Other Arrangements — is the technical report that evaluated several techniques to address these enterprise scenarios. Of the techniques considered, delegate certificate signing by the responsible entity has emerged as the one still under active discussion.

The delegate-cert approach shifts the question from network authentication to user authentication. Rather than the carrier signing on behalf of the enterprise, the carrier issues a constrained certificate that the enterprise (or a delegate of the enterprise) uses to sign calls itself. The enterprise — the responsible entity — asserts its own authority over the calling numbers it uses; the carrier’s role becomes attesting to having delegated that authority rather than directly attesting to caller identity. The decision moves to whichever party actually has the knowledge to make it.

ATIS-1000092 also specifies a complementary mechanism: when a network signing a call onward can’t directly verify the customer-number authorization but receives an upstream-signed call carrying a valid delegate-cert signature, the upstream signature can serve as justification for the network asserting A-attestation on its own signature. The delegate-cert mechanism becomes doubly useful — it lets the party with actual authority do the original signing, and it gives downstream networks a recognized basis for an A-attestation claim when they forward the call. See delegate certificates for the operational detail.

How the system has evolved in practice

The attestation level was designed as a per-call signal — a structured claim by the originating provider that downstream networks could weight when deciding how to handle a call. The reality of how that signal has been used has been mixed.

Two patterns shaped the deployment experience. First, some vendors selling SHAKEN signing services promised providing A-attestation regardless of the call. That practice devalued attestation as an indicator of trust: if A-attestation can be obtained simply by paying a vendor that always signs A, then verified A-attestation alone tells a terminating network very little about whether the originating provider actually has KYC-grounded confidence in the caller. Second, with no operational expectations enforced, providers’ attestation practices varied widely; downstream analytics engines learned to weight the per-call signal accordingly.

What has become more reliably valuable is “shaken” signing as network authentication of the responsible provider. The originating provider’s certificate identity is the same signal across every call they sign. Patterns become visible: which providers sign calls later identified as bad traffic, which providers consistently assign attestation levels that don’t match eventual trust outcomes, which providers operate as gateways for problematic origination. The OSP-level signal accumulates evidence over time in a way per-call attestation doesn’t.

The FCC’s Eighth Report and Order strengthens this by requiring providers using third-party signing services to sign with their own certificates rather than the third party’s. The certificate identity now corresponds to the provider whose name is in the Robocall Mitigation Database (RMD), the registry where US service providers file their robocall mitigation plans. Ejection from the RMD effectively cuts a provider off from authorized SHAKEN participation, and OSP cert-identity patterns are what make the case for ejection investigable. The RMD is where enforcement actually has consequence. (The RMD has its own dynamics deserving separate treatment in the library.)

Per-call attestation is also being strengthened, but along a different axis. Evolving FCC rulemaking is moving toward enforcing what A-attestation was always supposed to mean — that the originating provider has KYC-grounded confidence about the responsible entity that originated the call, based on an authenticated relationship with the endpoint. As those expectations get codified, the per-call A-attestation signal should regain meaning that ecosystem confusion and lax operational practice eroded. Whether the eventual enforcement matches the design intent is a question this page can revisit as the rules settle.

The OSP-level shift and the strengthening of A-attestation expectations aren’t substitutes for each other. They operate at different layers — OSP signing identifies the responsible provider; A-attestation, properly enforced, identifies that the responsible provider has the knowledge of the responsible entity that the model demands. Together with delegate certificates (which add user authentication of the entity itself), the architecture is moving toward layered trust signals rather than the single-bit-per-call signal the original design implied.

Where attestation interacts with the display layer

The conservative position — and the one I take — is that rich call data and branded-calling presentation should not rely on SHAKEN attestation. Network attestation tells the called party’s network something about the responsible provider; it does not authenticate the responsible entity about to appear on the called party’s screen with name, logo, and reason-for-call branding. Driving display from network attestation alone treats one signal as if it carries the trust of two layers, and the resulting trust model is weaker than what the user experience implies.

The right anchor for display-layer presentation is user-level authentication — the responsible entity itself signing, asserting authority over the calling number and the brand information being shown. Delegate certificates are the current operational mechanism. VESPER is the work in progress toward a fully transitive trust model that authenticates the responsible caller and validates their right to use the telephone number on the telephone network.

The display-layer specs — verified caller display (ATIS-1000081), rich call data (RFC 9795 substantively, with ATIS-1000094 as the SHAKEN operational profile), branded-calling implementations — don’t mandate which authentication layer anchors them; the operational discipline of insisting on user-level authentication before the display layer activates is a deployment choice. See rich call data for the display-layer detail.

Common confusions, summarized

A few framings worth stating plainly:

Attestation is a knowledge claim by the originating provider, not a quality judgment about the call. A and C are not “good” and “bad” — they’re different statements about what the asserter knows.

Attestation is assigned by the originating provider’s policy. The same call can carry different attestation levels across different originating providers, depending on their internal data and verification practices.

Verified attestation does not mean verified caller. Cryptographic verification confirms that the asserter’s claim is intact and authorized; it does not amplify the claim itself. A C-attestation that verifies cleanly is still a C-attestation.

Analytics engines do not treat attestation as a verdict. They treat it as one signal among many, and the actual call treatment emerges from the combination.

Where this fits

Attestation is the conceptual hinge between SHAKEN’s operational profile and STIR’s protocol mechanics. The model — the meaning of each level and how providers are expected to assign them — is defined at ATIS (1000074, 1000088, 1000089); the on-the-wire protocol structure that conveys it is specified at the IETF (RFC 8588); the regulatory accountability for attestation decisions is set by the FCC’s caller-ID authentication rulemakings. Each layer makes its own commitments, and the operational reality of any specific call’s attestation status sits at the intersection.