Re: [stir] Not just "called party" - Re: current draft charter

[Dan York <[e-mail]>]

Hadriel,


On 6/17/13 3:04 PM, "Hadriel Kaplan" <[e-mail]> wrote:

>For sake of focus and having a prayer of getting this done before we all
>retire, 

Ack!  We need something deployable - and sooner rather than later.  I
definitely agree with that.

>I think we should focus exclusively on caller-id reputability.  No bank
>would ever trust this type of thing for called-party identity anyway,
>because it only identifies phone numbers not humans - i.e., at best it
>identifies a phone, not the person on the other end.  Thus they'll have
>to ask you a bunch of identifying questions anyway.

Yes, using a bank as an example was a poor choice on my part because they
do have many other processes for identifying the person they are calling.

In this era of call automation, though, being able to have better
confidence in the identifier of the number being called would be
advantageous and could feed application calling logic.  If an outbound
application called a number and received as the secure identifier the
number/identifier it had on file, the application could deliver whatever
message it had.  If there was a mismatch, the app could deliver a
different message ("please call us back") or transfer the call to a
waiting agent to perform an additional identification test of the person
being called.  

I agree that for the sake of getting a secure identifier out we should
focus on the called party identifying the caller, but as we look at
architectural choices it would be good if whatever we choose does not rule
out the usage by the calling party.

Dan


>On Jun 17, 2013, at 1:38 PM, Dan York <[e-mail]> wrote:
>
>> I would not necessarily restrict it to the "called party".  This is the
>> dominant use case we've been discussing, I.e that I receive a call and
>> want to be as certain as possible about the identity of the endpoint
>> calling me.
>> 
>> However, I could be calling out to my customers or clients and as the
>> "calling party" would like to be as certain as possible that I am
>>reaching
>> the correct endpoint.  Consider a bank wanting to reach a customer about
>> issues with the customer's account - or to verify a recent transaction.
>>Or
>> a doctor's office want to relay results to a patient and wanting to be
>> sure they are reaching the patient's number.
>> 
>> My understanding is that we are aiming to solve the "secure origin
>> identification" challenge - and that could apply to either or both ends
>>of
>> the conversation.
>> 
>> Dan
>> 
>> _______________________________________________
>> stir mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/stir
>