1. Verstat Related Best Practices
Mark Desterdick
Verizon
IP-NNI Task Force May 2, 2018

2. Topics Format Granularity Legitimate Privacy
P-Asserted-ID for SIP and tel URIs
Various SIP methods
Granularity
Terminating Attestation Level Identification to terminating UA or CVT
Legitimate Privacy
CLIP/CLIR
This document offers several proposals for consideration in the IPNNI and other standards bodies to be included in future standards or best practices documents, as appropriate.

3. P-Asserted-ID: SIP URI
Format in P-Asserted_Identity (PAI) using a SIP URI - placement of verstat before sign
 This is derived from the syntax for verstat in the P-asserted-id in Tel-URI format as defined in 3GPP TS section 7.2A.20.
Reasoning:
tel: ;postd=pp22;verstat=TN-Validation-Passed
verstat is a TEL URI parameter
Parameters are associated with a TEL URI per the syntax specified in RFC-3966
Parameters are associated with a SIP or SIPS URI per the syntax specified in RFC-3261
TEL URIs are mapped to SIP URIs as specified in RFC-3261
Format: P-Asserted-ID: SIP URI
Based on the following analysis, the format shown below for verstat in P-Asserted_Identity (PAI) using a SIP URI is correct with the placement of verstat before sign:
The above is derived from the syntax for verstat in the P-asserted-id in Tel-URI format as defined in 3GPP TS section 7.2A.20, and using the below reasoning and references.
tel: ;postd=pp22;verstat=TN-Validation-Passed
Assertion:  verstat is a TEL URI parameter
Explanation: “verstat” is described as a TEL URI in 3GPP TS section 7.2A.20.  It is registered as such with IANA.  It is NOT registered as a SIP or SIPS URI parameter.  indicates that verstat may be used in the From and P-Asserted-Identity headers containing “a tel URI or a SIP URI with the user=phone parameter”.
References:
Parameters are associated with a TEL URI per the syntax specified in RFC-3966
Explanation: the format is basically  tel: <digits> [; <parameter> = <value>]*
Reference:
Parameters are associated with a SIP or SIPS URI per the syntax specified in RFC-3261
Explanation:  the format is basically As noted in point 1 above, however, “verstat” is not registered as a SIP or SIPS URI parameter.  Therefore this syntax cannot be used to incorporate a “verstat” parameter into a SIP or SIPS URI. 
Reference:
TEL URIs are mapped to SIP URIs as specified in RFC-3261
Explanation:  the mapping logic is in section , which indicates that “When a tel URL (RFC 2806 [9]) is converted to a SIP or SIPS URI, the entire telephone-subscriber portion of the tel URL, including any parameters, is placed into the userinfo part of the SIP or SIPS URI.”.  This syntax can be used to incorporate a “verstat” parameter into a SIP or SIPS URI.
Reference:

4. Verstat in Various SIP Methods
Proposed verstat syntax in various SIP methods
INVITE
P-Asserted-Identity OR From: tel: ;verstat=TN-Validation-Passed
P-Asserted-Identity OR From:
SUBSCRIBE
Message Body
Calling-party: tel: ;verstat=TN-Validation-Passed
Calling-party:
NOTIFY
Calling-Name: "BUSINESS005"  tel: ;verstat=TN-Validation-Passed OR
Calling-party: "BUSINESS005" user=phone
MESSAGE
Format: Verstat in Various SIP Methods
A summary of the proposed verstat syntax in various SIP methods is listed below:
INVITE
P-Asserted-Identity OR From: tel: ;verstat=TN-Validation-Passed
P-Asserted-Identity OR From:
SUBSCRIBE
Message Body
Calling-party: tel: ;verstat=TN-Validation-Passed
Calling-party:
NOTIFY
Calling-Name: "BUSINESS005"  tel: ;verstat=TN-Validation-Passed OR
Calling-party: "BUSINESS005" user=phone
MESSAGE

5. Granularity
Terminating Attestation Level Identification to terminating UA or CVT
Current Values
Verstat value
STI-VS Description
TN-Validation-Passed
The number passed the validation
TN-Validation-Failed
The number failed the validation
No-TN-Validation
No number validation was performed
Tagging and Validation Results Sent to UA or CVT Must Reflect the Attestation Indicator
While multiple levels of attestation have been introduced for signing within the STIR/SHAKEN framework, the verstat values resulting from the signature validation or those used in tagging currently have no indication what attestation level was used. 
The lack of attestation in what is presented to the UA or CVT within the currently defined verstat values poses a risk to the implementation of STIR/SHAKEN due to unintended consequences of introducing multiple attestation levels with signing, but not reflecting them in validation results.
To illustrate, consider a case when the attestation indicator is either B or C for a signed call, and a verstat value of TN-Validation-Passed (as a result of a cryptographically sound signature) is sent by the STI-VS to the invoking network device. The network device then passes this verstat value on to a terminating UA, which interprets the results as the originating number having been authenticated when in fact the signature was only using attestation B or C.  This introduces a gap and undermines the premise of trusting the originating number when in it could have been spoofed, but arriving over some IP interface where attestation B was applied, or a gateway where an attestation C for was applied. 
Service providers, CVTs and over the top applications have a need to differentiate the validation based on attestation so that appropriate information is relayed to an end user device or analytics platform based on policy. For example, an attestation B or C may not add appreciable value to an end user display regarding the authenticity of a calling number, but may add value to intermediary service providers or analytics engines during traceback investigations, statistical and reputational analysis or troubleshooting.
The following illustrate a few other use cases:
An application or service provider may choose to ONLY present validation results to an end user if the attestation was A. 
A service provider may choose to only use validations of attestation B and C for traceback, behavioral analytics and non-repudiation.
Different messages or displays may be presented terminating to end users based on the combination of the validation status and the attestation level.

6. Granularity Possible Syntax Augmenting current verstat values
with a “-A”, “-B” or “-the C” at the end
Verstat value
STI-VS Description
TN-Validation-Passed
The number passed the validation (kept to maintain backwards compatibility with early implementations which are expected to sign with Attestation A)
TN-Validation-Passed-A
The number passed the validation with Attestation A
TN-Validation-Passed-B
The number passed the validation with Attestation B
TN-Validation-Passed-C
The number passed the validation with Attestation C
TN-Validation-Failed
The number failed the validation (kept to maintain backwards compatibility with early implementations which are expected to sign with Attestation A)
TN-Validation-Failed-A
The number failed the validation for Attestation A
TN-Validation-Failed-B
The number failed the validation for Attestation B
TN-Validation-Failed-C
The number failed the validation for Attestation C
No-TN-Validation
No number validation was performed
Possible Syntax for Augmented verstat Values
The following is one proposed syntax which has found some acceptance among a few service providers:
Augmenting the current verstat values with a “-A”, “-B” or “-C” at the end
Other possible syntax formats:
Current values of verstat are retained and P-Attestation-Indicator Header is included in the response from the STI-VS or in the tag toward the terminating node
Changing the current verstat values to “Validation-Y-Passed”, “Validation-Y-Failed” and “No-Y-Validation” where Y is the attestation level A, B or C
Defining new verstat values for attestation B and C such as:
Attestation B: IP-Validation-Passed, IP-Validation-Failed, No-IP-Validation
Attestation C: GW-Validation-Passed, GW-Validation-Failed, No-GW-Validation
In the case of tagging, the SP should retain the appropriate attestation level in the verstat value upon delivery to terminating UEs, applications or CVTs.
Display Framework and OEM Considerations
Display framework recommendations will need to be updated to include attestation levels, and OEM procedures will need to address actions for the cases of failed validation.

7. Verstat for Anonymous CLIP/CLIR
verstat should be signaled to the end user even in cases where Privacy is requested
For Caller initiated Privacy, common practice has the originating network/device signaling “Anonymous” in the From header.  The P-Asserted-Identity (PAI) would carry the actual Calling Party number.
The originating network would perform SHAKEN Authentication over the PAI, sending the Identity header to the terminating network along with the PAI (with callers TN), From (anonymous) and Privacy headers
The terminating network performs verification (using the TN received in the PAI), and populates verstat into the PAI
Because of the Privacy indication, the terminating network removes the PAI header prior to sending the call to the UE:
Example
FROM:
The following are proposed “Best Practices” with regards to sending verstat to the End User in cases of Private/Anonymous calls:
For Caller initiated Privacy, common practice has the originating network/device signaling “Anonymous” in the From header.  The P-Asserted-Identity (PAI) would carry the actual Calling Party number.
The originating network would perform SHAKEN Authentication over the PAI, sending the Identity header to the terminating network along with the PAI (with callers TN), From (anonymous) and Privacy headers
The terminating network performs verification (using the TN received in the PAI), and populates verstat into the PAI
Because of the Privacy indication, the terminating network removes the PAI header prior to sending the call to the UE:
If the From header indicates “Anonymous”, the From header should be populated with the verstat received in the PAI
If the received From header does not indicate “Anonymous”, but the terminating network anonymizes the From header, the From header should be populated with the verstat received in the PAI
If the received From header does not indicate “Anonymous” and the terminating network does not anonymize the From header, the From header should not be populated with the verstat received in the PAI (note: would not expect this case to happen because the originating and/or terminating network(s) must anonymize)
Example: FROM:

8. Next Steps Agree on Best Practices with limited focused scopes
Priority and timeline for Best Practices