idnits 2.17.1 draft-ietf-stir-passport-rcd-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 11, 2019) is 1863 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCThis' is mentioned on line 581, but not defined == Outdated reference: A later version (-07) exists of draft-ietf-stir-oob-04 ** Downref: Normative reference to an Informational draft: draft-ietf-stir-oob (ref. 'I-D.ietf-stir-oob') ** Downref: Normative reference to an Experimental RFC: RFC 6919 ** Downref: Normative reference to an Informational RFC: RFC 7340 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Peterson 3 Internet-Draft Neustar Inc. 4 Intended status: Standards Track C. Wendt 5 Expires: September 12, 2019 Comcast 6 March 11, 2019 8 PASSporT Extension for Rich Call Data 9 draft-ietf-stir-passport-rcd-03 11 Abstract 13 This document extends PASSporT, a token for conveying 14 cryptographically-signed information about personal communications, 15 to include rich data that can be rendered to users, such as a human- 16 readable display name comparable to the "Caller ID" function common 17 on the telephone network. The element defined for this purpose is 18 extensible to include related information about calls that helps 19 people decide whether to pick up the phone. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 12, 2019. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. PASSporT "rcd" Claim . . . . . . . . . . . . . . . . . . . . 3 58 3.1. "nam" key . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3.2. "jcd" key . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.3. "jcl" key . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.4. "rcd" Usage . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.5. Example "rcd" PASSporTs . . . . . . . . . . . . . . . . . 5 63 4. Further Information Associated with Callers . . . . . . . . . 6 64 5. Third-Party Uses . . . . . . . . . . . . . . . . . . . . . . 7 65 5.1. Signing as a Third Party . . . . . . . . . . . . . . . . 8 66 6. Levels of Assurance . . . . . . . . . . . . . . . . . . . . . 9 67 7. Using "rcd" in SIP . . . . . . . . . . . . . . . . . . . . . 9 68 7.1. Authentication Service Behavior . . . . . . . . . . . . . 9 69 7.2. Verification Service Behavior . . . . . . . . . . . . . . 10 70 8. Using "rcd" as additional claims to other PASSporT extensions 11 71 8.1. Procedures for applying "rcd" as claims only . . . . . . 11 72 8.2. Example for applying "rcd" as claims only . . . . . . . . 11 73 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 74 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 75 10.1. JSON Web Token Claim . . . . . . . . . . . . . . . . . . 12 76 10.2. PASSporT Types . . . . . . . . . . . . . . . . . . . . . 13 77 10.3. PASSporT RCD Types . . . . . . . . . . . . . . . . . . . 13 78 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 79 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 81 12.2. Informative References . . . . . . . . . . . . . . . . . 14 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 84 1. Introduction 86 PASSporT [RFC8225] is a token format based on JWT [RFC7519] for 87 conveying cryptographically-signed information about the people 88 involved in personal communications; it is used to convey a signed 89 assertion of the identity of the participants in real-time 90 communications established via a protocol like SIP [RFC8224]. The 91 STIR problem statement [RFC7340] declared securing the display name 92 of callers outside of STIR's initial scope, so baseline STIR provides 93 no features for caller name. This specification documents an 94 optional mechanism for PASSporT and the associated STIR mechanisms 95 which extends PASSporT to carry additional elements conveying richer 96 information: information that is intended to be rendered to an end 97 user to assist a called party in determining whether to accept or 98 trust incoming communications. This includes the name of the person 99 on one side of a communications session, the traditional "Caller ID" 100 of the telephone network, along with related display information that 101 would be rendered to the called party during alerting, or potentially 102 used by an automaton to determine whether and how to alert a called 103 party. 105 In the traditional telephone network, the display name associated 106 with a call is typically provided in one of three ways: by a third- 107 party service queried at the terminating side, by the originator of 108 the call, or through a local address book maintained by a device on 109 the terminating side. The STIR architecture lends itself especially 110 to the first of these approaches, as it assumes that an authority on 111 the originating side of the call provides a cryptographic assurance 112 of the validity of the calling party number in order to prevent 113 impersonation attacks. That same authority could sign for a display 114 name associated with that number, which the terminating side could 115 render to the user when the call is alerting. Even when the 116 originating side does not provide a display name for the caller, the 117 cryptographic attestation of the validity of the calling number 118 provided by STIR still allows the terminating side to query a local 119 or remote service for a name associated with that number without fear 120 that the number has been impersonated by the caller; STIR thus makes 121 "Caller ID" more secure even when there is no first-party attestation 122 of a display name. For these cases, this specification outlines 123 various ways that a display name for a calling party could be 124 determined at the terminating side in a secure fashion. 126 2. Terminology 128 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 129 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 130 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 131 described in [RFC2119] and [RFC6919]. 133 3. PASSporT "rcd" Claim 135 This specification defines a new JSON Web Token claim for "rcd", Rich 136 Call Data, the value of which is a JSON object that can contain one 137 or more key value pairs. This document defines a default set of 138 three key values one being mandatory, the others are optional. 140 3.1. "nam" key 142 The "nam" key value is a display name, associated with the originator 143 of personal communications, which may for example derive from the 144 display-name component of the From header field value of a SIP 145 request, or a similar field in other PASSporT using protocols. This 146 key MUST be included once and MUST be included as as part of the 147 "rcd" claim value JSON object. If there is no string associated with 148 a display name, the claim value SHOULD then be an empty string. 150 3.2. "jcd" key 152 The "jcd" key value is defined to contain a value of a jCard 153 [RFC7095] JSON object. This jCard object is intended to be an 154 extensible object that the calling party of personal communications 155 can provide both the types of information defined in jCard or can use 156 the built in extensibility of the jCard specification to add 157 additional information. The "jcd" is optional. If included, this 158 key MUST only be included once in the "rcd" JSON object and SHOULD 159 NOT be included if there is a "jcl" key included. The "jcd" and 160 "jcl" keys should be mutually exclusive. 162 3.3. "jcl" key 164 The "jcl" key value is defined to contain a HTTPS URL that refers the 165 recipient to a jCard [RFC7095] JSON object hosted on a HTTPS enabled 166 web server. This link is intended to be an external reference to a 167 JSON file with the same intended use of the "jcd" jCard object and 168 has the same intended properties. The "jcl" key is optional. If 169 included, this key MUST only be included once in the "rcd" JSON 170 object and SHOULD NOT be included if there is a "jcd" key included. 171 The "jcd" and "jcl" keys should be mutually exclusive. 173 3.4. "rcd" Usage 175 The "rcd" claim may appear in any PASSporT claims object as an 176 optional element. The creator of a PASSporT MAY however add a "ppt" 177 value of "rcd" to the header of a PASSporT as well, in which case the 178 PASSporT claims MUST contain a "rcd" claim, and any entities 179 verifying the PASSporT object will be required to understand the 180 "ppt" extension in order to process the PASSporT in question. A 181 PASSporT header with the "ppt" included will look as follows: 183 { "typ":"passport", 184 "ppt":"rcd", 185 "alg":"ES256", 186 "x5u":"https://www.example.com/cert.cer" } 188 The PASSporT claims object will then contain the "rcd" key with its 189 corresponding value. The value of "rcd" is an array of JSON objects, 190 of which one, the "nam" object, is mandatory. The key syntax of 191 "nam" follows the display-name ABNF given in [RFC3261]. 193 After the header and claims PASSporT objects have been constructed, 194 their signature is generated normally per the guidance in [RFC8225]. 196 3.5. Example "rcd" PASSporTs 198 An example of a "nam" only PASSporT claims obejct is shown next (with 199 line breaks for readability only). 201 { "orig":{"tn":"12025551000"}, 202 "dest":{"tn":"12025551001"}, 203 "iat":1443208345, 204 "rcd":{"nam":"James Bond"} } 206 An example of a PASSporT claims object that includes the "jcd" which 207 is optional, but will also include the mandatory "nam" object is 208 shown next (with line breaks for readability only). 210 { "orig":{"tn":"12025551000"}, 211 "dest":{"tn":"12155551001"}, 212 "iat":1443208345, 213 "rcd":{"nam":"James Bond","jcd":["vcard",[["version",{},"text","4.0"], 214 ["fn",{},"text", "James Bond"], 215 ["n",{},"text",["Bond","James","","","Mr."]], 216 ["adr",{"type":"work"},"text", 217 ["","","3100 Massachusetts Avenue NW","Washington","DC","20008","USA"] 218 ], 219 ["email",{},"text","007@mi6-hq.com"], 220 ["tel",{"type":["voice","text","cell"],"pref":"1"},"uri", 221 "tel:+1-202-555-1000"], 222 ["tel",{"type":["fax"]},"uri","tel:+1-202-555-1001"], 223 ["bday",{},"date","19241116"], 224 ["logo",{},"uri", 225 "https://upload.wikimedia.org/wikipedia/en/c/c5/Fleming007impression.jpg" 226 ]]]}} 228 In an example PASSporT where a jCard is linked via HTTPS URL and 229 "jcl" a jCard file served at a particular URL will be created. 231 An example jCard JSON file is shown as follows: 233 ["vcard", 234 [ 235 ["version", {}, "text", "4.0"], 236 ["fn", {}, "text", "James Bond"], 237 ["n", {}, "text", ["Bond", "James", "", "", "Mr."]], 238 ["adr", {"type":"work"}, "text", 239 ["", "", "3100 Massachusetts Avenue NW", "Washington", "DC", "20008", 240 "USA"] 241 ], 242 ["email", {}, "text", "007@mi6-hq.com"], 243 ["tel", { "type": ["voice", "text", "cell"], "pref": "1" }, "uri", 244 "tel:+1-202-555-1000"], 245 ["tel", { "type": ["fax"] }, "uri", "tel:+1-202-555-1001"], 246 ["bday", {}, "date", "19241116"] 247 ["logo", {}, "uri", 248 "https://upload.wikimedia.org/wikipedia/en/c/c5/Fleming007impression.jpg"] 249 ] 250 ] 252 If that jCard is hosted at the example address of 253 "https://example.org/james_bond.json", the corresponding PASSporT 254 claims object would be as follows (with line breaks for readability 255 only): 257 { "orig":{"tn":"12025551000"}, 258 "dest":{"tn":"12155551001"}, 259 "iat":1443208345, 260 "rcd":{"nam":"James Bond","jcl":"https://example.org/james_bond.json"} 261 } 263 4. Further Information Associated with Callers 265 Beyond naming information and the information that can be contained 266 in a jCard [RFC7095] object, there may be additional human-readable 267 information about the calling party that should be rendered to the 268 end user in order to help the called party decide whether or not to 269 pick up the phone. This is not limited to information about the 270 caller, but includes information about the call itself, which may 271 derive from analytics that determine based on call patterns or 272 similar data if the call is likely to be one the called party wants 273 to receive. Such data could include: 275 o information related to the location of the caller, or 277 o any organizations or institutions that the caller is associated 278 with, or even categories of institutions (is this a government 279 agency, or a bank, or what have you), or 281 o hyperlinks to images, such as logos or pictures of faces, or to 282 similar external profile information, or 284 o information that will be processed by an application before 285 rendering it to a user, like social networking data that shows 286 that an unknown caller is a friend-of-a-friend, or reputation 287 scores derived from crowdsourcing, or confidence scores based on 288 broader analytics about the caller and callee. 290 All of these data elements would benefit from the secure attestations 291 provided by the STIR and PASSporT frameworks. A new IANA registry 292 has been defined to hold potential values of the "rcd" array; see 293 Section 10.3. Specific extensions to the "rcd" PASSporT claim are 294 left for future specification. 296 While in the traditional telephone network, the business relationship 297 between calling customers and their telephone service providers is 298 the ultimate root of information about a calling party's name, some 299 other forms of data like crowdsourced reputation scores might derive 300 from third parties. It is more likely that when those elements are 301 present, they will be in a third-party "rcd" PASSporT. 303 5. Third-Party Uses 305 While rich data about the call can be provided by an originating 306 authentication service, the terminating side or an intermediary in 307 the call path could also acquire rich call data by querying a third- 308 party service. In telephone operations today, a third-party 309 information service is commonly queried with the calling party's 310 number in order to learn the name of the calling party, and 311 potentially other helpful information could also be passed over that 312 interface. The value of using a PASSporT to convey this information 313 from third parties lies largely in the preservation of the original 314 authority's signature over the data, and the potential for the 315 PASSporT to be conveyed from intermediaries to endpoint devices. 316 Effectively, these use cases form a sub-case of out-of-band 317 [I-D.ietf-stir-oob] use cases. The manner in which third-party 318 services are discovered is outside the scope of this document. 320 An intermediary use case might look as follows: a SIP INVITE carries 321 a display name in its From header field value and an initial PASSporT 322 object without the "rcd" claim. When the a terminating verification 323 service implemented at a SIP proxy server receives this request, and 324 determines that the signature is valid, it might query a third-party 325 service that maps telephone numbers to calling party names. Upon 326 receiving the PASSport in a response from that third-party service, 327 the terminating side could add a new Identity header field to the 328 request for the "rcd" PASSporT object provided by the third-party 329 service. It would then forward the INVITE to the terminating user 330 agent. If the display name in the "rcd" PASSporT object matches the 331 display name in the INVITE, then the name would presumably be 332 rendered to the end user by the terminating user agent. 334 A very similar flow could be followed by an intermediary closer to 335 the origination of the call. Presumably such a service could be 336 implemented at an originating network in order to decouple the 337 systems that sign for calling party numbers from the systems that 338 provide rich data about calls. 340 In an alternative use case, the terminating user agent might query a 341 third-party service. In this case, no new Identity header field 342 would be generated, though the terminating user agent might receive a 343 PASSporT object in return from the third-party service, and use the 344 "rcd" field in the object as a calling name to render to users while 345 alerting. 347 5.1. Signing as a Third Party 349 When a third party issues a PASSporT with an "rcd" claim, the 350 PASSporT MUST contain the "rcd" "ppt" type in its header object. It 351 moreover MUST include an "iss" claim as defined in [RFC7519] to 352 indicate the source of this PASSporT; that field SHOULD be populated 353 with the subject of the credential used to sign the PASSporT. 355 A PASSporT with a "ppt" of "rcd" MAY be signed with credentials that 356 do not have authority over the identity that appears in the "orig" 357 element of the PASSporT claims. Relying parties in STIR have always 358 been left to make their own authorization decisions about whether or 359 not the trust the signers of PASSporTs, and in the third-party case, 360 where an entity has explicitly queried a service to acquire the 361 PASSporT object, it may be some external trust or business 362 relationship that induces the relying party to trust a PASSporT. 364 An example of a Third Party issued PASSporT claims object is as 365 follows. 367 { "orig":{"tn":"12025551000"}, 368 "dest":{"tn":"12025551001"}, 369 "iat":1443208345, 370 "iss":"Example, Inc.", 371 "rcd":{"nam":"James Bond"} } 373 6. Levels of Assurance 375 As "rcd" can be provided by either first or third parties, relying 376 parties could benefit from an additional claim that indicates the 377 relationship of the attesting party to the caller. Even in first 378 party cases, this admits of some complexity: the Communications 379 Service Provider (CSP) to which a number was assigned might in turn 380 delegate the number to a reseller, who would then sell the number to 381 an enterprise, in which case the CSP might have little insight into 382 the caller's name. In third party cases, a caller's name could 383 derive from any number of data sources, on a spectrum between public 384 data scraped from web searches to a direct business relationship to 385 the caller. As multiple PASSporTs can be associated with the same 386 call, potentially a verification service could receive attestations 387 of the caller name from multiple sources, which have different levels 388 of granularity or accuracy. 390 Therefore PASSporTs that carry "rcd" data SHOULD also carry an 391 indication of the relationship of the generator of the PASSporT to 392 the caller. [TBD claim - take from SHAKEN?] 394 7. Using "rcd" in SIP 396 This section specifies SIP-specific usage for the "rcd" claim in 397 PASSporT, and in the SIP Identity header field value. Other using 398 protocols of PASSporT may define their own usages for the "rcd" 399 claim. 401 7.1. Authentication Service Behavior 403 An authentication service creating a PASSporT containing a "rcd" 404 claim MAY include a "ppt" for "rcd" or not. Third-party 405 authentication services following the behavior in Section 5.1 MUST 406 include a "ppt" of "rcd". If "ppt" does contain a "rcd", then any 407 SIP authentication services MUST add a "ppt" parameter to the 408 Identity header containing that PASSporT with a value of "rcd". The 409 resulting Identity header might look as follows: 411 Identity: "sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9dlxkWzo 412 eU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgtw0Lu5csIp 413 pPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs="; \ 414 info=;alg=ES256;ppt="rcd" 416 This specification assumes that by default, a SIP authentication 417 service will derive the value of "rcd", specifically only for the 418 "nam" key value, from the display-name component of the From header 419 field value of the request, alternatively for some calls this may 420 come from the P-Asserted-ID header. It is however a matter of 421 authentication service policy to decide how it populates the value of 422 "rcd" and "nam" key, which MAY also derive from other fields in the 423 request, from customer profile data, or from access to external 424 services. If the authentication service generates a PASSporT object 425 containing "rcd" with a value that is not equivalent to the From 426 header field display-name value, it MUST use the full form of the 427 PASSporT object in SIP. 429 7.2. Verification Service Behavior 431 [RFC8224] Section 6.2 Step 5 requires that specifications defining 432 "ppt" values describe any additional verifier behavior. The behavior 433 specified for the "ppt" values of "rcd" is as follows. If the 434 PASSporT is in compact form, then the verification service SHOULD 435 extract the display-name from the From header field value, if any, 436 and use that as the value for the "rcd" key when it recomputes the 437 header and claims of the PASSporT object. If the signature validates 438 over the recomputed object, then the verification should be 439 considered successful. 441 However, if the PASSport is in full form with a "ppt" value of "rcd", 442 then the verification service MUST extract the value associated with 443 the "rcd" "nam" key in the object. If the signature validates, then 444 the verification service can use the value of the "rcd" "nam" key as 445 the display name of calling party, which would in turn be rendered to 446 alerted users or otherwise leveraged in accordance with local policy. 447 This will allow SIP networks that convey the display name through a 448 field other than the From header field to interoperate with this 449 specification. 451 The third-party "rcd" PASSporT cases presents some new challenges, as 452 an attacker could attempt to cut-and-paste such a third-party 453 PASSporT into a SIP request in an effort to get the terminating user 454 agent to render the display name or confidence values it contains to 455 a call that should have no such assurance. A third-party "rcd" 456 PASSporT provides no assurance that the calling party number has not 457 been spoofed: if it is carried in a SIP request, for example, then 458 some other PASSporT in another Identity header field value would have 459 to carry a PASSporT attesting that. A verification service MUST 460 determine that the calling party number shown in the "orig" of the 461 "rcd" PASSporT corresponds to the calling party number of the call it 462 has received, and that the "iat" field of the "rcd" PASSporT is 463 within the date interval that the verification service would 464 ordinarily accept for a PASSporT. 466 Verification services may alter their authorization policies for the 467 credentials accepted to sign PASSporTs when third parties generate 468 PASSporT objects, per Section 5.1. This may include accepting a 469 valid signature over a PASSporT even if it is signed with a 470 credential that does not attest authority over the identity in the 471 "orig" claim of the PASSporT, provided that the verification service 472 has some other reason to trust the signer. No further guidance on 473 verification service authorization policy is given here. 475 The behavior of a SIP UAS upon receiving an INVITE containing a 476 PASSporT object with a "rcd" claim will largely remain a matter of 477 implementation policy. In most cases, implementations would render 478 this calling party name information to the user while alerting. Any 479 user interface additions to express confidence in the veracity of 480 this information are outside the scope of this specification. 482 8. Using "rcd" as additional claims to other PASSporT extensions 484 Rich Call Data, including, for example, calling name information, is 485 often data that is additive data to the personal communications 486 information defined in the core PASSporT data required to support the 487 security properties defined in [RFC8225]. For cases where the entity 488 that is originating the personal communications and additionally is 489 supporting the authentication service and also is the authority of 490 the Rich Call Data, rather than creating multiple identity headers 491 with multiple PASSporT extensions or defining multiple combinations 492 and permutations of PASSporT extension definitions, the 493 authentication service can alternatively directly add the "rcd" 494 claims to the PASSporT it is creating, whether it is constructed with 495 a PASSporT extension or not. 497 8.1. Procedures for applying "rcd" as claims only 499 For a given PASSporT using some other extension than "rcd", the 500 Authentication Service MAY additionally include the "rcd" claim as 501 defined in this document. This would result in a set of claims that 502 correspond to the original intended extension with the addition of 503 the "rcd" claim. 505 The Verification service that receives the PASSporT, if it supports 506 this specification and chooses to, should interpret the "rcd" claim 507 as simply just an additional claim intended to deliver and/or 508 validate delivered Rich Call Data. 510 8.2. Example for applying "rcd" as claims only 512 In the case of [I-D.ietf-stir-passport-shaken] which is the PASSporT 513 extension supporting the SHAKEN specification [ATIS-1000074], a 514 common case for an Authentication service to co-exist in a CSP 515 network along with the authority over the calling name used for the 516 call. Rather than require two identity headers, the CSP 517 Authentication Service can apply both the SHAKEN PASSporT claims and 518 extension and simply add the "rcd" required claims defined in this 519 document. 521 For example, the PASSporT claims for the "shaken" PASSporT with "rcd" 522 claims would be as follows: 524 Protected Header 525 { 526 "alg":"ES256", 527 "typ":"passport", 528 "ppt":"shaken", 529 "x5u":"https://cert.example.org/passport.cer" 530 } 531 Payload 532 { 533 "attest":"A", 534 "dest":{"tn":["12025551001"]}, 535 "iat":1443208345, 536 "orig":{"tn":"12025551000"}, 537 "origid":"123e4567-e89b-12d3-a456-426655440000", 538 "rcd":{"nam":"James Bond"} 539 } 541 A Verification Service that supports "rcd" and "shaken" PASSporT 542 extensions will be able to receive the above PASSporT and interpret 543 both the "shaken" claims as well as the "rcd" defined claim. 545 If the Verification Service only understands the "shaken" extension 546 claims but doesn't support "rcd", the "rcd" can simply be ignored and 547 disregarded. 549 9. Acknowledgements 551 We would like to thank Robert Sparks and Russ Housley for helpful 552 suggestions. 554 10. IANA Considerations 556 10.1. JSON Web Token Claim 558 This specification requests that the IANA add a new claim to the JSON 559 Web Token Claims registry as defined in [RFC7519]. 561 Claim Name: "rcd" 563 Claim Description: Caller Name Information 564 Change Controller: IESG 566 Specification Document(s): [RFCThis] 568 10.2. PASSporT Types 570 This specification requests that the IANA add a new entry to the 571 PASSporT Types registry for the type "rcd" which is specified in 572 [RFCThis]. 574 10.3. PASSporT RCD Types 576 This document requests that the IANA create a new registry for 577 PASSporT RCD types. Registration of new PASSporT RCD types shall be 578 under the Specification Required policy. 580 This registry is to be initially populated with three values, "nam", 581 "jcd", and "jcl", which are specified in [RFCThis]. 583 11. Security Considerations 585 Revealing information such as the name, location, and affiliation of 586 a person necessarily entails certain privacy risks. Baseline 587 PASSporT has no particular confidentiality requirement, as the 588 information it signs over in a using protocol like SIP is all 589 information that SIP carries in the clear anyway. Transport-level 590 security can hide those SIP fields from eavesdroppers, and the same 591 confidentiality mechanisms would protect any PASSporT(s) carried in 592 SIP. 594 More TBD. 596 12. References 598 12.1. Normative References 600 [I-D.ietf-stir-oob] 601 Rescorla, E. and J. Peterson, "STIR Out-of-Band 602 Architecture and Use Cases", draft-ietf-stir-oob-04 (work 603 in progress), March 2019. 605 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 606 A., Peterson, J., Sparks, R., Handley, M., and E. 607 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 608 DOI 10.17487/RFC3261, June 2002, 609 . 611 [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words 612 for Use in RFCs to Indicate Requirement Levels", RFC 6919, 613 DOI 10.17487/RFC6919, April 2013, 614 . 616 [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, 617 DOI 10.17487/RFC7095, January 2014, 618 . 620 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 621 Telephone Identity Problem Statement and Requirements", 622 RFC 7340, DOI 10.17487/RFC7340, September 2014, 623 . 625 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 626 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 627 . 629 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 630 "Authenticated Identity Management in the Session 631 Initiation Protocol (SIP)", RFC 8224, 632 DOI 10.17487/RFC8224, February 2018, 633 . 635 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 636 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 637 . 639 12.2. Informative References 641 [ATIS-1000074] 642 ATIS/SIP Forum NNI Task Group, "Signature-based Handling 643 of Asserted information using toKENs (SHAKEN) 644 ", January 2017. 647 [I-D.ietf-stir-passport-shaken] 648 Wendt, C. and M. Barnes, "PASSporT SHAKEN Extension 649 (SHAKEN)", draft-ietf-stir-passport-shaken-08 (work in 650 progress), March 2019. 652 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 653 Requirement Levels", BCP 14, RFC 2119, 654 DOI 10.17487/RFC2119, March 1997, 655 . 657 Authors' Addresses 659 Jon Peterson 660 Neustar Inc. 661 1800 Sutter St Suite 570 662 Concord, CA 94520 663 US 665 Email: jon.peterson@neustar.biz 667 Chris Wendt 668 Comcast 669 Comcast Technology Center 670 Philadelphia, PA 19103 671 USA 673 Email: chris-ietf@chriswendt.net