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

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

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.

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.

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

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.

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

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.

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