Subject: Re: [stir] RCD vs "div"

From: Jack Rickard <[email-masked]>
Date: Tue, 8 Mar 2022 17:03:40 +0000

I think you may be overcomplicating it: there's nothing preventing you from putting 2 different valid RCD passports on the same call, so you're going to have to be able to deal with conflicting RCD information no matter what. I believe the idea is that you just gather all of the RCD information you consider valid (which may have come from SHAKEN, RCD, or even DIV passports) and deal with it however you want to.

Given that I think the answers are:

Would a retargeted call inherit any RCD claims in the innermost passport?
Yes, but the RCD claims would remain only in the innermost passport, the div passport won't need them because the original passport is still valid.

What happens if someone adds RCD claims to a "div" passport, especially if they conflict with any claims from earlier in the chain?
You deal with however you see fit. I'd guess most people will have them take lower priority than the original ones but I'm not sure.

Is the answer the same for RCD passports vs other passport types with RCD claims?
I don't think there's any real distinction between RCD information in RCD passports vs in any other type of passport.

Jack

From: stir <[email-masked]> On Behalf Of Ben Campbell
Sent: 08 March 2022 15:40
To: Mary Barnes <[email-masked]>; Chris Wendt <[email-masked]>
Cc: Peterson, Jon <[email-masked]>; IETF STIR Mail List <[email-masked]>
Subject: [EXTERNAL] Re: [stir] RCD vs "div"

I'm willing to believe that the RCD draft doesn't need to talk about "div" passports. But just to check my understanding:

- A "div" passport would not copy forward RCD claims from an inner passport. This is covered in RFC 8946, where it says no other claims are copied forward.

- A single "div" passport can chain back to multiple inner passports with matching orig/dest, e.g. if you have a separate SHAKEN and RCD passport in the original INVITE request. Also covered in 8946.

- Can we also assume that no one would ever add _new_ RCD claims to a "div" passport? That seems to make sense, but is it documented somewhere?

Thanks!

Ben.

On Mar 7, 2022, at 2:48 PM, Mary Barnes <[email-masked]<mailto:[email-masked]>> wrote:

I would agree with that in general.  IMHO, we really need a call flow document to show examples of all of this.  I worked on one a long while back  (no RCD - it was focused on DIV) and no one was interested in progressing.
https://www.ietf.org/archive/id/draft-barnes-stir-passport-div-hi-callflows-02.txt<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-barnes-stir-passport-div-hi-callflows-02.txt&data=04%7C01%7Cjack.rickard%40microsoft.com%7Cb79b619144674a4e80a108da011a08c3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637823509198874901%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=oN0%2B%2B5kE8fJQVNNT6iGwNLAsmiAkX9BxP1SS%2F6kC%2BMo%3D&reserved=0>

It's way too much work to do on my own.  But, if anyone is interested, let me know.

Regards,
Mary.

On Mon, Mar 7, 2022 at 2:32 PM Chris Wendt <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ben,

I think the way i'd like to think about it is that "div" rules apply to all PASSporTs and you don't need multiple "div"s if you have multiple PASSporT types.  So, to the extent possible i'd like to keep that line of distinction.  In other words, i'd prefer to not have to discuss all of the other PASSporT types in subsequent PASSporT type specifications to the extent possible.

A simpler answer would be that i don't believe "rcd" has any implications specific to "div" other than someone adding new "div"s and following the general rules.

-Chris

> On Mar 7, 2022, at 3:25 PM, Ben Campbell <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi,
>
> (Apologies for bringing this up late in the process for RCD, but I just thought about it over the weekend.)
>
> Does the RCD passport draft need to talk about interactions with "div" passports?
>
> For example, would a retargeted call inherit any RCD claims in the innermost passport? What happens if someone adds RCD claims to a "div" passport, especially if they conflict with any claims from earlier in the chain? Is the answer the same for RCD passports vs other passport types with RCD claims?
>
> Thanks!
>
> Ben.

_______________________________________________
stir mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/stir<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fstir&data=04%7C01%7Cjack.rickard%40microsoft.com%7Cb79b619144674a4e80a108da011a08c3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637823509198874901%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=eAuVhp53yB%2BYmlWFzCqE9sj9LZpT3OlZkfNjxkg11PE%3D&reserved=0>
_______________________________________________
stir mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/stir

---

From: Ben Campbell <[email-masked]>
Date: Tue, 8 Mar 2022 11:11:48 -0600

Hi Jack,

I understand you could get multiple passports with RCD in them even without div, and have to figure out what to use. But since a “div” passport has an explicit association with a chain of earlier passports, I wonder what it would mean to put RCD claims in a “div” passport if an innermost passport already had RCD. That seems semantically different from getting two passports with RCD that are only related by the fact they are in the same INVITE request.

A simple answer could be “don’t do that.”

Thanks!

Ben.

> On Mar 8, 2022, at 11:03 AM, Jack Rickard <[email-masked]> wrote:
> 
> I think you may be overcomplicating it: there’s nothing preventing you from putting 2 different valid RCD passports on the same call, so you’re going to have to be able to deal with conflicting RCD information no matter what. I believe the idea is that you just gather all of the RCD information you consider valid (which may have come from SHAKEN, RCD, or even DIV passports) and deal with it however you want to.
>  
> Yes, but the RCD claims would remain only in the innermost passport, the div passport won’t need them because the original passport is still valid.
>  
> What happens if someone adds RCD claims to a “div” passport, especially if they conflict with any claims from earlier in the chain?
> You deal with however you see fit. I’d guess most people will have them take lower priority than the original ones but I’m not sure.
>  
> I don’t think there’s any real distinction between RCD information in RCD passports vs in any other type of passport.
> 
> Jack
>  
> From: stir <[email-masked] <mailto:[email-masked]>> On Behalf Of Ben Campbell
> To: Mary Barnes <[email-masked] <mailto:[email-masked]>>; Chris Wendt <[email-masked] <mailto:[email-masked]>>
> Cc: Peterson, Jon <[email-masked] <mailto:[email-masked]>>; IETF STIR Mail List <[email-masked] <mailto:[email-masked]>>
> I’m willing to believe that the RCD draft doesn’t need to talk about “div” passports. But just to check my understanding:
>  
> - A “div” passport would not copy forward RCD claims from an inner passport. This is covered in RFC 8946, where it says no other claims are copied forward.
>  
> - A single “div” passport can chain back to multiple inner passports with matching orig/dest, e.g. if you have a separate SHAKEN and RCD passport in the original INVITE request. Also covered in 8946.
>  
> - Can we also assume that no one would ever add _new_ RCD claims to a “div” passport? That seems to make sense, but is it documented somewhere?
>  
> Thanks!
>  
> Ben.
> 
> 
> On Mar 7, 2022, at 2:48 PM, Mary Barnes <[email-masked] <mailto:[email-masked]>> wrote:
>  
> https://www.ietf.org/archive/id/draft-barnes-stir-passport-div-hi-callflows-02.txt <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-barnes-stir-passport-div-hi-callflows-02.txt&data=04%7C01%7Cjack.rickard%40microsoft.com%7Cb79b619144674a4e80a108da011a08c3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637823509198874901%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=oN0%2B%2B5kE8fJQVNNT6iGwNLAsmiAkX9BxP1SS%2F6kC%2BMo%3D&reserved=0>
>  
> On Mon, Mar 7, 2022 at 2:32 PM Chris Wendt <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Ben,
> 
> I think the way i'd like to think about it is that “div” rules apply to all PASSporTs and you don’t need multiple “div”s if you have multiple PASSporT types.  So, to the extent possible i’d like to keep that line of distinction.  In other words, i’d prefer to not have to discuss all of the other PASSporT types in subsequent PASSporT type specifications to the extent possible.
> 
> A simpler answer would be that i don’t believe “rcd” has any implications specific to “div” other than someone adding new “div”s and following the general rules.
> 
> -Chris
> 
> > On Mar 7, 2022, at 3:25 PM, Ben Campbell <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > Hi,
> > 
> > Does the RCD passport draft need to talk about interactions with “div” passports?
> > 
> > For example, would a retargeted call inherit any RCD claims in the innermost passport? What happens if someone adds RCD claims to a “div” passport, especially if they conflict with any claims from earlier in the chain? Is the answer the same for RCD passports vs other passport types with RCD claims?
> > 
> > Thanks!
> > 
> > Ben.
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/stir <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fstir&data=04%7C01%7Cjack.rickard%40microsoft.com%7Cb79b619144674a4e80a108da011a08c3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637823509198874901%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=eAuVhp53yB%2BYmlWFzCqE9sj9LZpT3OlZkfNjxkg11PE%3D&reserved=0>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>

---

From: Chris Wendt <[email-masked]>
Date: Tue, 8 Mar 2022 12:24:09 -0500

I think putting “rcd” on a “div” identity header would be simply a fundamental misunderstanding of what “div” represents regarding the calling party identity.  I would hope we don’t need to spell that out.

I’m not sure if this was your intention but i wouldn’t say there is an “explicit association with a chain of earlier PASSporTs”  I think the opposite is true, there is a relationship with orig and dest of PASSporT(s) and new destination of “div” PASSporTs.

-Chris

> On Mar 8, 2022, at 12:11 PM, Ben Campbell <[email-masked]> wrote:
> 
> Hi Jack,
> 
>> On Mar 8, 2022, at 11:03 AM, Jack Rickard <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Ben Campbell <[email-masked]>
Date: Tue, 8 Mar 2022 11:28:48 -0600

> On Mar 8, 2022, at 11:24 AM, Chris Wendt <[email-masked]> wrote:
> 

I guess the real question is interoperability. If people think this is obvious enough that people won’t screw it up, I’m okay with it.

> I’m not sure if this was your intention but i wouldn’t say there is an “explicit association with a chain of earlier PASSporTs”  I think the opposite is true, there is a relationship with orig and…

I didn’t mean to imply any semantics to the association other than that the linkage exists. I guess two RCD passports with the same orig and dest would have the same association—which I guess supports Jack’s argument that there is nothing special about RCD in “div” passports.

Ben.

> 
> -Chris
> 
>> On Mar 8, 2022, at 12:11 PM, Ben Campbell <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Jack,
>>

---

From: "Holmes, David" <[email-masked]>
Date: Tue, 8 Mar 2022 19:59:44 +0000

The bottom line is going to be which passport comes from the most trusted entity (from the perspective of the terminating carrier and/recipient) and/or which allows a better assessment of the caller's reputation to be made (if needed).  Obviously issues way beyond scope of any SDO, but ripe for someone to create a relevant "Code of practice".

BR/David

From: stir <[email-masked]> On Behalf Of Ben Campbell
Sent: Tuesday, March 8, 2022 9:29 AM
To: Chris Wendt <[email-masked]>
Cc: Peterson, Jon <[email-masked]>; Mary Barnes <[email-masked]>; Jack Rickard <[email-masked]>; IETF STIR Mail List <[email-masked]>
Subject: Re: [stir] RCD vs "div"

[External]

On Mar 8, 2022, at 11:24 AM, Chris Wendt <[email-masked]<mailto:[email-masked]>> wrote:

I think putting "rcd" on a "div" identity header would be simply a fundamental misunderstanding of what "div" represents regarding the calling party identity.  I would hope we don't need to spell that out.

I guess the real question is interoperability. If people think this is obvious enough that people won't screw it up, I'm okay with it.

I'm not sure if this was your intention but i wouldn't say there is an "explicit association with a chain of earlier PASSporTs"  I think the opposite is true, there is a relationship with orig and dest of PASSporT(s) and new destination of "div" PASSporTs.

I didn't mean to imply any semantics to the association other than that the linkage exists. I guess two RCD passports with the same orig and dest would have the same association-which I guess supports Jack's argument that there is nothing special about RCD in "div" passports.

Ben.

-Chris

On Mar 8, 2022, at 12:11 PM, Ben Campbell <[email-masked]<mailto:[email-masked]>> wrote:

Hi Jack,

I understand you could get multiple passports with RCD in them even without div, and have to figure out what to use. But since a "div" passport has an explicit association with a chain of earlier passports, I wonder what it would mean to put RCD claims in a "div" passport if an innermost passport already had RCD. That seems semantically different from getting two passports with RCD that are only related by the fact they are in the same INVITE request.

A simple answer could be "don't do that."

Thanks!

Ben.

On Mar 8, 2022, at 11:03 AM, Jack Rickard <[email-masked]<mailto:[email-masked]>> wrote:

Jack

From: stir <[email-masked]<mailto:[email-masked]>> On Behalf Of Ben Campbell
Sent: 08 March 2022 15:40
To: Mary Barnes <[email-masked]<mailto:[email-masked]>>; Chris Wendt <[email-masked]<mailto:[email-masked]>>
Cc: Peterson, Jon <[email-masked]<mailto:[email-masked]>>; IETF STIR Mail List <[email-masked]<mailto:[email-masked]>>
Subject: [EXTERNAL] Re: [stir] RCD vs "div"

Thanks!

Ben.

I would agree with that in general.  IMHO, we really need a call flow document to show examples of all of this.  I worked on one a long while back  (no RCD - it was focused on DIV) and no one was interested in progressing.
https://www.ietf.org/archive/id/draft-barnes-stir-passport-div-hi-callflows-02.txt<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-barnes-stir-passport-div-hi-callflows-02.txt&data=04%7C01%7Cdavid.holmes%40t-mobile.com%7C11d4aa0d70ec4a7cfb7408da01292bef%7Cbe0f980bdd994b19bd7bbc71a09b026c%7C0%7C0%7C637823573598265762%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=wp86b64trt9hVVKjAoA6MlBkeFZu8gpOshEWty7kjis%3D&reserved=0>

Regards,
Mary.

-Chris

_______________________________________________
stir mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/stir<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fstir&data=04%7C01%7Cdavid.holmes%40t-mobile.com%7C11d4aa0d70ec4a7cfb7408da01292bef%7Cbe0f980bdd994b19bd7bbc71a09b026c%7C0%7C0%7C637823573598265762%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Qx7nrpVtUpR52LwSr5fJ0HyD7RpUNOyFiXnzJwJlSqM%3D&reserved=0>
_______________________________________________
stir mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/stir<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fstir&data=04%7C01%7Cdavid.holmes%40t-mobile.com%7C11d4aa0d70ec4a7cfb7408da01292bef%7Cbe0f980bdd994b19bd7bbc71a09b026c%7C0%7C0%7C637823573598265762%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Qx7nrpVtUpR52LwSr5fJ0HyD7RpUNOyFiXnzJwJlSqM%3D&reserved=0>

---

From: David Hancock <[email-masked]>
Date: Wed, 9 Mar 2022 12:44:29 -0700

Adding rich call data to a div PASSporT does seem to me to go above and
beyond the original intent of the div PASSporT RFC. However, if we think
someone might want to do this, then would it make sense to have a rule that
the rich call data in the "rcd" claim of a div PASSporT must be associated
with the "div" claim identity, not the "orig" claim identity. The logic
being – the div authentication service is authoritative for the identity in
the "div" claim, but has no relationship with the identity in the "orig"
claim. I’m not sure if this would be a useful capability; e.g., might there
be a case where the diverting entity wants to provide its rich call data to
the diverted-to user? But in any case this would avoid creating the
situation where there is conflicting rcd info between an inner PASSporT and
the div PASSporT(s).

On Tue, Mar 8, 2022 at 1:00 PM Holmes, David <[email-masked]>
wrote:

> The bottom line is going to be which passport comes from the most trusted
> entity (from the perspective of the terminating carrier and/recipient)
> and/or which allows a better assessment of the caller’s reputation to be
> made (if needed).  Obviously issues way beyond scope of any SDO, but ripe
> for someone to create a relevant “Code of practice”.
>
>
>
> BR/David
>
>
>
> *From:* stir <[email-masked]> *On Behalf Of * Ben Campbell
> *Sent:* Tuesday, March 8, 2022 9:29 AM
> *To:* Chris Wendt <[email-masked]>
> *Cc:* Peterson, Jon <[email-masked]>; Mary Barnes <
> [email-masked]>; Jack Rickard <[email-masked]>;
> IETF STIR Mail List <[email-masked]>
> *Subject:* Re: [stir] RCD vs "div"
>
>
>
> *[External]*
>
>
>
>
>
>
>
> I think putting “rcd” on a “div” identity header would be simply a
> fundamental misunderstanding of what “div” represents regarding the calling
> party identity.  I would hope we don’t need to spell that out.
>
>
>
> I guess the real question is interoperability. If people think this is
> obvious enough that people won’t screw it up, I’m okay with it.
>
>
>
>
>
> I’m not sure if this was your intention but i wouldn’t say there is
> an “explicit association with a chain of earlier PASSporTs”  I think
> the opposite is true, there is a relationship with orig and dest of
> PASSporT(s) and new destination of “div” PASSporTs.
>
>
>
> I didn’t mean to imply any semantics to the association other than that
> the linkage exists. I guess two RCD passports with the same orig and dest
> would have the same association—which I guess supports Jack’s argument that
> there is nothing special about RCD in “div” passports.
>
>
>
> Ben.
>
>
>
>
>
> -Chris
>
>
>
> I understand you could get multiple passports with RCD in them even
> without div, and have to figure out what to use. But since a “div” passport
> has an explicit association with a chain of earlier passports, I wonder
> what it would mean to put RCD claims in a “div” passport if an innermost
> passport already had RCD. That seems semantically different from getting
> two passports with RCD that are only related by the fact they are in the
> same INVITE request.
>
>
>
> I think you may be overcomplicating it: there’s nothing preventing you
> from putting 2 different valid RCD passports on the same call, so you’re
> going to have to be able to deal with conflicting RCD information no matter
> what. I believe the idea is that you just gather all of the RCD information
> you consider valid (which may have come from SHAKEN, RCD, or even DIV
> passports) and deal with it however you want to.
>
>
>
> Yes, but the RCD claims would remain only in the innermost passport, the
> div passport won’t need them because the original passport is still valid.
>
>
>
> What happens if someone adds RCD claims to a “div” passport, especially if
> they conflict with any claims from earlier in the chain?
>
> You deal with however you see fit. I’d guess most people will have them
> take lower priority than the original ones but I’m not sure.
>
>
>
> I don’t think there’s any real distinction between RCD information in RCD
> passports vs in any other type of passport.
>
>
> Jack
>
>
>
> *From:* stir <[email-masked]> *On Behalf Of *Ben Campbell
> *Sent:* 08 March 2022 15:40
> *To:* Mary Barnes <[email-masked]>; Chris Wendt <
> [email-masked]>
> *Cc:* Peterson, Jon <[email-masked]>; IETF STIR Mail List <
> [email-masked]>
> *Subject:* [EXTERNAL] Re: [stir] RCD vs "div"
>
>
>
> I’m willing to believe that the RCD draft doesn’t need to talk about “div”
> passports. But just to check my understanding:
>
>
>
> - A “div” passport would not copy forward RCD claims from an inner
> passport. This is covered in RFC 8946, where it says no other claims are
> copied forward.
>
>
>
> - A single “div” passport can chain back to multiple inner passports with
> matching orig/dest, e.g. if you have a separate SHAKEN and RCD passport in
> the original INVITE request. Also covered in 8946.
>
>
>
> - Can we also assume that no one would ever add _new_ RCD claims to a
> “div” passport? That seems to make sense, but is it documented somewhere?
>
>
>
> Thanks!
>
>
>
> Ben.
>
>
>
>
> On Mar 7, 2022, at 2:48 PM, Mary Barnes <[email-masked]>
> wrote:
>
>
>
> I would agree with that in general.  IMHO, we really need a call flow
> document to show examples of all of this.  I worked on one a long while
> back  (no RCD - it was focused on DIV) and no one was interested in
> progressing.
>
>
> https://www.ietf.org/archive/id/draft-barnes-stir-passport-div-hi-callflows-02.txt
> <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-barnes-stir-passport-div-hi-callflows-02.txt&data=04%7C01%7Cdavid.holmes%40t-mobile.com%7C11d4aa0d70ec4a7cfb7408da01292bef%7Cbe0f980bdd994b19bd7bbc71a09b026c%7C0%7C0%7C637823573598265762%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=wp86b64trt9hVVKjAoA6MlBkeFZu8gpOshEWty7kjis%3D&reserved=0>
>
>
>
> On Mon, Mar 7, 2022 at 2:32 PM Chris Wendt <[email-masked]>
> wrote:
>
> Hi Ben,
>
> I think the way i'd like to think about it is that “div” rules apply to
> all PASSporTs and you don’t need multiple “div”s if you have multiple
> PASSporT types.  So, to the extent possible i’d like to keep that line of
> distinction.  In other words, i’d prefer to not have to discuss all of the
> other PASSporT types in subsequent PASSporT type specifications to the
> extent possible.
>
> A simpler answer would be that i don’t believe “rcd” has any implications
> specific to “div” other than someone adding new “div”s and following the
> general rules.
>
> -Chris
>
> > On Mar 7, 2022, at 3:25 PM, Ben Campbell <[email-masked]> wrote:
> >
> > Hi,
> >
> > For example, would a retargeted call inherit any RCD claims in the
> innermost passport? What happens if someone adds RCD claims to a “div”
> passport, especially if they conflict with any claims from earlier in the
> chain? Is the answer the same for RCD passports vs other passport types
> with RCD claims?
> >
> > Thanks!
> >
> > Ben.
>
> [email-masked]
> <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fstir&data=04%7C01%7Cdavid.holmes%40t-mobile.com%7C11d4aa0d70ec4a7cfb7408da01292bef%7Cbe0f980bdd994b19bd7bbc71a09b026c%7C0%7C0%7C637823573598265762%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Qx7nrpVtUpR52LwSr5fJ0HyD7RpUNOyFiXnzJwJlSqM%3D&reserved=0>
>
> [email-masked]
> <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fstir&data=04%7C01%7Cdavid.holmes%40t-mobile.com%7C11d4aa0d70ec4a7cfb7408da01292bef%7Cbe0f980bdd994b19bd7bbc71a09b026c%7C0%7C0%7C637823573598265762%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Qx7nrpVtUpR52LwSr5fJ0HyD7RpUNOyFiXnzJwJlSqM%3D&reserved=0>
>
>
>
>
>
>
> [email-masked]

---

From: Chris Wendt <[email-masked]>
Date: Wed, 9 Mar 2022 15:14:14 -0500

No, the identity header is all about the calling party, should not represent anything else. I think we even say that explicitly many times, hopefully “div” specs donot imply that it represents anything besides the fact that the call has been redirected from the original destination party.

> On Mar 9, 2022, at 2:44 PM, David Hancock <[email-masked]> wrote:
> 
> Adding rich call data to a div PASSporT does seem to me to go above and beyond the original intent of the div PASSporT RFC. However, if we think someone might want to do this, then would it make sense to have a rule that the rich call data in the "rcd" claim of a div PASSporT must be associated with the "div" claim identity, not the "orig" claim identity. The logic being – the div authentication service is authoritative for the identity in the "div" claim, but has no relationship with the identity in the "orig" claim. I’m not sure if this would be a useful capability; e.g., might there be a case where the diverting entity wants to provide its rich call data to the diverted-to user? But in any case this would avoid creating the situation where there is conflicting rcd info between an inner PASSporT and the div PASSporT(s). 
> 
> 
> On Tue, Mar 8, 2022 at 1:00 PM Holmes, David <[email-masked] <mailto:[email-masked]>> wrote:
> The bottom line is going to be which passport comes from the most trusted entity (from the perspective of the terminating carrier and/recipient) and/or which allows a better assessment of the caller’s reputation to be made (if needed).  Obviously issues way beyond scope of any SDO, but ripe for someone to create a relevant “Code of practice”.
> 
>  
> 
> BR/David
> 
>  
> 
> To: Chris Wendt <[email-masked] <mailto:[email-masked]>>
> Cc: Peterson, Jon <[email-masked]>; Mary Barnes <[email-masked] <mailto:[email-masked]>>; Jack Rickard <[email-masked] <mailto:[email-masked]>>; IETF STIR Mail List <[email-masked] <mailto:[email-masked]>>
> On Mar 8, 2022, at 11:24 AM, Chris Wendt <[email-masked] <mailto:[email-masked]>> wrote:
> 
>  
> 
> https://www.ietf.org/archive/id/draft-barnes-stir-passport-div-hi-callflows-02.txt <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-barnes-stir-passport-div-hi-callflows-02.txt&data=04%7C01%7Cdavid.holmes%40t-mobile.com%7C11d4aa0d70ec4a7cfb7408da01292bef%7Cbe0f980bdd994b19bd7bbc71a09b026c%7C0%7C0%7C637823573598265762%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=wp86b64trt9hVVKjAoA6MlBkeFZu8gpOshEWty7kjis%3D&reserved=0>
>  
> 
> https://www.ietf.org/mailman/listinfo/stir <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fstir&data=04%7C01%7Cdavid.holmes%40t-mobile.com%7C11d4aa0d70ec4a7cfb7408da01292bef%7Cbe0f980bdd994b19bd7bbc71a09b026c%7C0%7C0%7C637823573598265762%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Qx7nrpVtUpR52LwSr5fJ0HyD7RpUNOyFiXnzJwJlSqM%3D&reserved=0>
> https://www.ietf.org/mailman/listinfo/stir <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fstir&data=04%7C01%7Cdavid.holmes%40t-mobile.com%7C11d4aa0d70ec4a7cfb7408da01292bef%7Cbe0f980bdd994b19bd7bbc71a09b026c%7C0%7C0%7C637823573598265762%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Qx7nrpVtUpR52LwSr5fJ0HyD7RpUNOyFiXnzJwJlSqM%3D&reserved=0>
>  
> 
>  
> 
>  
>

---

From: Mary Barnes <[email-masked]>
Date: Wed, 9 Mar 2022 16:14:41 -0600

Both Diversion Header and History-Info header have information as to why
the call was diverted.  And, History-Info includes the type of retarget
that is useful for some services.  There are services that can involve
retargeting where the calling party number matters.  For example, there may
be call forwarding scenarios where you want to display the number for the
first retargeting as the calling party and not the original calling party.
The whole purpose for Diversion and History-Info header fields is to
provide information to services and there is not a single way they are
handled by the called party.

On Wed, Mar 9, 2022 at 2:14 PM Chris Wendt <[email-masked]>
wrote:

> No, the identity header is all about the calling party, should not
> represent anything else. I think we even say that explicitly many times,
> hopefully “div” specs donot imply that it represents anything besides the
> fact that the call has been redirected from the original destination party.
>
>> What happens if someone adds RCD claims to a “div” passport, especially
>> if they conflict with any claims from earlier in the chain?
>>
>> I’m willing to believe that the RCD draft doesn’t need to talk about
>> “div” passports. But just to check my understanding:
>>
>>
>>

---

From: David Hancock <[email-masked]>
Date: Wed, 9 Mar 2022 15:38:35 -0700

Yeah, maybe my suggestion was a road too far, although it has the nice
feature that it reduces the opportunity for conflicting rich call data. I
had in mind that the "rcd" claim could be applied more broadly; i.e., it
could provide rich-call-data for any identity, as opposed to rich-call-data
for only the calling identity. But rereading the rcd draft, I see that it
is pretty calling-identity centric, and there are probably good reasons not
to deviate from that at this point.

Since the div authentication service has no relationship with the calling
identity, it seems inappropriate (almost wrong) for it to add an rcd claim
for the calling identity. The only case I can think of is – a div
authentication service notices that none of the inner PASSporTs contain
rich-call-data, and so it uses the 3rd-party rcd procedures (section 12 of
the rcd draft) to obtain the rich call data for the verified inner PASSporT
"orig" claim identity. But this seems very unlikely – why would a div
authentication service be so altruistic?

Based on this discussion, what does a verification service do with "extra"
claims in a PASSporT type that aren’t explicitly defined for that PASSporT
type (noting that the rcd ietf draft does explicitly say that a shaken
PASSporT can have an "rcd" claim)? Would it be OK/compliant if the
verification service includes these “extra” claims when validating the
PASSporT’s signature, but otherwise ignores them?

Thanks,

David

---

From: David Hancock <[email-masked]>
Date: Wed, 9 Mar 2022 15:58:59 -0700

Hi Mary -- comment on your following comment...

"For example, there may be call forwarding scenarios where you want to
display the number for the first retargeting as the calling party and not
the original calling party."

I vaguely remember hearing about call scenarios where the retargeting
identity is displayed to the called user, instead of or in addition to the
original calling identity. Are these cases documented anywhere?

If the TSP is displaying the number for the first retargeting entity to the
called user instead of the original calling identity, then would there be
value in also being able to display rich call data associated with the
first retargeting entity? This gets back to my suggestion that an "rcd"
claim in a div PASSporT describes the rich call data of the "div" claim
identity. If there are legitimate scenarios where the "div" claim identity
becomes the calling identity, then maybe my suggestion has merit? Just want
to understand what we're leaving on/off the table with what we decide here.

Thanks,
David

On Wed, Mar 9, 2022 at 3:14 PM Mary Barnes <[email-masked]>
wrote:

>>> The bottom line is going to be which passport comes from the most
>>> trusted entity (from the perspective of the terminating carrier
>>> and/recipient) and/or which allows a better assessment of the caller’s
>>> reputation to be made (if needed).  Obviously issues way beyond scope of
>>> any SDO, but ripe for someone to create a relevant “Code of practice”.
>>>
>>>
>>>
>>> BR/David
>>>
>>>
>>>
>>> I don’t think there’s any real distinction between RCD information in
>>> RCD passports vs in any other type of passport.
>>>
>>>
>>> Jack
>>>
>>>
>>>
>>> - A single “div” passport can chain back to multiple inner passports
>>> with matching orig/dest, e.g. if you have a separate SHAKEN and RCD
>>> passport in the original INVITE request. Also covered in 8946.
>>>
>>>
>>>
>>> A simpler answer would be that i don’t believe “rcd” has any
>>> implications specific to “div” other than someone adding new “div”s and
>>> following the general rules.
>>>
>>> -Chris
>>>

---

From: "Dianda, Robert" <[email-masked]>
Date: Thu, 10 Mar 2022 15:22:01 +0000

David,

I don’t know of any case where the TSP displays the forwarding TN as the calling number. There are forwarding cases where a call is forwarded by an enterprise and the original calling number is discarded and an enterprise TN is used as the calling party number for the forwarded TN. The only case where I know that this occurs is where the enterprise does not support Diversion (or History-Info) – so forwarded call looks like a “new” call versus a forwarded call.
Since this would be treated by  the OSP as a new call no “div” PASSporT would be present.

I have seen where the called party (a cell phone) sees the calling party number and the forwarded number. In this case I don’t think “rcd” for the forwarding TN would be of value.

Regards
Robert

From: stir [mailto:[email-masked]] On Behalf Of David Hancock
Sent: Wednesday, March 9, 2022 3:59 PM
To: Mary Barnes <[email-masked]>
Cc: Ben Campbell <[email-masked]>; Jack Rickard <[email-masked]>; Holmes, David <[email-masked]>; IETF STIR Mail List <[email-masked]>; Peterson, Jon <[email-masked]>; Chris Wendt <[email-masked]>
Subject: [EXTERNAL] Re: [stir] RCD vs "div"

CAUTION: The e-mail below is from an external source. Please exercise caution before opening attachments, clicking links, or following guidance.
Hi Mary -- comment on your following comment...

"For example, there may be call forwarding scenarios where you want to display the number for the first retargeting as the calling party and not the original calling party."

I vaguely remember hearing about call scenarios where the retargeting identity is displayed to the called user, instead of or in addition to the original calling identity. Are these cases documented anywhere?

If the TSP is displaying the number for the first retargeting entity to the called user instead of the original calling identity, then would there be value in also being able to display rich call data associated with the first retargeting entity? This gets back to my suggestion that an "rcd" claim in a div PASSporT describes the rich call data of the "div" claim identity. If there are legitimate scenarios where the "div" claim identity becomes the calling identity, then maybe my suggestion has merit? Just want to understand what we're leaving on/off the table with what we decide here.

Thanks,
David

On Wed, Mar 9, 2022 at 3:14 PM Mary Barnes <[email-masked]<mailto:[email-masked]>> wrote:
Both Diversion Header and History-Info header have information as to why the call was diverted.  And, History-Info includes the type of retarget that is useful for some services.  There are services that can involve retargeting where the calling party number matters.  For example, there may be call forwarding scenarios where you want to display the number for the first retargeting as the calling party and not the original calling party.  The whole purpose for Diversion and History-Info header fields is to provide information to services and there is not a single way they are handled by the called party.

On Wed, Mar 9, 2022 at 2:14 PM Chris Wendt <[email-masked]<mailto:[email-masked]>> wrote:
No, the identity header is all about the calling party, should not represent anything else. I think we even say that explicitly many times, hopefully “div” specs donot imply that it represents anything besides the fact that the call has been redirected from the original destination party.

On Mar 9, 2022, at 2:44 PM, David Hancock <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Mar 8, 2022 at 1:00 PM Holmes, David <[email-masked]<mailto:[email-masked]>> wrote:
The bottom line is going to be which passport comes from the most trusted entity (from the perspective of the terminating carrier and/recipient) and/or which allows a better assessment of the caller’s reputation to be made (if needed).  Obviously issues way beyond scope of any SDO, but ripe for someone to create a relevant “Code of practice”.

BR/David

From: stir <[email-masked]<mailto:[email-masked]>> On Behalf Of Ben Campbell
Sent: Tuesday, March 8, 2022 9:29 AM
To: Chris Wendt <[email-masked]<mailto:[email-masked]>>
Cc: Peterson, Jon <[email-masked]<mailto:[email-masked]>>; Mary Barnes <[email-masked]<mailto:[email-masked]>>; Jack Rickard <[email-masked]<mailto:[email-masked]>>; IETF STIR Mail List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [stir] RCD vs "div"

[External]

Ben.

-Chris

Hi Jack,

Thanks!

Ben.

Jack

Thanks!

Ben.

Regards,
Mary.

-Chris

E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.

---

From: Chris Wendt <[email-masked]>
Date: Thu, 10 Mar 2022 11:10:52 -0500

Wouldn’t you essentially treat that as a new call with new caller-id and start from scratch anyway?  I’m a bit afraid of any of this scenario because it implies some sort of spoofing of the caller that we are trying to eliminate with STIR in the first place.

> On Mar 9, 2022, at 5:58 PM, David Hancock <[email-masked]> wrote:
> 
> On Wed, Mar 9, 2022 at 3:14 PM Mary Barnes <[email-masked] <mailto:[email-masked]>> wrote:
> On Wed, Mar 9, 2022 at 2:14 PM Chris Wendt <[email-masked] <mailto:[email-masked]>> wrote:
>> On Mar 9, 2022, at 2:44 PM, David Hancock <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Cc: Peterson, Jon <[email-masked] <mailto:[email-masked]>>; Mary Barnes <[email-masked] <mailto:[email-masked]>>; Jack Rickard <[email-masked] <mailto:[email-masked]>>; IETF STIR Mail List <[email-masked] <mailto:[email-masked]>>

---

From: Mary Barnes <[email-masked]>
Date: Thu, 10 Mar 2022 10:32:37 -0600

The scenario where I think this could be used would be example 3.4 in
https://datatracker.ietf.org/doc/html/rfc7131.  In that scenario, they
could use RCD to display to the "Silver" agent that the call was being
retargeted from the Gold queue.

Basically, when it comes to "div" I don't think we should be limiting the
types of information available as different services use it differently.

Mary.

On Wed, Mar 9, 2022 at 4:59 PM David Hancock <[email-masked]>
wrote:

> If the TSP is displaying the number for the first retargeting entity to
> the called user instead of the original calling identity, then would there
> be value in also being able to display rich call data associated with the
>>>> Yes, but the RCD claims would remain only in the innermost passport,
>>>> the div passport won’t need them because the original passport is still
>>>> valid.
>>>>
>>>>
>>>>

---

From: Mary Barnes <[email-masked]>
Date: Thu, 10 Mar 2022 10:33:14 -0600

We are trying to eliminate "illegal" spoofing. There is also legal spoofing
that we shouldn't be eliminating.

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

> Wouldn’t you essentially treat that as a new call with new caller-id and
> start from scratch anyway?  I’m a bit afraid of any of this scenario
> because it implies some sort of spoofing of the caller that we are trying
> to eliminate with STIR in the first place.
>

---

From: Chris Wendt <[email-masked]>
Date: Thu, 10 Mar 2022 12:21:50 -0500

This is an important concept we need to agree, “spoofing” is the act of saying who you are not.  STIR should eliminate that concept, you can only assert your own identity, not an identity you do not have the right-to-use.  So i would disagree with you.

> On Mar 10, 2022, at 11:33 AM, Mary Barnes <[email-masked]> wrote:
> 
> We are trying to eliminate "illegal" spoofing. There is also legal spoofing that we shouldn't be eliminating.
> 
> On Thu, Mar 10, 2022 at 10:10 AM Chris Wendt <[email-masked] <mailto:[email-masked]>> wrote:
>> On Mar 9, 2022, at 5:58 PM, David Hancock <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Chris Wendt <[email-masked]>
Date: Thu, 10 Mar 2022 12:23:35 -0500

Sorry, clarification “spoofing” and what we want to remove is the act of using an identity you haven’t proven you have the right-to-use.

> On Mar 10, 2022, at 12:21 PM, Chris Wendt <[email-masked]> wrote:
> 
>> On Mar 10, 2022, at 11:33 AM, Mary Barnes <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Thu, 10 Mar 2022 13:04:31 -0600

OK, so then 2 questions.

   1. How does a consumer (or their device) "prove" they have the right to
   use a number?  What "evidence" do they present, and to whom?

   2. Who grants the consumer this "right"?  What form does the grant
   take?

I think they're silly questions because the answers are (1) they can't, and
(2) nobody.

As I understand it, there is nothing "on the wire" that would prove such a
right-to-use was valid.  Instead we "implicitly trust" the identity in the
P-Asserted-Identity header.  If it's not a number the originating device is
authorized to use, the originating carrier made a mistake.  STIR / SHAKEN
provides a means to hold carriers responsible if they make such mistakes.

STIR / SHAKEN will not AFAIK stop a call from the furnace repairman
presenting as its CPN the toll free number of Home Depot's service center.
For that to happen, Home Depot had to have worked with their carrier to
provide the numbers of their technicians, and authorized their carrier to
modify the PAID header in this way.  The carrier should have "signed its
work" so if there's any question whether it was appropriate, we have an
audit trail.

The interesting follow-on question is what RCD gets presented in such a
case.  ISTM it might combine information about Home Depot (e.g., address,
logo, hours) and information about the repairman (e.g., his name, what he
looks like, what kind of car he drives).  If that's a desired end result,
are there standards needed to make it possible?

tim

On Thu, Mar 10, 2022 at 11:23 AM Chris Wendt <[email-masked]>
wrote:

> Sorry, clarification “spoofing” and what we want to remove is the act of
> using an identity you haven’t proven you have the right-to-use.
>
> This is an important concept we need to agree, “spoofing” is the act of
> saying who you are not.  STIR should eliminate that concept, you can only
> assert your own identity, not an identity you do not have the
> right-to-use.  So i would disagree with you.
>
> We are trying to eliminate "illegal" spoofing. There is also legal
> spoofing that we shouldn't be eliminating.
>
>>>>> I didn’t mean to imply any semantics to the association other than
>>>>> that the linkage exists. I guess two RCD passports with the same orig and
>>>>> dest would have the same association—which I guess supports Jack’s argument
>>>>> that there is nothing special about RCD in “div” passports.
>>>>>
>>>>>
>>>>>
>>>>> Ben.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -Chris
>>>>>
>>>>>
>>>>>
>>>>> What happens if someone adds RCD claims to a “div” passport,
>>>>> especially if they conflict with any claims from earlier in the chain?
>>>>>
>>>>> You deal with however you see fit. I’d guess most people will have
>>>>> them take lower priority than the original ones but I’m not sure.
>>>>>
>>>>>
>>>>>
>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__nam02.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.ietf.org-252Farchive-252Fid-252Fdraft-2Dbarnes-2Dstir-2Dpassport-2Ddiv-2Dhi-2Dcallflows-2D02.txt-26data-3D04-257C01-257Cdavid.holmes-2540t-2Dmobile.com-257C11d4aa0d70ec4a7cfb7408da01292bef-257Cbe0f980bdd994b19bd7bbc71a09b026c-257C0-257C0-257C637823573598265762-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C3000-26sdata-3Dwp86b64trt9hVVKjAoA6MlBkeFZu8gpOshEWty7kjis-253D-26reserved-3D0&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=c_Kmr0d7wYbLjRgLlHhXDviBK0s0URNX8Rv57YMgUiA&m=GvnHPrfC3PsLJXplKXyXqK6mGtduWtTybUpETLN0oqjjin1oz9J9GUSgUqxIa1W5&s=zhMTOg29rgCq8KsjWnXyZ_582kT7zpmyLEmycFMOWtQ&e=>
>>>>>
>>>>>
>>>>>
>>>>> I think the way i'd like to think about it is that “div” rules apply
>>>>> to all PASSporTs and you don’t need multiple “div”s if you have multiple
>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__nam02.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.ietf.org-252Fmailman-252Flistinfo-252Fstir-26data-3D04-257C01-257Cdavid.holmes-2540t-2Dmobile.com-257C11d4aa0d70ec4a7cfb7408da01292bef-257Cbe0f980bdd994b19bd7bbc71a09b026c-257C0-257C0-257C637823573598265762-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C3000-26sdata-3DQx7nrpVtUpR52LwSr5fJ0HyD7RpUNOyFiXnzJwJlSqM-253D-26reserved-3D0&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=c_Kmr0d7wYbLjRgLlHhXDviBK0s0URNX8Rv57YMgUiA&m=GvnHPrfC3PsLJXplKXyXqK6mGtduWtTybUpETLN0oqjjin1oz9J9GUSgUqxIa1W5&s=Ny0S_IVz5OJQ3WTT8hBPOhB33PeNbOhnPye9sPWGB1g&e=>
>>>>>
>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__nam02.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.ietf.org-252Fmailman-252Flistinfo-252Fstir-26data-3D04-257C01-257Cdavid.holmes-2540t-2Dmobile.com-257C11d4aa0d70ec4a7cfb7408da01292bef-257Cbe0f980bdd994b19bd7bbc71a09b026c-257C0-257C0-257C637823573598265762-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C3000-26sdata-3DQx7nrpVtUpR52LwSr5fJ0HyD7RpUNOyFiXnzJwJlSqM-253D-26reserved-3D0&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=c_Kmr0d7wYbLjRgLlHhXDviBK0s0URNX8Rv57YMgUiA&m=GvnHPrfC3PsLJXplKXyXqK6mGtduWtTybUpETLN0oqjjin1oz9J9GUSgUqxIa1W5&s=Ny0S_IVz5OJQ3WTT8hBPOhB33PeNbOhnPye9sPWGB1g&e=>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_stir&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=c_Kmr0d7wYbLjRgLlHhXDviBK0s0URNX8Rv57YMgUiA&m=GvnHPrfC3PsLJXplKXyXqK6mGtduWtTybUpETLN0oqjjin1oz9J9GUSgUqxIa1W5&s=cGHwLGDrBZcVLymefoh2JE2UZ5Fv7EbQBMA1OXIhMhg&e=>
>>>>>
>>>>
>>>>
>>
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_stir&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=c_Kmr0d7wYbLjRgLlHhXDviBK0s0URNX8Rv57YMgUiA&m=GvnHPrfC3PsLJXplKXyXqK6mGtduWtTybUpETLN0oqjjin1oz9J9GUSgUqxIa1W5&s=cGHwLGDrBZcVLymefoh2JE2UZ5Fv7EbQBMA1OXIhMhg&e=
>

---

From: Mary Barnes <[email-masked]>
Date: Thu, 10 Mar 2022 13:06:51 -0600

Yes. And, that is what many refer to as "illegal" or perhaps "illegitimate"
is a better way to categorize that type of spoofing.

---

From: Chris Wendt <[email-masked]>
Date: Thu, 10 Mar 2022 16:00:33 -0500

Hi Tim,

I think you need to sort of separate the STIR concept of identity and the SHAKEN concept of a specific implementation of STIR that is in the context of policies and other things.  In SHAKEN, we assume a model that yes consumers directly can’t assert their identity.  I think that is common model, but i think STIR doesn’t assume any policy rather focuses on protocol and PKI model.

-Chris

> On Mar 10, 2022, at 2:04 PM, Dwight, Timothy M (Tim) <[email-masked]> wrote:
> 
> OK, so then 2 questions.  
> How does a consumer (or their device) "prove" they have the right to use a number?  What "evidence" do they present, and to whom?
> 
> Who grants the consumer this "right"?  What form does the grant take?  
> 
> I think they're silly questions because the answers are (1) they can't, and (2) nobody.
> 
> As I understand it, there is nothing "on the wire" that would prove such a right-to-use was valid.  Instead we "implicitly trust" the identity in the P-Asserted-Identity header.  If it's not a number the originating device is authorized to use, the originating carrier made a mistake.  STIR / SHAKEN provides a means to hold carriers responsible if they make such mistakes.
> 
> STIR / SHAKEN will not AFAIK stop a call from the furnace repairman presenting as its CPN the toll free number of Home Depot's service center.  For that to happen, Home Depot had to have worked with their carrier to provide the numbers of their technicians, and authorized their carrier to modify the PAID header in this way.  The carrier should have "signed its work" so if there's any question whether it was appropriate, we have an audit trail.
> 
> The interesting follow-on question is what RCD gets presented in such a case.  ISTM it might combine information about Home Depot (e.g., address, logo, hours) and information about the repairman (e.g., his name, what he looks like, what kind of car he drives).  If that's a desired end result, are there standards needed to make it possible?
> 
> tim
> 
> 
> On Thu, Mar 10, 2022 at 11:23 AM Chris Wendt <[email-masked] <mailto:[email-masked]>> wrote:
>> On Mar 10, 2022, at 12:21 PM, Chris Wendt <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>>>> https://www.ietf.org/archive/id/draft-barnes-stir-passport-div-hi-callflows-02.txt <https://urldefense.proofpoint.com/v2/url?u=https-3A__nam02.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.ietf.org-252Farchive-252Fid-252Fdraft-2Dbarnes-2Dstir-2Dpassport-2Ddiv-2Dhi-2Dcallflows-2D02.txt-26data-3D04-257C01-257Cdavid.holmes-2540t-2Dmobile.com-257C11d4aa0d70ec4a7cfb7408da01292bef-257Cbe0f980bdd994b19bd7bbc71a09b026c-257C0-257C0-257C637823573598265762-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C3000-26sdata-3Dwp86b64trt9hVVKjAoA6MlBkeFZu8gpOshEWty7kjis-253D-26reserved-3D0&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=c_Kmr0d7wYbLjRgLlHhXDviBK0s0URNX8Rv57YMgUiA&m=GvnHPrfC3PsLJXplKXyXqK6mGtduWtTybUpETLN0oqjjin1oz9J9GUSgUqxIa1W5&s=zhMTOg29rgCq8KsjWnXyZ_582kT7zpmyLEmycFMOWtQ&e=>
>>>>>  
>>>>> 
>>>>> https://www.ietf.org/mailman/listinfo/stir <https://urldefense.proofpoint.com/v2/url?u=https-3A__nam02.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.ietf.org-252Fmailman-252Flistinfo-252Fstir-26data-3D04-257C01-257Cdavid.holmes-2540t-2Dmobile.com-257C11d4aa0d70ec4a7cfb7408da01292bef-257Cbe0f980bdd994b19bd7bbc71a09b026c-257C0-257C0-257C637823573598265762-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C3000-26sdata-3DQx7nrpVtUpR52LwSr5fJ0HyD7RpUNOyFiXnzJwJlSqM-253D-26reserved-3D0&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=c_Kmr0d7wYbLjRgLlHhXDviBK0s0URNX8Rv57YMgUiA&m=GvnHPrfC3PsLJXplKXyXqK6mGtduWtTybUpETLN0oqjjin1oz9J9GUSgUqxIa1W5&s=Ny0S_IVz5OJQ3WTT8hBPOhB33PeNbOhnPye9sPWGB1g&e=>
>>>>> https://www.ietf.org/mailman/listinfo/stir <https://urldefense.proofpoint.com/v2/url?u=https-3A__nam02.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.ietf.org-252Fmailman-252Flistinfo-252Fstir-26data-3D04-257C01-257Cdavid.holmes-2540t-2Dmobile.com-257C11d4aa0d70ec4a7cfb7408da01292bef-257Cbe0f980bdd994b19bd7bbc71a09b026c-257C0-257C0-257C637823573598265762-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C3000-26sdata-3DQx7nrpVtUpR52LwSr5fJ0HyD7RpUNOyFiXnzJwJlSqM-253D-26reserved-3D0&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=c_Kmr0d7wYbLjRgLlHhXDviBK0s0URNX8Rv57YMgUiA&m=GvnHPrfC3PsLJXplKXyXqK6mGtduWtTybUpETLN0oqjjin1oz9J9GUSgUqxIa1W5&s=Ny0S_IVz5OJQ3WTT8hBPOhB33PeNbOhnPye9sPWGB1g&e=>
>>>>>  
>>>>> 
>>>>>  
>>>>> 
>>>>>  
>>>>> 
>>>>> https://www.ietf.org/mailman/listinfo/stir <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_stir&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=c_Kmr0d7wYbLjRgLlHhXDviBK0s0URNX8Rv57YMgUiA&m=GvnHPrfC3PsLJXplKXyXqK6mGtduWtTybUpETLN0oqjjin1oz9J9GUSgUqxIa1W5&s=cGHwLGDrBZcVLymefoh2JE2UZ5Fv7EbQBMA1OXIhMhg&e=>
>>>> 
>>> 
>> 
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_stir&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=c_Kmr0d7wYbLjRgLlHhXDviBK0s0URNX8Rv57YMgUiA&m=GvnHPrfC3PsLJXplKXyXqK6mGtduWtTybUpETLN0oqjjin1oz9J9GUSgUqxIa1W5&s=cGHwLGDrBZcVLymefoh2JE2UZ5Fv7EbQBMA1OXIhMhg&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_stir&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=c_Kmr0d7wYbLjRgLlHhXDviBK0s0URNX8Rv57YMgUiA&m=GvnHPrfC3PsLJXplKXyXqK6mGtduWtTybUpETLN0oqjjin1oz9J9GUSgUqxIa1W5&s=cGHwLGDrBZcVLymefoh2JE2UZ5Fv7EbQBMA1OXIhMhg&e=>

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Thu, 10 Mar 2022 15:22:22 -0600

Can't say as I understand that response.

Would you answer my 2 questions differently than I did?

tim

On Thu, Mar 10, 2022 at 3:00 PM Chris Wendt <[email-masked]>
wrote:

> Hi Tim,
>
> I think you need to sort of separate the STIR concept of identity and the
> SHAKEN concept of a specific implementation of STIR that is in the context
> of policies and other things.  In SHAKEN, we assume a model that yes
> consumers directly can’t assert their identity.  I think that is common
> model, but i think STIR doesn’t assume any policy rather focuses on
> protocol and PKI model.
>
> -Chris
>
>    1. How does a consumer (or their device) "prove" they have the right
>    to use a number?  What "evidence" do they present, and to whom?
>
>>>> Both Diversion Header and History-Info header have information as to
>>>> why the call was diverted.  And, History-Info includes the type of retarget
>>>>> Adding rich call data to a div PASSporT does seem to me to go above
>>>>> and beyond the original intent of the div PASSporT RFC. However, if we
>>>>> think someone might want to do this, then would it make sense to have a
>>>>> rule that the rich call data in the "rcd" claim of a div PASSporT must be
>>>>> associated with the "div" claim identity, not the "orig" claim identity.
>>>>> The logic being – the div authentication service is authoritative for the
>>>>> identity in the "div" claim, but has no relationship with the identity in
>>>>> the "orig" claim. I’m not sure if this would be a useful capability; e.g.,
>>>>> might there be a case where the diverting entity wants to provide its rich
>>>>> call data to the diverted-to user? But in any case this would avoid
>>>>> creating the situation where there is conflicting rcd info between an inner
>>>>> PASSporT and the div PASSporT(s).
>>>>>
>>>>> On Tue, Mar 8, 2022 at 1:00 PM Holmes, David <
>>>>> [email-masked]> wrote:
>>>>>
>>>>>> I guess the real question is interoperability. If people think this
>>>>>> is obvious enough that people won’t screw it up, I’m okay with it.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I think you may be overcomplicating it: there’s nothing preventing
>>>>>> you from putting 2 different valid RCD passports on the same call, so
>>>>>> you’re going to have to be able to deal with conflicting RCD information no
>>>>>> matter what. I believe the idea is that you just gather all of the RCD
>>>>>> information you consider valid (which may have come from SHAKEN, RCD, or
>>>>>> even DIV passports) and deal with it however you want to.
>>>>>>
>>>>>>
>>>>>>
>>>>>> *Cc:* Peterson, Jon <[email-masked]>; IETF STIR Mail List
>>>>>> <[email-masked]>

---

From: Chris Wendt <[email-masked]>
Date: Thu, 10 Mar 2022 16:37:21 -0500

STIR doesn’t address that, SHAKEN doesn’t even specifically address that quite yet, but we are talking about vetting/TN validation/KYC concepts that allow those types of use cases to be addressed in a way that is compatible with policies.

-Chris

> On Mar 10, 2022, at 4:22 PM, Dwight, Timothy M (Tim) <[email-masked]> wrote:
> 
> On Thu, Mar 10, 2022 at 3:00 PM Chris Wendt <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Tim,
> 
>> On Mar 10, 2022, at 2:04 PM, Dwight, Timothy M (Tim) <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> OK, so then 2 questions.

---

From: Chris Wendt <[email-masked]>
Date: Thu, 10 Mar 2022 16:48:13 -0500

I do recognize i am speaking a bit abstractly, but that is how we built the specs and how they relate.  STIR is the core protocols and PKI definition, SHAKEN is the set of specifications based on STIR, but with North American or maybe more generally telephone service provider deployment model in mind, where the SP represents the user with a telephone number vs. a private SIP deployment that might use STIR that may have a different deployment model.  So, we very intentionally do not want to build the base specs to address any telephone number usage policies or anything specific to a deployment.  Hopefully that explains things a bit better.

So for a consumer to “prove” they have right to use a number, in North America and probably most place, you and I know that can’t happen in order to general STIR certificate base credentials to prove that.  The service provider can perhaps do that on a users behalf based on having the proper customer relationship, etc.  vetting/KYC whatever you want.  But in STIR specs, we don’t address any of this, very much intentionally.

-Chris

> On Mar 10, 2022, at 4:37 PM, Chris Wendt <[email-masked]> wrote:
> 
>> On Mar 10, 2022, at 4:22 PM, Dwight, Timothy M (Tim) <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Chris Wendt <[email-masked]>
Date: Thu, 10 Mar 2022 17:03:14 -0500

Ok, last one for this thread, just to go back to the original point.  I know the traditional definition of “spoofing” is to change the CLI for different applications reasons whether legit or illegal, today, for legitimate applications, it’s mostly done without a lot of checks and balances depending on the provider, some have more, some have less, some have very little at all.

Tomorrow, with STIR/SHAKEN, we would like the policy that in order to set the CLI for calls to something that may not be the CLI the customer purchased with a line of service, for example, you need to either as OSP and “shaken” attestation be able to prove “right-to-use” directly or indirectly using delegate cert or other proposed mechanisms.  And my meta point was that in that sense, there should no longer be any “spoofing” but rather the number that the customer has the right-to-use is authenticated from the start of each call because the checks/balances or vetting was done properly to associate that alternative number with the customers right to use that number.

Hope that explanation is clearer.  Whether everyone agrees, let’s see, but i think that is our long term goal of all of this work, that the traditional practice of “spoofing” evolves to what i described above or something similar.

-Chris

> On Mar 10, 2022, at 4:48 PM, Chris Wendt <[email-masked]> wrote:
> 
>> On Mar 10, 2022, at 4:37 PM, Chris Wendt <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Thu, 10 Mar 2022 16:20:02 -0600

Yeah I get it.  Tools not services... IETF philosophy...

My question was motivated by the statement below in this thread, "what we
want to remove is the act of using an identity you haven’t proven you have
the right-to-use".  I wanted to understand if that's even possible.  I
think you have confirmed my understanding, that it is not.  At least, not
in the context of public telephone networks.

I also offered my understanding of what I believe we are trying to
achieve.  Namely, to hold your service provider accountable if it
indicates, on your behalf, an identity you are not authorized to use.

I suppose in another context we might let you assert your identity, sign it
yourself, and carry that end to end.  In that case we could hold YOU
responsible for the asserted identity.  There are some logistical
challenges with that but I think it could be made to work.  Maybe people
are working on that too, but I'm not.

I suppose I'm guilty of making this all about me (or at least, about the
context in which I am implementing S/S) :-)

tim

On Thu, Mar 10, 2022 at 3:48 PM Chris Wendt <[email-masked]>
wrote:

> I do recognize i am speaking a bit abstractly, but that is how we built
> the specs and how they relate.  STIR is the core protocols and PKI
> definition, SHAKEN is the set of specifications based on STIR, but with
> North American or maybe more generally telephone service provider
> deployment model in mind, where the SP represents the user with a telephone
> number vs. a private SIP deployment that might use STIR that may have a
> different deployment model.  So, we very intentionally do not want to build
> the base specs to address any telephone number usage policies or anything
> specific to a deployment.  Hopefully that explains things a bit better.
>
> So for a consumer to “prove” they have right to use a number, in North
> America and probably most place, you and I know that can’t happen in order
> to general STIR certificate base credentials to prove that.  The service
> provider can perhaps do that on a users behalf based on having the proper
> customer relationship, etc.  vetting/KYC whatever you want.  But in STIR
> specs, we don’t address any of this, very much intentionally.
>
> -Chris
>
> STIR doesn’t address that, SHAKEN doesn’t even specifically address that
> quite yet, but we are talking about vetting/TN validation/KYC concepts that
> allow those types of use cases to be addressed in a way that is compatible
> with policies.
>
> -Chris
>
>> As I understand it, there is nothing "on the wire" that would prove such
>> a right-to-use was valid.  Instead we "implicitly trust" the identity in
>> the P-Asserted-Identity header.  If it's not a number the originating
>> device is authorized to use, the originating carrier made a mistake.  STIR
>> / SHAKEN provides a means to hold carriers responsible if they make such
>> mistakes.
>>
>>>> Wouldn’t you essentially treat that as a new call with new caller-id
>>>> and start from scratch anyway?  I’m a bit afraid of any of this scenario
>>>>>>> [email-masked]>; Jack Rickard <
>>>>>>> [email-masked]>; IETF STIR Mail List <[email-masked]>
>>>>>>> I don’t think there’s any real distinction between RCD information
>>>>>>> in RCD passports vs in any other type of passport.
>>>>>>>
>>>>>>>
>>>>>>> Jack
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *Cc:* Peterson, Jon <[email-masked]>; IETF STIR Mail
>>>>>>> List <[email-masked]>
>>>>>>> - Can we also assume that no one would ever add _new_ RCD claims to
>>>>>>> a “div” passport? That seems to make sense, but is it documented somewhere?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Ben.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I would agree with that in general.  IMHO, we really need a call
>>>>>>> flow document to show examples of all of this.  I worked on one a long
>>>>>>> while back  (no RCD - it was focused on DIV) and no one was interested in
>>>>>>> progressing.
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Mar 7, 2022 at 2:32 PM Chris Wendt <
>>>>>>> [email-masked]> wrote:
>>>>>>>
>>>>>>> Hi Ben,
>>>>>>>

---

From: Chris Wendt <[email-masked]>
Date: Thu, 10 Mar 2022 21:47:46 -0500

Hi Tim,

I think i shouldn’t have used the word “you”, rather “authorized signer” and “customer" or something like that.  It’s a good thing to clarify because i don’t think everyone fully appreciates the different scopes of the specifications and standards bodies roles, so i don’t mind the conversation.

Thanks!

-Chris

> On Mar 10, 2022, at 5:20 PM, Dwight, Timothy M (Tim) <[email-masked]> wrote:
> 
> My question was motivated by the statement below in this thread, "what we want to remove is the act of using an identity you haven’t proven you have the right-to-use".  I wanted to understand if that's even possible.  I think you have confirmed my understanding, that it is not.  At least, not in the context of public telephone networks.
> 
> I also offered my understanding of what I believe we are trying to achieve.  Namely, to hold your service provider accountable if it indicates, on your behalf, an identity you are not authorized to use.
> 
> I suppose in another context we might let you assert your identity, sign it yourself, and carry that end to end.  In that case we could hold YOU responsible for the asserted identity.  There are some logistical challenges with that but I think it could be made to work.  Maybe people are working on that too, but I'm not. 
> 
> I suppose I'm guilty of making this all about me (or at least, about the context in which I am implementing S/S) :-)
> 
> tim
> 
> On Thu, Mar 10, 2022 at 3:48 PM Chris Wendt <[email-masked] <mailto:[email-masked]>> wrote: