A STIR/SHAKEN certificate does not begin with a simple request to a Certificate Authority. Before a telecom provider can obtain the certificate it must establish its eligibility and demonstrate the authorization required by the STIR/SHAKEN framework.
Two important elements in this process are the Operating Company Number (OCN) and the Service Provider Code (SPC) token. They serve different purposes: the OCN identifies the telecom service provider while the SPC token helps establish that the provider is authorized to request a certificate through the relevant issuance workflow.
For telecom operators implementing caller authentication these details matter because certificate issuance depends on more than cryptographic technology. It also depends on the authorization framework connecting the service provider, the STI Policy Administrator and the STI Certificate Authority.
Peeringhub supports STIR/SHAKEN certificate issuance through its Certificate Authority services, ACME-based workflows and developer APIs. Understanding how OCNs and SPC tokens fit into that process helps providers prepare for certificate enrollment and avoid preventable configuration issues.
1. What Is an OCN and Why Does It Matter?
Identifying the Telecom Service Provider
An Operating Company Number (OCN) is an identifier associated with a telecommunications operating company. Within the STIR/SHAKEN certificate process, it helps identify the service provider seeking authorization to participate in the framework.
Before obtaining a STIR/SHAKEN certificate through Peeringhub, a provider must have its own OCN and approved STIR/SHAKEN Service Provider status from the STI Policy Administrator. Peeringhub's documentation explains that an eligible provider's OCN is whitelisted for certificate issuance after completing the subscription process.
The OCN is therefore an important part of establishing the provider's eligibility. It is not itself a certificate or a cryptographic signature.
A Practical Example
Imagine a regional voice carrier preparing to authenticate outbound calls. Before it can request its STIR/SHAKEN certificate, it must establish its identity and complete the required authorization process.
Think of the OCN as an organization's identifying reference in that process. It helps connect the certificate request to the service provider seeking authorization.
However, having an OCN alone does not automatically authorize a provider to obtain a STIR/SHAKEN certificate. The relevant Policy Administrator approval and Certificate Authority requirements must also be satisfied.
2. What Is an SPC Token?
Proof of Authorization for Certificate Requests
An SPC token, or Service Provider Code token, is an authorization token issued through the STI Policy Administrator process. It helps establish that a service provider has been approved to request STIR/SHAKEN certificates.
The token can contain service-provider identification information, such as an OCN or SPID, depending on the applicable workflow. In an ACME-based issuance process it can also be associated with proof that the requester controls the relevant ACME account key.
TransNexus describes the traditional process as requiring the provider to obtain an SPC token from the Policy Administrator and submit it as part of its certificate request to the CA. The CA then evaluates the request before issuing the certificate.
Why the Token Matters
A Certificate Authority should not issue STIR/SHAKEN certificates to an organization whose authorization has not been established.
The SPC token helps connect the provider's approved status to the certificate issuance process.
A useful way to distinguish the two concepts is:
OCN: Identifies the telecom operating company.
SPC token: Helps demonstrate the service provider's authorization to request a certificate.
STI-CA: Processes the certificate request and issues the certificate when the applicable requirements are met.
These elements work together but serve different functions.
3. How OCN and SPC Tokens Work Together
From Provider Authorization to Certificate Issuance
The overall process connects the service provider's identity with its authorization and certificate request.
Step 1: Establish provider identity
The telecom provider has its OCN and completes the required registration process.
Step 2: Obtain authorization
The STI-PA reviews the provider and establishes its eligibility within the framework.
Step 3: Complete the token or ACME authorization workflow
The applicable process supplies the required authorization evidence for the certificate request.
Step 4: Request the certificate
The CA processes the request and issues the certificate if the required checks succeed.
The exact token exchange varies according to the CA's implementation. In Peeringhub's documented web workflow, users provide their STI-PA credentials when generating a certificate. Its ACME workflow provides another route for certificate issuance.
What Happens If Something Is Missing?
If the provider's STI-PA credentials are invalid or its authorization is incomplete, certificate generation may fail. Peeringhub explicitly warns that invalid STI-PA credentials prevent certificate generation through its web interface.
This is why providers should confirm their authorization status before troubleshooting keys, certificate requests or deployment settings.
4. Where Peeringhub Fits Into the Process
Certificate Issuance Through Web and API Workflows
Peeringhub operates a STIR/SHAKEN Certificate Authority service designed to help eligible voice providers obtain certificates.
Its documented options include a web portal and developer APIs. The API workflow consists of generating an authentication token, creating a private key and requesting a STIR/SHAKEN certificate.
The platform also operates an STI-ACME service that it identifies as compliant with RFC 8555. After completing the subscription process, an eligible provider's OCN is whitelisted for certificate issuance through the ACME server.
This approach helps providers integrate certificate issuance into their operational processes instead of relying exclusively on manual administration.
Why Automation Helps
Consider a provider that needs to repeat certificate operations as part of its normal infrastructure management. A programmatic workflow can make those operations more repeatable and reduce the need to manually complete every step.
Peeringhub's API documentation describes endpoints for generating private keys and requesting certificates. Its certificate-generation response includes the certificate repository path and certificate validity information.
The key benefit is a more structured certificate workflow, not the removal of authorization requirements.
5. Peeringhub vs. TransNexus: Comparing Certificate Workflows
Both Peeringhub and TransNexus provide STIR/SHAKEN Certificate Authority services. The distinction for providers evaluating them lies in their documented workflows and the broader capabilities they need.
Peeringhub
ACME and API-oriented certificate operations
STI-ACME service described as RFC 8555 compliant
Web-based certificate generation
API workflows for private-key and certificate generation
Certificate repository hosting
TransNexus
Certificate issuance and broader STIR/SHAKEN capabilities
Certificate requests through a web interface or REST API
Certificate repository hosting
SPC token submission in its documented enrollment process
Additional products for authentication, verification and call analytics
These are overlapping services rather than identical implementations. TransNexus documents an SPC-token submission workflow while Peeringhub documents both STI-PA credential-based certificate generation and ACME-based issuance.
Providers should evaluate the exact workflow, integration requirements and operational scope of each service rather than assume every CA handles authorization tokens in precisely the same way.
6. Common Mistakes to Avoid During Certificate Enrollment
Treat Authorization and Cryptographic Setup as Separate Checks
OCN and SPC token issues are not the same as private-key or certificate deployment issues. Troubleshooting is more efficient when these areas are checked separately.
Before requesting a certificate, providers should confirm:
The correct OCN is associated with their service provider registration.
Their STI-PA approval is active and the required credentials are valid.
They are following the token or authorization procedure required by their chosen CA.
The correct private key is selected for certificate generation.
The certificate is successfully issued and its repository URL is recorded.
The private key is protected and the certificate is deployed correctly.
Peeringhub's documentation provides separate guides for private-key generation, certificate issuance and ACME client configuration. Following the workflow for the selected method helps avoid mixing steps from different issuance procedures.
Conclusion: Identity and Authorization Come Before Certificate Issuance
OCNs and SPC tokens serve complementary roles in the STIR/SHAKEN certificate process. The OCN identifies the telecom operating company while the SPC token helps establish the provider's authorization to request a certificate. Together with the STI-PA approval process and the Certificate Authority's issuance checks they help maintain the integrity of the STIR/SHAKEN trust framework.
For telecom providers the practical lesson is clear: confirm eligibility and authorization first then follow the correct certificate issuance workflow.
Peeringhub supports this process through its STIR/SHAKEN CA service, web portal, ACME infrastructure and developer APIs. If your team is preparing for STIR/SHAKEN or looking to streamline certificate enrollment, explore the platform and its technical documentation.
Explore Peeringhub: www.peeringhub.io!
Post a Comment