1. Calling Party Identity
Douglas Ranalli
Founder, Chief Strategy Officer
NetNumber, Inc.
Calling Party Identity
Enhancing SHAKEN attestation and verification with optional calling-party Identity-Header with RCD PASSPorT

2. Problem Statement
Baseline SHAKEN/STIR doesn’t support complex enterprise call-origination scenarios

3. High Level Objectives
First-Class Treatment for Enterprises: Give the industry a tool within the SHAKEN framework to help enterprise customers with complex calling use-cases to achieve A-Level attestation.
Enterprise Defined Call Information: Enable enterprise customers with complex use-cases to define their preferred calling-name display.
Keep it simple: Start with the smallest possible addition to the SHAKEN framework to enable the industry to begin working on complex enterprise call origination use-cases.
Enable Competition: Empower enterprises and service providers to choose who they trust without trying to “pick one solution” for everyone.

4. Underlying Principles
Enterprise Pays: Enterprises should pay the cost of full participation in the SHAKEN framework. Aligns cost with benefits.
Competitive Options: If we expect the enterprise to pay, then the solution should support competitive alternatives, from which the paying customer can choose.
SP Controls TNs: SPs retain control over allocation and use of TN resources.
SP Controls STI-AS Policy: SPs control who to trust when attesting to a call.
Implementation Options: Each SP and each Enterprise can decide to manage certs and sign calls on their own or outsource to any number of solution providers.

5. Proposal Summary
Add support in SHAKEN framework for optional ”additional” identity header signed by the calling-party.
Calling-party identity header provides information to Originating-SP that optionally informs local policy attestation.
No change to role defined for Originating-SP
Calling-party identity header with rcd PASSPorT provides additional information to Terminating-SPs that optionally informs analytics and CVT functions.
No change to roles defined for Terminating-SP

6. Why Additional Identity-Header?
RFC 8224 already defines support for multiple identity-headers.
No new standardization required.
911 Calling scenarios likely to use additional signed identity-header with “rph” PASSPorT as per RFC 8443.
Optional calling-party identity header adds to the baseline SHAKEN framework without changing the framework.
Simple tool that the industry can use to begin working on enterprise use cases today.

7. Why Service-Provider Delegated Certificates?
RFC 8226 already defines role of delegated-certificates
For TNs, Number-Blocks or for SPCs – anything allowed in TNAuthList
Service-Provider is the regulated entity within SHAKEN framework that is responsible for TN assignment.
Baseline SHAKEN A-Level attestation assumes Originating-SP is TN-Provider
Service Provider that issued the TN provides valuable ”check and balance” within the SHAKEN framework
SP can revoke certificate when TN assignment is changed.
SP can revoke certificate when TN is used inappropriately.
Issued certificates can be audited at the STI-CR to ensure validity of delegation

8. Proposal Advantages No new standardization required
RFC 8224 supports multiple identity headers
RFC 8226 supports TN/block level delegated certificates
No change to SHAKEN framework entities or roles
Calling party signature is optional tool that informs STI-AS and CVT functions
Simple, but powerful, incremental enhancement that enables industry to begin innovating to address complex enterprise use-cases
Each Service Provider retains control over who they trust to validate enterprise callers while benefiting from competitive options.

9. Implementation Proposal
New ATIS Document: “Calling-Party Identity to inform SHAKEN STI-AS and STI-VS services”
Start with a simple first step – define option for calling-party to add a signed identity header
Let the market get started with PoC activities so we can all begin learning.
Evaluate further enhancements to the SHAKEN framework (if needed) based on learning