1. 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

2. 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.

3. 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)

4. 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

5. 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

6. 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.

7. 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

8. 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?

9. 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

10. 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

11. 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

12. 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