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

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 27 Aug 2013 16:36:22 -0400

OK, but if these databases work so well, then what's the problem we need to fix?

-hadriel

On Aug 27, 2013, at 3:01 PM, Brian Rosen <[email-masked]> wrote:

> No one suggested we do that in a PKI/DKIM that is issuing credentials for phone numbers.  I merely wish to be able to carry the validation information as asserted by the entity signing the number.  The validator service for the name is likely different from the number delegation authority.  
> 
> I repeat, often, that the mechanisms we use to do the name validation are not perfect, and they are most often local (i.e. a given validation database often only covers one, or a very small number of countries).  If you attempted to use Stiofán O'Fearghail assuming you presently resided in the U.S., you would get a very low score, unless you have regularly used that name in a variety of commercial circumstances or public records.  Even if your birth certificate used that version of your name, if you didn't regularly use it, the database would score it low, even if you supplied other information about yourself.  The same is very likely true of the databases that cover Ireland, unless, again, that was how you represented yourself commonly, especially in commercial transactions or public records, but I am less familiar with them than the U.S. databases.
> 
> Each of these databases has different sources of data that it builds on, and they have different methods of correcting bad data.  They are, however, pretty darn reliable over all, even though they are not perfect.   I would not suggest that we standardize how these databases work.  We only need to recognize that they exist, that they supply a score, and that they work better with more information suppled on a query, which leads me to try to get validation done at the origination side, where more information is typically available.  We don't have to standardize queries to these databases, or anything other than the range of the score, where 0-100 is a generally acceptable range.
> 
> Brian
> 
> 
> 
> 
> On Tue, Aug 27, 2013 at 2:40 PM, Stephen Farrell <[email-masked]> wrote:
> On þri 27.ágú 2013 18:21, Brian Rosen wrote:
> 
> We DO know how to do reasonable, but not entirely accurate, validation of names against numbers, especially if, as we can reasonably do, we get additional information from the origination service provider to do the validation.  We do that now, pretty successfully.  We can imagine extending the kinds of things we do now in the direction Tim, Henning, and others have suggested - primarily, the notion of having a taxonomy of callers (like "bank") and labeling the caller with the taxonomy in a reasonably accurate way.  Based on the kinds of databases that exist, doing validation against an agreed upon taxonomy is not research.
> FWIW, I don't think we know how to do that in a PKI (or DKIM-like equivalent) that is being established to issue credentials just for phone numbers. I think I saw Steve Kent say the same thing earlier as well. Dealing with people's
> names and businesses names like that just has a lot of complexity, or at least has had in any context in which I've encountered the problem. Just to throw one of many possible examples into the picture, the name Stiofán O'Fearghail would likely have to be accepted for me if an Irish regulator were deploying a STIR system that had to support people's names - are you saying you know how to handle all the i18n issues with naming that'd come up?
> 
> S.
> 
> 
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: Brian Rosen <[email-masked]>
Date: Tue, 27 Aug 2013 16:41:59 -0400

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.

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

Brian

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 27 Aug 2013 21:28:52 +0000

-stir, +cnit (to which I'm not yet subscribed)

On þri 27.ágú 2013 19:01, Brian Rosen wrote:
> No one suggested we do that in a PKI/DKIM that is issuing credentials 
> for phone numbers.  I merely wish to be able to carry the validation 
> information as asserted by the entity signing the number.  The 
> validator service for the name is likely different from the number 
> delegation authority.
>
> I repeat, often, that the mechanisms we use to do the name validation 
> are not perfect, and they are most often local (i.e. a given 
> validation database often only covers one, or a very small number of 
> countries).  If you attempted to use Stiofán O'Fearghail assuming you 
> presently resided in the U.S., you would get a very low score, unless 
> you have regularly used that name in a variety of commercial 
> circumstances or public records.  Even if your birth certificate used 
> that version of your name, if you didn't regularly use it, the 
> database would score it low, even if you supplied other information 
> about yourself.  The same is very likely true of the databases that 
> cover Ireland, unless, again, that was how you represented yourself 
> commonly, especially in commercial transactions or public records, but 
> I am less familiar with them than the U.S. databases.
I thought you had just said that reputation systems for this were not 
understood?

In any case, you missed my point, or I wasn't clear enough. In any Irish 
caller-ID context with names, its quite possible that COMREG (the Irish 
FCC equivalent) might insist that names be provided in both Irish and 
English (where the name differs in the two languages, which is mostly 
but not always the case) or in whichever the caller or callee prefers - 
it'd be politics that determined the actual choice probably and your 
putative caller name PKI would need to cater for that kind of 
complexity.  Its just a hard hard problem and I doubt that its at all as 
well understood as you claimed to be honest.

S.

>
> Each of these databases has different sources of data that it builds 
> on, and they have different methods of correcting bad data.  They are, 
> however, pretty darn reliable over all, even though they are not 
> perfect.   I would not suggest that we standardize how these databases 
> work.  We only need to recognize that they exist, that they supply a 
> score, and that they work better with more information suppled on a 
> query, which leads me to try to get validation done at the origination 
> side, where more information is typically available.  We don't have to 
> standardize queries to these databases, or anything other than the 
> range of the score, where 0-100 is a generally acceptable range.
>
> Brian
>
>
>
>
> On Tue, Aug 27, 2013 at 2:40 PM, Stephen Farrell 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>         We DO know how to do reasonable, but not entirely accurate,
>         validation of names against numbers, especially if, as we can
>         reasonably do, we get additional information from the
>         origination service provider to do the validation.  We do that
>         now, pretty successfully.  We can imagine extending the kinds
>         of things we do now in the direction Tim, Henning, and others
>         have suggested - primarily, the notion of having a taxonomy of
>         callers (like "bank") and labeling the caller with the
>         taxonomy in a reasonably accurate way.  Based on the kinds of
>         databases that exist, doing validation against an agreed upon
>         taxonomy is not research.
>
>     FWIW, I don't think we know how to do that in a PKI (or DKIM-like
>     equivalent) that is being established to issue credentials just
>     for phone numbers. I think I saw Steve Kent say the same thing
>     earlier as well. Dealing with people's
>     names and businesses names like that just has a lot of complexity,
>     or at least has had in any context in which I've encountered the
>     problem. Just to throw one of many possible examples into the
>     picture, the name Stiofán O'Fearghail would likely have to be
>     accepted for me if an Irish regulator were deploying a STIR system
>     that had to support people's names - are you saying you know how
>     to handle all the i18n issues with naming that'd come up?
>
>     S.
>
>

---

From: Brian Rosen <[email-masked]>
Date: Tue, 27 Aug 2013 17:46:22 -0400

It's possible for regulators to make something that was possible in an engineering sense become impossible by poor choice of regulation.  I would never dispute that.

However, if Irish names were not commonly used in commerce, then the databases that provide authentication for a wide variety of uses including customer support calls, credit decisions, ordering pizza and others would not work if you tried to claim you were Stiofán O'Fearghail.  If they were not commonly used, and COMREG required they be used, we might have a problem.  Can't engineer a way around that.

We'd have the same problem if they required Gaelic.  But if the name you assert is the same one you use with your bank, your car dealer and your pizza parlor, then it will be given a decent score.

Brian

On Aug 27, 2013, at 5:28 PM, Stephen Farrell <[email-masked]> wrote:

> I thought you had just said that reputation systems for this were not understood?
> 
> In any case, you missed my point, or I wasn't clear enough. In any Irish caller-ID context with names, its quite possible that COMREG (the Irish FCC equivalent) might insist that names be provided in both Irish and English (where the name differs in the two languages, which is mostly but not always the case) or in whichever the caller or callee prefers - it'd be politics that determined the actual choice probably and your putative caller name PKI would need to cater for that kind of complexity.  Its just a hard hard problem and I doubt that its at all as well understood as you claimed to be honest.
> 
> S.
> 
> 
>>

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 27 Aug 2013 18:22:25 -0400

> 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 ha…

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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 27 Aug 2013 22:30:31 +0000

On þri 27.ágú 2013 21:46, Brian Rosen wrote:
>
> We'd have the same problem if they required Gaelic.  But if the name 
> you assert is the same one you use with your bank, your car dealer and 
> your pizza parlor, then it will be given a decent score.
I was talking about Gaelige - you see the point is that once you 
consider naming people, you get these kind of complexities. In the 
specific case, Irish (Gaelige) is the first official language of Ireland 
and that wins in all sorts of ways (e.g. street signs, our University 
letterhead) and would likely win in this case too. So the putative PKI 
or whatever would have to support Irish and other oddities of naming, 
and I'm sure many other countries have their own fine oddities too;-)

All I'm saying is: this is complicated stuff and not simple and claiming 
its a solved problem is not credible.

S.

---

From: Brian Rosen <[email-masked]>
Date: Tue, 27 Aug 2013 18:33:30 -0400

But we have solved it well enough that commerce based on it works well enough.

It can be stymied by poor regulation, and it's not perfect, but it works well enough to use.

Brian

On Aug 27, 2013, at 6:30 PM, Stephen Farrell <[email-masked]> wrote:

> I was talking about Gaelige - you see the point is that once you consider naming people, you get these kind of complexities. In the specific case, Irish (Gaelige) is the first official language of Ireland and that wins in all sorts of ways (e.g. street signs, our University letterhead) and would likely win in this case too. So the putative PKI or whatever would have to support Irish and other oddities of naming, and I'm sure many other countries have their own fine oddities too;-)
> 
> All I'm saying is: this is complicated stuff and not simple and claiming its a solved problem is not credible.
> 
> S.
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 27 Aug 2013 22:42:44 +0000

> It can be stymied by poor regulation, and it's not perfect, but it works well enough to use.
So I've no idea what we nor what solution you mean, nor within what 
scope that solution might work.  Can you provide pointers?

"Poor regulation" also seems trite - sure all regulators can do weird 
stuff, but you can't (I hope) claim that anything that your favourite 
regulator doesn't require is poor regulation, right? The world is just a 
bigger place than that.

S.

---

From: Brian Rosen <[email-masked]>
Date: Tue, 27 Aug 2013 18:49:32 -0400

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 27 Aug 2013 18:53:28 -0400

> I was talking about Gaelige - you see the point is that once you consider naming people, you get these kind of complexities. In the specific case, Irish (Gaelige) is the first official language of…

What do your phone calls display now?  What do your printed phonebooks list?

From a character encoding perspective we can encode anything in UTF-8.  From a perspective of "I have two names", we can even carry two names in SIP or put two or more names into a database (obviously).

One question is which name should be displayed when you receive a call?  Is that up to the sender to decide, or the receiver to decide?  Regardless, we can have the SIP message indicate which one to display but let the receiver pick a different one.  Or if the sender gets to decide, then just carry only one of the possible names to begin with, so long as the receiver can validate that name is one of the ones the sender is allowed to claim.

I think the really hard part with any of this is how do we know the sender can claim one (or more) names - i.e., who would receivers truly trust to validate source names properly?

> All I'm saying is: this is complicated stuff and not simple and claiming its a solved problem is not credible.

It's sorta "solved" in a way: email.  It isn't solved in the sense that the username is valid obviously, but I mean it's solved in the sense that this email seems to have only one representation of your display-name and your government didn't complain. ;)

-hadriel

---

From: Brian Rosen <[email-masked]>
Date: Tue, 27 Aug 2013 18:58:48 -0400

See the email I just sent to Hadriel for how these systems work.  In the U.S., there are maybe 5 or 6 such databases.  They all have different content, and for any given record, some of them will be more accurate than the others, but they could all provide a service like what I described.  I don't know how many exist for Irish records, but I'd guess it's more than one and less than 5 or 6.  They exist in most developed countries.

It's always possible for the origination carrier to attempt to provide the validation service itself.  Depending on how it collects and verifies data, it might be able to do the job acceptably well.  The scheme only works well if there are a relatively small number of validators, where the trust level can reasonably be evaluated by the termination SP (or other service).  If every SP tried to do it themselves, we probably would not have a workable system.

If the regulator requires names be presented in Irish, but that form of name is not commonly used in commercial transactions, unless there is a reasonable way to translate, the mechanisms we have today would fail.  If the regulator requires something we can't do, then it is at least a candidate for bad regulation.  In my experience, regulators try not to ask for the impossible, but sometimes, it happens anyway.

Brian

On Aug 27, 2013, at 6:42 PM, Stephen Farrell <[email-masked]> wrote:

> So I've no idea what we nor what solution you mean, nor within what scope that solution might work.  Can you provide pointers?
> 
> "Poor regulation" also seems trite - sure all regulators can do weird stuff, but you can't (I hope) claim that anything that your favourite regulator doesn't require is poor regulation, right? The world is just a bigger place than that.
> 
> S.
>> 
>> Brian
>>

---

From: Brian Rosen <[email-masked]>
Date: Tue, 27 Aug 2013 19:08:10 -0400

Today, all we get is what we told the origination provider (or enter into their UI for the examples Henning cited) or what we get from the thresholded query to termination side CNAM dips that I described.

I hope current UIs are not a limiting factor in this work.  We have to make POTS phones served by ATAs or SIP interconnects to Class 5 switches work, but if smartphones have better UIs, we can make use of them.

I've only thought about carrying one name.  I'm not sure what the use case for more than one is.

Clearly, the receiver decides what to display.

I would like the sender to send one name, with the score and validation of that name.

I agree that in order to work, there has to be only a small number of validation services that the receiver can evaluate and decide what to do.  It's certainly conceivable that if it has a name validated by an entity it does not know, or does not trust, it could do the kind of termination query we have now.  It could even send in the name it gets (and the phone number) and get a better score than sending just the number.

Or, it could downgrade the score, or just display "unknown".

email is not a good example.  The display name typically has no validation at all.  It's more likely it's right if the domain is ibm.com, and less likely if it's gmail.com, but in general, there is no validation of display name in email.

Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 27 Aug 2013 23:10:59 +0000

There are a fairly large number of entities that provide mostly-accurate information about businesses. They are obviously country-specific, including multiple language renderings (think Canada if China and Japan are too exotic). Well-known examples include Experian (for both businesses and consumers) and Dun & Bradstreet (for businesses; they provide the DUN which identifies every US business of non-trivial size). They often also provide credit information, but that's usually a separate product. 

Random selection:
http://www.experian.com/business-information/business-information-c.html?intcmp=hptn_bis

"The company's business database provides comprehensive, third-party-verified information on 99.9 percent of all U.S. companies."

There are probably half a dozen similar outfits, with different business models.

As an example, the FCC Video Relay Service Report & Order discusses validation of key attributes (name, address, DOB) for potential users of that service, to reduce fraud. A number of entities have claimed that they provide such services on a routine and large-scale basis today. They don't work 100% of the time, i.e., some low-profile entities that haven't left much of a footprint are hard to validate, but they mostly seem to work. Obviously, this is even easier in countries with more established identity verification and record keeping, such as most European countries.

These databases are keyed on phone numbers, social security numbers, DUNs, FEINs (Federal tax ID) or name matches. Besides rendering the information in a way that is meaningful to the recipient (UTF8 will do that...), the precise accents on the name are immaterial for that process.

As noted, in many cases, carriers, through their business relationships, know pretty well who their (large) customers are (i.e., their legally registered name) and what their DUN is. That's probably not as true for residential customers.

I think the scores that Brian is talking about are of two kinds: If a prospective customer gets sent to one of those services, they try to ascertain whether the person they are talking to is really John Smith, as claimed, based on answering questions. (This is done either by phone or a web page.) If the person doesn't have a whole lot of verifiable information ("who financed your first car?" "where did you live in 1990?"), they get a lower confidence score. Obviously, for wireline service, the service provider is 100% sure where the customer lives, but may not have checked the name against the driver's license.

There may also be scores on the data record itself, but I haven't seen that as much in practice. This is not a credit score, simply a "is this information likely reliable?" score.

Thus, for a business, besides providing full information, you could imagine that a carrier would certify "this call is from DUN 12345, I'm sure", and then the recipient can look up the information.

You can try this out by typing a business name at dnb.com

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Tuesday, August 27, 2013 6:43 PM
To: Brian Rosen
Cc: [email-masked]; Henning Schulzrinne
Subject: Re: [cnit] [stir] Reputation vs Display name (was Textual caller ID)

S.

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 27 Aug 2013 20:39:40 -0400

On Aug 27, 2013, at 6:58 PM, Brian Rosen <[email-masked]> wrote:

> See the email I just sent to Hadriel for how these systems work.  In the U.S., there are maybe 5 or 6 such databases.  

Actually I've been told there are over a dozen CNAM providers just in the US.  And over a dozen LIDB too (some are the same company as the CNAM, some not).  I do agree there are only a handful of "big" ones.

> It's always possible for the origination carrier to attempt to provide the validation service itself.  Depending on how it collects and verifies data, it might be able to do the job acceptably well…

It's worse than that.  It just reverts back to the problems for how we got to STIR.  It also reverts back to the discussion of why doing a web-pki model for calling numbers wouldn't work in the long run, and I don't see a reason to think a web-pki model will work for calling names any more than numbers.

> If the regulator requires names be presented in Irish, but that form of name is not commonly used in commercial transactions, unless there is a reasonable way to translate, the mechanisms we have t…

[It's not germane to this discussion, but as an aside I find some regulators do indeed ask for the impossible, either on purpose (to protect commercial interests of specific companies in their country), or because they don't have technical expertise in the specific areas they regulate. But that's a topic for another day.]

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 27 Aug 2013 21:11:54 -0400

Ignore the score thing for a minute - I think it's crazy to rely on the sender's notion of a validity score (and that's not how spam score systems work, for example) - but ignore that for now.

Let's just talk about this need to sign the stuff in the INVITE.  I think we must be talking past each other somehow.  Either I'm missing something, or you are, or both. :)

What is it you think you're gaining by having the validation service's "package" signed by STIR?

Or maybe my disconnect is more basic than that - what exactly is in the "package"?  You don't have to describe every possible field, but let's just say an absolutely plain/simplest package possible: what's in it?

-hadriel

On Aug 27, 2013, at 6:49 PM, Brian Rosen <[email-masked]> wrote:

> cnit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cnit

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 27 Aug 2013 21:35:21 -0400

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.

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.

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.

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.

	Thanks,
	Paul

---

From: Alex Bobotek <[email-masked]>
Date: Tue, 27 Aug 2013 22:55:06 -0700

The points that the originating service provider should be presenting and possibly signing the display name I accept as generally positive.   The originating service provider is usually in the best position to provide this information.  And if some notion of originator reputation (e.g., 'score') is also presented and signed by the originating service provider, great.  

A display name service cannot provide an adequate basis for trust for several reasons: 

1.  Linear unstructured text naming cannot prevent fooling the recipient.  If an attacker wants to have their display name be Charlotte C Union and vish, smish or phish Charlotte Credit Union's customers, they may.  What might be Ms. Charlotte's 'personal' calls shouldn't be blocked.  

2.  Further, even a perfect taxonomy of caller types (bank, person, ...)that tells a called party that the caller is a person rather than a  bank would offer inadequate protection to vulnerable (e.g., permanently or temporarily disabled) individuals.  Criminals are creative and will always find ways to exploit the vulnerable with naming similarities.  Nor could it, at least without global adoption of identity authentication and registration requirements such as India's, be counted on to indicate telemarketing.  I do not see how a practical role-based naming taxonomy could be comprehensive enough to prevent these exploits, but my ears are open if someone could point me to such an explanation.  

3.  We cannot assume that all originating service providers will be trustworthy or even well intentioned.  The opening of the service provider market is increasing access to both reputable and disreputable parties.  Display Names provided/signed only by an originating service provider should not be trusted more than the service provider itself.  

Given unique authenticated identities of the calling party and originating service provider, reputation-based systems incorporating called party feedback and calling pattern analysis can and are currently being used successfully in some telephony applications (e.g., text messaging) to pressure peer service providers to police their originations and originating parties, as well as block calls from disreputable callers and,  if necessary, disreputable service providers.  In much more heavily abused communications media (i.e., email), reputation does the heavy lifting.   

We need notions of service provider and originator reputation to control several types of abuse such as vishing and smishing that authenticated names cannot adequately mitigate.  Called party Display Name is beneficial, but insufficient.  

It appears to me the 'score' Brian mentions is one notion of reputation.  But it's only one, and IMHO reputation needs much more extensive discussion.   

Personally, I believe that the telephony security framework should include the following:

* Authenticated identity (phone number)
* Display name
* Reputation framework that can be used to filter calls and indicate trust, 

and possibly an

* Authorization framework that can be used to prove authority to use (e.g., by a fundraising boiler room or integrated messaging system) a particular identity.

Regards,

Alex

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, August 27, 2013 3:50 PM
To: Hadriel Kaplan
Cc: Henning Schulzrinne; [email-masked]; Alex Bobotek; Dwight, Timothy M (Tim); Stephen Farrell
Subject: Re: [cnit] [stir] Reputation vs Display name (was Textual caller ID)

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 

Brian

On Aug 27, 2013, at 6:22 PM, Hadriel Kaplan <[email-masked]> wrote:

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 28 Aug 2013 09:02:29 -0400

Unfortunately your point-3 is the problem: we know that some originating "service providers" cannot be trusted.  Some of them are just lazy or understaffed; but some of them are actually complicit: letting their customers generate unverified and unverifiable calling numbers and names is actually part of their business model.

That's the same problem that is making us do STIR to begin with.  If we could trust all originating service providers, or even thought that reputation of originating providers alone was sufficient, we wouldn't need half of the stuff STIR is defining.  For example we could have simply implement draft-kaplan-sip-asserter-identity, which was far simpler than STIR will be.  That would have enabled creating reputation services to weed out bad originating service providers.

But when I talked to some of the carriers about doing that, they had concerns over the notion of deciding an entire originating service provider was untrustworthy; concerns regarding lawsuits from those originating providers, threshold level issues, and big problems if it was used for international calls.  The thing they liked about STIR was it would be easily and legally defensible, including at an international level.

-hadriel

---

From: Brian Rosen <[email-masked]>
Date: Wed, 28 Aug 2013 09:29:01 -0400

Inline please

> Actually I've been told there are over a dozen CNAM providers just in the US.  And over a dozen LIDB too (some are the same company as the CNAM, some not).  I do agree there are only a handful of "…
Most of these are NOT the databases I'm talking about.

The classical LIDB does not have much validation, and some of them have none.  Those only have name and number.  What I'm talking about has 50-70 fields for each record.  At least one of them is used as a CNAM database, but they are usually used for web or call center commercial transactions.  There reason for existence is to validate data, not to supply a name given a telephone number.  Many of them, in normal circumstances, don't give out field contents.  They simply give a score to  set of data presented to them, where the score is a confidence index of how likely the information presented is accurate and refers to the same entity.

I'm not opposed to a carrier operating a database, but the trust that a recipient places in the data may be pretty low unless it mimics what the commercial systems do.

> It's worse than that.  It just reverts back to the problems for how we got to STIR.  It also reverts back to the discussion of why doing a web-pki model for calling numbers wouldn't work in the lon…
Not arguing.

However, this is all a confidence discussion - how confident are you that the name is accurate.

In the current LIDB, for some carriers, there is zero confidence, because there is zero validation.  For some of the larger carriers, there is some validation, but usually it's pretty minimal.  Where the termination SP uses the validation databases, rather than querying the origination provider's LIDB, it doesn't matter how much validation the originating carrier provides, because the termination carrier does't use it.  However, the validation database can't be really accurate (that is, the score for the data it is supplying isn't very high) because all it has to query with is the phone number, and the way these systems work, if you only have one input factor, confidence is fairly low.

On the other hand, if you queried that same database with both the number AND the display name carried in the signaling, you would get a higher confidence, even if the name was believed to be invalid.  The score would be low (score represents likelihood the data is consistent with an actual entity) for a believed-to-be-invalid name, but the underlying confidence in the data would be higher than querying with just the phone number.

I'm NOT advocating any sort of PKI here.  Just a relatively small number of validators whose trust can be assessed (independently) by the termination.  The credentials for the validators could be well known.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 28 Aug 2013 13:29:41 +0000

Quick comments (not just on the message below):

- I don't think either Brian or I are talking about LIDB/CNAM providers as of today, although they may obviously overlap. If you actually take a look at the real-world examples I provided, you'll notice that they have nothing to do with CNAM.

- I explained how identity trust scoring works today, at scale. This is not hypothetical, just not used for phone calls at the moment.

- If you're looking for perfection, there is no solution. The most likely outcome is that a vulnerable person can buy a service that says "only accept calls from my address book, a registered bank, a real government agency and real health-care provider". No need for looking at names.

- With the third-party identity provider model, whether the carrier is pink or has any other color is largely immaterial.

Henning

---

From: Brian Rosen <[email-masked]>
Date: Wed, 28 Aug 2013 09:41:10 -0400

I know I haven't been very articulate on this, but I'll try to be so in this reply.

The reason you want to sign the package with the credentials of the number holder is that the validation is done at relatively long intervals (say, months if we have a revocation mechanism), but we need to stop a cut and paste attack, so we protect the package under the number signature that has a timestamp and id/sequence number.

The same package would be used in any call from that phone number.

I don't want the validator to have to be in the path of every call.  We don't need that and it makes the mechanism much simpler.

The entity asserting it has the right to use the number is the same entity that asserts it has the right to the name, so it makes sense to me to just put it in the stir signature.

The entity asserting the name doesn't get a credential from the validator, it gets the package.

I think the package is the name, the canonical phone number, an id of the validator, some id for the package (which could really just be a small package version when combined with the name and number) and the signature of the validator over the package.

Brian

---

From: Brian Rosen <[email-masked]>
Date: Wed, 28 Aug 2013 09:52:47 -0400

On Aug 27, 2013, at 9:35 PM, Paul Kyzivat <[email-masked]> 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
> 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).

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Aug 2013 10:30:18 -0400

Brian,

OK, clearly I don't understand what you are proposing. Can you explain 
it better?

On one hand I think you are assuming a service that can be queried with 
a bunch of factors, and returns a confidence score that that combination 
of factors is valid. E.g., I might present a name and number and get a 
score. Or I might present a name, number, and some other secrets known 
to the caller, and get a score.

Assuming there is some value in using that extra information, and 
assuming the extra information is something that the caller doesn't want 
to share with the callee, then I see why the caller would need to do the 
query rather than the callee.

How is that to be communicated to the callee? You seen to say that the 
service will return some sort of signed object that the recipient can 
understand. Presumably that object must include the name, number, and 
score in some crypto-protected form. I guess this means that the request 
must be of the form: please score (number,name,x,y,z) and return the 
score in cert showing only (number,name,score). This is presumably 
possible, though it seems a bit weird.

My problem with the above is that you suggest that giving more 
information will get a higher score. I don't understand why. If the 
name/number combination is valid, then its valid. How much better can it 
get than that? Any increased score due to more inputs being correct only 
pertains to the extra attributes, not the name/number.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 28 Aug 2013 11:30:20 -0400

OK good, the "package contains the phone number.  I was worried you were saying it didn't contain the number.  So the minimal "package" contains the name, E.164 number, and the signature of the validation service.

To avoid confusion, let's call the validation service's signature in the package the "varsig", and the SIP INVITE's STIR-based signature the sipsig (this would be the one in the STIR SIP header).

So let's say you, Brian Rosen, had your name verified by TrueName.  The package given to you by TrueName contained: {name="Brian Rosen", number="+17245551234", varsig=<sig-by-TrueName>}.

Signing that package with the sipsig for 17245551234 isn't what prevents cut-and-paste.  It would prevent someone from replacing the package while still pretending to be 17245551234.  But they couldn't do that *anyway*, or else the concept of STIR itself is broken, since the whole premise of STIR is to prevent someone else from claiming to be your number.

So let's talk about a different form of cut-and-paste: if you call me, I can copy just the "package" from your INVITE and put it in an INVITE of my own, and sipsig sign it with my own source number, and thus pretend to be Brian Rosen.  But what makes the package useful is the fact that it contains the phone number, and that we have a way to verify the phone number sender of the INVITE; and that's what prevents me from being able to re-use your package in my INVITE, not the the fact that it was sipsig signed by your private key.

In other words, the actual calling name binding and verification check required by receivers of the call is to verify that the phone number in the package matches the phone number of the INVITE sender; and STIR's sipsig verifies the phone number of the INVITE sender.  Using sipsig to sign the package isn't necessary.

-hadriel

---

From: Brian Rosen <[email-masked]>
Date: Wed, 28 Aug 2013 11:31:09 -0400

I'll try to step through this carefully.

1. Assume stir credentials assigned, so sending SP has credential for +12125551212
2. At service initiation sending SP gets name and other info from its subscriber.  It sends info to its chosen validation service (with number), and receives a score and a signature in response.  Re-validation is done periodically, say months.
3. At call time, sending SP puts name in display name part of From/P-A-I, and includes score and signature in stir header (and probably a digest of the name, so the name can be munged and have the stir header check work)
4. Receiver SP verifies signature in stir header
5. Receiver SP verifies signature of validator, which has a well known credential
6. Based on score, receiver SP decides how to populate display name for recipient device, or it may pass the score to the receiver device for display.

Brian
On Aug 28, 2013, at 10:30 AM, Paul Kyzivat <[email-masked]> wrote:

> Brian,
> 
> OK, clearly I don't understand what you are proposing. Can you explain it better?
> 
> On one hand I think you are assuming a service that can be queried with a bunch of factors, and returns a confidence score that that combination of factors is valid. E.g., I might present a name and number and get a score. Or I might present a name, number, and some other secrets known to the caller, and get a score.
> 
> Assuming there is some value in using that extra information, and assuming the extra information is something that the caller doesn't want to share with the callee, then I see why the caller would need to do the query rather than the callee.
> 
> How is that to be communicated to the callee? You seen to say that the service will return some sort of signed object that the recipient can understand. Presumably that object must include the name, number, and score in some crypto-protected form. I guess this means that the request must be of the form: please score (number,name,x,y,z) and return the score in cert showing only (number,name,score). This is presumably possible, though it seems a bit weird.
> 
> My problem with the above is that you suggest that giving more information will get a higher score. I don't understand why. If the name/number combination is valid, then its valid. How much better can it get than that? Any increased score due to more inputs being correct only pertains to the extra attributes, not the name/number.
> 
> 	Thanks,
> 	Paul
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Aug 2013 13:09:24 -0400

> I'll try to step through this carefully.

Thanks.

> 1. Assume stir credentials assigned, so sending SP has credential for +12125551212

And this is independent of the (name) validation service, right?

> 2. At service initiation sending SP gets name and other info from its subscriber.

So a key point is that the validation service is not in the call path.
It doesn't have the same real-time constraints.

> It sends info to its chosen validation service (with number), and receives a score and a signature in response.  Re-validation is done periodically, say months.

What is signed? Number+name+score?
ISTM that such a signature attests to the combination signed, and in 
particular that the score pertains to the other signed information.
I don't see how it would make sense for information that isn't signed to 
affect the score.

Or do you intend that the other info sent to the validator is proof that 
the requester is the holder of the credential for the number?
(In lieu of including that in calls.)

> 6. Based on score, receiver SP decides how to populate display name for recipient device, or it may pass the score to the receiver device for display.

ISTM that you can achieve the same effect by putting a signed number and 
an unsigned name in the call. The recipient then verifies the signature 
on the number. Then it takes the name and number and requests a score 
from a validator.

This requires the validator in the call path. But the receiving SP can 
cache these and build its own DB.

	Thanks,
	Paul

---

From: Brian Rosen <[email-masked]>
Date: Wed, 28 Aug 2013 13:34:01 -0400

Yes
Yes
Yes
> ISTM that such a signature attests to the combination signed, and in particular that the score pertains to the other signed information.
> I don't see how it would make sense for information that isn't signed to affect the score.
Take, for example, address.  The database has address.  If you pass name + number + address than the score is likely higher than if you just had name + number.  Or, it could be something like  prior addresses, or prior phone number, or home phone if the phone number you are validating  is a mobile number.

All of these fields are in the database, and the more you provide, the higher the score would be, assuming it's correct.

> 
> Or do you intend that the other info sent to the validator is proof that the requester is the holder of the credential for the number?
No, it's proof that the name being asserted is correct.  The database has a record with dozens of fields.  You can supply as many fields as you have on the query.  The score represents the likelihood that given all that data, the database has the correct record, and the name associated with that record is correct.

> ISTM that you can achieve the same effect by putting a signed number and an unsigned name in the call. The recipient then verifies the signature on the number. Then it takes the name and number and requests a score from a validator.
Well, yes, you could do that, although you have to pass the id of the validator (because there are more than one of them), and you have to do a data dip on the recipient side.  As proposed, there is no dip.  You get everything you need, since the credential of the validator is well known.

If there is a dip, you can get the name and the score and the signature.  I'm proposing there is no dip.

> 
> This requires the validator in the call path. But the receiving SP can cache these and build its own DB.
> 
> 	Thanks,
> 	Paul
> 
>> Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 28 Aug 2013 17:50:24 +0000

Based on what I've seen, the score is an indicator of confidence by the third party in the information presented. Thus, presumably a self-asserted name would get a score of 0, and somebody that the validator has checked out personally for a security clearance would get a high-90s score.

At least in the systems I've been told about, this does *not* depend on the amount of information provided, although you could obviously have different confidence scores for different parts. For example, a wireline service provider would have high confidence in the service address, possibly low confidence in the name of a residential subscriber (depending on, for example, the credit card information agrees with that name or not).

To make this simple, one model I envision ("by value") would have

"[call to 213 555 1234 at 13:48] service address is at 123 Main St. [95%]; name is Dewey, Cheatem & Howe, LLP [60%]." {signed: Verizon, carrier}

As I've mentioned earlier, in many (business-identifying) cases, for third-party assertions, you don't really need any new SIP additions or signatures, just a way to reliably associate a phone number with an assertion record. This doesn't work well for residential numbers, for the obvious privacy reasons, since you've just created an inverse white pages for everybody. The ARID Internet Draft I mentioned avoids this problem and doesn't require any new PKI.

Henning

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Aug 2013 13:55:08 -0400

> All of these fields are in the database, and the more you provide, the higher the score would be, assuming it's correct.

Sorry. I'm still not getting it.
Why is the score higher, and if so, is that relevant to the callee?

What is the score measuring?
You seem to assume that this DB has a bunch of entries, and the score 
measures how closely the query matches exactly one entry. But that isn't 
interesting here.

All the caller wants to know is how likely it is that the name is 
associated with the number. What else the caller knows about the db 
entry is not relevant to the callee.

	Thanks,
	Paul

---

From: Brian Rosen <[email-masked]>
Date: Wed, 28 Aug 2013 14:00:57 -0400

In the systems I know, the more information that is presented, the higher the likelihood field of interest is correct, because the sources of the data vary a lot, and there are overlapping records.
This arrises in consumer data because there is no single universal id to use to construct an individual record for each actual person.  

Brian

---

From: Brian Rosen <[email-masked]>
Date: Wed, 28 Aug 2013 14:17:43 -0400

I'm getting to the limit of what I know about these systems, so I may have to go back and find out more, but as I understand it, the fundamental thing the database is scoring is how likely the set of data presented represents a real person.  Because there are many sources of data going into the database, it isn't possible to know from a small set of data, like a phone number, which records the database may have match.  The more data provided, the larger the ability of the database to correlate what it knows and determine whether the information supplied is good.

So, indeed, if you gave it a good name, a good phone number and a bad address, you likely would get a much lower score than if you just gave it a good name and good phone number, but if you gave it a good name, a good number AND a good address, you get a higher score, and the higher score does mean that the name is more likely correct than if address was not supplied.

So the score really does represent what you want to see - it correlates well to the probability the name is correct (since the address isn't available to the recipient, all it has is the name and the number, and it knows the number is correct).

Brian

On Aug 28, 2013, at 1:55 PM, Paul Kyzivat <[email-masked]> wrote:

> You seem to assume that this DB has a bunch of entries, and the score measures how closely the query matches exactly one entry. But that isn't interesting here.
> 
> All the caller wants to know is how likely it is that the name is associated with the number. What else the caller knows about the db entry is not relevant to the callee.
> 
> 	Thanks,
> 	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 28 Aug 2013 18:17:56 +0000

This contradicts what a large provider of such services told us, but your mileage and database may vary. (They base the confidence of a particular "is the person filling out that webpage really the person they claim to be" transaction, a slightly different problem, on the amount of other information, such as financial transactions, provided and verifiable. That may be what you're referring to.) The additional information is *not* made available to anybody else. This is conceptually similar to the additional security questions that ask where your first pet was born.

For our purposes, we really have two inter-related problems:

(1) Who made this call? In other words, assume a near-perfect record of call makers (humans and/or organizations), and identify one of them uniquely. We all agree that names are a somewhat imperfect identifier, but clearly used for other business transactions; there is no reason the identity for businesses couldn't be some unique non-name identifier (like the DUN I mentioned before).

(2) Does the person have these attributes, such as name, address and business license, and how confident are we in each attribute?

There are potential problems with both steps, such as the same physical person having multiple records and multiple people getting accidentally merged into one record. (The latter is apparently a problem for credit records, with not-so-pleasant outcomes.) This is probably less of an issue for business records, although some parts of the information may well be out of date or never been correct. (For example, most small businesses only update their state incorporation records once a year, so the address may be wrong, and the state registrars don't validate the postal address beyond possibly checking the existence of the address.)

Henning

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, August 28, 2013 2:01 PM
To: Henning Schulzrinne
Cc: Paul Kyzivat; [email-masked]
Subject: Re: [cnit] [stir] Reputation vs Display name (was Textual caller ID)

Brian

---

From: Alex Bobotek <[email-masked]>
Date: Wed, 28 Aug 2013 11:16:25 -0700

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: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Wednesday, August 28, 2013 6:53 AM
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [cnit] [stir] Reputation vs Display name (was Textual caller ID)

Yes

>> 1. We're proposing to move the name determination from the 
>> termination to the origination 2. We're proposing to send a score
>> 
>>> 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)
>>>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 28 Aug 2013 18:41:43 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Alex Bobotek
Sent: Wednesday, August 28, 2013 2:16 PM
To: Brian Rosen; Paul Kyzivat
Cc: [email-masked]
Subject: Re: [cnit] [stir] Reputation vs Display name (was Textual caller ID)

Regards,

Alex

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

Yes

---

From: Brian Rosen <[email-masked]>
Date: Wed, 28 Aug 2013 14:43:09 -0400

I'm suggesting the originating service provider seek a validation from a  3rd party validator in most cases, although I wouldn't entirely rule out having the originating SP do the validation itself if it has access to enough data to do it well.  The mechanism would not allow the origination to tamper with the score or substitute a different score from an unrelated number, or change the name associated with the validation.

Doing it at the termination side is no where near as good, because the terminating side doesn't have enough information to get a good score.

Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Aug 2013 14:44:22 -0400

On 8/28/13 2:00 PM, Brian Rosen wrote:
> This arises in consumer data because there is no single universal id to use to construct an individual record for each actual person.

This is not my field, and I'm not a statistician either.
But what you say above makes no sense to me.

Suppose I query this DB with just a number and name.
There might be 0,1, or >1 matching records in the DB.

If there are zero matching records, then I expect a 0 score.
If there is one matching entry, then I expect a score of 1.

If there is more than one matching entry, I still expect a score of 1. 
Its an odd case, but irrelevant to me.

That assumes the DB has total confidence in the info it contains.
If not, then the score can be reduced to reflect the confidence in the name.

If there are multiple matching entries, and the confidence level in the 
name varies from one to another, then I guess the confidence level in 
the result must be some combination of the values from the multiple 
records. And in *this* case, having more information can reduce the 
match to a single record, and then to a single confidence level for the 
name. But frankly this sounds like nonsense to me. What is a real world 
example of this?

Trying to construct an example:

1) name=foo, number=+12125551212, address="1 main st.", confidence=.75
2) name=foo, number=+12125551212, address="2 state st.", confidence=.25
3) name=bar, number=+12125551212, address="2 state st.", confidence=.10

If I query with name and number there are two matches. The confidence I 
get in the result is some combination of .75 and .25. It is really 
debatable whether I should get the max, min, or average, or even 
something greater than the max. Should the presence of an entry that 
matches the number and not the name reduce the score?

Now suppose the caller does the query and also provides the address, 
matching (2). Does that mean the confidence level in the name should be 
.25? The callee doesn't get the address, so its correctness is 
irrelevant to him.

This all seems dubious to me.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Aug 2013 14:52:22 -0400

> (1) Who made this call? In other words, assume a near-perfect record of call makers (humans and/or organizations), and identify one of them uniquely. We all agree that names are a somewhat imperfec…

But we can simplify this problem by reducing it to "what number made 
this call?"

> (2) Does the person have these attributes, such as name, address and business license, and how confident are we in each attribute?

Then this becomes "does this number have these attributes?"

 From Brian's comments it seems that many of the DBs out there aren't 
designed to answer precisely this last question. But it also seems that 
a DB to do that could be derived from them.

---

From: Brian Rosen <[email-masked]>
Date: Wed, 28 Aug 2013 15:24:19 -0400

> If there is one matching entry, then I expect a score of 1.
No.  The system would probably give this a fairly low score because it does't have much to go on.  It would have one match, but that's a pretty low.  
> 
> If there is more than one matching entry, I still expect a score of 1. Its an odd case, but irrelevant to me.
No, it's the common case.  The database gets data from a wide variety of sources.

For example, it may have billing data from a utility provider, login data from a website, property records from a public real estate database, and drivers license data for some states.

In each of these, it may or may not have an address, may or may not have a phone number, and the name may be the same or similar.  The more similarities and correlated data, the higher the confidence it has in  the data.  It tries to match records, but it doesn't know that it has an exact match, so it uses statistics.   When you query it with a small amount of data, it gets some records that may have weak correlation, but if you add data, then the correlation between the records is increased.
> If not, then the score can be reduced to reflect the confidence in the name.
It's more like the more correlation of the data from multiple sources, the higher its confidence.  It does actually take into account where the data comes from, but, as I understand it, it favors recurring data (same name/number/address) over the source of the data.

> 
> If there are multiple matching entries, and the confidence level in the name varies from one to another, then I guess the confidence level in the result must be some combination of the values from the multiple records. And in *this* case, having more information can reduce the match to a single record, and then to a single confidence level for the name. But frankly this sounds like nonsense to me. What is a real world example of this?
> 
I don't know enough how to tell you how it handles this.  It probably would be easier to understand if you assumed there were 10 or 20 source records that had only 2 or 3 big discrepancies (foo vs bar and 1 main vs 2 state).  As I understand it, no record source is really considered golden, so a range of .1 to .75 is probably overstating the range of source reliability assumed.  It would favor foo and 2 state st., but I think the score for name would be pretty low with these data.

> 
> If I query with name and number there are two matches. The confidence I get in the result is some combination of .75 and .25. It is really debatable whether I should get the max, min, or average, or even something greater than the max. Should the presence of an entry that matches the number and not the name reduce the score?
If you just queried with number and asked for name, it would give you foo, and a low score.  In most use cases, the database doesn't actually give you any field content. It just gives you the score.  The database we run grew out of the CNAM database, so we still will give that data out for that service, but most users can't query for field contents, only score.

> 
> Now suppose the caller does the query and also provides the address, matching (2). Does that mean the confidence level in the name should be .25? The callee doesn't get the address, so its correctness is irrelevant to him.
The caller queries with all three.  The score will be higher (assuming we have a match) with 3 items in the query than it will be with two (name and number) or one (just number) which is all the termination could query with if we use the current model.  The score will be very low if you send us all three data items and we have none, or only a small number of source records that match.

> This all seems dubious to me.
It works for a whole lot of use cases.  It should work pretty well here.  No guarantees though.

Nature of the name game.

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 29 Aug 2013 09:46:05 -0400

I think a lot of these multi-source needs for your particular implementation arose because you weren't on the originating side, but were doing it as a third party CNAM DB for the termination, no?  I think a verification provider working for the originating carriers - being paid by them - wouldn't bother with most of these extra data sources.  If they wanted to have a good reputation, they might require more than just the originating carrier's claim, but probably not much more.

Regardless, I think the "score" thing is a bad idea - at least as described so far.  It doesn't matter what the verification service thinks the score is, it matters what the call receivers can do with that information.  If they don't have a relationship with the verification service (which is the basic premise of this model to begin with), then I don't see how they'd really know what a score of 72 vs. 63 means.  I think the *verification service* should be the one deciding what their own score means, by deciding whether their internal score is at a sufficient threshold to be a usably reliable name for others or not, and thus asserting it or not.  Telling other people a score is just a cop-out and going to cause interop problems in terms of actual usability.

If you really want this type of thing, I suggest following Verisign's "Class" type model for certificates, since at least it might be defined well enough for other people to figure out usages for.  And we might want to ask some folks from that world how successful that has been and if it had issues or not. (I don't know)

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 29 Aug 2013 09:47:07 -0400

ISTM the "score" shouldn't be put in a separate SIP header or param by the carrier - it should be inside the signed "package" thingy, because it's the verification service who's claiming this score, and the verification service that therefore has to sign the {name, number, score} package.  The originating carrier isn't the one generating this thing itself.

This "score" discussion is getting us off-track though, I think.  It doesn't matter what one specific vendor's features or implementation model is - it doesn't even matter whether we think some future CNIT mechanism should use a "score" concept to begin with.

All we need to know right now is if CNIT needs to have some blob signed by STIR.  I don't think it does, and no one seems to be arguing otherwise.

Even at a 10,000 foot view level, STIR is only signing enough stuff to prevent cut-and-paste attacks of the source calling number.  So long as CNIT ties itself to the source number somehow, we don't need to sign it with the STIR SIP signature.  And if CNIT doesn't tie itself to the source number, signing it with STIR doesn't prevent CNIT from being cut-paste by others.

-hadriel

---

From: Brian Rosen <[email-masked]>
Date: Thu, 29 Aug 2013 10:19:29 -0400

The problem with names is that they aren't unique.  So you can't get a black/white answer to a question of "is this call coming from this guy".  Also true, but somewhat less so, for enterprise names.  There, we have better notions of what acceptable variations are, but we're subject to some of the shenanigans of the UTF-8 variety.  We also can't reliably tie a name to another identity, so we can't attach a name to a number with certainty.

Scores deal with that reality.  If you get rid of scores, you are losing information.  I think devices and services can usefully handle scores, and if you want to threshold it, fine, do that.

I have some sympathy with the inability to normalize scores.  However, it's reality - we don't have agreed upon metrics for these things.  If there are a small number of validators, then termination devices and services can handle those differences, and we'll probably see some 4th parties providing conversion services.

The cnit package is probably best as a new header, with the score, the validator identity and the signature as parameters.  There isn't a good reason to have it be a blob, repeating the number and the name for example.  We would have (a pretty simple) canonicalization of the name in From/PAI, the score and the canonicalized number covered by the signature.  The validator ID could be a URI or a token from a registry.  The termination runs a process similar to the stir process - picks apart From/PAI to extract the canonicalized name and number, takes the score from the header and verifies the signature.  Then it evaluates the score knowing the validator to decide what to present to the user.

I think you are probably right that IF the cnit package has the number, and IF both cnit and stir headers (whatever they are) are present, then the cut/paste protections of the stir signature prevent a cut/paste of the cnit signature.  The sender or observer could cut/paste a different cnit package, but it would have to be tied to the number.
Sending just the CNIT package without the STIR signature would allow a cut/paste of the cnit package, but that's probably not a problem.

Brian

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 29 Aug 2013 11:11:39 -0400

On Aug 29, 2013, at 10:19 AM, Brian Rosen <[email-masked]> wrote:

> The problem with names is that they aren't unique.  So you can't get a black/white answer to a question of "is this call coming from this guy".  Also true, but somewhat less so, for enterprise names.  There, we have better notions of what acceptable variations are, but we're subject to some of the shenanigans of the UTF-8 variety. 

Of course not.  But that has nothing to do with a "score" given to others.  If you're claiming a name of "Brian Rosen", the fact that there are other Brian Rosen's doesn't make your name more or less valid; nor should it affect what a verification service tells others about your name's validity.  It might cause the verification service to find more authentication factors to believe you, but that's the verification service's job.  At the end of the day, the whole point of a verification service is to verify things.  Putting the onus on everyone else to decide how valid it is or not, based on scores, misses the whole point of a verification service.

Put this in the context of x.509 certificates and Certificate Authorities.  When you connect to "https://fidelity.com", the certificate doesn't say "I'm 73% sure this is Fidelity".  The closest thing I can think of is Verisign's certificate Class model, where the different classes define how "strong" the assertion is, based on how much validation Verisign performed (among other things).  I am *not* an expert on how their classes truly get used, but as far as I know the point of their classification system is to be used in different contexts/applications.  For example they have one sufficient for email, separate from one sufficient for monetary business transactions.

>  We also can't reliably tie a name to another identity, so we can't attach a name to a number with certainty.

There's never such a thing as "certainty" obviously, but any assertion about calling name identity must be claimed to be linked to a phone number, because the calling number is all STIR provides.  Having the originator use its STIR-based private key to sign a name doesn't make the name itself *valid*, nor does it mean the name is linked to the phone number.  For example, if you get a package with just {name="Brian Rosen",versig="<sig-of-TrueName} and put that in the SIP message and sign it with your private key, it doesn't create a trustable binding between your name and the number, nor between your name and the call request. 

An obvious example of why not is because I can then take your package and sign it with my own STIR private key, and voila, I'm suddenly Brian Rosen with a different phone number for a new call.

What that would do is identify who signed the call request claiming such a name, so that if they lied we could go after them with non-reputable proof they claimed it.  But I don't think we should claim STIR signing has legal implications of that type, regarding what else is covered by the STIR signature.  There was debate about that before many years ago in SIPPING, and we can revisit it of course, but there are some nasty consequences for carriers if we start down the road of legal implications of other data being signed.

-hadriel

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 29 Aug 2013 23:33:43 +0000

As I've noted, I'm skeptical on numeric scores as well, but maybe it helps to distinguish two sub-cases that we've been discussing:

(1) plain display name, i.e., just a non-length-constrained version of today's textual caller ID

(2) more extensive description (address, line of business, BBB score, etc.)

For pure names, I don't think scores help much, as this is really mostly about where the information came from, if provided by a carrier. For names, getting back to roughly the "good old days" seems a good step forward, i.e., being able to tell who provided that information and generally being reliable. With a bit more effort, we can probably have four common cases that don't seem to impose any additional liability on carriers:

(1) Name only, user asserted; might be signed by caller, but that simply prevents third party munging

(2) Name only, carrier asserted; possibly a separate signature, particularly if the number signature is done by the end user, as in

{call-identifying information; 212 555 1212} [signed with E.164 key, but could be signed by John Doe]
{call-identifying information; John Doe; based on billing data} [signed by Verizon]

In this case, Verizon simply asserts "This is my customer and John Doe is the billing record". If the recipient has never heard of the signing party, they may decide to ignore the signature.

(3) Separate name and "Organization" header, common for organizations where the carrier wouldn't really know who is the caller within the organization and thus wouldn't want to sign for that.

From: Martin Gecko <tel:+12125551212>
Organization: GEICO Insurance
Identity: {call identifiers, GEICO Insurance; based on=billing} [Verizon]
Identity: {call identifiers, 1225551212} [GEICO]
Identity: {call identifiers, Martin Gecko; based on=assertion} [GEICO]

In this case, having Verizon include the fingerprint  of the GEICO cert would make this more useful. GEICO can provide an EV cert, if desired.

(4) Signed Call-Info for more extensive information
From: Martin Gecko <tel:+12125551212>
Call-Info: http://www.trustus.com/GI8LvzC3mPWHwsioD
Identity: {call identifiers, Call-Info content; based on=third-party} [Verizon]

It would be helpful if the recipient could ascertain that Verizon is responsible for the calling number, but this may not be strictly necessary if you're willing to take some lower-probability risks. Given the call identifying information, only somebody on the call path could sign and cut-and-paste doesn't seem to work.

As far as I can tell, this doesn't force the carrier to take any additional informational risk, but makes the source of the information explicit, rather than the "could be LIDB, could be some unknown CNAM, could be the caller" guessing game of today.

Henning

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
Sent: Thursday, August 29, 2013 11:12 AM
To: Brian Rosen
Cc: [email-masked]; Alex Bobotek; Paul Kyzivat
Subject: Re: [cnit] [stir] Reputation vs Display name (was Textual caller ID)

-hadriel

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 29 Aug 2013 23:41:41 +0000

I'm not a PKI expert by any stretch, but have had to deal with certs for a business I run, so from a user perspective, leaving the different applications (email, web) aside, there seem to be two widely-available versions for identity (not software signing and other purposes):

- standard certs that only prove that the entity owns the domain name or email address; all other information (country, organization name) are user-asserted and not verified. Issued automatically, only by proving operational control of the domain. (Temporary possession by the Syrian Electronic Army excepted.)

- EV certs that require a validation by a legal representative; see https://www.cabforum.org/Guidelines_v1_4.pdf

The EV cert guidelines make interesting reading.

Henning

---

From: Stephen Kent <[email-masked]>
Date: Fri, 30 Aug 2013 06:55:35 -0400

Henning,

What you cite as "standard certs" may be replaced by DANE, using 
self-signed certs,
and avoiding the pitfalls of the current browser PKI model.

EV certs attest to the potential trustworthiness of the cert holder, 
rather than
just the name binding. But, the EV cert auditing is pro forma, not very 
rigorous,
despite what one may read.

The reason DANE is a great successor to "standard certs" is because it 
follows the
model IO noted earlier, i.e., enabling an entity that is authoritative 
for a namespace
to act as a CA.

I am still quite skeptical that any "scoring" system will be 
intelligible to users.

I also have come to question the motives of some of the most vocal 
proponents of such
systems, wondering if their employers may be financial beneficiaries of this
technical approach.

Steve

---

From: Brian Rosen <[email-masked]>
Date: Fri, 30 Aug 2013 10:24:04 -0400

> I also have come to question the motives of some of the most vocal proponents of such
I assume that is directed at me.

While true that my employer has such capability and would stand to make money on the idea, that problem exists, in spades, with the entire stir effort.  Nevertheless, I would not be pushing the idea if I did not personally think this will be of great value to the caller.  You have no basis to question my sincerity.    

I submit that it is exceedingly hard for any entity to provide a name with certainty anywhere near the level of certainty we generally assume when we state values.  We will be able to state with some large degree of certainty that the phone number is correct.  We will have MUCH less certainty of the name, and wide variation of certainty, no matter what we do.  To assume, or say otherwise is foolish.

When you have varying levels of certainty, it helps, a lot, to have an idea of HOW certain you are.  I will give you an example in another domain.  When we report your location as latitude/longitude based on some measurement, there is both uncertainty (we know you are within some area, say a radius around a point) and confidence (what is the probability you are in that circle), which we have ways of expressing.  In location, unlike names, we have ways of measuring confidence and uncertainty.

Having two variables (confidence and uncertainty) does better represent reality, but makes it exceedingly difficult to compare values.  They are related, but the relationship is complex and you have to know a lot about the measuring system and the data to, for example, take uncertainty at 60% confidence and determine the uncertainty at 90% confidence.    Comparing uncertainty at different confidence levels is exceedingly difficult.

In names, we probably have both uncertainty and confidence.  Henning used the example of scoring confidence by source of data.  I used correlation of records to show how one might determine uncertainty.  The state of the art in validating names doesn't really assign separate confidence and uncertainty.  They tend to be mushed into a single score.  Maybe it should be separate, but it isn't.

You may be aware of this thing called "Big Data Analytics".  There is science behind scoring data like what I'm advocating, but we're still pretty much at the beginning of understanding it.

What is not so hard, is using it.  Lots and lots of companies and researchers are successfully using the data, for applications not so dissimilar from what we're discussing.

The situation we have now is that we have service providers who will assert names that have no validation.  It's what the subscriber says it is.    Some service providers are better than others, but there are many service providers, and no way to compare them.  The only way around that today is to use the termination side query that exists, but the uncertainty is medium with only the phone number as input.  Confidence is all over the map, depending on how much data we have on the phone number and the name.  We currently threshold the data, and that threshold is not controllable by the user.  Not a great situation, but it works within the limits of the current caller-id paradigm.  No other uses of the database I'm aware of is that simplistic.  We know too much about the data to be that simplistic.

We can do what Henning proposed - send multiple names with who asserts them and what it represents.  Labeling is helpful.  What the labeling does is allow the termination to come up with it's own notion of confidence.  I'm not worried about sorting out that information at the termination end.  However. to ignore score is to ignore reality.  We have, compared to number, low to medium confidence if you want reasonably high certainty that the name is right.  

Sending a score is cheap.  Make it optional if you wish.

Brian

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Fri, 30 Aug 2013 10:55:34 -0400

Brian,

You said:

"We can do what Henning proposed - send multiple names with who asserts them and what it represents. "

Isn't this problematic in the "benign spoofing" scenario?  Suppose the doctor-on-the-golf-course example.  He places a call to a patient using his cell phone, but wants the called party's caller ID to display the name of his practice.  But then this call arrives at the terminating user or SP, who sees a greater certainty associated with his real name than with the name of his practice.  How would we prevent the terminating side from over-riding what he's intended (and we've intended to allow him) to do?

tim

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 30 Aug 2013 15:05:45 +0000

I suspect you would need a "portable" mechanism, which then starts to look awfully similar to certs where a CA-like entity (say, the home carrier in our case) provides their customer with credentials that the customer can use outside that relationship. By analogy, this isn't altogether different from the model of various identity-like cards, from a library card to a student ID, that are used outside their original context, but it raises all the usual CA-like concerns. Some of these are mitigated if, DANE-like, the receiving entity can validate that Verizon is indeed the carrier for a certain phone number, so that trusting a Verizon-issued credential is reasonable. Thus, you get a trust chain (among several possible):

Caller proves assignment of phone number --> phone number is mapped reliably to carrier --> carrier asserts limited attributes of customer

We more-or-less have the middle step in place today and STIR provides the first step.

Longer term, I wonder if the mediated call signaling model will become more common, i.e., where the doctor's phone routes calls through an outbound proxy in the office. That reduces the number of cases where you need such portable credentials.

-----Original Message-----
From: Dwight, Timothy M (Tim) [mailto:[email-masked]] 
Sent: Friday, August 30, 2013 10:56 AM
To: Brian Rosen; Stephen Kent
Cc: [email-masked]; Henning Schulzrinne
Subject: RE: [cnit] [stir] Reputation vs Display name (was Textual caller ID)

Brian,

You said:

tim

---

From: Dave Crocker <[email-masked]>
Date: Fri, 30 Aug 2013 07:53:21 -0700

> I am still quite skeptical that any "scoring" system will be

No need for skepticism.  Skepticism is based on doubt and this is 
simpler than that.

It won't be intelligible; and to the extent it is, it won't affect their 
behavior very much.  This isn't a new topic, except in this venue.

> proponents of such systems, wondering if their employers may be
> financial beneficiaries of this technical approach.

Most people in IETF discussions have some sort of bias.  By itself, 
that's not typically very interesting, unless a person has undue 
influence on the decision-making and no counter-balance in the process.

So on the average, our protection against the biases is diverse 
participation, with serious, frank, open and constructive exploration 
and debate.  Focusing on the substance makes personal bias mostly 
irrelevant.

For me, one of the serious flags gets raised when an assertion is 
inappropriately simplistic, especially when accompanied by attempts to 
terminate that frank and open discussion that would explore the assertion.

In the current discussion, there is a tendency to assume that the topic 
is relatively straightforward in terms of engineering, deployment and 
outcome (effects).  I am not aware of any basis for such confidence, but 
am aware of quite a bit of field experience to the contrary.

The group really should seek to formulate some very clear, non-technical 
statements about what it trying to produce and the basis for believing 
that it will be useful.  So far, quite a bit is getting buried in verbal 
handwaves that approximate the cliche'd "and then a miracle happens".

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 30 Aug 2013 12:28:48 -0400

I think I'm repeating myself, but maybe if I say it differently it will be clearer...

The challenge with sending a score is that the receiver (a) can't believe it, and (b) doesn't know what it truly means relative to the receiver's notion of score values.  

Afaik, today email spam systems do have notions of score, but it's something the receivers create themselves - it's under the control and policy decision of the receiver.  For example, when BigCorp receives an email from someone, then they run a bunch of checks against the email headers+body resulting in a final score and determine based on that whether to put the message in a spam folder or not. (I'm simplifying)  But that's something BigCorp can control, knowing how the score is calculated and trusting their own spam-filter systems/code.

I don't debate for a second that TARGUSinfo databases have this type of information.  But when you're queried by the terminating carrier, you could actually give them that scoring information, today.  That would make sense because they have a relationship with you - they're paying you for the data, so they trust you, and since they have a direct relationship with you they can know what the score actually means and thus how to determine their local thresholds and policies.  If you'd like to define a way for that to work, that makes some sense to me - it's what draft-wing-sipping-spam-score was trying to do.  But instead what you're talking about is different.

What you're proposing for CNIT is a reputation-based naming authority.  It's really the same as web-pki style CAs, but much weaker.  Let's assume the CA model worked perfectly.  I've been told there are ~160 trusted CAs.  Do you think CNIT will end up with around the same, on a world-wide basis?  If so, is it likely that every receiving carrier of the ~10,000 SIP providers world-wide would understand and trust the properties of a 0-100 score from ~160 different CAs they have no direct relationship with?  Even if we focus just on the USA, there're ~1500 providers and about a dozen sources of this type of data today.

There is something like this in the email world, fwiw: RFC 5518 vouch-by-reference.  I don't know if it's used or not in the real world, but its assertion is a lot simpler and more constrained.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 30 Aug 2013 12:44:36 -0400

> Caller proves assignment of phone number --> phone number is mapped reliably to carrier --> carrier asserts limited attributes of customer

I think the problem with this is that we know we can't trust the "carriers".  That's how we got to STIR to begin with.  I totally trust Verizon, and a bunch of big carriers for that matter, but there are lots of SIP service "providers", of various sizes and shades of pink.  For example we know for a fact that some "providers" are complicit in generating fake calling numbers *and* names - it's part of their business model.

If we could decide which ones were bad purely on statistical reputation alone, and stop displaying their numbers+names, then the STIR solution would be quite different... maybe even unnecessary.  We know we can't do that for political, legal, and operational/scalability reasons.  That's why we think doing STIR the way we've been talking about it is worth-while, presumably.  No?

> Longer term, I wonder if the mediated call signaling model will become more common, i.e., where the doctor's phone routes calls through an outbound proxy in the office. That reduces the number of c…

Some of that happens already today, fwiw.  I do expect it to become more common if STIR gets deployed, if it's non-trivial to authorize third-party source identity use.

-hadriel

---

From: Brian Rosen <[email-masked]>
Date: Fri, 30 Aug 2013 13:07:06 -0400

While I understand the problem you are pointing out, I don't think it's anywhere near as bad as you are projecting it.  I think in any country, there are only a small number of suitable validation services.  I think that for any given recipient, knowing the in-country validators is good enough, or at most the few neighbor country's validators.  I think that the most likely entities to actually deal with the value are folks like Apple and Google, or Samsung and Nokia who create with the received call UIs, and they could develop methods rate a few thousand validators.  I expect we will see meta-rating services that deal with the problem also.  If the score is a scaler, then it's possible to derate a score if you have a rating on the scoring service.

Mostly I would say that having the score is infinitely better than not having the score, even with the problem that state of the art today doesn't let us have a more definitive mechanism.

Brian

---

From: Dave Crocker <[email-masked]>
Date: Fri, 30 Aug 2013 10:13:20 -0700

On 8/30/2013 9:28 AM, Hadriel Kaplan wrote:
> The challenge with sending a score is that the receiver (a) can't
> believe it, and (b) doesn't know what it truly means relative to the
> receiver's notion of score values.

+1

> Afaik, today email spam systems do have notions of score, but it's
> something the receivers create themselves - it's under the control
> and policy decision of the receiver.

Receivers have very complex filtering engines, typically with /layers/ 
of many different scores, based on a variety of attributes, and factored 
into highly contingent analysis engines.

Users never see any of this; the engines feed into basic handling 
choices, such as inbox vs. spam folder.

Over the last 15 years, there have been a number of startup company 
efforts to "empower' end-users with quality assessment information. 
Essentially all have failed.

The only report I've heard of real efficacy was at Yahoo, where they 
boiled it down to a trust/don't-trust/don't-know distinction, but this 
certainly has not gained traction in the industry.

References to thinks like EV certs could benefit from some reporting on 
efficacy; my impression is that they've had no effect on end-users, any 
more than the lock symbol at the bottom of the web page.

> What you're proposing for CNIT is a reputation-based naming

An essential point from many years of email reputation -- and by the way 
way, physical world reputation -- is the need for multiple and 
potentially competing services.

> There is something like this in the email world, fwiw: RFC 5518
> vouch-by-reference.  I don't know if it's used or not in the real
> world, but its assertion is a lot simpler and more constrained.

VBR isn't used.  Reasonable idea, but no market traction.

And then there's the more recent Repute working group that is just 
finishing up:

    http://datatracker.ietf.org/wg/repute/

On the average, folks tend to approach abuse remediation with an 
assumption that it is tractable to assertion of a bit more control and 
that that isn't difficult.

On the average, that hasn't produced encouraging results.

d/

---

From: Brian Rosen <[email-masked]>
Date: Fri, 30 Aug 2013 13:21:50 -0400

Hadriel

You seem to be rejecting all ideas.

If you don't like scoring and you don't like multiple names with source, what do you like?

?Magic happens here?

I don't think it's going to be hard to authorize third party use.

We seem to agree that within a country, there needs to be one database of credentials.  Since there are many entities that delegate numbers, that database needs a protocol or API to enable delegation from all those entities.  It will be able to track delegations, so that if the national number authority delegates a number to Carrier A and Carrier A delegates it to SP B and SP B delegates it to enterprise C, then the authority, A and B will use that protocol or API to tell the database.  The database will then know to allow enterprise C to permit enterprise D to assert the number on its behalf, and can do so with the same protocol or API.  The credential used to enable the protocol or API to do the delegation could be the same credential used to sign, although the database probably needs to assign an identity to A, B, C and D to allow a new delegation to occur.  That identity (it's like a SPID, but needs to allow enterprises, doctors and others to get IDs) is associated with the delegations.  The database might only expose the credentials for a given number, but it tracks the actual delegations inside as identity 1 delegated TN range X to Identity 2 at such and such a time.  Delegations have to be revocable, of course (cessation of service or return of numbers to inventory).

Brian

---

From: Dave Crocker <[email-masked]>
Date: Fri, 30 Aug 2013 10:26:51 -0700

> You seem to be rejecting all ideas.

Whereas you seem to be rejecting all concerns.

So, Brian and others who are convinced that this topic is 
straightforward and easily amenable to effective mechanisms:

      Please cite your evidence.

      Look for other areas with a history of abuse that were 
significantly mitigated by the approach you are espousing.

Over the course of my own involvement in anti-abuse, over the last 15 
years, I know of none that qualifies.

> We seem to agree that within a country, there needs to be one database of credentials.

Oh?

d/

---

From: Brian Rosen <[email-masked]>
Date: Fri, 30 Aug 2013 13:40:40 -0400

Okay.  We support dozens of customers who had serious fraud abuse until they started using our database to evaluate callers to their call center.  Typically, they query with 3-6 fields.  They get a score back.  They decide how to handle the caller based on the score.  Responses range from a polite goodbye to a what can we do to get your business, and lots in between.  The call taker doesn't often see the score directly - the call branch tree is modified automatically (what to ask, what to offer, what to accept, how to handle exceptions).  I'd have to get some numbers to cite what the usual decline in fraud is, but we have lots of long term customers.

The part of this that I can't cite a specific example for is what some clever UI developer will come up with to use the data.  What I know is, it's useful, and we'll figure out a way.  It might have binned responses.  It might change the response if this is the first call from the identity.  It might supply a thumbs up/down selection that is used for other callers.  It might supply a Travelocity style rating.  Dunno, but I have high confidence (with moderate uncertainty) that folks like Apple and Google will figure out a good UI to use the data.

Brian

On Aug 30, 2013, at 1:26 PM, Dave Crocker <[email-masked]> wrote:

> So, Brian and others who are convinced that this topic is straightforward and easily amenable to effective mechanisms:
> 
>     Look for other areas with a history of abuse that were significantly mitigated by the approach you are espousing.
> 
> Over the course of my own involvement in anti-abuse, over the last 15 years, I know of none that qualifies.
> 
> 
>

---

From: Dave Crocker <[email-masked]>
Date: Fri, 30 Aug 2013 10:41:13 -0700

On 8/30/2013 7:24 AM, Brian Rosen wrote:
> I submit that it is exceedingly hard for any entity to provide a name
> with certainty anywhere near the level of certainty we generally
> assume when we state values.

That's a foundational point.  What is not clear is how that is factored 
into assumptions about the receive-side evaluation process and why the 
assumptions are valid.

> When you have varying levels of certainty, it helps, a lot, to have
> an idea of HOW certain you are.

In the abstract, perhaps.   In the current discussion, how is 'variable 
certainty' to be used and by what agent and why is that expectation 
plausible?

For example, one scenario might provide for the callee (human user) to 
see a name and a certainty factor and assert that the callee will make 
differential choices accordingly.  In practice, the callee is likely to 
confuse the certainty assertion with a quality/safety assertion. 
Anything less than 100% will therefore get rejected.

But that's just a guess.  The reality of designing such human 
interaction mechanisms is that the right choice is always based on 
testing, not theory.

> You may be aware of this thing called "Big Data Analytics".  There is
> science behind scoring data like what I'm advocating, but we're still
> pretty much at the beginning of understanding it.
>
> What is not so hard, is using it.

To the extent that you mean use by an average end-user, who is making a 
real-time decision about whether to answer the call or assess who is 
calling them, you are quite wrong.

> Sending a score is cheap.  Make it optional if you wish.

    1. Cheap is not the same as free.
    2. Cheap is not the same as useful.

d/

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 30 Aug 2013 14:01:47 -0400

On Aug 30, 2013, at 1:07 PM, Brian Rosen <[email-masked]> wrote:

> While I understand the problem you are pointing out, I don't think it's anywhere near as bad as you are projecting it.  I think in any country, there are only a small number of suitable validation services.  I think that for any given recipient, knowing the in-country validators is good enough, or at most the few neighbor country's validators.  I think that the most likely entities to actually deal with the value are folks like Apple and Google, or Samsung and Nokia who create with the received call UIs, and they could develop methods rate a few thousand validators.  I expect we will see meta-rating services that deal with the problem also. 

I agree there are a limited number of smartphone vendors.  It would be great to get them involved with any of this stuff (like involved in STIR, for example).  Unfortunately they don't appear to be involved.  And the smartphone market, while incredibly powerful and growing dramatically, still only represents ~20% of call-receiving "phones".

Furthermore, using an analogy with email: while getting native email POP3/IMAP *clients* to do stuff is nice, in practice it's the SMTP email servers that do a bulk of the work as far as I can tell.  Whether they be corporate servers like MS Exchange and the spam-filtering boxes, or hosted ones like gmail, yahoo, and hotmail.  ISTM that's pretty similar to the SIP world of corporate IP-PBXs and the SIP Service Providers.

>  If the score is a scaler, then it's possible to derate a score if you have a rating on the scoring service.

I appreciate the business opportunity for SBCs to manipulate scores based on the meaning and reputation of various validation services, but I don't think it's a good idea. :)

> Mostly I would say that having the score is infinitely better than not having the score, even with the problem that state of the art today doesn't let us have a more definitive mechanism.

The reasons it's not infinitely better are the usual ones: complexity and interoperability.  Additional complexity for no gain is bad.  Additional interop issues are bad too, obviously.  As far as I can tell, the score would be a "do what I mean not what I say" model.  

If we can't figure out what the code needs to look like for all actors (the originating, terminating carriers, and verification service), by definition we'll have an interop problem.  If the code requires operators to set different "derating" values based on who the far-end validation service is, it's going to cause interop problems (or at least the "operability" part of "interoperability").

If you want to put extra optional vendor-specific data in the "package" that's up to you; optional vendor-specific extensions are done in CA certs too.  Just don't expect/require receivers to pay attention to it.  In my opinion the "base" CNIT mechanism should just either assert a name->phone mapping, or not do so, for any given call/caller.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 30 Aug 2013 14:16:52 -0400

> You seem to be rejecting all ideas.

Not at all - I'm debating the notion of call senders (or their validation service agents) sending scores in a meaningful way to everyone else.

[As an aside, I think you might feel I'm yelling or getting frustrated or whatever - I'm not.  I want to figure out a plausible solution.  The way I do that is I posit a premise/idea/solution and try to pick holes in it.  You're proposing sending scores, and I'm saying I see problems with that and trying to explain what those problems are.  It's hard to convey emotion/emphasis/volume in emails.  This would go better in a physical meeting methinks.]

> If you don't like scoring and you don't like multiple names with source, what do you like?

Who said I didn't like "multiple names with source"?  You lost me.  Or maybe I don't know what you mean by the words "multiple names with source".

I don't mind "scores", when it's a score generated by the terminating domain (or an agent of their's) based on various inputs, for their own use.  That's all up to them to do/decide/control.  There are no interop issues, and the complexity is as much as they want it to be.

> I don't think it's going to be hard to authorize third party use.

It's not hard from the perspective of writing a spec or even writing code.  It's hard in the sense that it requires devices and people to do things they didn't have to do before.  Don't get me wrong - I want it to be as trivially easy as possible, and I hope it will be used.  But my hunch is we don't really know all the variables that affect adoption of third-party authorization, and some of those variables might lead to having doctors call out "through" their office PBX. I don't think it's a big deal if that happens though.  I was just making a small comment about that, is all.

-hadriel

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 30 Aug 2013 18:20:47 +0000

I suspect we do need to distinguish two cases:

(1) Company uses single caller/client evaluation. From what I've been told, all the large financial companies do this, and they presumably spend the money on this for a reason. Scoring and such are relatively straightforward, as each company deals with one information service at a time. They can look back at their fraud cases and say "if we lower the acceptance score a bit, we can remove x% of fraud, but lose y% of legitimate customers."

(2) Our any-to-any model. The recipient has no way of knowing what scoring method the originator uses and what the scale might be.

We also need to separate two use cases:

(1) Inbound calls to companies. They can use existing tools and may not need much in terms of name validation, although that can obviously help as an additional source of data. They are probably most helped by STIR number validation. (For example, there are commercial outfits that try to estimate the location of the caller based on voice path characteristics, used by financial institutions to identify non-US callers with US VoIP numbers.)

(2) Inbound calls to individuals, particularly vulnerable populations, primarily from entities pretending to be a trustworthy organization, aided by third-party filters.

My main concern is the 2nd category although I obviously don't mind helping the first. I'm less concerned with Eve Mallory pretending to be Jane Good, i.e., another residential caller. This is a problem for spear-phishing and thus worth solving, but less for large-scale fraud.

However, the problem isn't nearly as intractable as for email for two reasons:

(1) The market is fairly concentrated (I'm not saying that as a good-thing argument, but as a statement of fact). The top 13 companies have well in excess of 80% of residential broadband customers. The top 100 companies are probably closer to 95% and the total number of consumer/business-facing carriers is a few thousand. Similar for wireless, except the number of companies is 4. That's even more true in other countries, where you don't tend to have as many regionals.

I suspect the concentration among consumer-facing large companies is even higher. A Fortune 500 company is unlikely to get its voice services from Joe's Broadband & Salvage.

(2) And, importantly, most of the customers have an on-going financial relationship with that provider, unlike for the dominant consumer email companies. That provides reasonable identity information based on billing records. (The number of commercial voice customers who are buying scratch-off cards at CVS with cash is probably pretty small.)

Thus, while lessons from email are helpful, it's probably more interesting to see if there are differences that can be exploited to make this more successful, at least for some significant fraction of the good calls. We all agree that the bad guys will continue to be able to find pink carriers. As long as none of the bigger guys goes rogue, that's not a major concern as nobody will pay attention to what some fly-by-night outfit asserts.

Also, the goal for name/property identification is not spam/SPIT prevention as much as dealing with the fraudulent calls that survive the STIR spam filter.

So far, the proposed alternative seems to be a "live with it" approach. 

Henning

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Friday, August 30, 2013 1:41 PM
To: [email-masked]
Cc: [email-masked]; Stephen Kent; Dwight, Timothy M (Tim); Henning Schulzrinne
Subject: Re: [cnit] [stir] Reputation vs Display name (was Textual caller ID)

Brian

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 30 Aug 2013 14:27:44 -0400

> Okay.  We support dozens of customers who had serious fraud abuse until they started using our database to evaluate callers to their call center.  Typically, they query with 3-6 fields.  They get a…

OK, then you've got a working solution.  What's the problem you're trying to solve then?  What's the problem CNIT is trying to solve, if these things are working fine?  And if they're not working fine, in what way are they not working fine?

> The part of this that I can't cite a specific example for is what some clever UI developer will come up with to use the data.  What I know is, it's useful, and we'll figure out a way.  It might hav…

If your database is used by the terminating provider, which as far as I know is the case, then ISTM that draft-wing-sipping-spam-score is the solution to that.  No?

-hadriel

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 30 Aug 2013 18:30:33 +0000

You seem to assume that the carrier decides to suppress callerID information. For the reasons you hint at, that seems unlikely. My mental model is a third-party provider (e.g., an app on a smartphone or a module in a PBX) that takes the available information and uses that to make policy decisions. The recipient can choose the trade-offs. As I mentioned earlier, for a senior citizen, they might subscribe to the AARP service that only shows callerID provided by the organizations they trust. If you don't like that list, you find another service. A bank PBX where the concern is phishing would apply a different policy and might, for example, be very careful about rendering organizational names that claim to be from a regulator or another bank.

The presence of pink carriers is not that relevant here, as they'd never make it on the trust list of either example.

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Friday, August 30, 2013 12:45 PM
To: Henning Schulzrinne
Cc: Dwight, Timothy M (Tim); Brian Rosen; Stephen Kent; [email-masked]
Subject: Re: [cnit] [stir] Reputation vs Display name (was Textual caller ID)

-hadriel

---

From: Brian Rosen <[email-masked]>
Date: Fri, 30 Aug 2013 14:31:37 -0400

If some devices do a better job of helping consumers deal with unknown callers then those phones will succeed.   

One of the reasons VoIP service is stuck at ATAs is that the service can't provide any useful features beyond what POTS service does.  If a direct VoIP phone, not an ATA, provided better service, it may succeed where ATAs are the norm. 

Your email analogy is flawed in that the services that do the best, the UI is done by someone who really does it well, and they provide mechanisms that help users separate interesting mail from spam.  Most of these use web browser or smartphone/tablet UIs.  It's the UI part that matters, and that's not the email server in the sense we usually take it.

There is very little complexity in a simple scaler score.  There is zero interoperability issues.  The problem is interpreting the score.  That isn't that the receiving device and the sending device disagree on how to handle the score in the protocol.  Ignoring the score is easy.  Interoperably transporting the score is easy.  Interpreting it may be more difficult.

Brian

---

From: Brian Rosen <[email-masked]>
Date: Fri, 30 Aug 2013 14:42:13 -0400

I'm trying to move scoring to the origination side, because I can get more information to validate the name that I can at the termination side.  If I get more information, I can get better scores.  At the termination side, all I have is phone number.

The complication, and the difference between this working example and the cnit problem is what Henning called the any-to-any problem - if the scoring is on the origination, then the termination has to evaluate the validator to know how to deal with the score.  I agree that makes it more complex than what we have working.  I think we probably can agree that if there are a relatively small number of validators, then having more than one is tractable, but if there are lots, then it isn't.  I'm arguing that for most cases, the reality will be okay - either the terminating side will only be dealing with a few validators, because the vast majority of calls are within a country, or at least within a few neighboring countries, or the service used by the terminating side, Google, Apple et. al. can deal with a couple thousand validators.

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 30 Aug 2013 14:42:05 -0400

Not sure who you're directing it to, but... I am not proposing a "live with it" solution.  I'm trying to understand the problem, and trying to figure out a solution.  I'm poking holes in the balloons being floated, to see if they burst.  That's a pretty common way to design I think; at least for me.  And right now this whole topic truly is in the research+design phase.

Quite honestly I think some folks might be getting frustrated, but I think that's because this debate is occurring in email.  Email's not a good medium for initial discussions like this.  Even voice conf calls aren't good for this.  Maybe we should schedule a small contingent of folks to get on Google hangouts?

-hadriel

---

From: Brian Rosen <[email-masked]>
Date: Fri, 30 Aug 2013 14:43:11 -0400

I am willing.

Brian

---

From: Alex Bobotek <[email-masked]>
Date: Fri, 30 Aug 2013 11:41:45 -0700

Dave wrote:  

> Over the last 15 years, there have been a number of startup company efforts
> to "empower' end-users with quality assessment information.

1.  What has succeeded is incorporating end-user preferences into a terminating service provider's filtering.  IMHO, this (terminating SP filters, based on subscriber prefs) is the most important call/message acceptance decision model.    In some cases this filtering may be extended to the user agent (e.g., if a user chooses to), where _automata_ acting on the behalf of the end-user may consume reputation information.  

2.  (A separate point, not in response to Dave's comment) Calling party display name as we know it (unstructured text) cannot provide sufficient information to prevent vishing, fraud, smishing and robocalling.  Adding structure to originating SP assertions does not solve this, as they cannot be compelled or trusted to provide accurate infomation.  I believe reputation associated with an identity is also needed, and that CNIT Display Name efforts should not expect nor attempt to obviate other necessary reputation information (e.g., terminating SP and 3rd party info).  Some sort of optional 'facts I know about the Display Name' assertion by the originating SP make sense.  However, there is clearly some security value in controlling display names.   

Regards,

Alex

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Dave Crocker
> Sent: Friday, August 30, 2013 10:13 AM
> To: Hadriel Kaplan
> Cc: [email-masked]; Brian Rosen
> > something the receivers create themselves - it's under the control and
> > policy decision of the receiver.
> 
> Receivers have very complex filtering engines, typically with /layers/ of many
> different scores, based on a variety of attributes, and factored into highly
> contingent analysis engines.
> 
> Users never see any of this; the engines feed into basic handling choices,
> such as inbox vs. spam folder.
> 
> Over the last 15 years, there have been a number of startup company efforts
> to "empower' end-users with quality assessment information.
> The only report I've heard of real efficacy was at Yahoo, where they boiled it
> down to a trust/don't-trust/don't-know distinction, but this certainly has not
> gained traction in the industry.
> 
> efficacy; my impression is that they've had no effect on end-users, any more
> than the lock symbol at the bottom of the web page.
> 
> 
> way, physical world reputation -- is the need for multiple and potentially
> competing services.
> 
> 
> And then there's the more recent Repute working group that is just finishing
> up:
> 
> assumption that it is tractable to assertion of a bit more control and that that
> isn't difficult.
>

---

From: Stephen Kent <[email-masked]>
Date: Fri, 30 Aug 2013 21:27:32 -0400

Brian,
> I assume that is directed at me.
if the shoe fits ...
> While true that my employer has such capability and would stand to make money on the idea, that problem exists, in spades, with the entire stir effort.
I, for one, don't have a financial stake in this, so I disagree. I get 
paid by clients
to track security-relevant standards activities and try to encourage 
good outcomes.

> Nevertheless, I would not be pushing the idea if I did not personally think this will be of great value to the caller.  You have no basis to question my sincerity.
I used the term motives, not sincerity.
> I submit that it is exceedingly hard for any entity to provide a name with certainty anywhere near the level of certainty we generally assume when we state values.
you may generally assume, not me. I know that the sort of names that 
people informally
use to identify individuals and orgs are not globally unique, and I try 
to warn people
about the pitfalls of creating systems that may mislead the consumers of 
such IDs.
>    We will be able to state with some large degree of certainty that the phone number is correct.
agreed.
>    We will have MUCH less certainty of the name, and wide variation of certainty, no matter what we do.  To assume, or say otherwise is foolish.
agreed.
> When you have varying levels of certainty, it helps, a lot, to have an idea of HOW certain you are.  I will give you an example in another domain.  When we report your location as latitude/longitud…
the ability to measure the uncertainty re location accuracy, and the 
underpinnings in physics, are very important differences, which call 
into question your analogy.

> ...
and you don't find that worrisome?
> What is not so hard, is using it.  Lots and lots of companies and researchers are successfully using the data, for applications not so dissimilar from what we're discussing.
I find it ironic that at a time when so many people are aghast at 
revelations about
NSA acquisition of communication metadata, we're assuming that creating 
an even bigger market for commercially-acquired metadata is a good idea.
> ...
Sending a score is cheap for the SPs. If one considers the potential for 
confusion for
users, I come to a different conclusion.

Steve

---

From: Dave Crocker <[email-masked]>
Date: Sat, 31 Aug 2013 12:35:28 -0700

On 8/30/2013 10:40 AM, Brian Rosen wrote:
> Okay.  We support dozens of customers who had serious fraud abuse
> until they started using our database to evaluate callers to their
> call center.

OK.  Good starting point.  Call centers represent specialized user 
organizations, with operators have some distinct skills and training, 
but a useful reference.  If the intended scope of the current work is... 
everyone in the world... then there are some issues in generalizing the 
experience from a few dozen skilled user organizations to billions of 
individual users.  But, again, a good starting point.

> Typically, they query with 3-6 fields.  They get a
> score back.  They decide how to handle the caller based on the score.

I assume that the call center operators have established procedures, 
rather than creating an action based personal whim of the moment. 
Again, this would distinguish them from typical, mass-market end users.

> The part of this that I can't cite a specific example for is what
> some clever UI developer will come up with to use the data.

Unfortunately that part of the equation matters.  Not necessarily the 
fine-grained detail, but the basic expectations of how information will 
get used and by whom and whether it is pre-determined or decided in 
real-time.

That's why I am trying to distinguish between an architectural component 
that implements policies -- the same as the filtering engine in email 
anti-abuse systems today -- versus assumptions that end-users will be 
making real-time decisions, largely based on raw information.

In fact, the essential difference is between having a software policy 
engine with built-in rulesets, versus a 'wet' real-time policy 
formulation engine.

 >  What I
> know is, it's useful, and we'll figure out a way.

Then you know more than I do, in spite of my background in usability 
design and the considerable industry experience in this space, which 
frankly encourages caution in this realm.

> It might have
> binned responses.  It might change the response if this is the first
> call from the identity.  It might supply a thumbs up/down selection
> that is used for other callers.  It might supply a Travelocity style
> rating.

So it turns out that what you've described is considerably more than 
clever UI design.

You've describe the effects of a policy engine that does its own 
analysis and handling decisions.  And indeed, that's exactly the 
distinction I'm suggesting for this work.  With luck, that means we're 
disagreeing on some terminology, rather than some architecture.

However, this is not a small point.  It is a key architectural component 
and designing for that function, rather than designing for end-users, 
per se, is a fundamental difference.

d/