Re: [cnit] [stir] Reputation vs Display name (was Textual caller ID)

[Henning Schulzrinne <[e-mail]>]

I suspect we all agree that this would be optional, by everybody. (In other words, end users and carriers should be able to decide *not* to do this.)

Given the much larger number of legitimate carriers than Experian/D&B-style third-party databases, I tend to agree with you that a simple declaration of fact ("user-asserted", "billing record", "service address") is likely to be more useful than a score. I don't see how any non-zero score presented by carrier A would be comparable to that by carrier B, even assuming both are of the most upstanding kind with no interest in score inflation.

For the small number of large third-party databases, this will likely be somewhat like credit scores - the number itself doesn't measure anything in particular (not meters, not total debt), but recipients will associate certain values with their risk tolerance. ("If we get a TrustUs score below 39, we don't believe the caller ID. For Neustar, we cut off at 52.")

Some carriers may want to offer value-added services, where they attach a third-party assertion to business-originated calls. ("This call came from General Motors, claimed by TrustUs Business Directory to be located in Detroit, MI and in the automotive business.") It is logistically much easier for a large carrier to get a dip agreement for a third-party database such as the business databases I've been using as examples than for the recipient.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Alex Bobotek
Sent: Wednesday, August 28, 2013 2:16 PM
To: Brian Rosen; Paul Kyzivat
Cc: [e-mail]
Subject: Re: [cnit] [stir] Reputation vs Display name (was Textual caller ID)

I support the notion of _permitting_ an originating service provider to present the strength of their subscriber authentication (e.g., drivers license presented, no auth, etc.) or other indicators of trust.  But asking an originating service provider to generate and attach a score of its own customers is problematic from a business perspective.  What, short of regulation, would motivate competing service providers to attach anything but a stellar score?  

Scoring should be adding in signaling transit and/or added at the terminating end.  

Terminating service providers are unlikely to value scores calculated using a formula that allows the originating service provider to inject unwarranted trust.  

Most of reputation assessment should be performed by a party other than the originating service provider.  

Regards,

Alex

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Brian Rosen
Sent: Wednesday, August 28, 2013 6:53 AM
To: Paul Kyzivat
Cc: [e-mail]
Subject: Re: [cnit] [stir] Reputation vs Display name (was Textual caller ID)


On Aug 27, 2013, at 9:35 PM, Paul Kyzivat <[e-mail]> wrote:

> Brian,
> 
> Like Hadriel, I'm not getting your point about the score, and what having a bunch of factors says about the score.
> 
> I can see that if I'm trying to enroll with some naming service that they would want to get a bunch of facts from me to verify I am who I say I am. And if I have less facts then they are less certain who I am. That could enter into a score they give when queried.
Yes
> 
> But I don't see what that has to do with this problem.
> 
> One possibility is that the originator of the call always uses one name per phone number, in which case getting the name by looking up the phone number is fine. In that case, the score depends on what facts were given when the name was assigned to the number in the db. The lookup can be done by the recipient without loss of function.
You missed the part where we proposed that the name comes in the signaling from the sender.

There is no lookup by phone number.

We could do that, but the proposal is to change the CNAM mechanism to carry the name in the signaling.

The score would come in the signaling.  The recipient gets a name, and it gets the score, and it gets a signature of one of a small number of validators that asserts the score.  It then can evaluate, based on it's trust in the validator, and the score, what to display to the user.

To be clear, it is possible to do something like send the id of the validator in the signaling, and then query the validator at the recipient  with the phone number to get the name and the score.  That would be equivalent to what I propose, but it isn't what I'm proposing.

> 
> Another possibility is that the originator wants the option of using multiple names with the same number. (One for any given call.) For that to work, I guess all the possible names for a number must be enrolled. And presumably each of them get a score. In this case the phone number isn't sufficient to lookup the name. But the caller could include the name in the signaling, and the recipient could provide both the name and number for lookup. Then I would succeed, with a score, if that is one of the enrolled names for the number. Else it would fail.
Not proposing multiple names per number

> 
> Another possibility is that signing of names is entirely independent of the signing of numbers, with possibly different entities doing it. In that case I agree that the recipient looking up the number won't give the same result. This seems something like a SAML system.
The proposal is that the name is signed by one of a small number of name validators, and those are independent of the number delegation based credentials issued to sign the number.  I just replied to Hadriel with the explanation of why I propose we mix them (because the name validation is done infrequently, and is used for multiple calls, so to prevent cut/paste, we cover it with the per-call number signature).

> 
> 	Thanks,
> 	Paul
> 
> On 8/27/13 6:49 PM, Brian Rosen wrote:
>> We're proposing to change CNAM in a couple of ways:
>> 1. We're proposing to move the name determination from the 
>> termination to the origination 2. We're proposing to send a score
>> 
>> We think the score can be used very effectively by the termination.  It can be used with a threshold, and the threshold can be set by the termination service provider to match what service level it offers.  More interestingly, it can be used by the termination device to display some useful data to the consumer that is not black or white.
>> 
>> We want the score to be as accurate as it can be.  The databases have dozens of fields, not all of which are populated for every record.  The more fields you provide, the more accurate the score is (and the higher the score gets).  If all you query with is name and phone number, the confidence level is medium to low.  If you have more data, like address for example, the confidence is considerably higher.  It's not that address is better, it's that if you have a match of name AND number AND address, you have a much smaller error.
>> 
>> The databases we have today use scores.
>> 
>> Just as an example, my company has such a database.  It has dozens of fields.  One of the products that is driven by the database is a CNAM service.  When the termination side dips the database, it does so only with the telephone number.   The scores are fairly low, but there is a threshold (I don't actually know the details).  You get a name, or no entry found out of that dip.  The database scores the data and applies a threshold to it.
>> 
>> The exact same database is used for a call center caller match query.  You call the call center, the operator asks your name and address, gets phone number from ANI and they query the database (same database) to get a score of how likely the data in the query matches (name and phone number and address match each other).  The service you get depends on that score.
>> 
>> We can provide a much better service if we have more information, and the devices and services downstream can make use of score data to decide how to present the call.
>> 
>> Brian
>> 
>> On Aug 27, 2013, at 6:22 PM, Hadriel Kaplan <[e-mail]> wrote:
>> 
>>> 
>>> On Aug 27, 2013, at 4:41 PM, Brian Rosen <[e-mail]> wrote:
>>> 
>>>> As I keep saying, over and over, what they are used for today is termination dips, where all you have to query with is the telephone number, and that gets poor scores.
>>> 
>>> Yes, I know they're queried on termination; and yes, I know they're 
>>> queried using the source telephone number.  STIR will provide 
>>> validity for that source number, so that you can't pretend to be a 
>>> source number you aren't.  That should make things better for 
>>> calling names, if the content of the calling name databases is 
>>> accurate.  You've been claiming the content of the databases is 
>>> fairly accurate. (and as far as I can tell, they have been 
>>> relatively accurate so far, for at least CNAM databases though maybe 
>>> not LIDB ones)
>>> 
>>> I know many folks don't like the CNAM model, but I believe they don't like it due to the pricing model - not due to bad content, nor due to having to physically query it.  They don't like the fact that the receiver of calls has to pay extra for getting data the far-end wanted to be delivered to begin with.
>>> 
>>> I don't know what you mean by "that gets poor scores".  As far as I know, there is no such thing as a "score" in the existing PSTN calling name market.  There are name/number/phone-service "types" or category, but not scores of name accuracy afaik.  Are there such things?  Why would anyone claim their score is anything but perfect?
>>> 
>>> 
>>>> What we need is to do the dip at the origination side, where you have more information to make the score larger, and securely carry it in the SIP signaling.  That is the problem to be solved - I have the name, the score, and the identity of the validator.  I have to get that information across reliably, and reliably includes preventing messing with it at the origination side (so the sender can't lie about the score).
>>> 
>>> I think that jumps to a solution - presumably the problem is "calling names aren't reliable"; the problem is not "we can't send scores securely in SIP".
>>> 
>>> This whole topic is reminiscent of the debates the SIPPING WG had years ago on:
>>> draft-wing-sipping-spam-score
>>> draft-schwartz-sipping-spit-saml
>>> 
>>> -hadriel
>>> 
>> 
>> _______________________________________________
>> cnit mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/cnit
>> 
> 
> _______________________________________________
> cnit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cnit

_______________________________________________
cnit mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/cnit
_______________________________________________
cnit mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/cnit