Draft Proposal — Version 0.3 Status: Early-stage conceptual proposal for discussion License: Creative Commons Attribution 4.0 International (CC BY 4.0)
Modern telephone networks lack a cryptographic mechanism to verify the true origin of a call. This document proposes the Telecommunications Identity Layer (TIL): a federated Public Key Infrastructure (PKI) framework that binds telephone numbers to cryptographically verifiable identity certificates issued by trusted authorities. TIL extends existing systems such as STIR/SHAKEN and SIP Identity to provide entity-level verification, consistent end-user trust signals, and backward compatibility with legacy PSTN infrastructure. This document is intended for discussion and does not represent a standard or implementation commitment.
- Problem Statement
- Core Idea
- System Overview
- Call Flow
- Relation to Existing Work
- Threat Model
- Goals and Non-Goals
- Open Questions
- Security Considerations
- Motivation
- Status of this Document
Modern telephone systems do not provide a reliable mechanism to verify the true origin of a call. As a result:
- Caller ID spoofing is trivial to execute at both SIP and SS7 layers
- Robocalls and scam calls are widespread, causing significant economic and social harm
- Users cannot reliably distinguish legitimate institutions (banks, government entities) from attackers impersonating them
- Telephone calls are routinely weaponized for social engineering attacks
Existing mitigations — most notably STIR/SHAKEN — reduce certain classes of spoofing but fall short of a comprehensive solution:
- Deployment is not global or uniform across all carriers and jurisdictions
- They provide call origin attestation, not entity-level identity verification
- They do not define consistent end-user trust semantics across network boundaries
TIL introduces a federated cryptographic identity layer for telephone numbers. Each telephone number is bound to a cryptographically verifiable identity certificate issued by a trusted authority — a Telecommunications Infrastructure Provider (TIP) — within a federated PKI hierarchy.
In simplified form:
Phone Number → Cryptographic Identity Certificate → Verified Entity
This binding allows any receiving party to verify the identity of the calling entity, regardless of the underlying network path, in a manner analogous to how HTTPS certificates verify website identity.
TIL is based on a federated PKI model adapted to telecommunications constraints.
TIL defines three layers of trust:
graph TD
R["🏛️ Root Trust Authority (RTA)"]
R --> T1["📡 Telecom Provider A (TIP)"]
R --> T2["📡 Telecom Provider B (TIP)"]
R --> T3["📡 Telecom Provider C (TIP)"]
T1 --> E1["🏦 Bank — Certificate"]
T1 --> E2["🏥 Hospital — Certificate"]
T2 --> E3["🏛️ Government Agency — Certificate"]
T2 --> E4["🏢 Enterprise — Certificate"]
T3 --> E5["👤 Verified Individual — Certificate"]
style R fill:#1a1a2e,color:#fff,stroke:#4a90d9
style T1 fill:#16213e,color:#fff,stroke:#4a90d9
style T2 fill:#16213e,color:#fff,stroke:#4a90d9
style T3 fill:#16213e,color:#fff,stroke:#4a90d9
| Layer | Role |
|---|---|
| Root Trust Authorities (RTA) | Federated governance entities; anchor of the trust chain |
| Telecommunications Infrastructure Providers (TIP) | Act as Certificate Authorities; issue and manage end-entity certificates |
| End Entities | Organizations or individuals owning one or more telephone numbers |
Each TIL certificate binds the following fields:
| Field | Description |
|---|---|
phoneNumbers |
One or more E.164-formatted telephone numbers |
entityIdentity |
Organization name or verified individual identity |
issuingTIP |
Identifier of the issuing Telecommunications Infrastructure Provider |
publicKey |
Public key for signature verification |
validityPeriod |
notBefore / notAfter timestamps |
revocationEndpoint |
URL or reference for revocation status checks (OCSP/CRL) |
certLevel |
Certificate assurance level (e.g., domain, organization, individual) |
A conceptual certificate structure:
TILCertificate {
version: 2
serialNumber: <unique identifier>
issuer: <TIP distinguished name>
validity: { notBefore, notAfter }
subject: { entityName, entityType }
phoneNumbers: ["+1-800-555-0100", "+1-800-555-0101"]
publicKey: <public key>
extensions: {
certLevel: "organization"
revocation: <OCSP endpoint>
}
signature: <TIP signature>
}
Unlike domain names — which are stable, globally unique, and managed through a
single registrar per name — telephone numbers are fluid resources. They are
reassigned after deactivation, ported between carriers, sub-allocated to
resellers, and leased for temporary use. This makes the phoneNumber → entity
binding the single hardest problem in TIL, and arguably the one that determines
whether the entire framework is viable.
A TIL certificate is therefore only as trustworthy as the authority of the issuing TIP over the number at the moment of issuance, combined with the speed at which that binding is invalidated when ownership changes. Two mechanisms are required:
| Mechanism | Purpose |
|---|---|
| Authoritative ownership check at issuance | The issuing TIP must confirm, against the carrier of record, that the subject genuinely controls the number now — not merely that it once did. |
| Ownership-change revocation triggers | Number portability, deactivation, and reassignment events must automatically revoke or suspend the associated certificate, ideally driven by the same porting and numbering databases carriers already operate. |
This binds TIL's trust model directly to existing numbering administration (e.g., national number portability databases and carrier-of-record registries) rather than treating ownership as a static, one-time attribute. Certificate validity periods should be short relative to the frequency of number churn, and revocation propagation (Open Question 2) is a hard requirement here, not an optimization.
The following diagram illustrates the end-to-end identity verification flow between Telecommunications Infrastructure Providers.
flowchart LR
A["📞 Caller"] --> B["Originating TIP"]
B --> C["Attach Cryptographic\nSignature + Certificate"]
C --> D["Interconnection\nNetwork"]
D --> E["Receiving TIP"]
E --> F["Verify Identity\nChain"]
F --> G["User Device"]
G --> H{"Trust Status"}
H -->|"✅ Verified"| I["Verified Entity\n(Bank, Gov, Org)"]
H -->|"⚠️ Unverified"| J["Unverified Caller"]
H -->|"🚫 Invalid"| K["No Attestation /\nSuspicious Origin"]
| Status | Meaning | User Signal |
|---|---|---|
| ✅ Verified Entity | Certificate valid, chain verified, number matches | Display entity name and badge |
| No TIL certificate present | Standard caller ID, no badge | |
| 🚫 Invalid / Suspicious | Certificate invalid, revoked, or number mismatch | Warning indicator |
TIL extends, rather than replaces, existing standards and frameworks.
| System | Scope | Deployment Status | Limitation |
|---|---|---|---|
| STIR/SHAKEN | Call origin attestation at carrier level | Partial (US, CA, some EU) | Limited entity identity model; not globally deployed |
| SIP Identity (RFC 8224) | Cryptographic identity in SIP signaling | Limited | Scoped to SIP; no federated entity registry |
| X.509 / PKI | General-purpose certificate infrastructure | Widespread (HTTPS) | Not adapted to telephony number binding |
| TIL (this proposal) | Entity-bound cryptographic identity for phone numbers | Proposed | Requires federated adoption |
TIL draws on the proven trust model of X.509 PKI, the telephony integration work of STIR/SHAKEN, and the SIP-layer identity mechanisms of RFC 8224, combining them into a unified, entity-centric framework.
STIR/SHAKEN already provides a hierarchical PKI (policy administrator → certification authorities → providers) and, through Rich Call Data (RCD) and branded-calling efforts, is moving toward displaying a verified caller name and logo. A fair reviewer will ask: why is TIL not just STIR/SHAKEN + RCD under new names? The honest answer is that most of TIL's building blocks are not new — its contribution is in three specific gaps that current deployments leave open:
-
Attestation of origin vs. binding of identity. STIR/SHAKEN attests which provider originated a call and its level of confidence that the caller is authorized to use the number. It does not, on its own, assert a verified entity identity bound to that number across provider boundaries. RCD carries display data, but the assurance level behind that data — how the name was vetted — is not consistently defined or audited. TIL's
certLeveland end-entity certificates target exactly this gap. -
A federated entity registry with consistent assurance levels. STIR/SHAKEN has no cross-provider notion of "this is an
organization-assurance identity, vetted to a defined standard." TIL proposes that shared assurance vocabulary and the transparency/audit mechanisms (§9) to make it verifiable. -
Consistent, carrier-independent end-user trust semantics. Today the trust signal a user sees depends on their carrier and handset. TIL's contribution is less a new cryptographic primitive than a standardized trust-outcome model (§4) that is the same regardless of network path.
In short, TIL should be read as a profile and governance layer on top of the existing STIR/SHAKEN + RCD machinery, not a competing PKI. Where the two overlap, TIL should defer to and reuse the deployed standards; its value is concentrated in entity-level assurance, federation, and uniform user semantics.
TIL assumes adversaries capable of:
- Caller ID spoofing at SIP or SS7 layers
- Operating compromised or malicious VoIP providers
- Conducting social engineering using legitimate-looking numbers
- Manipulating inter-provider signaling
TIL does not assume:
- Total compromise of all Root Trust Authorities simultaneously
- Universal non-cooperation among all Telecommunications Infrastructure Providers
| Attack Vector | TIL Mitigation |
|---|---|
| Caller ID spoofing | Certificate binds number to verified entity; mismatch is detectable |
| Compromised VoIP provider | Federated trust limits blast radius; revocation mechanisms apply |
| Stolen/misused valid certificate | Revocation propagation; certificate pinning options |
| SS7 interception/manipulation | The signature protects the integrity of the signed content, so tampering is detectable wherever the attestation is carried. However, TIL requires a transport channel for the certificate and signature (e.g., SIP signaling); pure SS7/PSTN legacy paths that cannot carry the attestation fall back to the Unverified outcome rather than being protected. TIL raises the cost of spoofing on interworked paths but does not secure calls that never traverse a TIL-capable segment. |
| Social engineering via verified number | TIL verifies identity, not intent; behavioral legitimacy is a non-goal |
- Cryptographically verifiable caller identity bound to telephone numbers
- Federated trust model across Telecommunications Infrastructure Providers
- Backward compatibility with legacy PSTN systems during incremental rollout
- Clear, consistent end-user trust signals independent of carrier
- Incremental deployment path without requiring simultaneous global adoption
- Eliminating all spam or unwanted calls (TIL verifies identity, not intent)
- Centralizing global telecommunications governance under a single authority
- Guaranteeing behavioral legitimacy of verified entities
- Replacing existing telephony infrastructure (PSTN, SIP, SS7)
The following questions require further analysis and community input:
- Governance model — How are Root Trust Authorities selected, audited, and removed? What international body or federated consortium governs them?
- Revocation propagation — How is certificate revocation propagated in near-real-time across a global, federated network without becoming a bottleneck?
- Privacy-preserving identity — How can entity identity be verified without exposing sensitive personal data, particularly for individual (non-organizational) certificates?
- Legacy PSTN integration — What is the integration path for carriers and devices that do not support TIL natively?
- Economic incentives and regulatory dependence — What incentivizes Telecommunications Infrastructure Providers to adopt and enforce TIL, particularly in markets without regulatory pressure? History suggests this, not cryptography, is the binding constraint: STIR/SHAKEN saw meaningful deployment in the United States largely because it was mandated (TRACED Act / FCC rules), not because carriers adopted it voluntarily. TIL should therefore be understood as requiring a regulatory or strong-consortium forcing function to reach critical mass; a purely technical proposal without an adoption mechanism is unlikely to move the market on its own.
- Certificate assurance levels — How are different levels of identity verification (domain, organization, individual) defined and audited in a telephony context?
| Risk | Description |
|---|---|
| Root/intermediate CA compromise | Compromise of a trust anchor could allow fraudulent certificates to be issued |
| Certificate misuse | A legitimately issued certificate could be used for malicious purposes |
| Privacy exposure | Certificate metadata could be used to track entities or individuals |
| Regulatory misuse | Governments could compel TIPs to issue false certificates or revoke legitimate ones |
- Federated trust model limits the impact of any single authority compromise
- Revocation mechanisms (OCSP, CRL) allow timely invalidation of compromised certificates
- Minimal identity disclosure — certificates should expose only the information necessary for trust decisions
- Transparency logs (analogous to Certificate Transparency for HTTPS) to provide auditability of certificate issuance
Certificates for individual-assurance subjects bind a real-world personal
identity to a phone number and to every call placed from it. This is
simultaneously the strongest surveillance risk (§9) and the strongest magnet for
regulatory compulsion, while offering the least immediate anti-fraud value —
most high-impact impersonation targets banks, government agencies, and other
organizations, not private individuals.
We therefore recommend that early phases of TIL scope individual certificates
out, focusing exclusively on organization-level assurance where the identity
being disclosed is already public and the fraud-reduction benefit is highest.
Individual identity — if pursued at all — should be treated as a later,
privacy-preserving extension (e.g., selective-disclosure or zero-knowledge
proofs of a claim without revealing the underlying identity), not a v1 feature.
Telephone communication remains one of the primary channels for high-trust interactions — banking, healthcare, emergency services, government communications — yet it is the only major communication medium that lacks a cryptographic identity layer.
This structural gap enables large-scale fraud that cannot be meaningfully mitigated with superficial measures. Addressing it requires systemic redesign at the infrastructure level, in a manner analogous to the transition from HTTP to HTTPS: incremental, federated, and driven by clear trust signals to end users.
TIL is a proposal toward that goal.
This is an early-stage conceptual proposal in the style of an IETF Internet-Draft, intended to stimulate discussion among telecommunications engineers, standards bodies, and policymakers.
It does not represent a finalized standard, an implementation commitment, or an official position of any organization.
Feedback and contributions are welcome.
This is an early-stage proposal. Feedback, criticism, and contributions are welcome. Open a GitHub Discussion for general feedback or specific technical concerns.
Creative Commons Attribution 4.0 International (CC BY 4.0)