idnits 2.17.1 draft-ietf-stir-passport-rcd-02.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 (February 18, 2019) is 1887 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 578, but not defined == Outdated reference: A later version (-07) exists of draft-ietf-stir-oob-03 ** 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 == Outdated reference: A later version (-08) exists of draft-ietf-stir-passport-shaken-07 Summary: 4 errors (**), 0 flaws (~~), 5 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: August 22, 2019 Comcast 6 February 18, 2019 8 PASSporT Extension for Rich Call Data 9 draft-ietf-stir-passport-rcd-02 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 August 22, 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 is mandatory and MUST be included as as part of the 'rcd' claim 147 value JSON object. 149 3.2. 'jcd' key 151 The 'jcd' key value is defined to contain a value of a jCard 152 [RFC7095] JSON object. This jCard object is intended to be an 153 extensible object that the calling party of personal communications 154 can provide both the types of information defined in jCard or can use 155 the built in extensibility of the jCard specification to add 156 additional information. The 'jcd' is optional. If included, this 157 key MUST only be included once in the 'rcd' JSON object and SHOULD 158 NOT be included if there is a 'jcl' key included. The 'jcd' and 159 'jcl' keys should be mutually exclusive. 161 3.3. 'jcl' key 163 The 'jcl' key value is defined to contain a HTTPS URL that refers the 164 recipient to a jCard [RFC7095] JSON object hosted on a HTTPS enabled 165 web server. This link is intended to be an external reference to a 166 JSON file with the same intended use of the 'jcd' jCard object and 167 has the same intended properties. The 'jcl' key is optional. If 168 included, this key MUST only be included once in the 'rcd' JSON 169 object and SHOULD NOT be included if there is a 'jcd' key included. 170 The 'jcd' and 'jcl' keys should be mutually exclusive. 172 3.4. 'rcd' Usage 174 The 'rcd' claim may appear in any PASSporT claims object as an 175 optional element. The creator of a PASSporT MAY however add a 'ppt' 176 value of 'rcd' to the header of a PASSporT as well, in which case the 177 PASSporT claims MUST contain a 'rcd' claim, and any entities 178 verifying the PASSporT object will be required to understand the 179 'ppt' extension in order to process the PASSporT in question. A 180 PASSporT header with the 'ppt' included will look as follows: 182 { "typ":"passport", 183 "ppt":"rcd", 184 "alg":"ES256", 185 "x5u":"https://www.example.com/cert.cer" } 187 The PASSporT claims object will then contain the "rcd" key with its 188 corresponding value. The value of "rcd" is an array of JSON objects, 189 of which one, the "nam" object, is mandatory. The key syntax of 190 "nam" follows the display-name ABNF given in [RFC3261]. 192 After the header and claims PASSporT objects have been constructed, 193 their signature is generated normally per the guidance in [RFC8225]. 195 3.5. Example 'rcd' PASSporTs 197 An example of a 'nam' only PASSporT claims obejct is shown next (with 198 line breaks for readability only). 200 { "orig":{"tn":"12025551000"}, 201 "dest":{"tn":"12025551001"}, 202 "iat":1443208345, 203 "rcd":{"nam":"James Bond"} } 205 An example of a PASSporT claims object that includes the "jcd" which 206 is optional, but will also include the mandatory "nam" object is 207 shown next (with line breaks for readability only). 209 { "orig":{"tn":"12025551000"}, 210 "dest":{"tn":"12155551001"}, 211 "iat":1443208345, 212 "rcd":{"nam":"James Bond","jcd":["vcard",[["version",{},"text","4.0"], 213 ["fn",{},"text", "James Bond"], 214 ["n",{},"text",["Bond","James","","","Mr."]], 215 ["adr",{"type":"work"},"text", 216 ["","","3100 Massachusetts Avenue NW","Washington","DC","20008","USA"] 217 ], 218 ["email",{},"text","007@mi6-hq.com"], 219 ["tel",{"type":["voice","text","cell"],"pref":"1"},"uri", 220 "tel:+1-202-555-1000"], 221 ["tel",{"type":["fax"]},"uri","tel:+1-202-555-1001"], 222 ["bday",{},"date","19241116"], 223 ["logo",{},"uri", 224 "https://upload.wikimedia.org/wikipedia/en/c/c5/Fleming007impression.jpg" 225 ]]]}} 227 In an example PASSporT where a jCard is linked via HTTPS URL and 228 'jcl' a jCard file served at a particular URL will be created. 230 An example jCard JSON file is shown as follows: 232 ["vcard", 233 [ 234 ["version", {}, "text", "4.0"], 235 ["fn", {}, "text", "James Bond"], 236 ["n", {}, "text", ["Bond", "James", "", "", "Mr."]], 237 ["adr", {"type":"work"}, "text", 238 ["", "", "3100 Massachusetts Avenue NW", "Washington", "DC", "20008", 239 "USA"] 240 ], 241 ["email", {}, "text", "007@mi6-hq.com"], 242 ["tel", { "type": ["voice", "text", "cell"], "pref": "1" }, "uri", 243 "tel:+1-202-555-1000"], 244 ["tel", { "type": ["fax"] }, "uri", "tel:+1-202-555-1001"], 245 ["bday", {}, "date", "19241116"] 246 ["logo", {}, "uri", 247 "https://upload.wikimedia.org/wikipedia/en/c/c5/Fleming007impression.jpg"] 248 ] 249 ] 251 If that jCard is hosted at the example address of 252 "https://example.org/james_bond.json", the cooresponding PASSporT 253 claims object would be as follows (with line breaks for readability 254 only): 256 { "orig":{"tn":"12025551000"}, 257 "dest":{"tn":"12155551001"}, 258 "iat":1443208345, 259 "rcd":{"nam":"James Bond","jcl":"https://example.org/james_bond.json"} 260 } 262 4. Further Information Associated with Callers 264 Beyond naming information and the information that can be contained 265 in a jCard [RFC7095] object, there may be additional human-readable 266 information about the calling party that should be rendered to the 267 end user in order to help the called party decide whether or not to 268 pick up the phone. This is not limited to information about the 269 caller, but includes information about the call itself, which may 270 derive from analytics that determine based on call patterns or 271 similar data if the call is likely to be one the called party wants 272 to receive. Such data could include: 274 information related to the location of the caller, or 276 any organizations or institutions that the caller is associated 277 with, or even categories of institutions (is this a government 278 agency, or a bank, or what have you), or 279 hyperlinks to images, such as logos or pictures of faces, or to 280 similar external profile information, or 282 information that will be processed by an application before 283 rendering it to a user, like social networking data that shows 284 that an unknown caller is a friend-of-a-friend, or reputation 285 scores derived from crowdsourcing, or confidence scores based on 286 broader analytics about the caller and callee. 288 All of these data elements would benefit from the secure attestations 289 provided by the STIR and PASSporT frameworks. A new IANA registry 290 has been defined to hold potential values of the "rcd" array; see 291 Section 10.3. Specific extensions to the "rcd" PASSporT claim are 292 left for future specification. 294 While in the traditional telephone network, the business relationship 295 between calling customers and their telephone service providers is 296 the ultimate root of information about a calling party's name, some 297 other forms of data like crowdsourced reputation scores might derive 298 from third parties. It is more likely that when those elements are 299 present, they will be in a third-party "rcd" PASSporT. 301 5. Third-Party Uses 303 While rich data about the call can be provided by an originating 304 authentication service, the terminating side or an intermediary in 305 the call path could also acquire rich call data by querying a third- 306 party service. In telephone operations today, a third-party 307 information service is commonly queried with the calling party's 308 number in order to learn the name of the calling party, and 309 potentially other helpful information could also be passed over that 310 interface. The value of using a PASSporT to convey this information 311 from third parties lies largely in the preservation of the original 312 authority's signature over the data, and the potential for the 313 PASSporT to be conveyed from intermediaries to endpoint devices. 314 Effectively, these use cases form of subcase of out-of-band 315 [I-D.ietf-stir-oob] use cases. The manner in which third-party 316 services are discovered is outside the scope of this document. 318 An intermediary use case might look as follows: a SIP INVITE carries 319 a display name in its From header field value and an initial PASSporT 320 object without the "rcd" claim. When the a terminating verification 321 service implemented at a SIP proxy server receives this request, and 322 determines that the signature is valid, it might query a third-party 323 service that maps telephone numbers to calling party names. Upon 324 receiving the PASSport in a response from that third-party service, 325 the terminating side could add a new Identity header field to the 326 request for the "rcd" PASSporT object provided by the third-party 327 service. It would then forward the INVITE to the terminating user 328 agent. If the display name in the "rcd" PASSporT object matches the 329 display name in the INVITE, then the name would presumably be 330 rendered to the end user by the terminating user agent. 332 A very similar flow could be followed by an intermediary closer to 333 the origination of the call. Presumably such a service could be 334 implemented at an originating network in order to decouple the 335 systems that sign for calling party numbers from the systems that 336 provide rich data about calls. 338 In an alternative use case, the terminating user agent might query a 339 third-party service. In this case, no new Identity header field 340 would be generated, though the terminating user agent might receive a 341 PASSporT object in return from the third-party service, and use the 342 "rcd" field in the object as a calling name to render to users while 343 alerting. 345 5.1. Signing as a Third Party 347 When a third party issues a PASSporT with an "rcd" claim, the 348 PASSporT MUST contain the "rcd" "ppt" type in its header object. It 349 moreover MUST include an "iss" claim as defined in [RFC7519] to 350 indicate the source of this PASSporT; that field SHOULD be populated 351 with the subject of the credential used to sign the PASSporT. 353 A PASSporT with a "ppt" of "rcd" MAY be signed with credentials that 354 do not have authority over the identity that appears in the "orig" 355 element of the PASSporT claims. Relying parties in STIR have always 356 been left to make their own authorization decisions about whether or 357 not the trust the signers of PASSporTs, and in the third-party case, 358 where an entity has explicitly queried a service to acquire the 359 PASSporT object, it may be some external trust or business 360 relationship that induces the relying party to trust a PASSporT. 362 An example of a Third Party issued PASSporT claims object is as 363 follows. 365 { "orig":{"tn":"12025551000"}, 366 "dest":{"tn":"12025551001"}, 367 "iat":1443208345, 368 "iss":"Example, Inc.", 369 "rcd":{"nam":"James Bond"} } 371 6. Levels of Assurance 373 As "rcd" can be provided by either first or third parties, relying 374 parties could benefit from an additional claim that indicates the 375 relationship of the attesting party to the caller. Even in first 376 party cases, this admits of some complexity: the Communications 377 Service Provider (CSP) to which a number was assigned might in turn 378 delegate the number to a reseller, who would then sell the number to 379 an enterprise, in which case the CSP might have little insight into 380 the caller's name. In third party cases, a caller's name could 381 derive from any number of data sources, on a spectrum between public 382 data scraped from web searches to a direct business relationship to 383 the caller. As multiple PASSporTs can be associated with the same 384 call, potentially a verification service could receive attestations 385 of the caller name from multiple sources, which have different levels 386 of granularity or accuracy. 388 Therefore PASSporTs that carry "rcd" data SHOULD also carry an 389 indication of the relationship of the generator of the PASSporT to 390 the caller. [TBD claim - take from SHAKEN?] 392 7. Using 'rcd' in SIP 394 This section specifies SIP-specific usage for the "rcd" claim in 395 PASSporT, and in the SIP Identity header field value. Other using 396 protocols of PASSporT may define their own usages for the "rcd" 397 claim. 399 7.1. Authentication Service Behavior 401 An authentication service creating a PASSporT containing a "rcd" 402 claim MAY include a "ppt" for "rcd" or not. Third-party 403 authentication services following the behavior in Section 5.1 MUST 404 include a "ppt" of "rcd". If "ppt" does contain a "rcd", then any 405 SIP authentication services MUST add a "ppt" parameter to the 406 Identity header containing that PASSporT with a value of "rcd". The 407 resulting Identity header might look as follows: 409 Identity: "sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9dlxkWzo 410 eU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgtw0Lu5csIp 411 pPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs="; \ 412 info=;alg=ES256;ppt="rcd" 414 This specification assumes that by default, a SIP authentication 415 service will derive the value of "rcd", specifically only for the 416 'nam' key value, from the display-name component of the From header 417 field value of the request, alternatively for some calls this may 418 come from the P-Asserted-ID header. It is however a matter of 419 authentication service policy to decide how it populates the value of 420 "rcd" and 'nam' key, which MAY also derive from other fields in the 421 request, from customer profile data, or from access to external 422 services. If the authentication service generates a PASSporT object 423 containing "rcd" with a value that is not equivalent to the From 424 header field display-name value, it MUST use the full form of the 425 PASSporT object in SIP. 427 7.2. Verification Service Behavior 429 [RFC8224] Section 6.2 Step 5 requires that specifications defining 430 "ppt" values describe any additional verifier behavior. The behavior 431 specified for the "ppt" values of "rcd" is as follows. If the 432 PASSporT is in compact form, then the verification service SHOULD 433 extract the display-name from the From header field value, if any, 434 and use that as the value for the "rcd" key when it recomputes the 435 header and claims of the PASSporT object. If the signature validates 436 over the recomputed object, then the verification should be 437 considered successful. 439 However, if the PASSport is in full form with a "ppt" value of "rcd", 440 then the verification service MUST extract the value associated with 441 the "rcd" "nam" key in the object. If the signature validates, then 442 the verification service can use the value of the "rcd" "nam" key as 443 the display name of calling party, which would in turn be rendered to 444 alerted users or otherwise leveraged in accordance with local policy. 445 This will allow SIP networks that convey the display name through a 446 field other than the From header field to interoperate with this 447 specification. 449 The third-party "rcd" PASSporT cases presents some new challenges, as 450 an attacker could attempt to cut-and-paste such a third-party 451 PASSporT into a SIP request in an effort to get the terminating user 452 agent to render the display name or confidence values it contains to 453 a call that should have no such assurance. A third-party "rcd" 454 PASSporT provides no assurance that the calling party number has not 455 been spoofed: if it is carried in a SIP request, for example, then 456 some other PASSporT in another Identity header field value would have 457 to carry a PASSporT attesting that. A verification service MUST 458 determine that the calling party number shown in the "orig" of the 459 "rcd" PASSporT corresponds to the calling party number of the call it 460 has received, and that the "iat" field of the "rcd" PASSporT is 461 within the date interval that the verification service would 462 ordinarily accept for a PASSporT. 464 Verification services may alter their authorization policies for the 465 credentials accepted to sign PASSporTs when third parties generate 466 PASSporT objects, per Section 5.1. This may include accepting a 467 valid signature over a PASSporT even if it is signed with a 468 credential that does not attest authority over the identity in the 469 "orig" claim of the PASSporT, provided that the verification service 470 has some other reason to trust the signer. No further guidance on 471 verification service authorization policy is given here. 473 The behavior of a SIP UAS upon receiving an INVITE containing a 474 PASSporT object with a "rcd" claim will largely remain a matter of 475 implementation policy. In most cases, implementations would render 476 this calling party name information to the user while alerting. Any 477 user interface additions to express confidence in the veracity of 478 this information are outside the scope of this specification. 480 8. Using 'rcd' as additional claims to other PASSporT extensions 482 Rich Call Data, including, for example, calling name information, is 483 often data that is additive data to the personal communications 484 information defined in the core PASSporT data required to support the 485 security properties defined in [RFC8225]. For cases where the entity 486 that is originating the personal communications and additionally is 487 supporting the authentication service and also is the authority of 488 the Rich Call Data, rather than creating multiple identity headers 489 with multiple PASSporT extensions or defining multiple combinations 490 and permutations of PASSporT extension definitions, the 491 authentication service can alternatively directly add the 'rcd' 492 claims to the PASSporT it is creating, whether it is constructed with 493 a PASSporT extension or not. 495 8.1. Procedures for applying 'rcd' as claims only 497 For a given PASSporT using some other extension than 'rcd,' the 498 Authentication Service MAY additionally include the 'rcd' claim as 499 defined in this document. This would result in a set of claims that 500 correspond to the original intended extension with the addition of 501 the 'rcd' claim. 503 The Verification service that receives the PASSporT, if it supports 504 this specification and chooses to, should interpret the 'rcd' claim 505 as simply just an additional claim intended to deliver and/or 506 validate delivered Rich Call Data. 508 8.2. Example for applying 'rcd' as claims only 510 In the case of [I-D.ietf-stir-passport-shaken] which is the PASSporT 511 extension supporting the SHAKEN specification [ATIS-1000074], a 512 common case for an Authentication service to co-exist in a CSP 513 network along with the authority over the calling name used for the 514 call. Rather than require two identity headers, the CSP 515 Authentication Service can apply both the SHAKEN PASSporT claims and 516 extension and simply add the 'rcd' required claims defined in this 517 document. 519 For example, the PASSporT claims for the 'shaken' PASSporT with 'rcd' 520 claims would be as follows: 522 Protected Header 523 { 524 "alg":"ES256", 525 "typ":"passport", 526 "ppt":"shaken", 527 "x5u":"https://cert.example.org/passport.cer" 528 } 529 Payload 530 { 531 "attest":"A", 532 "dest":{"tn":["12025551001"]}, 533 "iat":1443208345, 534 "orig":{"tn":"12025551000"}, 535 "origid":"123e4567-e89b-12d3-a456-426655440000", 536 "rcd":{"nam":"James Bond"} 537 } 539 A Verification Service that supports 'rcd' and 'shaken' PASSporT 540 extensions will be able to receive the above PASSporT and interpret 541 both the 'shaken' claims as well as the 'rcd' defined claim. 543 If the Verification Service only understands the 'shaken' extension 544 claims but doesn't support 'rcd', the 'rcd' can simply be ignored and 545 disregarded. 547 9. Acknowledgements 549 We would like to thank Robert Sparks for helpful suggestions. 551 10. IANA Considerations 553 10.1. JSON Web Token Claim 555 This specification requests that the IANA add a new claim to the JSON 556 Web Token Claims registry as defined in [RFC7519]. 558 Claim Name: "rcd" 560 Claim Description: Caller Name Information 562 Change Controller: IESG 563 Specification Document(s): [RFCThis] 565 10.2. PASSporT Types 567 This specification requests that the IANA add a new entry to the 568 PASSporT Types registry for the type "rcd" which is specified in 569 [RFCThis]. 571 10.3. PASSporT RCD Types 573 This document requests that the IANA create a new registry for 574 PASSporT RCD types. Registration of new PASSporT RCD types shall be 575 under the Specification Required policy. 577 This registry is to be initially populated with a single value for 578 "nam" which is specified in [RFCThis]. 580 11. Security Considerations 582 Revealing information such as the name, location, and affiliation of 583 a person necessarily entails certain privacy risks. Baseline 584 PASSporT has no particular confidentiality requirement, as the 585 information it signs over in a using protocol like SIP is all 586 information that SIP carries in the clear anyway. Transport-level 587 security can hide those SIP fields from eavesdroppers, and the same 588 confidentiality mechanisms would protect any PASSporT(s) carried in 589 SIP. 591 More TBD. 593 12. References 595 12.1. Normative References 597 [I-D.ietf-stir-oob] 598 Rescorla, E. and J. Peterson, "STIR Out-of-Band 599 Architecture and Use Cases", draft-ietf-stir-oob-03 (work 600 in progress), July 2018. 602 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 603 A., Peterson, J., Sparks, R., Handley, M., and E. 604 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 605 DOI 10.17487/RFC3261, June 2002, 606 . 608 [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words 609 for Use in RFCs to Indicate Requirement Levels", RFC 6919, 610 DOI 10.17487/RFC6919, April 2013, 611 . 613 [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, 614 DOI 10.17487/RFC7095, January 2014, 615 . 617 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 618 Telephone Identity Problem Statement and Requirements", 619 RFC 7340, DOI 10.17487/RFC7340, September 2014, 620 . 622 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 623 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 624 . 626 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 627 "Authenticated Identity Management in the Session 628 Initiation Protocol (SIP)", RFC 8224, 629 DOI 10.17487/RFC8224, February 2018, 630 . 632 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 633 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 634 . 636 12.2. Informative References 638 [ATIS-1000074] 639 ATIS/SIP Forum NNI Task Group, "Signature-based Handling 640 of Asserted information using toKENs (SHAKEN) 641 ", January 2017. 644 [I-D.ietf-stir-passport-shaken] 645 Wendt, C. and M. Barnes, "PASSporT SHAKEN Extension 646 (SHAKEN)", draft-ietf-stir-passport-shaken-07 (work in 647 progress), January 2019. 649 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 650 Requirement Levels", BCP 14, RFC 2119, 651 DOI 10.17487/RFC2119, March 1997, 652 . 654 Authors' Addresses 656 Jon Peterson 657 Neustar Inc. 658 1800 Sutter St Suite 570 659 Concord, CA 94520 660 US 662 Email: jon.peterson@neustar.biz 664 Chris Wendt 665 Comcast 666 Comcast Technology Center 667 Philadelphia, PA 19103 668 USA 670 Email: chris-ietf@chriswendt.net