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: [email protected]
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:
1. The terminating network (processing of STIR/SHAKEN information),
2. The CVT- Call Validation Treatment, or analytics providers, and
3. 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
• Verify signature in
Identity header
• Determine if call is
to be completed
• Tel-URI in PAI or
From header
Terminating
Network
CVT (analytics)
• Optional function - either
in carrier AS or 3rd party
• Use analytics &
reputation data sources
• Use verstat values
• Translate analytics for lay
person
• Verified calling
number
• Enhanced Name
with additional
Caller info
• Info includes level of
trust + analytics (if
available)
UE
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