Re: [stir] [sipcore] draft-ietf-sipcore-callinfo-04 (call-reason)

[Chris Wendt <[e-mail]>]

Hi Henning,

I understand what you are saying.  I do however think there is reasons to protect call-reason/Subject of call.  I think these situations are mostly in the context of delegation to perhaps a call center, where you have authorized them to represent your company in particular ways, including not only your identity, but for different context of calls that you have authorized them to represent you.  We all know there is some call centers that use call identities with good reputation for customers that may exploit that reputation for other customers.  I would look at this as similar situation.

There is also potential for future of Subject/call-reason to be more than just a text string.

I’m struggling a bit on your point that we should sign some data but not other data because it is less likely to be manipulated.  Is that the bar we should be striving for here? Seems to conflict with my understanding of some of the goals.

Why not have the framework that we can do that.  You are free to protect or not protect data depending on your own policy. 

I guess i want to be sure whether you are reacting to us not using Subject vs call-info as a common container for “rich call data” related info or that we have both call-info and ‘rcd’ as a container for Rich Call Data more generally?  I think there is many reasons why we landed there, we can re-hash that in the context of call-info vs subject.  I would be less excited about re-hashing it for passport/rcd.

I do believe both of these frameworks need to be extensible, i don’t think we are finished.  We can define more passport extensions, but at the same time, do we want to redefine “rcd” and “rcdi” for new passport extensions?

-Chris

> On Mar 18, 2022, at 4:23 PM, Henning Schulzrinne <[e-mail]> wrote:
> 
> I missed one important point of yours: It isn't quite clear what it means to protect the call reason (or Subject, for that matter). The likelihood that somebody downstream will insert a bogus call reason or Subject seems very low - there's no real incentive. The carrier, for the reasons mentioned, probably doesn't want anything to do with certifying the call purpose as "signing" could be seen as endorsement. After all, the whole point of STIR PaSSporT attestation is not just some random cryptographic signature like in TLS, but indeed an attestation of veracity or responsibility (for gateway attestation). The user is unlikely to have a way to sign the call purpose on their own, except maybe for enterprises, but this again seems not all that helpful.
> 
> (In the US, Section 230 and similar laws probably protect them from liability, but this may not be true everywhere.)
> 
> As mentioned, this is different from signing RCD, which indeed has some notion of attestation. ("I, as the originating carrier, attest that this is the business address I have on file for this customer." or "I, enterprise, attest that this is indeed my employee, Jane Talker.")
> 
> My general argument is: The call-purpose field raises all kinds of operational issues, doesn't seem necessary for RCD, seems unlikely to be used widely and can, if desired, be introduced as a new Call-Info purpose. I think we should generally err on the side of minimalism - all of this stuff is already complex enough. (See the 603/607/608 debate of what happens otherwise...)
> 
> Henning
> 
> On Fri, Mar 18, 2022 at 10:16 AM Chris Wendt <[e-mail] <mailto:[e-mail]>> wrote:
> 
> Beyond your point, but related and maybe just validation for me, do we want to protect call-reason as part of RCD?  I think we sort of said, yes why not protect/sign it because we view RCD as an extensible set of claims, as long as we make that a claim that is not part of the “rcd” claim that is specifically about the calling party identity, which we did with “crn”.
>