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

[Michael Hammer <[e-mail]>]

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