Re: [stir] Questions about stir-certificates

+1 .. I sat in those meetings with the FTC as did Martin Dolly and Chris Wendt. This is my point that the regulators do have ligitmate concerns but are willing to be helpful without being prescriptive.  As a additional note I also recently met with the FCC folks including brother Eric Burger and they had similar concerns.  

That said we will may see some further regulatory action in the 17-97 FCC docket within 90 days or so.  Right now the industry is digesting the implications of National Number Portability which is REALLY going to have a profound effect on US call routing. 

On 10/23/17, 2:37 PM, "stir on behalf of Gorman, Pierce A [CTO]" <stir-bounces@ietf.org on behalf of Pierce.Gorman@sprint.com> wrote:

    Paul,

    There's a letter from Janice Kopec at the Federal Trade Commission (filed as ATIS document "IPNNI-2017-00106R000.pdf") to Tom Goode, General Counsel for ATIS, where the FTC staff provided feedback and guidelines for developing SHAKEN/STIR Caller Validation Display that may provide helpful context around some of the remarks in the discussion.

    A few of the FTC comments were:

    * Design fallbacks (e.g., when technology fails or is not available for some users, how does the system react and what is communicated)

    * Warnings need to be accurate , or else users will get habituated and ignore them

    * What do full, partial, and gateway attestation translate to in plain language?

    * What are carriers able to vouch for with those data points, and with what level of confidence?  Need consistent interpretation of levels of validation.

    * How will carriers handle calls at each level of attestation, when calls fail attestation, and when attestation is absent?

    *Clearly differentiate between information about the caller ID and information about the content of the call.  Just because a call is authenticated doesn't mean the content of the call can be trusted.

    Remember that SHAKEN attestion doesn't provide anything with respect to call content and intent.  And, robocalling and spoofed caller ID are not illegal.  They're used by government agencies and charities too, not just bad actors.

    Call processing systems have a large variety of information presented to them from protocols designed by committees and interpeted by commercial programmers operating under challenging timelines and with limited resources.  Creating a stable consistent experience several millions of times a day will not be a quick achievement.  IMHO, application of SHAKEN/STIR will be permissive in the early stages, and really needs to be married to outboard analytics which look at things like network calling patterns and permit/deny lists in order to be able to render more reliable judgements to the network (or a client application) with respect to relative trustworthy-ness of a call attempt.

    -----Original Message-----
    From: Richard Shockey [mailto:richard@shockey.us]
    Sent: Monday, October 23, 2017 11:28 AM
    To: Paul Kyzivat <pkyzivat@alum.mit.edu>; Chris Wendt <chris-ietf@chriswendt.net>
    Cc: stir@ietf.org; Gorman, Pierce A [CTO] <Pierce.Gorman@sprint.com>
    Subject: Re: [stir] Questions about stir-certificates

    For suitably smart devices (e.g. mobile phones) I would hope that
        various apps and configuration options for those apps can provide the UI
        to users. Then app providers can compete on who does it better and users
        can choose. And these can evolve over time as the uptake on the signing
        increases. Maybe this is what you mean by Call Analytics apps.

        It would be bad if all of this gets locked up in the FCC regulatory regime.

    RS> Paul I don’t think this is going to get locked up in a FCC/FTC OFCOM CRTC like regime but the regulators do have legitimate concerns on consistency. The regulators have actually been quite helpful here. They are willing to eventually help with consumer education if the framework for display options is simple, and I also believe there are excellent opportunities for service providers to add value.   Sometimes choice is bad and confusing the consumer with different forms of UX could cause its own problems.  Its still early.

    ________________________________

    This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.
    _______________________________________________
    stir mailing list
    stir@ietf.org
    https://www.ietf.org/mailman/listinfo/stir