Personal Assertion Token (PaSSporT) Extension for Signature-based Handling of Asserted information using toKENs (SHAKEN)
RFC 8588

Note: This ballot was opened for revision 05 and is now closed.

(Ben Campbell) Yes

Comment (2018-11-20 for -05)
I am balloting "Yes" because I want to see the anti-robocalling framework get deployed sooner than later. But I share some of the privacy concerns that have been raised by others. I will follow that conversation on the thread resulting from Ekr's DISCUSS.

Some additional comments:

*** Substantive Comments ***

§3: "The second claim is a unique origination identifier that should be
used by the service provider..."
Was that "should" meant as a "SHOULD"?

- Some of the terminology in the definitions of the attestation types seems vague to me.  Does "authenticated relationship with the initiator" mean the same as "has authenticated the originator of the call"? Does "established a verified association with the calling party telephone number" mean the same as "verified that the calling party has the right to use the calling identity"? (The ATIS doc has more detailed explanations, which makes me wonder if it wouldn't have been better to just reference those definitions.)

- The type "C" description includes "Has no relationship with the initiator of the call (e.g.,
international gateways)" in the list of MUST conditions. Is it the intent that an operator can only use a Type C attestation if it does not have that relationship? That is, an operator that did have a relationship with the initiator of the call is not allowed to use a type C attestation to avoid disclosure of the relationship? (How would one test that?)

- As Alissa mentioned, the fact that similar information that might be gleaned from originid is carried in SIP is not very convincing. It's historically been common for operators to use SBCs to hide things like Record-Route and Via. (and I presume History-Info).

- Is originid required? Could an operator who had privacy concerns simply choose not to include it? (Maybe that operator has sufficient internal records to hunt down bad actors.)

- The ATIS doc talks about using the originid in type B attestations to track "reputation". I assume this sort of tracking could be done by parties other than the attesting operator? If so, I think that's worth some discussion.

*** Editorial Comments ***

- Abstract: Please expand SHAKEN in the abstract.

§1: Please expand VoIP, TDM, and SS7

(Spencer Dawkins) Yes

Comment (2018-11-20 for -05)
I echo Ben's "Yes assuming the Discusses can be resolved". It's about time we provided this capability!

I did have a couple of comments you might want to consider, along with anything else that pops up during IESG Evaluation.

"SHAKEN" isn't spelled out in either the title or Abstract - that would probably help almost all the readers of this document ...

I did find it odd that 

  This indicator allows for both identifying the service provider that
   is vouching for the call as well as clearly indicating what
   information the service provider is attesting to.  The 'attest' claim
   can be one of the following three values: 'A', 'B', or 'C' as defined
   in [ATIS-1000074].

used "A", "B", and "C", instead of something like "F"(ull), "P"(artial), and "G"(ateway), because if you discover a need for a fourth value, it's not clear whether anyone would be assuming "A" < "B" < "C" ordering in their code, that would break if the fourth value was naturally between "A" and "B".  If you're sure no one but Spencer would be so dumb, that's a fine response ...

(Adam Roach) Yes

(Ignas Bagdonas) No Objection

Deborah Brungard No Objection

Alissa Cooper No Objection

Comment (2018-11-20 for -05)
I support Eric's DISCUSS. In addition to points made by Benjamin in that thread, I think if this document is going to say that threats introduced by origids "already existed in SIP," it also needs to talk about expectations for usage of origids in cases were existing SIP features to support anonymous calling are in use. Presumably callers who enable such features may also not expect their calling patterns to be linkable.

Benjamin Kaduk (was Discuss) No Objection

Comment (2019-02-02 for -07)
No email
send info
Thank you for resolving the copyright issues.

[Original ballot COMMENT section preserved below]

I am interested in seeing the resolution of discussion on Ekr's Discuss, but
will stick to that thread for such discussion.

Section 4

Am I reading this properly that the difference between 'A' and 'B' is that
in 'B' we don't have any information about the device that's originating
the call, just the identity of the user/customer?

(Suresh Krishnan) No Objection

Warren Kumari No Objection

(Mirja Kühlewind) No Objection

(Terry Manderson) No Objection

(Alexey Melnikov) No Objection

(Eric Rescorla) (was Discuss) No Objection

Comment (2019-03-09 for -07)
Jon and I talked offline and came up with some text that I believe is mutually acceptable. In the interest of moving this forward, I am clearing my DISCUSS and trusting the AD to follow through with the new version.

Alvaro Retana No Objection

Martin Vigoureux No Objection