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

["Peterson, Jon" <[e-mail]>]

I think it's a much harder problem, anyway, and I wouldn't want to put it
on our plate until we've understood more about source identity.

I imagine that there are alternative ways to approach the fallback
mechanism that could probably confer this property for some use cases.

Jon Peterson
Neustar, Inc.

On 6/17/13 11:01 AM, "Michael Hammer" <[e-mail]> wrote:

>By doing that you turn this from a source identity non-repudiation
>capability to 
>a routing assurance capability (receipt non-repudiation).
>
>Despite being useful, I thought that was not in scope.
>
>Mike
>
>
>-----Original Message-----
>From: Dan York [mailto:[e-mail]]
>Sent: Monday, June 17, 2013 1:38 PM
>To: Michael Hammer; [e-mail]; [e-mail]
>Cc: [e-mail]; [e-mail]; [e-mail]
>Subject: Not just "called party" - Re: [stir] current draft charter
>
>
>On 6/17/13 12:04 PM, "Michael Hammer" <[e-mail]>
>wrote:
>
>>Third point:  The called party needs to unequivocally know how to
>>validate an assertion and who to go to for the inputs to perform that
>validation.
>
>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
>