Subject: Re: [cnit] what's the actual problem here?

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 1 Sep 2013 20:12:06 +0000

My short version is that we have two stages:

(1) Restore (at least) textual caller ID, i.e., caller name carried in the SIP From header, to the level of trustworthiness it generally had in the pre-VoIP days. Since we cannot eliminate untrustworthy participants in the system, we need to
(a) prevent on-path alteration
(b) indicate provenance of the information (e.g., was this inserted by the caller, the caller's carrier or by the receiving carrier, CNAM-style)
(c) possibly provide indications that allow the recipient to judge the trustworthiness of the information, such as whether the information was provided by the caller himself and whether the data was verified in some way (e.g., by billing record or a third-party business database).

(2) Provide additional information, such as name and address of organization or any licenses or registrations (e.g., licensed bank, health care provider), to allow call recipients to filter or evaluate calls, aided by third parties.

In both cases, the goal is to reduce the opportunities for impersonation-based fraud. (I'm intentionally saying "reduce", not "eliminate".) The goal of this effort is *not* to reduce robocalls, although some aspects of approach (2) may help there.

Henning

________________________________________
From: [email-masked] [[email-masked]] on behalf of Stephen Farrell [[email-masked]]
Sent: Saturday, August 31, 2013 5:19 PM
To: [email-masked]
Subject: [cnit] what's the actual problem here?

So having caught up on this list what I've seen is Brian proposing
solutions, Henning discussing aspects of those, and various people
apparently being puzzled or doubting some of the solutions being
offered.

I'm in the puzzled camp:-)

Can someone please state the problem that this list is aiming to
discuss, without referring to potential solutions?

That'd help me at least get a handle on whether this is worthwhile
or not, which is anything but clear for me right now.

Thanks,
S.
_______________________________________________
cnit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cnit

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 01 Sep 2013 21:20:54 +0100

So you're saying the problem is:

  "people/systems are faking textual caller ID"

is that right?

I'm not familiar with textual caller ID as a (pre- or post-)VoIP
service. I assume you mean that a call from me might say something
resembling "stephen farrell" though, is that right? Do you have
any pointers as to where/when this has been deployed? I don't think
I've seen it being used with the strings coming from a telco. but
maybe its more a US thing or something?

S.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 1 Sep 2013 20:31:26 +0000

See http://en.wikipedia.org/wiki/Caller_ID

This has existed for landline phones since the early 1990s.

For cell phones, generally only the phone number is delivered, although some carriers are now offering name delivery, for a fee.

Yes, it's generally the billing name that's delivered, which could be "S Farrell" or "Joe's Pizza". In some cases, only the rough geographic location ("Maine", "International") is shown, presumably based on country or area code.

________________________________________
From: Stephen Farrell [[email-masked]]
Sent: Sunday, September 01, 2013 4:20 PM
To: Henning Schulzrinne
Cc: [email-masked]
Subject: Re: [cnit] what's the actual problem here?

is that right?

S.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 01 Sep 2013 21:40:07 +0100

> This has existed for landline phones since the early 1990s.

Yes, I am familiar with seeing the caller's phone number
presented, just not with names.

> For cell phones, generally only the phone number is delivered,
> although some carriers are now offering name delivery, for a fee.

That's the bit I've not seen. The wiki page says that the names
are mostly added by the recipient's telco, when a recipient pays
for that service. (I'd imagine some EU data protection folks
might have an interest in that btw - any idea if they've looked
at it?)

Also, does "now offering" imply this is a new-ish thing? If so,
then I'm confused by your text saying a goal is to restore a
level of confidence that's been damaged.

> Yes, it's generally the billing name that's delivered, which could be
> "S Farrell" or "Joe's Pizza". In some cases, only the rough
> geographic location ("Maine", "International") is shown, presumably
> based on country or area code.

Ok,

S.

> 
> ________________________________________ From: Stephen Farrell
> [[email-masked]] Sent: Sunday, September 01, 2013 4:20 PM 
> To: Henning Schulzrinne Cc: [email-masked] Subject: Re: [cnit] what's
> the actual problem here?
> 
> resembling "stephen farrell" though, is that right? Do you have any
> pointers as to where/when this has been deployed? I don't think I've
> seen it being used with the strings coming from a telco. but maybe
> its more a US thing or something?
> 
> S.
> 
>> (1) Restore (at least) textual caller ID, i.e., caller name carried
>> in the SIP From header, to the level of trustworthiness it
>> generally had in the pre-VoIP days. Since we cannot eliminate
>> untrustworthy participants in the system, we need to (a) prevent
>> on-path alteration (b) indicate provenance of the information
>> (e.g., was this inserted by the caller, the caller's carrier or by
>> the receiving carrier, CNAM-style) (c) possibly provide indications
>> that allow the recipient to judge the trustworthiness of the
>> information, such as whether the information was provided by the
>> caller himself and whether the data was verified in some way (e.g.,
>> by billing record or a third-party business database).
>> 
>> (2) Provide additional information, such as name and address of
>> organization or any licenses or registrations (e.g., licensed bank,
>> health care provider), to allow call recipients to filter or
>> evaluate calls, aided by third parties.
>> 
>> In both cases, the goal is to reduce the opportunities for
>> impersonation-based fraud. (I'm intentionally saying "reduce", not
>> "eliminate".) The goal of this effort is *not* to reduce robocalls,
>> although some aspects of approach (2) may help there.
>> 
>> Henning
>> 
>> ________________________________________ From:
>> [email-masked] [[email-masked]] on behalf of Stephen
>> Farrell [[email-masked]] Sent: Saturday, August 31, 2013
>> 5:19 PM To: [email-masked] Subject: [cnit] what's the actual problem
>> here?
>> 
>> Thanks, S. _______________________________________________ cnit
>> mailing list [email-masked] 
>> _______________________________________________ cnit mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/cnit
>> 
>> 
> _______________________________________________ cnit mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/cnit
> 
>

---

From: Dave Crocker <[email-masked]>
Date: Sun, 01 Sep 2013 13:51:22 -0700

On 9/1/2013 1:12 PM, Henning Schulzrinne wrote:
> (1) Restore (at least) textual caller ID, i.e., caller name carried in the SIP From header, to the level of trustworthiness it generally had in the pre-VoIP days

Is there a description of what that original level of trustworthiness was?

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Sun, 1 Sep 2013 21:30:33 +0000

Henning in all due respect nothing dictates the behavior you say ? 

So magic and fairy dust makes it so? 

Martin Dolly
Lead Member of Technical Staff
Core Network & Gov't/Regulatory Standards  
AT&T Labs - Network Technology
+1-609-903-3360
[email-masked]

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 2 Sep 2013 11:51:06 -0400

> (1) Restore (at least) textual caller ID, i.e., caller name carried in the SIP From header, to the level of trustworthiness it generally had in the pre-VoIP days. Since we cannot eliminate untrustw…

I don't think you meant it this way, but to be clear the SIP From URI display-name has never been trustworthy and receivers should never blindly believe it.  If we need to publish an RFC stating that, we can.  RFC 4474 almost went that far, but didn't for some reason.

> (a) prevent on-path alteration

That's not been a source of problems afaict.  If it were, we'd have a concern for STIR too - but we're not worried about malicious MITM for STIR.  We're worried about "bad ends".  As an example of why we would *not* want to prevent on-path alteration: we need to let carriers in the middle remove any name assertion based on their knowledge the names are incorrect or aren't trustworthy, or possibly replace it with what they do know; but without impacting a calling number signed by STIR.

> (b) indicate provenance of the information (e.g., was this inserted by the caller, the caller's carrier or by the receiving carrier, CNAM-style)

I think that might be actually quite hard to accomplish, in a trustworthy manner.  The terminating carrier would know whether it got the name from a LIDB or 3rd-party CNAM; but even in the LIDB case it doesn't know where the LIDB data ultimately came from other than the LIDB AS for the calling number.

Since the premise for this discussion is that calling names are not trustworthy anymore (?), I'm assuming the LIDB AS'es are letting their data be populated by untrustworthy sources.  Is that correct?

> (c) possibly provide indications that allow the recipient to judge the trustworthiness of the information, such as whether the information was provided by the caller himself and whether the data wa…

Who generates this information, such that the terminating carrier (or its customers) would believe it?  If originating carriers would generate it, or some set of trusted third parties - that's essentially what LIDB is meant to be, no?  In what way is LIDB broken such that a new solution wouldn't be?

> (2) Provide additional information, such as name and address of organization or any licenses or registrations (e.g., licensed bank, health care provider), to allow call recipients to filter or eval…

Same question as (1-c) above.

> In both cases, the goal is to reduce the opportunities for impersonation-based fraud. (I'm intentionally saying "reduce", not "eliminate".) The goal of this effort is *not* to reduce robocalls, alt…

It's still not clear what the existing/current problem is for calling names, with enough clarity to figure out a solution to reduce it.  Are valid calling numbers being used with invalid names?  How did the invalid calling names get created/inserted such that terminating carriers get them and believe they're valid?

-hadriel

---

From: Ken Pogran <[email-masked]>
Date: Mon, 02 Sep 2013 13:43:26 -0400

Hello, all.  I am new to the group, but not to the subject matter.  My
name is Ken Pogran, and I'm with EGH, an OSS/BSS software firm in
Lexington, Massachusetts that provides LIDB AS software (referred to by
Hadriel) to the largest US Tier 1 service providers.

I would like to respond to several of Hadriel's comments:

On 9/2/13 11:51 AM, "Hadriel Kaplan" <[email-masked]> wrote:

>>(b) indicate provenance of the information (e.g., was this inserted by
>>the caller, the caller's carrier or by the receiving carrier, CNAM-style)
>
>I think that might be actually quite hard to accomplish, in a trustworthy
>manner.  The terminating carrier would know whether it got the name from
>a LIDB or 3rd-party CNAM; but even in the LIDB case it doesn't know where
>the LIDB data ultimately came from other than the LIDB AS for the calling
>number.
>
>Since the premise for this discussion is that calling names are not
>trustworthy anymore (?), I'm assuming the LIDB AS'es are letting their
>data be populated by untrustworthy sources.  Is that correct?

As it turns out, LIDB AS's are populated from multiple data sources, some
potentially less trustworthy than others. LIDB's (and LIDB AS's) operated
by the Tier 1 carriers will contain that carrier's own TN data, as well as
data for the TNs of other service providers who are wholesale or "data
storage" customers of the carrier's LIDB service.

For the LIDB operator's own TN data, the source is the Tier 1 provider's
CRM/subscriber management systems. And for wireline, these are typically
legacy systems implementing processes that have been in place a good long
time, with checks and balances and opportunities for human interaction to
correct errors. That is probably as close as we get in LIDB today to
trustworthy data. 

TN data for data storage customers is sourced by those other service
providers (ILEC, CLEC, wireless, VoIP providers etc.). Their checks and
balances on data quality won't necessarily be the same as those of the
Tier 1's.

>> (c) possibly provide indications that allow the recipient to judge the
>>trustworthiness of the information, such as whether the information was
>>provided by the caller himself and whether the data was verified in some
>>way (e.g., by billing record or a third-party business database).
>
>Who generates this information, such that the terminating carrier (or its
>customers) would believe it?  If originating carriers would generate it,
>or some set of trusted third parties - that's essentially what LIDB is
>meant to be, no?  In what way is LIDB broken such that a new solution
>wouldn't be?

I don't think LIDB is "broken" so much as the quality of data in LIDB will
vary according to its source, as I noted above. And, as has been noted,
lots of terminating carriers don't query LIDB, but instead query other
databases. Some terminating carriers query LIDB in certain situations, but
not others. 

Some non-LIDB CNAM databases derive CNAM strings from directory listings
data, which is typically organized differently and, especially for
business listings, may result in a different CNAM string from the one
stored in the designated LIDB. It may not be quite as up-to-date as LIDB
data populated directly from the subscriber management systems.

I can't speak to practices of the independent LIDB providers.

Hope this is helpful.
  Ken Pogran

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 3 Sep 2013 02:13:43 +0000

It's been widely available from all the typical residential local exchange carriers, in the US, at least ten years for wireline, probably closer to 15. Because of the way it's generated, via database lookup, it's not available for international calls.

I can't speak for other countries.

________________________________________
From: [email-masked] [[email-masked]] on behalf of Stephen Farrell [[email-masked]]
Sent: Sunday, September 01, 2013 4:40 PM
To: Henning Schulzrinne
Cc: [email-masked]
Subject: Re: [cnit] what's the actual problem here?

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 3 Sep 2013 02:22:18 +0000

I'm not sure how you'd quantify this, but Ken's later message provides a good summary, I think. 

Two qualitative statements:

(1) Almost all providers had processes in place that insured that the information was derived more or less directly from billing data.

(2) The opportunities for end users to create callerID data that was maliciously false were very limited.

I'm not saying that nobody ever maliciously spoofed textual callerID in the good old days, but sustained spoofing (without being quickly corrected) would have been difficult. Somebody would have had to impersonate a spoofing target (presumably a reasonably well-known entity to be criminally useful) in their business arrangements with a carrier.

Henning

________________________________________
From: Dave Crocker [[email-masked]]
Sent: Sunday, September 01, 2013 4:51 PM
To: Henning Schulzrinne
Cc: Stephen Farrell; [email-masked]
Subject: Re: [cnit] what's the actual problem here?

d/

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 3 Sep 2013 02:26:12 +0000

This wasn't clearly stated, but what I meant was that the SIP display name should be able to have (at least) the same level of trustworthiness as the pre-VoIP textual callerID of a tier-1 carrier (obviously not delivered by SIP at that time).

________________________________________
From: Hadriel Kaplan [[email-masked]]
Sent: Monday, September 02, 2013 11:51 AM
To: Henning Schulzrinne
Cc: Stephen Farrell; [email-masked]
Subject: Re: [cnit] what's the actual problem here?

-hadriel

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 3 Sep 2013 02:38:57 +0000

I didn't want to get into solution space, but I'm a bit surprised by the question, since that's exactly what's been discussed, at length. The idea was that, unlike today, the textual callerID is generally traceable to the originating carrier and/or originating entity, for the Organization/From split I provided as an example earlier.

As pointed out, that's not always true today, given that the destination has no clue which database is being used and who inserted the information there - a tier-1 carrier based on business records, listyourself.net based on caller assertion or some random white pages service based on who-knows.

For the additional information, we have, as pointed out repeatedly, numerous third-party databases, both private and governmental. The originating carrier or possibly the originator can obtain and sign that information as a value-add. The ARID approach is another possibility.

I've tried to provide very specific examples of how this could work, but am obviously not getting the point across.

-hadriel

---

From: Brian Rosen <[email-masked]>
Date: Tue, 3 Sep 2013 13:32:50 -0400

I'm going to try and restate the "what is the problem", working off what has been said.

In the PSTN today, there is an optional service that will display the name of the caller.  The name is currently obtained from a database.  Historically, the database is operated by the originating carrier, and is populated with the name obtained from the billing and service data used to establish the service.  The database is queried by the terminating carrier with the phone number to obtain the name.  Recently, due to charges levied on the terminating carrier by the originating carrier to query the database, alternatives have arose where large consumer oriented databases are queried that independently match name with telephone number without reference to the originating carrier's information.  When the databases were operated by large established telcos, the reliability of the data was good.  However, some service providers are now lax in how the data is populated, and some even advertise the ability to allow any name to be used with a number.  This has significantly eroded the usefulness of the service.  Where caller name service is provided, it replaces the display of the calling party number, although smart phones will usually substitute their local contact list name for whatever is provided by the calling name service.  This means that if stir succeeds in improving the quality of the calling party number, but no solution is provided for calling party name, fraudsters may still be able to disguise their activities.

This work proposes to change how caller name is carried to using the existing display name portion of the SIP URI in the From or P-A-I field.  The name would be carried in the signaling from origination to termination.  This capability exists today, although the service providers typically do not restrict or asses what name the caller asserts.  Therefore, along with the name would come a form of validation that the name is genuine, and, for calls from businesses, the type of business it is from.  

Validation of names is exceedingly difficult, and this work does not propose a solution that will provide a name with absolute certainty that it is genuine and associated with the telephone number of the calling party.  It does propose that the data be vetted through some process, which may not result in a simple "this is the name" result.  Rather, the vetting process may provide a name, but accompany it with a confidence factor(score) indicating the source's assessment of the likelihood that the name is represents the calling party.  Confidence would be a simple 0-100 scaler, without an attempt to precisely define or normalize it between sources.  That means that the termination side would have to evaluate the confidence factor and the source of the confidence together to decide how much to trust the name.  The termination could take a variety of actions based on the source and the claimed confidence.  Doing so implies that the number of sources is limited so that evaluating the source for trustworthiness can be accomplished.  

Vetting the name at the source is more likely to be of value, because the source may have a variety of other information about the party the name is assigned to that can be used to improve the reliability of the vetting process.  For example, address, other phone numbers, age, email addresses, domains (for businesses), etc can be used to provide much higher confidence that the name accurately represents the calling party than just the number known at the termination side.

Besides the name, when a call is made from a business, the type of business can provide important information to the caller when deciding to answer the call, or trust the caller.  The type of business would be a selection from an existing taxonomy of business types and would be relatively high level ("bank", "florist", "doctor"). 

The name, type of business (if appropriate), the source of the data, the confidence indicator and some indication of the vetting process would accompany the name in a new header in a secure manner -- secure in the sense that the number, the name, type, the source, and the sources' asserted confidence of the name is signed by the source. 

If the termination side did not trust the source, or it did, but the confidence was too low in its opinion, the termination may take a number of actions, including, but not limited to:
a) Refuse the call, or send it to voicemail
b) Use an independent source of names, like the alternative name suppliers that exist today to display an alternate name
c) Provide a visual or audible warning to the user that the name may not be valid
d) Provide a visual or audible representation of the confidence, possibly simplified (red/orange/yellow/green)
e) Provide a caller feedback (thumbs up/down) mechanism to further develop a rating of the source, or the specific name/number pair

Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 03 Sep 2013 15:31:19 -0400

Nits:

s/arose/arisen/
s/scaler/scalar/

Substance:

I'm still not buying the trust chain that says:

- caller supplies the name
- caller's provider provides the validation of the name,
   using an undefined method and scale
- callee decides how to trust the name based on the
   provided score and trust in the signer

	Thanks,
	Paul

On 9/3/13 1:32 PM, Brian Rosen wrote:
> In the PSTN today, there is an optional service that will display the name of the caller.  The name is currently obtained from a database.  Historically, the database is operated by the originating carrier, and is populated with the name obtained from the billing and service data used to establish the service.  The database is queried by the terminating carrier with the phone number to obtain the name.  Recently, due to charges levied on the terminating carrier by the originating carrier to query the database, alternatives have arose where large consumer oriented databases are queried that independently match name with telephone number without reference to the originating carrier's information.  When the databases were operated by large established telcos, the reliability of the data was good.  However, some service providers are now lax in how the data is populated, and some even advertise the ability to allow any name to be used with a number.  This has significantly erod
 ed
>    the usefulness of the service.  Where caller name service is provided, it replaces the display of the calling party number, although smart phones will usually substitute their local contact list name for whatever is provided by the calling name service.  This means that if stir succeeds in improving the quality of the calling party number, but no solution is provided for calling party name, fraudsters may still be able to disguise their activities.
>
> Validation of names is exceedingly difficult, and this work does not propose a solution that will provide a name with absolute certainty that it is genuine and associated with the telephone number of the calling party.  It does propose that the data be vetted through some process, which may not result in a simple "this is the name" result.  Rather, the vetting process may provide a name, but accompany it with a confidence factor(score) indicating the source's assessment of the likelihood that the name is represents the calling party.  Confidence would be a simple 0-100 scaler, without an attempt to precisely define or normalize it between sources.  That means that the termination side would have to evaluate the confidence factor and the source of the confidence together to decide how much to trust the name.  The termination could take a variety of actions based on the source and the claimed confidence.  Doing so implies that the number of sources is limited so that evaluati
 ng
>    the source for trustworthiness can be accomplished.
>

---

From: Brian Rosen <[email-masked]>
Date: Tue, 3 Sep 2013 15:36:32 -0400

Henning proposed to have some standardization of "method", but he meant broad categories like "from billing records".  That probably doesn't help you, but I liked that idea.

Without the validation, how would we change anything?  As it exists now, both the display name, if sent, and the content of the CNAM database can easily be anything you want if you use a pink carrier.  How would you propose to fix that?

Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 03 Sep 2013 15:54:46 -0400

> Without the validation, how would we change anything?  As it exists now, both the display name, if sent, and the content of the CNAM database can easily be anything you want if you use a pink carri…

As a user of this service, I would be more comfortable with it done by 
an agent for the callee, based on number lookup. At least then the 
callee has somebody to blame, and hopefully can choose which one.

At least this way the callee has a contract with *somebody* that will 
say *something* about the level of trust in the data, and a recourse if 
it turns out to be wrong.

I'm imagining that companies like Neustar would offer this service, 
either directly to the end user, or to the provider for the callee. And 
companies like Google might also provide a service like this. The 
interface to the service need not be standardized. On smart phones you 
could install a call validation app that plugs into incoming call 
handling, and manages its own display of the information.

	Thanks,
	Paul

---

From: Brian Rosen <[email-masked]>
Date: Tue, 3 Sep 2013 16:04:21 -0400

So you want to cut the originating provider, who has the most information available to validate the number, completely out of the loop?

We have this service now, and it's fairly good.  Instead of paying  the origination provider for the LIDB dip, they pay us to dip out database with the number.  But because the only input to validation is phone number, what comes out is variable quality.  It also has a specific problem that new service is very hard to accommodate.  Until the number is in use within the sources of data the database uses, the entry would be considered unknown.  That's not a huge problem to anyone but the new customer.

So the objection I have to termination side DB dip is that the quality of validation is constrained by the limited amount of information in the query.  If I do validation on the origination, I get much better results.  That, by the way, is independent of any score that might be sent in the signaling.  

Brian

On Sep 3, 2013, at 3:54 PM, Paul Kyzivat <[email-masked]> wrote:

> As a user of this service, I would be more comfortable with it done by an agent for the callee, based on number lookup. At least then the callee has somebody to blame, and hopefully can choose which one.
> 
> At least this way the callee has a contract with *somebody* that will say *something* about the level of trust in the data, and a recourse if it turns out to be wrong.
> 
> I'm imagining that companies like Neustar would offer this service, either directly to the end user, or to the provider for the callee. And companies like Google might also provide a service like this. The interface to the service need not be standardized. On smart phones you could install a call validation app that plugs into incoming call handling, and manages its own display of the information.
> 
> 	Thanks,
> 	Paul
> 
>> Brian
>>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 3 Sep 2013 20:29:50 +0000

Particularly for individuals and small businesses, the information tying numbers to names outside the carrier relationship can be of very low quality and out-of-date, as numbers get re-assigned. If you look at the white pages web pages, you may find who had the number a few years ago. Google doesn't have magic information on who uses what phone number - most of those numbers don't appear on web pages or other indexable information sources (and, if they did, you wouldn't want search engine optimization to kick in).

For large businesses, you really want better information, namely the organization name and possibly additional information such as the location ("Pizza Hut, Springfield") or caller name ("George Bailey, Bailey Savings & Loan"). Only the originator can provide this with any reliability, with the division of responsibility that I outlined earlier.

The current system makes it difficult for legitimate entities to provide helpful information and easy for bad actors to provide misleading information. Not a good combination.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Tuesday, September 03, 2013 4:04 PM
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [cnit] what's the actual problem here?

Brian

On Sep 3, 2013, at 3:54 PM, Paul Kyzivat <[email-masked]> wrote:

>>> - caller's provider provides the validation of the name,  using an 
>>> undefined method and scale
>>> - callee decides how to trust the name based on the  provided score 
>>> and trust in the signer
>>> 
>>> 	Thanks,
>>> 	Paul
>>> 
>>>> In the PSTN today, there is an optional service that will display 
>>>> the name of the caller.  The name is currently obtained from a 
>>>> database.  Historically, the database is operated by the 
>>>> originating carrier, and is populated with the name obtained from 
>>>> the billing and service data used to establish the service.  The 
>>>> database is queried by the terminating carrier with the phone 
>>>> number to obtain the name.  Recently, due to charges levied on the 
>>>> terminating carrier by the originating carrier to query the 
>>>> database, alternatives have arose where large consumer oriented 
>>>> databases are queried that independently match name with telephone 
>>>> number without reference to the originating carrier's information.  
>>>> When the databases were operated by large established telcos, the 
>>>> reliability of the data was good.  However, some service providers 
>>>> are now lax in how the data is populated, and some even advertise 
>>>> the ability to allow any name to be used with a number.  This has 
>>>> significantly e
 rod
>>>> Validation of names is exceedingly difficult, and this work does 
>>>> not propose a solution that will provide a name with absolute 
>>>> certainty that it is genuine and associated with the telephone 
>>>> number of the calling party.  It does propose that the data be 
>>>> vetted through some process, which may not result in a simple "this 
>>>> is the name" result.  Rather, the vetting process may provide a 
>>>> name, but accompany it with a confidence factor(score) indicating 
>>>> the source's assessment of the likelihood that the name is 
>>>> represents the calling party.  Confidence would be a simple 0-100 
>>>> scaler, without an attempt to precisely define or normalize it 
>>>> between sources.  That means that the termination side would have 
>>>> to evaluate the confidence factor and the source of the confidence 
>>>> together to decide how much to trust the name.  The termination 
>>>> could take a variety of actions based on the source and the claimed 
>>>> confidence.  Doing so implies that the number of sources is limited 
>>>> so that evalu
 ati
>>>> b) Use an independent source of names, like the alternative name 
>>>> suppliers that exist today to display an alternate name
>>>> d) Provide a visual or audible representation of the confidence, 
>>>> possibly simplified (red/orange/yellow/green)
>>>> e) Provide a caller feedback (thumbs up/down) mechanism to further 
>>>> develop a rating of the source, or the specific name/number pair
>>>> 
>>>> Brian
>>>> 
>>>> 
>>>>>> (b) indicate provenance of the information (e.g., was this 
>>>>>> inserted by the caller, the caller's carrier or by the receiving 
>>>>>> carrier, CNAM-style)
>>>>>

---

From: Ken Pogran <[email-masked]>
Date: Tue, 03 Sep 2013 16:43:03 -0400

>   provided score and trust in the signer

With regard to the first step in the chain, I believe one of the key
points is WHEN does the caller supply the name?  With PSTN LIDB that
happens at service subscription time (when the caller first establishes
his/her telephone service) and IMO that is a model that imparts greater
trust. The next step, "caller's provider provides the validation of the
name..." effectively occurs when the provider provisions the telephone
number record with the validated name into LIDB.

The call-terminating provider, as "callee's agent", dips the LIDB
designated by the caller's provider (as published in the Calling Name
Routing Guide) and presents the resulting CNAM string to the callee. Or,
the call-terminating provider dips an alternative CNAM database and
presents that result.

In the case of LIDB we know the caller's provider has validated the
caller's name as part of service establishment. In the case of non-LIDB
CNAM databases it is important to understand how and from where the caller
name data is constructed. In that vein, I would tend to trust Neustar's
database more than I would Joe's Cheapo CNAM Service.

Ken Pogran

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 04 Sep 2013 00:06:03 +0100

On 09/03/2013 09:29 PM, Henning Schulzrinne wrote:
> The current system makes it difficult for legitimate entities to
> provide helpful information and easy for bad actors to provide
> misleading information. Not a good combination.

True, that's not a good combination.

But, OTOH, just not defining such a service would also
nicely solve that problem.

FWIW, that (not bothering) seems more attractive to
me personally when I consider the privacy issues that
might arise were we to standardise this service.
Especially given that callee address books and enterprise
directories seem to work just fine, and since the
other use cases that I've heard so far don't seem
the least bit compelling (those being: "I want to
charge US$") given the privacy and complexity downsides.

And before someone asks, STIR is different since its
dealing with phone numbers which are required for
making at least some calls. In contrast names as
discussed here are not required at all.

So all in all, I'm not seeing why we should bother
doing any work here. But I could well be wrong, that
happens all the time:-)

S.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 03 Sep 2013 22:10:58 -0400

Stephen,

Its easy for somebody from a place that doesn't have it to suggest this. 
But in the US the expectation has been set.

This feature, when it works as intended, *is* useful. I get reminder 
calls from doctors, pharmacies, and sometimes from banks. Often these 
aren't from numbers that I know. It is indeed useful information to 
decide whether to answer. (And for a shared home phone, to decide *who* 
should answer.)

	Thanks,
	Paul

---

From: "Mishra, Sanjay" <[email-masked]>
Date: Tue, 3 Sep 2013 22:42:49 -0400

+1.

Our household only answers phone from names that are recognized on the caller ID otherwise the phone goes to the VM.

Thanks
Sanjay

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Tuesday, September 03, 2013 10:11 PM
To: Stephen Farrell
Cc: [email-masked]; 'Brian Rosen'; Henning Schulzrinne
Subject: Re: [cnit] what's the actual problem here?

Stephen,

This feature, when it works as intended, *is* useful. I get reminder calls from doctors, pharmacies, and sometimes from banks. Often these aren't from numbers that I know. It is indeed useful information to decide whether to answer. (And for a shared home phone, to decide *who* should answer.)

	Thanks,
	Paul

On 9/3/13 7:06 PM, Stephen Farrell wrote:
> But, OTOH, just not defining such a service would also nicely solve 
> that problem.
>
> FWIW, that (not bothering) seems more attractive to me personally when 
> I consider the privacy issues that might arise were we to standardise 
> this service.
> Especially given that callee address books and enterprise directories 
> seem to work just fine, and since the other use cases that I've heard 
> so far don't seem the least bit compelling (those being: "I want to 
> And before someone asks, STIR is different since its dealing with 
> phone numbers which are required for making at least some calls. In 
> contrast names as discussed here are not required at all.
>
> So all in all, I'm not seeing why we should bother doing any work 
> here. But I could well be wrong, that happens all the time:-)
>
> S.
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 4 Sep 2013 03:24:16 +0000

And on our fairly-new cordless (DECT) phone, there's a text-to-speech feature that announces "Call from Rite Aid Pharmacy". (It's actually surprisingly clever about pronouncing names.) Much more user friendly than "Call from two one two five five five one two one two". For a variety of user interface reasons, such phones typically don't have extensive address books, and, as mentioned, if they do, they don't typically contain business numbers.

Steve, you might want to suggest such a feature to your local phone company instead of taking it away from US consumers...

________________________________________
From: Mishra, Sanjay [[email-masked]]
Sent: Tuesday, September 03, 2013 10:42 PM
To: Paul Kyzivat; Stephen Farrell
Cc: [email-masked]; 'Brian Rosen'; Henning Schulzrinne
Subject: RE: [cnit] what's the actual problem here?

+1.

Thanks
Sanjay

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Tuesday, September 03, 2013 10:11 PM
To: Stephen Farrell
Cc: [email-masked]; 'Brian Rosen'; Henning Schulzrinne
Subject: Re: [cnit] what's the actual problem here?

Stephen,

        Thanks,
        Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 4 Sep 2013 12:04:22 -0400

I asked the question because it seems to me there's a contradiction in here somewhere.

From a 10k foot view, the current LIDB model is essentially the model being proposed as the solution.  Not the pricing model, maybe, but the architectural model.

The model being proposed is "the originator uses a name validation service that provides some assertion about the originating text name, and everyone else trusts that validation service's assertion".  That sure sounds like LIDB to me, just with different powerpoint slide icons.  The LIDB AS runs the database for its phone number customers, and in theory the AS should audit/verify the contents of its name entries to be valid.  It also provides a lot more than simply calling name data today, and if we think it needs even more information then we can talk about that.

But if bad names are entering the LIDB databases, then I don't know why we think they won't enter whatever "validation service" we're talking about.  Sure they might not enter TARGUSinfo databases, but there's no reason to think everyone will start using TARGUSinfo for their validation service.  For example why wouldn't the existing LIDB AS providers simply market themselves as a "validation service" to their existing customers?  And since some Tier-1 carriers run their own LIDB AS, why would they switch to someone else?

If the answer to that is "well no one would trust claimed names from LIDB AS", I find that hard to believe, since they appear to be trusted sufficiently right now; and it's not in the power of the terminating carriers to force the originating carriers to use a different LIDB AS.

Ultimately if this whole thing just boils down to "we don't know how this name got into the DB", then add a field to LIDB identifying the source... if an existing field doesn't already do that. (what does the "Account Owner" field hold?)

The other "problem" I've heard about LIDB is the pricing model, but that's a separate issue.

-hadriel

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 4 Sep 2013 16:14:58 +0000

I think it helps if we distinguish between two models, the "basic" (name + organization) in-band delivery, and extended information (location, business type).  The latter is by reference, due to size and maybe other practical issues, and doesn't really exist today.

For tier-1 providers, the basic process may not change all that much, except that the information will be carried in-band for end-to-end VoIP calls, rather than (just) be inserted into a database and will have provenance information to distinguish it reliably from information derived from other, more indirect, sources.

I don't see this as a major undertaking or fundamental change - a large fraction of the current textual callerID is valid, but even if 95% is, it's impossible for the end user to tell which 95%, and the bad 5% can really ruin your day (and bank account).

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Wednesday, September 04, 2013 12:04 PM
To: Henning Schulzrinne
Cc: [email-masked]; Stephen Farrell
Subject: Re: [cnit] what's the actual problem here?

-hadriel

---

From: Brian Rosen <[email-masked]>
Date: Wed, 4 Sep 2013 13:19:11 -0400

The architectural difference is that the data is carried in the signaling, not queried by the termination side.

Today, each provider loads the data with whatever it wants in the way of validation.  We propose to carry the identity of the validation, and the type of validation provided, in the signaling, in the hope that providers will use a relatively small number of 3rd party validation services instead of, or in addition to, any validation they do now.  

Peering arrangements could cover this kind of thing to.  A "green" provider could have a requirement that calls coming into its network have a name validated by an acceptable (to it) validation source.   

A termination network might suppress names that weren't from a source it trusted.

Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 04 Sep 2013 15:49:58 -0400

Brian,

My issue is with the trust model. Today this is a service offered by my 
provider. If there are problems, I would complain to my provider. It may 
be that my provider gets the data from a DB that was populated by the 
calling provider, but that is not *my* problem.

IIUC, in what you are proposing, the data I get will be signed by the 
caller or calling provider. Then I must decide whether to trust that. 
And if there are problems, then I presumably need to take it up with 
that provider.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 04 Sep 2013 15:56:50 -0400

> A termination network might suppress names that weren't from a source it trusted.

ISTM that here you are describing a system in which the callee's 
provider is doing a validation on the callee's behalf, possibly based on 
data provided by others. That gives me somebody I can blame that I have 
a contractual relationship with.

	Thanks,
	Paul

---

From: Brian Rosen <[email-masked]>
Date: Wed, 4 Sep 2013 16:03:06 -0400

While I think the situation could be the same - your provider handles it all, and you only see either "unknown" or  a name, I think it will be more probable that your device provider wants the data to make better use of it than your provider could (since it's actions are more limited).  You still look to your provider (or device/app supplier).  You don't look to the origination provider.

Brian

On Sep 4, 2013, at 3:49 PM, Paul Kyzivat <[email-masked]> wrote:

> Brian,
> 
> My issue is with the trust model. Today this is a service offered by my provider. If there are problems, I would complain to my provider. It may be that my provider gets the data from a DB that was populated by the calling provider, but that is not *my* problem.
> 
> IIUC, in what you are proposing, the data I get will be signed by the caller or calling provider. Then I must decide whether to trust that. And if there are problems, then I presumably need to take it up with that provider.
> 
> 	Thanks,
> 	Paul
>

---

From: Hala Mowafy <[email-masked]>
Date: Wed, 4 Sep 2013 20:44:43 +0000

Hadriel,

I worked on LIDB's architecture and services for a number of years and I'd like to offer a few points of clarification:
- When talking about a LIDB operated by the traditional carriers in the U.S. (e.g., AT&T) the data stored in LIDB is derived from the service order and the direct relationship the carrier has with each customer - not from mailing lists or credit bureaus.  Third party databases - because in most cases they have no direct relation with the end user - tend to use a variety of marketing sources, as such.  I cannot speak of TARGUSinfo (now Neustar) or any other entrepreneur out there that created a database from the white pages but later on failed to update the records in a timely fashion.  Some are better than others, of course.
- However, it is worth noting that in my 10 years on LIDB, whenever our team received field trouble reports on CNAM (customers complaining about receiving incorrect names, names of people long dead, etc.) the result of the investigations pointed to third party databases containing aged data - more than 95% of the time.  No exaggeration!
- The role of the LIDB Administration System (AS) - as Ken pointed out - is to maintain the master files (if you will) and provision the LIDB line records.  The AS also updates LIDB any time a change occurs with the account, again based on any changes the customer makes in his/her service profile.  The AS periodically audits LIDB line records against the customers' billing records to ensure no data entry/human errors occurred, etc.  The LIDB administrators go to great lengths to maintain the integrity and accuracy of the data in LIDB and do not simply accept variations of the name on a whim.
- To your question:  The AO or account owner is a data parameter on each LIDB line record that contains the SPID or service provider ID responsible for that account.  
- When you mentioned "validation service" I chuckled because there is a completely different service that LIDB offers called "Validation Service" but it is not what CNIT or STIR is thinking of (certifications and all).  Instead it is a validation of customer data (name, billing address, phone number, preferred language, ZIP Code, and more) that some retailers and banks have started using to help reduce their online retail fraud.  In the area of Validation Service, LIDB sometimes competes with and sometimes complements a large number of other data sources that retailers use.  From working with members of the Merchant Risk Council (MRC) for over 3 years, the feedback I got was that they received better accuracy ratings when they trialed LIDB than they did with other sources for various sets of data.   
- I really don't like talking about pricing models in this venue because business decisions should drive that.  However,  given that my company does not own a LIDB, I feel a little better offering this observation from my industry interactions regarding  LIDB's pricing model:- Most people are still under the impression that LIDB query prices are exorbitant (a few pennies per query back in the 1980s) when indeed it is a fraction of a U.S. penny for CNAM and the Validation Services today.   

Hala

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
Sent: Wednesday, September 04, 2013 12:04 PM
To: Henning Schulzrinne
Cc: [email-masked]; Stephen Farrell
Subject: Re: [cnit] what's the actual problem here?

-hadriel

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 4 Sep 2013 21:03:28 +0000

Today, we have two cases, neither of which has a satisfactory outcome:

(1) Good original provider, bad (or cheap) callee provider: The injured party is the business whose display is inaccurate or missing; they have no reasonable way of fixing the problem. The callee likely believes that they see information provided by the origin provider, and I suspect that, if they had too much time on their hand and complain to their local service provider, the customer service rep would not know how callerID works and would be happy to blame the caller. In most cases, they have no way of knowing whether the information is right, wrong or missing for a good reason.

(2) Bad original data, good callee service provider: The callee service provider can't do anything about the pick-your-own-text providers, as most of the data even for those services is probably still accurate, so they can't just drop those names. Again, no reasonable remedy.

Thus, the current system seems pessimal - the entities that are incented and knowledgeable can't fix problems. 

Henning

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Wednesday, September 04, 2013 4:03 PM
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [cnit] what's the actual problem here?

Brian

On Sep 4, 2013, at 3:49 PM, Paul Kyzivat <[email-masked]> wrote:

>>>>> - callee decides how to trust the name based on the  provided 
>>>>> score and trust in the signer
>>>>> 
>>>>> 	Thanks,
>>>>> 	Paul
>>>>> 
>>>>>> number to obtain the name.  Recently, due to charges levied on 
>>>>>> the terminating carrier by the originating carrier to query the 
>>>>>> databases are queried that independently match name with 
>>>>>> telephone number without reference to the originating carrier's 
>>>>>> information.  When the databases were operated by large 
>>>>>> established telcos, the reliability of the data was good.  
>>>>>> However, some service providers are now lax in how the data is 
>>>>>> populated, and some even advertise the ability to allow any name 
>>>>>> to be used with a number.  This has significantly
  erod
>>>>>> vetted through some process, which may not result in a simple 
>>>>>> "this is the name" result.  Rather, the vetting process may 
>>>>>> provide a name, but accompany it with a confidence factor(score) 
>>>>>> indicating the source's assessment of the likelihood that the 
>>>>>> name is represents the calling party.  Confidence would be a 
>>>>>> simple 0-100 scaler, without an attempt to precisely define or 
>>>>>> normalize it between sources.  That means that the termination 
>>>>>> side would have to evaluate the confidence factor and the source 
>>>>>> of the confidence together to decide how much to trust the name.  
>>>>>> The termination could take a variety of actions based on the 
>>>>>> source and the claimed confidence.  Doing so implies that the 
>>>>>> number of sources is limited so that eva
 luati
>>>>>> e) Provide a caller feedback (thumbs up/down) mechanism to 
>>>>>> further develop a rating of the source, or the specific 
>>>>>> name/number pair
>>>>>> 
>>>>>> Brian
>>>>>> 
>>>>>> 
>>>>>>>> inserted by the caller, the caller's carrier or by the 
>>>>>>>> receiving carrier, CNAM-style)
>>>>>>>

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 4 Sep 2013 17:48:41 -0400

Hi Hala,
I'm not sure if you meant those points as countering mine, but I think they're consistent with what I was saying.  No?

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 04 Sep 2013 18:24:43 -0400

> (2) Bad original data, good callee service provider: The callee service provider can't do anything about the pick-your-own-text providers, as most of the data even for those services is probably st…

Based on Brian's comments, I was thinking that the callee service 
provider would be making judgement calls on the trustworthiness of the 
original data it is getting, and excluding that which it deems 
inadequate to meet the promises it is making to its customers.

Then if a customer complains that he isn't getting a name for certain 
callers, the response (after checking the logs) can be that trustworthy 
name data is not available for that caller.

I'll grant that putting it in the hands of the callee provider has 
problems for (1). But users of such providers likely have lots of problems.

How about a mechanism that allows multiple signatures? Then both the 
originating and terminating ends could sign. Then the callee looks for a 
signature by somebody it knows/trusts. The callee provider will sign if 
it trusts the signature by the caller provider.

	Thanks,
	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 4 Sep 2013 22:33:57 +0000

Having multiple sources signed works for me, but it does make the display name mechanism harder to fit into the existing SIP model and adds complications to the UI.

Also, I'm having a hard time thinking of cases where the callee provider has better information than the call origin. This would only be the case if the caller somehow overrides the CNAM/LIDB information. For malicious callers that misrepresent themselves in the pick-your-own databases, this would obviously make no difference.

There are legitimate reasons for the display name to differ from the billing name, e.g., for PBXs ("Jane Smith, working at GEICO"). This is why I earlier proposed that we use the two SIP headers available differently: the Organization field is signed by the originating carrier (or possibly the LIDB/CNAM data by the terminating one) and the display name is signed by the number holder. I suspect this only works if large providers allow this privilege only for customers they know and trust, i.e., larger business customers.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Wednesday, September 04, 2013 6:25 PM
To: Henning Schulzrinne
Cc: [email-masked]; 'Brian Rosen'
Subject: Re: [cnit] what's the actual problem here?

> (2) Bad original data, good callee service provider: The callee service provider can't do anything about the pick-your-own-text providers, as most of the data even for those services is probably st…

Based on Brian's comments, I was thinking that the callee service provider would be making judgement calls on the trustworthiness of the original data it is getting, and excluding that which it deems inadequate to meet the promises it is making to its customers.

Then if a customer complains that he isn't getting a name for certain callers, the response (after checking the logs) can be that trustworthy name data is not available for that caller.

I'll grant that putting it in the hands of the callee provider has problems for (1). But users of such providers likely have lots of problems.

How about a mechanism that allows multiple signatures? Then both the originating and terminating ends could sign. Then the callee looks for a signature by somebody it knows/trusts. The callee provider will sign if it trusts the signature by the caller provider.

	Thanks,
	Paul

>>>>>> - caller's provider provides the validation of the name,  using 
>>>>>> an undefined method and scale
>>>>>>> In the PSTN today, there is an optional service that will 
>>>>>>> display the name of the caller.  The name is currently obtained 
>>>>>>> from a database.  Historically, the database is operated by the 
>>>>>>> originating carrier, and is populated with the name obtained 
>>>>>>> from the billing and service data used to establish the service.  
>>>>>>> The database is queried by the terminating carrier with the 
>>>>>>> phone number to obtain the name.  Recently, due to charges 
>>>>>>> levied on the terminating carrier by the originating carrier to 
>>>>>>> query the database, alternatives have arose where large consumer 
>>>>>>> oriented databases are queried that independently match name 
>>>>>>> with telephone number without reference to the originating 
>>>>>>> carrier's information.  When the databases were operated by 
>>>>>>> large established telcos, the reliability of the data was good.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 4 Sep 2013 22:41:37 +0000

I mainly care about clear responsibility so that all parties know who did what (and maybe some meta-information about their source of the information) and for new opportunities for "good" actors to provide such information.

As you note, multiple reasonable models could emerge. This doesn't seem that hard - as long as multiple parties, including the originator, originating and terminating carrier, can add information and sign it, your objective would seem to be met. It would be up to the carrier-customer contract as well as national signaling integrity rules who can modify and delete information (and clearly beyond any CNIT-related effort).

-----Original Message-----
From: Cary FitzGerald [mailto:[email-masked]] 
Sent: Wednesday, September 04, 2013 6:31 PM
To: Henning Schulzrinne
Cc: 'Brian Rosen'; Paul Kyzivat; [email-masked]
Subject: Re: [cnit] what's the actual problem here?

Brian correctly says that the originating provider is the one who is most likely to actually know who the originator is.  Great.  First, they are going to assert that they know a number based on that relationship, and they use that number as the primary key into whatever database they have.  If they are good actors (like Hala describes), then the data they deliver will be as accurate as their key(s) are into their database(s) modulo billing changes, etc.  If they are bad actors, then, well, they are shoveling a bunch of calls into the world and will be willing to do whatever is needed to terminate it.

The originating service provider gets paid on the basis of how successful the originator is in terminating a call.  The human terminating the call won't have a relationship with the originating service provider, and it's impractical to think that they will know any more than 1 or 2 out of the thousands out there.  The relationship they have with the originating SP is mediated by their terminating SP.

The terminating service provider gets paid based on completing the call, but discounted on the costs in reputation (and presumably market share), customer service and unwelcome regulatory oversight.  It is much more reasonable that the terminating SP should know something about the originating SPs.  Paul's saying 

Organizations fill these roles:

* The originating SP asserts that they have a call, that they have keys to map the caller to a name, and that they want to launch this call into the network
* Someone hosts a database that translates those keys into a name
* Someone does the lookup of the keys in the database and asserts they know a name with some confidence
* Other someones rate how reliable the database and database dipper are, and/or offer other lookups
* The terminating SP delivers the call in such a way that the human at the end of the call can make a rational decision about how to make the call

I don't think that the cnit architecture/protocol should say who the someones are; the architecture should allow for a diversity of answers.  Regulators and the market need to have the flexibility to shape who does what for whom at what cost/value.

I'm sympathetic to Henning's hope that something like the reliability of calling name delivery can be restored to status quo ante bellum.  I can see how the architecture can make that easier or harder to do, but given that part of the end service is based on the intention/motives of the players, the best thing that this group can do is to create an architecture that allows for external forces to act ion the players in rational ways.

---

From: Cary FitzGerald <[email-masked]>
Date: Wed, 4 Sep 2013 15:59:15 -0700

---

From: Hala Mowafy <[email-masked]>
Date: Thu, 5 Sep 2013 03:03:28 +0000

Hi Hadriel, 
Correct!  Not countering your points; rather adding to them.
I expanded simply to correct the misconceptions I keep reading in the thread about LIDB - to everyone in one shot.  
Hala
 
-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Wednesday, September 04, 2013 5:49 PM
To: Hala Mowafy
Cc: Henning Schulzrinne; [email-masked]; Stephen Farrell
Subject: Re: [cnit] what's the actual problem here?

Hi Hala,

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 05 Sep 2013 01:00:07 -0400

> Also, I'm having a hard time thinking of cases where the callee provider has better information than the call origin. This would only be the case if the caller somehow overrides the CNAM/LIDB infor…

My point wasn't that the callee provider has better (or even different) 
information than the calling provider. My point is that the callee 
provider is the one the callee knows. He depends on his provider to 
screen the information from caller providers, and indicate that it has 
done so by signing again.

E.g., Caller says he is John Doe. Caller provider Alpha signs that. 
Callee provider Beta checks the signature, and its own rating of 
provider Alpha, and signs with its key. The callee can then check either 
or both signatures. If he only knows Beta, then he only checks for that 
signature and otherwise treats as unsigned. Another, more complex, 
callee might have a number of signers it trusts.

Really simple callees simply check P-Asserted-ID, and trust their 
provider to only put trusted stuff in there.

	Thanks,
	Paul

---

From: Stephen Kent <[email-masked]>
Date: Thu, 05 Sep 2013 10:41:01 -0400

Paul,

I agree with your assessment about the potential role of the callee SP 
evaluating
the trustworthiness of the caller SP wrt a caller's asserted name. I 
still worry
about making this intelligible to residential (vs. business or call 
center) users,
but at least this strategy addresses the concerns about bad caller SPs.

Steve