TITLE: Contribution on Display Guidelines ATIS PTSC Virtual Meeting June 19, 2017 Contribution TITLE: Contribution on Display Guidelines SOURCE*: Hala Mowafy (Ericsson) and Jonathan Nelson (Hiya) _______________________________ Abstract   This presentation aims to progress discussion on the components of the display framework to help develop display guidelines. NOTICE This contribution has been prepared to assist the ATIS PTSC. This document is offered to the Committee as a basis for discussion and is not a binding agreement on Ericsson or any other company. The requirements are subject to change in form and numerical value after more study. Ericsson specifically reserves the right to add to, or withdraw, the statements contained CONTACT: Hala Mowafy email: hala.mowafy@ericsson.com

Purpose Identify the elements that ultimately determine what is displayed to IP customers. List minimum requirements and recommendations for each element. Discuss human factors considerations that could optimize the display. Include ADA considerations. Discuss role of carriers, OEMs and Analytics providers. Outline potential future enhancements to the proposed display.

Main Elements The three main elements that shape what gets displayed to the user are: The terminating network (processing of STIR/SHAKEN information), The CVT- Call Validation Treatment, or analytics providers, and The UE The Display is composed of multiple sets of data, mainly A Calling Number The Name from CNAM/eCNAM Additional eCNAM identity information (profile details) The trust in the calling TN (verstat translation) The call purpose (signaled/ queried/ deduced from CVT)

Main Elements CVT (analytics) Terminating Network UE Verify signature in Identity header Determine if call is to be completed Tel-URI in PAI or From header Terminating Network Optional function - either in carrier AS or 3rd party Use analytics & reputation data sources Use verstat values Translate analytics for lay person CVT (analytics) Verified calling number Enhanced Name with additional Caller info Info includes level of trust + analytics (if available) UE Main Elements

Min requirements - Network After validating the certificate, the terminating network shall make the following available to the CVT to process as part of its analytics The tel URI parameter containing the TN and the verstat values Data retrieved from queries by the terminating network (arrangements could be in place to relay the query results to the CVT for added value to the analytics) If the final results are not delivered directly from the CVT to the UE, the terminating network (AS or S-CSCF) shall deliver the results to the UE via eCNAM The interface between the CVT and the terminating network – tbd (ISC or proprietary?) The interface between the terminating network and UE - eCNAM

Min requirements - CVT The CVT analyzes the level of risk associated with the call, based on: Information from the network (verified calling number, queried data, etc.) Information from black/whitelist databases, reputation db, listing databases, etc. The CVT will consider verstat when deciding risk level: Verstat failed: determine spoof probability, provide warning and analytics Verstat inconclusive or passed: standard CVT analytics CVT will accommodate individual carrier policies in addition to the minimum requirements.

Min requirements - UE The UE shall Support 3GPP TS 24.XXX, 29.XXX to support receipt of verstat. Support eCNAM according to ATIS and 3GPP standards. The message delivered to the customer will be: a combination of (1) verstat attestation, and (2) the results of CVT analytics easy to comprehend message (symbols, text, etc.) of the incoming call’s intent Bundled into eCNAM data (client is not expected to interpret verstat directly) CVT integration into eCNAM fields minimizes client integration work CVT & any verstat UI to be incorporated into eCNAM

Min requirements - UE 1 2 3 4 5 1&2. Verstat passed + optional analytics subscription = TN, name, eCNAM w/analytics statement 3. Verstat inconclusive = TN, name, only analytics delivered in eCNAM 4&5. Verstat failed = TN yes/no?, no name, spoof warning and other analytics details Is there agreement on this proposal?

Human factors – what matters? What matters to the consumer on that display? Remember: Attestation does not mean anything to the consumer. Attestation is for the service provider’s use to trace back and pursue bad actors Verified identity signals (green checkmark) likely to be confusing Should be the vast majority of calls, when adoption becomes widespread Significance of the green check’s presence/absence will likely be lost on the user Also, the green check’s positive signal may sometimes conflict with negative signals from analytics Focus on binary warning system to user; a warning is warranted, or it’s not. Gray areas of uncertainty are just as unclear to users as to the system Prior and future usability studies to be compiled to test these assumptions

ADA Compliance ADA iOS and Android accessibility features are available but still evolving (e.g., no Braille keyboard). The following is supported: Display customization Speech (read display text, symbols, different languages, ) so “text” and not just symbols may be necessary for ADA compliance. Color matters If the application relies heavily on red and green to convey, there needs to be an alternative way to indicate what colors they are (state it) Ensure error messages based on red and green are understood correctly Consider audio announcements for the visually impaired when the call is answered. A delay in completing the call should be permissible while an audio message is played relaying results of verstat+analytics Interactive Voice: to support responses from blind users to accept or reject call

Ongoing Monitoring Assessing the risk on incoming calls is an evolving and learning process that will continuously reshape the analytics. Does verstat failure always equal spoofing? Launch assumption allows for valid failure cases; CVT or other intelligence makes final spoof decision Need to monitor situations and frequency of verstat failure to adjust analytics logic End goal: verstat failure + simple logic validation is definitive for malicious spoofing Significance of inconclusive attestation? Frequency should decrease as adoption widens Significance of inconclusive attestation likely to change Monitor frequency of inconclusive states. Encourage use of CVT services to detect and warn against potential bad actors

Future enhancements UE, CVT and Network to support interactive features Example: user could press a button to “request” more data about the call The return code 607 could trigger queries for more data, instead of a passive “unwanted” indication Service provider could offer a menu of data elements to choose from on the screen Possible pay-per-use