appliedbits
LIBRARY  ·  STIR/SHAKEN LIBRARY ENTRY
Last updated 2026-05-03 drafted

Delegate certificates — solving the customer-of-customer authority problem

Delegate certificates extend STIR’s certificate model so that a party downstream of a carrier can sign calls under telephone numbers that are administratively held by the carrier. The carrier remains the trust anchor — the entity whose authority over the numbers is recognized by the trust framework — but the party with the actual call-origination relationship can do the signing itself. The mechanism is specified in RFC 9060 at the IETF; the operational profile for North American SHAKEN is specified in ATIS-1000092.

I co-chair the ATIS IP-NNI Task Force that produces ATIS-1000092, and I’m authoring the VESPER draft at the IETF that extends the delegate-certificate model in directions covered toward the end of this page. The framing here is from inside the work.

The problem the mechanism solves

The standard SHAKEN model assumes the originating service provider is the entity with both the customer relationship and the operational position to sign the call. In practice, that assumption breaks down in several common scenarios:

Multi-homed enterprises. A large enterprise — a bank, a retailer, an airline — may hold telephone numbers from one carrier but route outbound traffic through another carrier depending on cost, geography, or capacity. The carrier doing the signing isn’t the carrier that assigned the numbers, which makes A-attestation difficult to assert honestly.

CPaaS and software-defined origination. A communications platform-as-a-service provider may originate calls on behalf of hundreds of enterprise customers, each of whom holds telephone numbers from various underlying carriers. The CPaaS provider is the entity with the operational signing position, but the authority over the numbers is distributed across its customer base and their underlying carriers.

Reseller and channel arrangements. Smaller service providers that don’t operate their own SHAKEN infrastructure historically relied on signing-as-a-service arrangements through upstream providers. The Eighth FCC R&O changed the rules around this for US providers (see attestation levels), but the underlying authority-vs-signing-position mismatch remains a structural feature of the ecosystem.

In each case, the party with the operational signing position isn’t the same as the party with the authority claim. Without a delegation mechanism, the only options are: have the carrier sign on behalf of an opaque downstream relationship (which loses information and stretches the meaning of A-attestation), or allow non-carriers to obtain certificates directly (which disconnects signing authority from telephone-number administration). Delegate certificates avoid both extremes.

The mechanism

A delegate certificate is a STIR certificate constrained to a subset of the issuing carrier’s TNAuthList authority. The constraints are encoded using the JWT Claim Constraints mechanism defined in RFC 8226 and enhanced by RFC 9118; the delegation relationship — that this certificate represents authority delegated from a higher-tier certificate — is specified in RFC 9060.

The structure is hierarchical:

  • The carrier holds an STI certificate issued under SHAKEN governance, with TNAuthList authority covering the numbers it administers.
  • The carrier issues a delegate certificate to a downstream party (an enterprise, a CPaaS provider, a reseller). The delegate certificate’s TNAuthList is constrained to a subset of the carrier’s authority — specific number ranges, specific individual numbers, or a specific service-provider code.
  • The delegate uses its own delegate certificate to sign STIR PASSporTs for calls it originates within the constrained scope.
  • A verifier walking the certificate chain validates that the delegate’s signing authority is properly bounded by the carrier’s authority, and that both certificates are rooted in a recognized trust anchor.

This preserves the trust framework’s core property — that signing authority traces to recognized authority over telephone numbers — while letting the actual signing happen at the party with the operational relationship to the call.

        ┌────────────────────────────────┐
        │      Trust Anchor (STI-PA)     │
        │        trust list root         │
        └────────────────┬───────────────┘
                         │
                         ▼
        ┌────────────────────────────────┐
        │    Carrier STI Certificate     │
        │                                │
        │  TNAuthList: full SPC and      │
        │  number-range authority the    │
        │  carrier administers           │
        │                                │
        │  Issued by an STI-CA under     │
        │  SHAKEN governance (RFC 8226)  │
        └────────────────┬───────────────┘
                         │ issues delegate cert
                         │ (RFC 9060)
                         ▼
        ┌────────────────────────────────┐
        │    Delegate Certificate        │
        │  (issued to enterprise         │
        │   customer or CPaaS)           │
        │                                │
        │  TNAuthList constrained to a   │
        │  subset of the carrier's       │
        │  authority via JWT Claim       │
        │  Constraints (RFC 8226 +       │
        │  RFC 9118)                     │
        │                                │
        │  Constraints can name:         │
        │  - specific number ranges      │
        │  - specific individual TNs     │
        │  - a specific SPC              │
        └────────────────┬───────────────┘
                         │ delegate signs
                         │ PASSporTs in scope
                         ▼
        ┌────────────────────────────────┐
        │      Signed PASSporT           │
        │                                │
        │  Originated by the enterprise  │
        │  or CPaaS for a call within    │
        │  the delegate's constrained    │
        │  authority                     │
        └────────────────────────────────┘

A verifier walks the chain from the PASSporT signature back through the delegate cert to the carrier cert to the trust anchor, confirming at each step that the signing scope is properly bounded by the issuing scope.

ATIS-1000092 — the SHAKEN operational profile

ATIS-1000092 is the SHAKEN-side specification that operationalizes delegate certificates for North American deployment. It addresses the questions RFC 9060 leaves open by design: who issues delegate certificates, what verification the issuing carrier is expected to perform before issuing, how revocation propagates, what the certificate lifecycle looks like, and how the resulting certificate hierarchy interacts with the SHAKEN trust list.

The spec also specifies a complementary mechanism that’s operationally important. 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. This makes the delegate-cert mechanism 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. (This is treated in detail in attestation levels.)

In current deployment, ATIS-1000092.v002 is the canonical operational profile, with the SHAKEN governance arrangement extending naturally to delegate-cert issuance: STI-CAs that issue SHAKEN base certificates also issue delegate certificates under the same trust hierarchy, and STI-PA enforcement reaches the delegate-cert layer through the same compliance mechanisms.

What the current model doesn’t address

The current delegate-certificate model — RFC 9060 plus ATIS-1000092 — solves the structural problem of separating signing position from authority. It leaves several questions open that the model itself wasn’t designed to answer.

RTU establishment. Right-to-Use establishment — the question of how the carrier verifies that the delegate has actual authority over the numbers being delegated — is treated as a business-process matter rather than a protocol-level concern. The carrier’s customer relationship, contracts, and number-assignment records are the basis; there’s no on-the-wire artifact that captures or evidences the RTU determination. For most cases this is adequate, but for high-stakes scenarios — enterprises with multi-homing, complex reseller chains, cross-border situations — the lack of explicit RTU evidence has been a recurring concern.

Transparency. Once a delegate certificate is issued, there’s no public record of the issuance event. A carrier could in principle issue a delegate certificate covering numbers it shouldn’t have authority over, and the lack of public visibility makes such an issuance difficult to detect. Certificate Transparency, which has become baseline practice in the WebPKI, isn’t part of the current STIR/SHAKEN model.

Domain-bound identity. The delegate-cert model preserves authority-tracing for telephone numbers, but it doesn’t connect that authority to the broader identity of the responsible entity. A bank that signs calls under its delegated certificate is asserting authority over specific telephone numbers, but nothing in the cryptographic chain ties those numbers to the bank’s domain identity, its WebPKI certificate, or any other identifier the called party might use to evaluate trust in the bank as an entity. This is a missing layer for the post-attestation display layer to anchor on.

These gaps motivate the next-generation work.

Where this is heading: VESPER

VESPER is an IETF draft I’m authoring that extends the delegate-certificate model to address all three gaps above. The full treatment is in VESPER; this section sketches the connection to the delegate-cert thread.

VESPER defines a delegate-certificate profile that brings three trust elements into a single auditable artifact. The TNAuthList extension carries telephone-number authority entries, optionally alongside service-provider-code (SPC) entries identifying the originating providers authorized to place calls from those numbers. A SubjectAltName carries the responsible entity’s internet domain, providing a corroborating identity signal grounded in WebPKI. An embedded Signed Certificate Timestamp proves the certificate was recorded in a public transparency log before use. Standard PASSporTs (RFC 8225) signed by the certificate carry the assertions on the wire — there’s no new VESPER-specific PASSporT claim; the certificate itself is what makes the assertion verifiable beyond the standard STIR model.

Three things VESPER addresses for the delegate-cert thread specifically:

RTU establishment with explicit roles. VESPER defines a Right-to-Use (RTU) Authority role — typically a TNSP or RespOrg — that issues a TNAuthList Authority Token as verifiable RTU evidence. The STI Certification Authority validates the token before issuing the delegate certificate. The RTU evidence becomes on-the-wire rather than a buried business-process matter, with the issuance flow grounded in the ACME authority-token mechanism specified in RFC 9447 and RFC 9448.

Certificate transparency. VESPER requires every delegate certificate to be submitted to a STIR certificate transparency log, with the resulting SCT embedded in the certificate before deployment. Verifiers validate the embedded SCT as part of certificate validation. This brings WebPKI-style public visibility to the STIR certificate ecosystem, making misissuance detectable rather than invisible.

Domain corroboration. The SubjectAltName dNSName in the delegate certificate carries the entity’s domain. The certificate must be published at a stable HTTPS location under that domain, with the hosting server’s TLS certificate matching the same domain. A verifier confirms the domain in the PASSporT’s x5u URL matches the certificate’s SubjectAltName as part of verification, providing proof of domain control independent of the telephone-number ecosystem. When two trust chains — STI right-to-use and WebPKI domain control — independently point to the same entity, the combined signal is substantially stronger than either alone.

VESPER doesn’t replace RFC 9060 or ATIS-1000092 — it builds on them, treating them as the substrate. A VESPER-aware verifier still validates the delegate-cert chain in the standard way; the VESPER additions (the SubjectAltName dNSName, the embedded SCT, optional SPC entries for originating-provider authorization, the required x5c and x5u PASSporT headers) are layered on the same X.509 mechanism. The result is a profile that addresses the gaps without disturbing the deployed base.

Where this fits

Delegate certificates sit at the architectural seam between the clean trust-framework model and the operational reality of how calls actually originate. The mechanism is a partial answer to the customer-of-customer problem; ATIS-1000092 is the operational profile that makes it deployable; VESPER is the active research direction that extends it.

For most calls in current SHAKEN deployment, delegate certificates are still the exception rather than the norm — most originating providers sign their own calls directly. But as enterprise adoption grows and as the framework’s enforcement leverage settles at the OSP cert-identity level (see attestation levels), the delegate-cert mechanism is becoming structurally more important. The party doing the actual signing increasingly needs to be the party with the actual authority, and delegate certificates are how that gets done.