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

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 17 Mar 2022 23:49:35 -0400

There was a brief discussion on this in August 2020, but now that the draft
is stabilizing, I'd like to comment on the call-reason parameter. I'm not
sure I found all the discussions, with only an August 2020 discussion (from
Paul Kyzivat and Chris Wendt) popping up. In any event, as drafted, this
seems to be exactly duplicating the Subject header. Having two header
fields that do pretty much the same thing seems unwise.

There was discussion on structured content, but this doesn't seem possible
to add without breaking backwards-compatibility. You really don't want to
add JSON to an existing string, or other parameters.

There seems to be no obvious reason why systems that drop Subject would
treat call-reason with more care (or deliver it to the UA). Indeed, richer
information is likely to make the handling more challenging - the more
stuff the UA can embed, the more likely that this will cause security
concerns. (You really don't want to include full HTML with JavaScript
here...)

It is also a poor addition to the callinfo header, as the RCD will likely
be generated by a trusted entity, such as the carrier or the enterprise
PBX, while the call-reason has to be generated, on a call-by-call basis, by
the UA, either via human input or via the robot generating the (hopefully
wanted) calls.

I think there are three reasons that Subject has not seen much use:

(1) For person-to-person phone calls, there seems to be little appetite to
add more overhead to making calls. If I want to text ahead ("I'll call you
shortly about the vet"), people will likely do that instead. Call-reason or
Subject are not substitutes for texting-ahead.

(2) For enterprise-to-consumer calls, this seems like an opportunity for
potential abuse and spam.

(3) SIP headers provided by the end system or end user don't seem to
survive the paranoia of B2BUAs and various other in-call entities.

All of these would likely apply to call-reason, with the additional issue
of who-generates-what added for complexity. If the landscape has changed,
i.e., there's a willingness to deliver information UA-to-UA, then this
would apply to the Subject header as well.

Henning

---

From: Chris Wendt <[email-masked]>
Date: Fri, 18 Mar 2022 10:16:35 -0400

Hi Henning, 

This is good feedback, you are correct there really hasn’t been a lot of discussion on the callinfo-rcd draft, most of the mind share has been toward the passport-rcd, now that i think that document has mostly stabilized on issues not related to your comments or the specifics of how we do callinfo, it’s a good time to engage on that and appreciate you starting the discussion.

I’d be curious to think what others think about using Subject for call-reason vs callinfo.  

I think the thought process as you sort of indicate sort of went a bit back in forth about whether jcard would be the extensible object we all put information about caller into, we seemed to have backed off of that for what has emerged to be the initial minimum use of RCD which is name, TN, icon, call reason.  The first three is info about the caller, the call reason is info that is likely specific to the call intent, not information about the caller. So in that sense Subject may make sense because after all that is what it was created for, but also we weren’t sure if there would be other categories of information that we may want to extend in call-info. For example, URL to relevant info about the intent of the call, or other call specific info.

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

I do also think we need to address when callinfo and other SIP headers/parameters are used to carry info vs in RCD claims.  Should they be mutually exclusive, that you should either do one or the other depending if you want the signature/integrity protection for your use-case?

-Chris

> On Mar 17, 2022, at 11:49 PM, Henning Schulzrinne <[email-masked]> wrote:
> 
> There was a brief discussion on this in August 2020, but now that the draft is stabilizing, I'd like to comment on the call-reason parameter. I'm not sure I found all the discussions, with only an August 2020 discussion (from Paul Kyzivat and Chris Wendt) popping up. In any event, as drafted, this seems to be exactly duplicating the Subject header. Having two header fields that do pretty much the same thing seems unwise. 
> 
> There was discussion on structured content, but this doesn't seem possible to add without breaking backwards-compatibility. You really don't want to add JSON to an existing string, or other parameters.
> 
> There seems to be no obvious reason why systems that drop Subject would treat call-reason with more care (or deliver it to the UA). Indeed, richer information is likely to make the handling more challenging - the more stuff the UA can embed, the more likely that this will cause security concerns. (You really don't want to include full HTML with JavaScript here...)
> 
> It is also a poor addition to the callinfo header, as the RCD will likely be generated by a trusted entity, such as the carrier or the enterprise PBX, while the call-reason has to be generated, on a call-by-call basis, by the UA, either via human input or via the robot generating the (hopefully wanted) calls.
> 
> (1) For person-to-person phone calls, there seems to be little appetite to add more overhead to making calls. If I want to text ahead ("I'll call you shortly about the vet"), people will likely do that instead. Call-reason or Subject are not substitutes for texting-ahead.
> 
> (2) For enterprise-to-consumer calls, this seems like an opportunity for potential abuse and spam.
> 
> (3) SIP headers provided by the end system or end user don't seem to survive the paranoia of B2BUAs and various other in-call entities.
> 
> All of these would likely apply to call-reason, with the additional issue of who-generates-what added for complexity. If the landscape has changed, i.e., there's a willingness to deliver information UA-to-UA, then this would apply to the Subject header as well.
> 
> Henning
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 18 Mar 2022 16:05:08 -0400

Generalizing a bit, we are trying to provide information that allows a
called party to decide whether to (1) accept the call; (2) trust the caller
in some sense ("this is a real charity; this is actually a real bank; this
call is important enough to answer"), with both (1) and (2) probably
outsourced to your favorite ML/AI/robot service in some cases, whether
enterprise phishing/fraud prevention or some service for residential users.

We use a variety of means for this:
* information about the telephone identity (usually, TN) of the caller ->
STIR "classic", using From, mostly, but also the various
P-Asserted-Identity, verstat and similar headers
* information about the caller's "real world" identity -> RCD
* information about the nature of the call -> SDP and others ("sorry, no
video calls"); possible the Subject header and the call-reason field

All of these have different sources and change periods:
* TNs often don't change for decades and are best provided (or validated)
and, where available, signed by the OSP, but may also be inserted by
intermediaries, e.g., in SS7-to-SIP gateways.

* RCD may change more frequently (people move, businesses change names),
but are also best provided by the OSP, at least for most users, e.g., based
on billing addresses and the KYC process. This will be pretty much required
for the JWT version. This means there's relatively little opportunity for
inappropriate content, for example.

* The nature of the call is, by necessity, provided by the caller, on a
call-by-call basis. Unless one creates another API from the UA to the local
PBX (or carrier), it would have to be either merged with the RCD data or
carried in two Call-Info headers. If the carrier merges it, this blurs the
responsibility - it makes it look like the carrier vouches for the call
purpose, which they presumably want nothing to do with. Given the potential
for abuse, you probably need to provide the called party with an
opportunity to suppress this. (This new text channel is a perfect way to
harass people or businesses with messages, at no cost and none of the SMS
campaign registration and cost overhead.)

Also, for regulated businesses such as banks, the call purpose information
would need to be recorded and possibly filtered - you don't want this to be
used to bypass content filters and flagging. ("Buy T at $100"). Putting
this in the same header as the RCD is not helpful - it just makes it
messier.

Thus, the call-purpose information is much more akin to a new messaging
channel - after all, the caller can just make a bunch of calls, each with a
new call-purpose (or Subject).

Thus, RCD and call-purpose share very little in terms of responsibility,
spam risks and method of generation. Combining them in one header offers
little advantage and just blurs responsibility.

Providing a reason for the call was the original motivation for the Subject
header. This hasn't been too successful, but the new proposal, in my view,
makes things worse and addresses none of the likely reasons for the Subject
non-success.

If there's a need to provide more call-specific information that can't be
handled by Subject, this seems best to be a new Call-Info purpose. It is
then clear that this is of a different nature than the business card
information in jCard.

Henning

On Fri, Mar 18, 2022 at 10:16 AM Chris Wendt <[email-masked]>
wrote:

> Hi Henning,
>
> This is good feedback, you are correct there really hasn’t been a lot of
> discussion on the callinfo-rcd draft, most of the mind share has been
> toward the passport-rcd, now that i think that document has mostly
> stabilized on issues not related to your comments or the specifics of how
> we do callinfo, it’s a good time to engage on that and appreciate you
> starting the discussion.
>
> I think the thought process as you sort of indicate sort of went a bit
> back in forth about whether jcard would be the extensible object we all put
> information about caller into, we seemed to have backed off of that for
> what has emerged to be the initial minimum use of RCD which is name, TN,
> icon, call reason.  The first three is info about the caller, the call
> reason is info that is likely specific to the call intent, not information
> about the caller. So in that sense Subject may make sense because after all
> that is what it was created for, but also we weren’t sure if there would be
> other categories of information that we may want to extend in call-info.
> For example, URL to relevant info about the intent of the call, or other
> call specific info.
>
> 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”.
>
> I do also think we need to address when callinfo and other SIP
> headers/parameters are used to carry info vs in RCD claims.  Should they be
> mutually exclusive, that you should either do one or the other depending if
> you want the signature/integrity protection for your use-case?
>
> -Chris
>
> > There was a brief discussion on this in August 2020, but now that the
> draft is stabilizing, I'd like to comment on the call-reason parameter. I'm
> not sure I found all the discussions, with only an August 2020 discussion
> (from Paul Kyzivat and Chris Wendt) popping up. In any event, as drafted,
> this seems to be exactly duplicating the Subject header. Having two header
> > There was discussion on structured content, but this doesn't seem
> possible to add without breaking backwards-compatibility. You really don't
> want to add JSON to an existing string, or other parameters.
> >
> > It is also a poor addition to the callinfo header, as the RCD will
> likely be generated by a trusted entity, such as the carrier or the
> enterprise PBX, while the call-reason has to be generated, on a
> call-by-call basis, by the UA, either via human input or via the robot
> generating the (hopefully wanted) calls.
> >
> > (1) For person-to-person phone calls, there seems to be little appetite
> to add more overhead to making calls. If I want to text ahead ("I'll call
> you shortly about the vet"), people will likely do that instead.
> Call-reason or Subject are not substitutes for texting-ahead.
> >
> > All of these would likely apply to call-reason, with the additional
> issue of who-generates-what added for complexity. If the landscape has
> changed, i.e., there's a willingness to deliver information UA-to-UA, then
> this would apply to the Subject header as well.
> >
> > Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 18 Mar 2022 16:23:58 -0400

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

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

---

From: "Holmes, David" <[email-masked]>
Date: Fri, 18 Mar 2022 20:32:03 +0000

Generalizing further:

  *   For real-time interactive communications (mainly voice/video), prior to responding (answering the call) the recipient can only determine the credibility of the content they are about to receive based on the "call metadata".
  *   The best we can ever do in technical specifications is to ensure correct conveyance of ID information in that metadata from the call origination point to the termination point.  That can be done in a chain manner, which is relatively easy to break (e.g. due to lack of applicable specs/standards, or their application), but is better achieved on an end-to-end basis.
  *   The recipient can use a verified ID to look up reputational information on the caller (& that may include the reputation of the ID supplier).  Provision & verification of reputational information is way outside the remit of any technical group.

If we consider the above it is relatively easy to determine how any addition to a technical specification will result in better achievement of the ultimate goal, which to create/restore trust in, or at least to enable the recipient to make judgement on, the validity of the content of real-time communications.

/David

David Holmes  (He/Him/His)
Industry Forums & Relations
T-Mobile USA
Direct 425.256.7082 | Mobile 425.260.1868  | [email-masked]<mailto:[email-masked]>
T-Mobile.com<http://www.t-mobile.com/> | Follow T-Mobile on Twitter<https://twitter.com/tmobile>, Facebook<https://www.facebook.com/TMobile> and Instagram<http://instagram.com/tmobile>

From: stir <[email-masked]> On Behalf Of Henning Schulzrinne
Sent: Friday, March 18, 2022 1:05 PM
To: Chris Wendt <[email-masked]>
Cc: [email-masked]; SIPCORE <[email-masked]>
Subject: Re: [stir] [sipcore] draft-ietf-sipcore-callinfo-04 (call-reason)

[External]

Generalizing a bit, we are trying to provide information that allows a called party to decide whether to (1) accept the call; (2) trust the caller in some sense ("this is a real charity; this is actually a real bank; this call is important enough to answer"), with both (1) and (2) probably outsourced to your favorite ML/AI/robot service in some cases, whether enterprise phishing/fraud prevention or some service for residential users.

We use a variety of means for this:
* information about the telephone identity (usually, TN) of the caller -> STIR "classic", using From, mostly, but also the various P-Asserted-Identity, verstat and similar headers
* information about the caller's "real world" identity -> RCD
* information about the nature of the call -> SDP and others ("sorry, no video calls"); possible the Subject header and the call-reason field

All of these have different sources and change periods:
* TNs often don't change for decades and are best provided (or validated) and, where available, signed by the OSP, but may also be inserted by intermediaries, e.g., in SS7-to-SIP gateways.

* RCD may change more frequently (people move, businesses change names), but are also best provided by the OSP, at least for most users, e.g., based on billing addresses and the KYC process. This will be pretty much required for the JWT version. This means there's relatively little opportunity for inappropriate content, for example.

* The nature of the call is, by necessity, provided by the caller, on a call-by-call basis. Unless one creates another API from the UA to the local PBX (or carrier), it would have to be either merged with the RCD data or carried in two Call-Info headers. If the carrier merges it, this blurs the responsibility - it makes it look like the carrier vouches for the call purpose, which they presumably want nothing to do with. Given the potential for abuse, you probably need to provide the called party with an opportunity to suppress this. (This new text channel is a perfect way to harass people or businesses with messages, at no cost and none of the SMS campaign registration and cost overhead.)

Also, for regulated businesses such as banks, the call purpose information would need to be recorded and possibly filtered - you don't want this to be used to bypass content filters and flagging. ("Buy T at $100"). Putting this in the same header as the RCD is not helpful - it just makes it messier.

Thus, the call-purpose information is much more akin to a new messaging channel - after all, the caller can just make a bunch of calls, each with a new call-purpose (or Subject).

Thus, RCD and call-purpose share very little in terms of responsibility, spam risks and method of generation. Combining them in one header offers little advantage and just blurs responsibility.

Providing a reason for the call was the original motivation for the Subject header. This hasn't been too successful, but the new proposal, in my view, makes things worse and addresses none of the likely reasons for the Subject non-success.

If there's a need to provide more call-specific information that can't be handled by Subject, this seems best to be a new Call-Info purpose. It is then clear that this is of a different nature than the business card information in jCard.

Henning

On Fri, Mar 18, 2022 at 10:16 AM Chris Wendt <[email-masked]<mailto:[email-masked]>> wrote:
Hi Henning,

This is good feedback, you are correct there really hasn't been a lot of discussion on the callinfo-rcd draft, most of the mind share has been toward the passport-rcd, now that i think that document has mostly stabilized on issues not related to your comments or the specifics of how we do callinfo, it's a good time to engage on that and appreciate you starting the discussion.

I'd be curious to think what others think about using Subject for call-reason vs callinfo.

I think the thought process as you sort of indicate sort of went a bit back in forth about whether jcard would be the extensible object we all put information about caller into, we seemed to have backed off of that for what has emerged to be the initial minimum use of RCD which is name, TN, icon, call reason.  The first three is info about the caller, the call reason is info that is likely specific to the call intent, not information about the caller. So in that sense Subject may make sense because after all that is what it was created for, but also we weren't sure if there would be other categories of information that we may want to extend in call-info. For example, URL to relevant info about the intent of the call, or other call specific info.

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

-Chris

> On Mar 17, 2022, at 11:49 PM, Henning Schulzrinne <[email-masked]<mailto:[email-masked]>> wrote:
>
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sipcore<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsipcore&data=04%7C01%7Cdavid.holmes%40t-mobile.com%7Cbb87c967d7d9432dc42e08da091ab62d%7Cbe0f980bdd994b19bd7bbc71a09b026c%7C0%7C0%7C637832307608208318%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=S1jVvqHFUsdcP%2FtQuLu8OJeyjWfgFte4WaX%2BTePFnJE%3D&reserved=0>

---

From: Chris Wendt <[email-masked]>
Date: Fri, 18 Mar 2022 17:17:39 -0400

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 <[email-masked]> 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 <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 19 Mar 2022 15:25:56 -0400

Hi Chris,

tl;dr: My suggestions are: (1) leave call purpose out
of draft-ietf-stir-passport-rcd; (2) drop call-purpose
from draft-ietf-sipcore-call-info-rcd; (3) consider a new JWT claim
"subject" [or whatever] that encapsulates the signed call purpose in the
future.

More details inline below.

On Fri, Mar 18, 2022 at 5:17 PM Chris Wendt <[email-masked]>
wrote:

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

I think we generally agree - your example of a call center is probably, in
my view, the most likely case where some indication of call purpose will be
used, probably with explicit arrangement with the carrier. This may well
turn out to be similar to the current model for SMS, where (in the US and
some other countries) you'll have to register your "campaign" with the
carrier or designated third party. This may even take the notion of a
template ("This call is about your recent order from {date}") that can be
auto-enforced. It's clear that carriers seem quite concerned about their
individual customers messaging, in volume, to their subscribers, given the
abuse.

> There is also potential for future of Subject/call-reason to be more than

I suspect that's best handled separately, once we have a clearer use case.
I don't think we can just stick this into call-reason without all kinds of
backwards-compatibility issues.

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

Maybe this indicates that we should be clearer on the goals. My take on the
value of STIR "classic" (for TNs) is that the main purpose of signing is to
make it clear who is responsible for the information provided - thus, the
whole discussion of A/B/C attestation. Indeed, the experience seems to
indicate that C-level attestation is actually a signal for a robocall,
i.e,. C-level calls are *more* likely to be robocalls than unsigned calls.
A/B/C obviously have the same cryptographic strength and all prevent
modification by third parties.

I don't think that carrier manipulation of the caller information (except
in various normalization ways) has ever been a major problem - it's
originator (OSP or end user) spoofing. This is rather different than the
typical threat model where the originator worries about evil Mallory
changing their data, e.g., by redirecting a money transfer to them.

But for call-purpose, this is less relevant - this is clearly (mostly)
useful if inserted by the originating caller, and unlike for A-level
attestation, the carrier can't really validate that the message is
truthful. How would it know that "You have won a cruise!" in the
call-purpose/Subject was correct or a scam? Indeed, as mentioned, if I were
a carrier, I'd never want to attest to that purpose, as somebody could
reasonably claim that the carrier should have known that the recipients
hadn't won anything.

This is the main reason that I think this should be a separate claim - if
anybody should sign/attest this, it's the enterprise call center and only
that call center.

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

Nothing wrong as such. My argument is that RCD and call-purpose/Subject are
very different, so they shouldn't be in the *same* framework. If we need
Subject/call-purpose, they should be in separate claims, for the
operational reasons mentioned.

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

For the reasons above, I think this is a bad idea for both cases, in
my view. It's worse for Call-Info, because of the duplication of existing
functionality.

To use an analogy: The RCD is mostly like a business card. We don't
typically write our contracts and messages on business cards - we might
staple our business card to a note.

My constructive suggestion is to create a separate claim if needed. (My
understanding is that rcd-14 does not contain the call purpose, so this is
the current state.)

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

No, we should create, in my view, a separate document that focuses on
signing the call purpose, expressed either as Subject (as the compact form)
or an explicit JWT claim, such as "subject".

---

From: Chris Wendt <[email-masked]>
Date: Sun, 20 Mar 2022 11:47:18 -0400

Hi Henning,

Just to focus on call-reason for passport-rcd at the moment, we do have that, it is an independent claim “crn” explicitly separate from the “rcd” claim. It is defined in same passport-rcd document, but that doesn’t change how it’s defined or used. I think one hopefully simple fix is to maybe reference Subject as a mapping for this claim and maybe point to callinfo-rcd in a more generic way that we can further discuss subject vs callinfo in the sipcore draft as we move that forward.  As i understand it, most implementations are focused on passport-rcd at the moment, so i don’t want to hold that up if possible.

To everyone,

It would be great to get further input on this whether anyone has strong feelings about using Subject vs callinfo parameter call-reason.  I have the sense that there isn’t yet much implementation if any at all (of callinfo/call-reason, i believe there is implementation of passport-rcd “crn”), and there won't strong feeling one way or the other, but if anyone does have strong feelings please speak up.

-Chris

> On Mar 19, 2022, at 3:25 PM, Henning Schulzrinne <[email-masked]> wrote:
> 
> Hi Chris,
> 
> tl;dr: My suggestions are: (1) leave call purpose out of draft-ietf-stir-passport-rcd; (2) drop call-purpose from draft-ietf-sipcore-call-info-rcd; (3) consider a new JWT claim "subject" [or whatever] that encapsulates the signed call purpose in the future.
> 
> On Fri, Mar 18, 2022 at 5:17 PM Chris Wendt <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Henning,
> 
> I think we generally agree - your example of a call center is probably, in my view, the most likely case where some indication of call purpose will be used, probably with explicit arrangement with the carrier. This may well turn out to be similar to the current model for SMS, where (in the US and some other countries) you'll have to register your "campaign" with the carrier or designated third party. This may even take the notion of a template ("This call is about your recent order from {date}") that can be auto-enforced. It's clear that carriers seem quite concerned about their individual customers messaging, in volume, to their subscribers, given the abuse.
>  
> 
> I suspect that's best handled separately, once we have a clearer use case. I don't think we can just stick this into call-reason without all kinds of backwards-compatibility issues. 
>  
> 
> Maybe this indicates that we should be clearer on the goals. My take on the value of STIR "classic" (for TNs) is that the main purpose of signing is to make it clear who is responsible for the information provided - thus, the whole discussion of A/B/C attestation. Indeed, the experience seems to indicate that C-level attestation is actually a signal for a robocall, i.e,. C-level calls are *more* likely to be robocalls than unsigned calls. A/B/C obviously have the same cryptographic strength and all prevent modification by third parties.
> 
> I don't think that carrier manipulation of the caller information (except in various normalization ways) has ever been a major problem - it's originator (OSP or end user) spoofing. This is rather different than the typical threat model where the originator worries about evil Mallory changing their data, e.g., by redirecting a money transfer to them.
>  
> But for call-purpose, this is less relevant - this is clearly (mostly) useful if inserted by the originating caller, and unlike for A-level attestation, the carrier can't really validate that the message is truthful. How would it know that "You have won a cruise!" in the call-purpose/Subject was correct or a scam? Indeed, as mentioned, if I were a carrier, I'd never want to attest to that purpose, as somebody could reasonably claim that the carrier should have known that the recipients hadn't won anything.
> 
> This is the main reason that I think this should be a separate claim - if anybody should sign/attest this, it's the enterprise call center and only that call center.
> 
> 
> Nothing wrong as such. My argument is that RCD and call-purpose/Subject are very different, so they shouldn't be in the *same* framework. If we need Subject/call-purpose, they should be in separate claims, for the operational reasons mentioned. 
>  
> 
> For the reasons above, I think this is a bad idea for both cases, in my view. It's worse for Call-Info, because of the duplication of existing functionality.
> 
> To use an analogy: The RCD is mostly like a business card. We don't typically write our contracts and messages on business cards - we might staple our business card to a note.
> 
> My constructive suggestion is to create a separate claim if needed. (My understanding is that rcd-14 does not contain the call purpose, so this is the current state.)
>  
> 
> No, we should create, in my view, a separate document that focuses on signing the call purpose, expressed either as Subject (as the compact form) or an explicit JWT claim, such as "subject".
> 
> 
> -Chris
> 
>

---

From: Richard Shockey <[email-masked]>
Date: Sun, 20 Mar 2022 16:43:18 -0400

In line.

From: sipcore <[email-masked]> on behalf of Chris Wendt <[email-masked]>
Date: Sunday, March 20, 2022 at 11:47 AM
To: Henning Schulzrinne <[email-masked]>
Cc: <[email-masked]>, SIPCORE <[email-masked]>
Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-04 (call-reason)

Hi Henning,

RS> Agreed.  There is clear demand for rcd at this point especially among those jurisdictions, especially in the EU that never adopted CNAM.  RCD can deploy and deploy quickly given the pent up demand.

To everyone,

RS> I share Henning’s over all concern and the value of callinfo /call reason is almost self-evident.  I would advise proceeding with rcd as is and lets revisit as we gain experience.  This problem has come up with the value of VERSTAT in the INVITE itself which for now is very very limited and binary and what value does it potentially provide consumers or enterprises in the B and C attestation levels if the full IDENITY header does not cross the AS boundary. I could go into how this might work in VOLTE environments but I won’t. 

As you well know we will be dealing with this all next week at SIPNOC.  (Shameless plug) 

https://www.sipforum.org/news-events/sipnoc-2022-overview/schedule/

Yes all the virtural sessions will be kept on line after the conference.

-Chris

Hi Chris,

On Fri, Mar 18, 2022 at 5:17 PM Chris Wendt <[email-masked]> wrote:

Hi Henning,

 

 

 

 

 

 

-Chris

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