draft-ietf-stir-passport-rcd-05.txt   draft-ietf-stir-passport-rcd-06.txt 
Network Working Group J. Peterson Network Working Group J. Peterson
Internet-Draft Neustar Inc. Internet-Draft Neustar Inc.
Intended status: Standards Track C. Wendt Intended status: Standards Track C. Wendt
Expires: May 7, 2020 Comcast Expires: September 10, 2020 Comcast
November 04, 2019 March 09, 2020
PASSporT Extension for Rich Call Data PASSporT Extension for Rich Call Data
draft-ietf-stir-passport-rcd-05 draft-ietf-stir-passport-rcd-06
Abstract Abstract
This document extends PASSporT, a token for conveying This document extends PASSporT, a token for conveying
cryptographically-signed call information about personal cryptographically-signed call information about personal
communications, to include rich data that can be transmitted and communications, to include rich data that can be transmitted and
subsequently rendered to users, extending identifying information subsequently rendered to users, extending identifying information
beyond human-readable display name comparable to the "Caller ID" beyond human-readable display name comparable to the "Caller ID"
function common on the telephone network. The element defined for function common on the telephone network. The element defined for
this purpose, Rich Call Data (RCD), is an extensible object defined this purpose, Rich Call Data (RCD), is an extensible object defined
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 7, 2020. This Internet-Draft will expire on September 10, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of the use of the Rich Call Data PASSporT extension 4 3. Overview of the use of the Rich Call Data PASSporT extension 4
4. Overview of Rich Call Data integrity . . . . . . . . . . . . 5 4. Overview of Rich Call Data integrity . . . . . . . . . . . . 5
5. PASSporT Claims . . . . . . . . . . . . . . . . . . . . . . . 5 5. PASSporT Claims . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. PASSporT "rcd" Claim . . . . . . . . . . . . . . . . . . 5 5.1. PASSporT "rcd" Claim . . . . . . . . . . . . . . . . . . 5
5.1.1. "nam" key . . . . . . . . . . . . . . . . . . . . . . 5 5.1.1. "nam" key . . . . . . . . . . . . . . . . . . . . . . 6
5.1.2. "jcd" key . . . . . . . . . . . . . . . . . . . . . . 6 5.1.2. "jcd" key . . . . . . . . . . . . . . . . . . . . . . 6
5.1.3. "jcl" key . . . . . . . . . . . . . . . . . . . . . . 6 5.1.3. "jcl" key . . . . . . . . . . . . . . . . . . . . . . 6
5.1.4. "rcdi" RCD integrity Claim . . . . . . . . . . . . . 6 5.1.4. "rcdi" RCD integrity Claim . . . . . . . . . . . . . 6
5.1.5. Creation of the "rcd" digest . . . . . . . . . . . . 7 5.1.5. Creation of the "rcd" digest . . . . . . . . . . . . 7
5.2. JWT Constraint for "rcdi" claim . . . . . . . . . . . . . 8 5.1.6. JWT Constraint for "rcdi" claim . . . . . . . . . . . 8
6. "rcd" Usage . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. PASSporT "crn" claim - Call Reason . . . . . . . . . . . 9
6. "rcd" and "crn" Claims Usage . . . . . . . . . . . . . . . . 9
6.1. Example "rcd" PASSporTs . . . . . . . . . . . . . . . . . 9 6.1. Example "rcd" PASSporTs . . . . . . . . . . . . . . . . . 9
7. Compact form of "rcd" PASSporT . . . . . . . . . . . . . . . 11 7. Compact form of "rcd" PASSporT . . . . . . . . . . . . . . . 11
7.1. Compact form of the "rcd" PASSporT claim . . . . . . . . 11 7.1. Compact form of the "rcd" PASSporT claim . . . . . . . . 11
7.2. Compact form of the "rcdi" PASSporT claim . . . . . . . . 11 7.2. Compact form of the "rcdi" PASSporT claim . . . . . . . . 12
8. Further Information Associated with Callers . . . . . . . . . 11 7.3. Compact form of the "crn" PASSporT claim . . . . . . . . 12
9. Third-Party Uses . . . . . . . . . . . . . . . . . . . . . . 12 8. Further Information Associated with Callers . . . . . . . . . 12
9.1. Signing as a Third Party . . . . . . . . . . . . . . . . 13 9. Third-Party Uses . . . . . . . . . . . . . . . . . . . . . . 13
10. Levels of Assurance . . . . . . . . . . . . . . . . . . . . . 14 9.1. Signing as a Third Party . . . . . . . . . . . . . . . . 14
11. Using "rcd" in SIP . . . . . . . . . . . . . . . . . . . . . 14 10. Levels of Assurance . . . . . . . . . . . . . . . . . . . . . 15
11.1. Authentication Service Behavior . . . . . . . . . . . . 14 11. Using "rcd" in SIP . . . . . . . . . . . . . . . . . . . . . 15
11.2. Verification Service Behavior . . . . . . . . . . . . . 15 11.1. Authentication Service Behavior . . . . . . . . . . . . 15
12. Using "rcd" as additional claims to other PASSporT extensions 16 11.2. Verification Service Behavior . . . . . . . . . . . . . 16
12.1. Procedures for applying "rcd" as claims only . . . . . . 16 12. Using "rcd" as additional claims to other PASSporT extensions 17
12.2. Example for applying "rcd" as claims only . . . . . . . 16 12.1. Procedures for applying "rcd" as claims only . . . . . . 17
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 12.2. Example for applying "rcd" as claims only . . . . . . . 17
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
14.1. JSON Web Token Claim . . . . . . . . . . . . . . . . . . 17 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
14.2. PASSporT Types . . . . . . . . . . . . . . . . . . . . . 18 14.1. JSON Web Token Claim . . . . . . . . . . . . . . . . . . 18
14.3. PASSporT RCD Types . . . . . . . . . . . . . . . . . . . 18 14.2. PASSporT Types . . . . . . . . . . . . . . . . . . . . . 19
15. Security Considerations . . . . . . . . . . . . . . . . . . . 18 14.3. PASSporT RCD Types . . . . . . . . . . . . . . . . . . . 19
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 15. Security Considerations . . . . . . . . . . . . . . . . . . . 19
16.1. Normative References . . . . . . . . . . . . . . . . . . 18 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
16.2. Informative References . . . . . . . . . . . . . . . . . 20 16.1. Normative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 16.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
PASSporT [RFC8225] is a token format based on JWT [RFC7519] for PASSporT [RFC8225] is a token format based on JWT [RFC7519] for
conveying cryptographically-signed information about the people conveying cryptographically-signed information about the people
involved in personal communications; it is used to convey a signed involved in personal communications; it is used to convey a signed
assertion of the identity of the participants in real-time assertion of the identity of the participants in real-time
communications established via a protocol like SIP [RFC8224]. The communications established via a protocol like SIP [RFC8224]. The
STIR problem statement [RFC7340] declared securing the display name STIR problem statement [RFC7340] declared securing the display name
of callers outside of STIR's initial scope, so baseline STIR provides of callers outside of STIR's initial scope, so baseline STIR provides
skipping to change at page 4, line 29 skipping to change at page 4, line 30
the caller themselves if they are authoritative, or a service the caller themselves if they are authoritative, or a service
provider, or a third-party service may be authoritative over the rich provider, or a third-party service may be authoritative over the rich
call data on behalf of the caller or service provider representing call data on behalf of the caller or service provider representing
the caller. the caller.
The RCD described in this document is of two main categories. The The RCD described in this document is of two main categories. The
first data is a more traditional set of info about a caller first data is a more traditional set of info about a caller
associated with "display-name" in SIP [RFC3261] and typically is the associated with "display-name" in SIP [RFC3261] and typically is the
calling name that is a textual description of the caller. The second calling name that is a textual description of the caller. The second
data is a set of RCD that is defined as part of the jCard definitions data is a set of RCD that is defined as part of the jCard definitions
or extensions to that data. [I.D.wendt-sipcore-callinfo-rcd-00] or extensions to that data. [I-D.wendt-sipcore-callinfo-rcd]
describes the use of jCard as RCD with the "jcard" Call-Info purpose describes the use of jCard as RCD with the "jcard" Call-Info purpose
token. Either or both of these two types of data can be incorporated token. Either or both of these two types of data can be incorporated
into a "rcd" claim defined in this document. into a "rcd" claim defined in this document.
Additionally, [I-D.wendt-sipcore-callinfo-rcd] also describes a
"reason" parameter intended for description of the intent or reason
for a particular call. A new claim "crn" for call reason can contain
the string or object that describes the intent of the call. This
claim is intentionally kept separate from the "rcd" claim because it
is envisioned that reason will often change on a more frequent, per
call, type of basis and would not fit the "rcdi" claim and other
integrity methods tied to the certificate and identity of the caller.
In addition to the type of RCD that can be signed, there are three In addition to the type of RCD that can be signed, there are three
normative modes of use of the signing of Rich Call Data (RCD). The normative modes of use of the signing of Rich Call Data (RCD). The
first and simplest mode is exclusively for when RCD content is first and simplest mode is exclusively for when RCD content is
direcly included as part of the claims (i.e. no URIs are included in directly included as part of the claims (i.e. no URIs are included in
the content). In this mode the set of claims is signed via standard the content). In this mode the set of claims is signed via standard
PASSporT [RFC8225] and SIP identity header [RFC8224] procedures. The PASSporT [RFC8225] and SIP identity header [RFC8224] procedures. The
second mode is an extension of the first where a "rcd" claim is second mode is an extension of the first where a "rcd" claim is
included and the content MAY or MAY NOT include URI external included and the content MAY or MAY NOT include a URI identifying
resources. In this mode, a "rcdi" integrity claim MUST be included. external resources. In this mode, a "rcdi" integrity claim MUST be
This integrity claim is defined in this document and provides a included. This integrity claim is defined in this document and
digest of the content so that, particularly for the case where there provides a digest of the content so that, particularly for the case
is URI references in the RCD, the content of that RCD can be where there is URI references in the RCD, the content of that RCD can
comprehensively validated that it was received as intended by the be comprehensively validated that it was received as intended by the
signer of the PASSporT. The third mode is yet another addition to signer of the PASSporT. The third mode is an extension to both the
both the first and second modes and incorporates the ability to first and second modes and incorporates the ability to include the
include the digest of the integrity claim as a required value in the digest of the integrity claim as a required value in the certificate
certificate used to create the PASSporT digital signature. This mode used to create the PASSporT digital signature. This mode allows for
allows for cases where there is a different authoritative entity over cases where there is a different authoritative entity responsible for
the content of the RCD, separate from the signer of the PASSporT the content of the RCD, separate from the signer of the PASSporT
itself allowing the ability to have policy around the content and itself allowing the ability to have policy around the content and
potential review or pre-determination of allowed RCD content. potential review or pre-determination of allowed RCD content.
4. Overview of Rich Call Data integrity 4. Overview of Rich Call Data integrity
When incorporating call data that represents a user, even in When incorporating call data that represents a user, even in
traditional calling name services today, often there is policy and traditional calling name services today, often there is policy and
restrictions around what data is allowed to be used. Whether restrictions around what data is allowed to be used. Whether
preventing offensive language or icons or enforcing uniqueness or preventing offensive language or icons or enforcing uniqueness or
skipping to change at page 5, line 50 skipping to change at page 6, line 13
Call Data, the value of which is a JSON object that can contain one Call Data, the value of which is a JSON object that can contain one
or more key value pairs. This document defines a default set of key or more key value pairs. This document defines a default set of key
values. values.
5.1.1. "nam" key 5.1.1. "nam" key
The "nam" key value is a display name, associated with the originator The "nam" key value is a display name, associated with the originator
of personal communications, which may for example derive from the of personal communications, which may for example derive from the
display-name component of the From header field value of a SIP display-name component of the From header field value of a SIP
request, or a similar field in other PASSporT using protocols. This request, or a similar field in other PASSporT using protocols. This
key MUST be included once and MUST be included as as part of the key MUST be included once and MUST be included as part of the "rcd"
"rcd" claim value JSON object. If there is no string associated with claim value JSON object. If there is no string associated with a
a display name, the claim value SHOULD then be an empty string. display name, the claim value SHOULD then be an empty string.
5.1.2. "jcd" key 5.1.2. "jcd" key
The "jcd" key value is defined to contain a value of a jCard The "jcd" key value is defined to contain a value of a jCard
[RFC7095] JSON object. This jCard object is intended to and may [RFC7095] JSON object. This jCard object is intended to represent
derive from the Call-Info header field value defined in [I.D.wendt- and derives from the Call-Info header field value defined in
sipcore-callinfo-rcd] with a type of "jcard". As also defined in [I-D.wendt-sipcore-callinfo-rcd] with a type of "jcard". As also
[I.D.wendt-sipcore-callinfo-rcd], format of the jCard and properties defined in [I-D.wendt-sipcore-callinfo-rcd], format of the jCard and
used should follow the normative usage and formating rules and properties used should follow the normative usage and formatting
procedures. It is an extensible object where the calling party can rules and procedures. It is an extensible object where the calling
provide both the standard types of information defined in jCard or party can provide both the standard types of information defined in
can use the built in extensibility of the jCard specification to add jCard or can use the built-in extensibility of the jCard
additional information. The "jcd" is optional. If included, this specification to add additional information. The "jcd" is optional.
key MUST only be included once in the "rcd" JSON object and SHOULD If included, this key MUST only be included once in the "rcd" JSON
NOT be included if there is a "jcl" key included. The "jcd" and object and SHOULD NOT be included if there is a "jcl" key included.
"jcl" keys should be mutually exclusive. The "jcd" and "jcl" keys should be mutually exclusive.
5.1.3. "jcl" key 5.1.3. "jcl" key
The "jcl" key value is defined to contain a HTTPS URL that refers the The "jcl" key value is defined to contain a HTTPS URL that refers the
recipient to a jCard [RFC7095] JSON object hosted on a HTTPS enabled recipient to a jCard [RFC7095] JSON object hosted on a HTTPS enabled
web server. This link is intended to and may derive from the Call- web server. This link may derive from the Call-Info header field
Info header field value defined in [I.D.wendt-sipcore-callinfo-rcd] value defined in [I-D.wendt-sipcore-callinfo-rcd] with a type of
with a type of "jcard". As also defined in [I.D.wendt-sipcore- "jcard". As also defined in [I-D.wendt-sipcore-callinfo-rcd], format
callinfo-rcd], format of the jCard and properties used should follow of the jCard and properties used should follow the normative usage
the normative usage and formating rules and procedures. The "jcl" and formatting rules and procedures. The "jcl" key is optional. If
key is optional. If included, this key MUST only be included once in included, this key MUST only be included once in the "rcd" JSON
the "rcd" JSON object and SHOULD NOT be included if there is a "jcd" object and SHOULD NOT be included if there is a "jcd" key included.
key included. The "jcd" and "jcl" keys should be mutually exclusive. The "jcd" and "jcl" keys should be mutually exclusive.
5.1.4. "rcdi" RCD integrity Claim 5.1.4. "rcdi" RCD integrity Claim
The "rcdi" claim is an optional claim that if the application The "rcdi" claim is an optional claim that SHOULD be included if the
requires integrity applied to the content of the "rcd" claim SHOULD application requires integrity to be applied to the content of the
be included with a corresponding "rcd" claim. The value of the "rcd" claim and if included MUST be included only once with a
"rcdi" key pair should contain a string that is defined as follows. corresponding "rcd" claim. The value of the "rcdi" key pair should
contain a string that is defined as follows.
The first part of the string should define the crypto algorithm used The first part of the string should define the crypto algorithm used
to generate the digest. For RCD, implementations MUST support the to generate the digest. For RCD, implementations MUST support the
following hash algorithms, "SHA256", "SHA384", or "SHA512". The SHA- following hash algorithms, "SHA256", "SHA384", or "SHA512". The SHA-
256, SHA-384, and SHA-512 are part of the SHA-2 set of cryptographic 256, SHA-384, and SHA-512 are part of the SHA-2 set of cryptographic
hash functions defined by the NIST. Implementations MAY support hash functions defined by the NIST. Implementations MAY support
additional algorithms, but MUST NOT support known weak algorithms additional algorithms, but MUST NOT support known weak algorithms
such as MD5 or SHA-1. In the future, the list of algorithms may re- such as MD5 or SHA-1. In the future, the list of algorithms may re-
evaluated based on security best practices. The algorithms MUST be evaluated based on security best practices. The algorithms MUST be
represented in the text by "sha256", "sha384", or "sha512". The represented in the text by "sha256", "sha384", or "sha512". The
skipping to change at page 7, line 19 skipping to change at page 7, line 31
Example: Example:
"rcdi" : "sha256-H8BRh8j48O9oYatfu5AZzq6A9RINQZngK7T62em8MUt1FLm52t+eX6xO" "rcdi" : "sha256-H8BRh8j48O9oYatfu5AZzq6A9RINQZngK7T62em8MUt1FLm52t+eX6xO"
5.1.5. Creation of the "rcd" digest 5.1.5. Creation of the "rcd" digest
In order to facilitate proper verification of the digest and whether In order to facilitate proper verification of the digest and whether
the "rcd" content was modified, the input to the digest must be the "rcd" content was modified, the input to the digest must be
completely deterministic at three points in the process. First, at completely deterministic at three points in the process. First, at
the certification point where the content is evaluated to conform to the certification point where the content is evaluated to conform to
the application policy and the JWT constraint is applied to the the application policy and the JWT Claim Constraints is applied to
certificate containing the digest. Second, when the call is signed the certificate containing the digest. Second, when the call is
at the Authentication Service, there may be a local policy to verify signed at the Authentication Service, there may be a local policy to
that the provided "rcd" claim corresponds to the digest. Third, when verify that the provided "rcd" claim corresponds to the digest.
the "rcd" data is verified at the Verification Service, it MUST Third, when the "rcd" data is verified at the Verification Service,
verify the digest by constructing the "rcd" input digest string. it MUST verify the digest by constructing the "rcd" input digest
string.
The procedures for the creation of the "rcd" input digest string is The procedures for the creation of the "rcd" input digest string is
as follows. as follows.
1. Arrange the keys in the "rcd" claim value to be in lexicographic 1. Arrange the keys in the "rcd" claim value to be in lexicographic
order. order.
2. Serialize the resulting "rcd" claim value JSON object to remove 2. Serialize the resulting "rcd" claim value JSON object to remove
all white space and line breaks. The procedures of this all white space and line breaks. The procedures of this
deterministic JSON serialization is defined in [RFC8225], deterministic JSON serialization is defined in [RFC8225],
Section 9. Section 9.
3. Identify, in order of where they appear in the serialized string, 3. Identify, in order of where they appear in the serialized string,
all of the URLs referencing external resource files. all of the URLs referencing external resource files.
4. Construct the "rcd" input string by first inserting the 4. Construct the "rcd" input string by first inserting the
serialized "rcd" claim value. serialized "rcd" claim value.
5. If there is at least one URL identified, insert a semicolon 5. If there is at least one URL identified, insert a semicolon
character in the "rcd" input string. character at the end of the "rcd" serialized string.
6. Follow the semicolon with the Base64 encoded contents of resource 6. Follow the semicolon with the Base64 encoded contents of resource
file referenced by the first URL. file referenced by the first URL.
7. Repeat steps 5 and 6 for any additionally identified 7. Repeat steps 5 and 6 for any additionally identified
corresponding URLs. corresponding URLs including URLs contained in resources
referenced by other URLs. When or if these nested URLs occur in
the contents referred to by a parent URL, the insertion of the
Base64 encoded contents should be included for all child URLs
before moving to any subsequent parent URL.
Once the input digest string has been created, use this string to Once the input serialized string has been created, use this string to
create the base64 encoded digest output that can be inserted into the create the base64 encoded digest output that can be inserted into the
"rcdi" claim as discussed in the last section. "rcdi" claim as discussed in the last section.
Example "rcd" claim with URL: Example "rcd" claim with URL:
"rcd": { "nam" : "James Bond", "rcd": { "nam" : "James Bond",
"jcl" : "https://example.org/james_bond.json" "jcl" : "https://example.org/james_bond.json"
} }
Example "rcd" input digest string (with line breaks for readability): Example "rcd" input digest string (with line breaks for readability):
{"nam":"James Bond","jcl":"https://example.org/james_bond.json"}; {"nam":"James Bond","jcl":"https://example.org/james_bond.json"};
ONG##*NCCCDJK123...KLJASlkJlkjsadlf2e3 ONG##*NCCCDJK123...KLJASlkJlkjsadlf2e3
Example "rcdi" claim: Example "rcdi" claim:
"rcdi":"sha256-u5AZzq6A9RINQZngK7T62em8M" "rcdi":"sha256-u5AZzq6A9RINQZngK7T62em8M"
5.2. JWT Constraint for "rcdi" claim 5.1.6. JWT Constraint for "rcdi" claim
Once both the contents of the "rcd" claim is certified and the Once both the contents of the "rcd" claim is certified and the
construction of the "rcdi" claim is complete, the "rcdi" digest is construction of the "rcdi" claim is complete, the "rcdi" digest is
linked to the STIR certificate associated with the signature in the linked to the STIR certificate associated with the signature in the
PASSporT via JWT Constraints as defined in [RFC8226] Section 8. PASSporT via JWT Claim Constraints as defined in [RFC8226] Section 8.
The certificate JWT Constraint MUST include both of the following: The certificate JWT Claims Constraint MUST include both of the
following:
o a "mustInclude" for the "rcd" claim o a "mustInclude" for the "rcd" claim
o a "mustInclude" for the "rcdi" claim and a "permittedValues" equal o a "mustInclude" for the "rcdi" claim and a "permittedValues" equal
to the created "rcdi" claim value string. to the created "rcdi" claim value string.
6. "rcd" Usage The "permitedValues" for the "rcdi" claim may contain multiple
entries, to support the case where the certificate holder is
authorized to use different sets of rich call data.
The "rcd" claim may appear in any PASSporT claims object as an 5.2. PASSporT "crn" claim - Call Reason
optional element. The creator of a PASSporT MAY however add a "ppt"
value of "rcd" to the header of a PASSporT as well, in which case the This specification defines a new JSON Web Token claim for "crn", Call
PASSporT claims MUST contain a "rcd" claim, and any entities Reason, the value of which is a single string or object that can
verifying the PASSporT object will be required to understand the contains information as defined in [I-D.wendt-sipcore-callinfo-rcd]
"ppt" extension in order to process the PASSporT in question. A corresponding to the "reason" parameter for the Call-Info header.
PASSporT header with the "ppt" included will look as follows: This claim is optional.
Example "crn" claim with "rcd":
"rcd": { "nam" : "James Bond",
"jcl" : "https://example.org/james_bond.json"
},
"crn" : "For your ears only"
6. "rcd" and "crn" Claims Usage
Either the "rcd" or "crn" claim may appear in any PASSporT claims
object as an optional element. The creator of a PASSporT MAY also
add a "ppt" value of "rcd" to the header of a PASSporT as well, in
which case the PASSporT claims MUST contain either a "rcd" or "crn"
claim, and any entities verifying the PASSporT object will be
required to understand the "ppt" extension in order to process the
PASSporT in question. A PASSporT header with the "ppt" included will
look as follows:
{ "typ":"passport", { "typ":"passport",
"ppt":"rcd", "ppt":"rcd",
"alg":"ES256", "alg":"ES256",
"x5u":"https://www.example.com/cert.cer" } "x5u":"https://www.example.com/cert.cer" }
The PASSporT claims object will then contain the "rcd" key with its The PASSporT claims object will then contain the "rcd" key with its
corresponding value. The value of "rcd" is an array of JSON objects, corresponding value. The value of "rcd" is an array of JSON objects,
of which one, the "nam" object, is mandatory. The key syntax of of which one, the "nam" object, is mandatory. The key syntax of
"nam" follows the display-name ABNF given in [RFC3261]. "nam" follows the display-name ABNF given in [RFC3261].
skipping to change at page 11, line 12 skipping to change at page 12, line 4
"rcdi":"sha256-H8BRh8j48O9oYatfu5AZzq6A9R6dQZngK7T62em8MUt1FLm52t+eX6xO" "rcdi":"sha256-H8BRh8j48O9oYatfu5AZzq6A9R6dQZngK7T62em8MUt1FLm52t+eX6xO"
} }
7. Compact form of "rcd" PASSporT 7. Compact form of "rcd" PASSporT
7.1. Compact form of the "rcd" PASSporT claim 7.1. Compact form of the "rcd" PASSporT claim
Compact form of an "rcd" PASSporT claim has some restrictions but Compact form of an "rcd" PASSporT claim has some restrictions but
mainly follows standard PASSporT compact form procedures. For re- mainly follows standard PASSporT compact form procedures. For re-
construction of the "nam" claim the string for the display-name in construction of the "nam" claim the string for the display-name in
the From header MUST be used. For re-construction of the "jcl", the the From header field. For re-construction of the "jcl", the Call-
Call-Info header with purpose "jcard" MUST be used. "jcd" claim MAY Info header as with purpose "jcard" defined in
NOT be used as part of compact form. [I-D.wendt-sipcore-callinfo-rcd] MUST be used. "jcd" claim MAY NOT be
used as part of compact form.
7.2. Compact form of the "rcdi" PASSporT claim 7.2. Compact form of the "rcdi" PASSporT claim
Compact form of an "rcdi" PASSPorT claim shall be re-constructed Compact form of an "rcdi" PASSPorT claim shall be re-constructed
following the same "rcdi" defined digest procedures in this document following the same "rcdi" defined digest procedures in this document
of all of the content and referenced URI content once downloaded. of all of the content and referenced URI content once downloaded.
7.3. Compact form of the "crn" PASSporT claim
Compact form of a "crn" PASSporT claim shall be re-constructed using
the "reason" parameter of a Call-Info header as defined by
[I-D.wendt-sipcore-callinfo-rcd].
8. Further Information Associated with Callers 8. Further Information Associated with Callers
Beyond naming information and the information that can be contained Beyond naming information and the information that can be contained
in a jCard [RFC7095] object, there may be additional human-readable in a jCard [RFC7095] object, there may be additional human-readable
information about the calling party that should be rendered to the information about the calling party that should be rendered to the
end user in order to help the called party decide whether or not to end user in order to help the called party decide whether or not to
pick up the phone. This is not limited to information about the pick up the phone. This is not limited to information about the
caller, but includes information about the call itself, which may caller, but includes information about the call itself, which may
derive from analytics that determine based on call patterns or derive from analytics that determine based on call patterns or
similar data if the call is likely to be one the called party wants similar data if the call is likely to be one the called party wants
skipping to change at page 13, line 24 skipping to change at page 14, line 24
In an alternative use case, the terminating user agent might query a In an alternative use case, the terminating user agent might query a
third-party service. In this case, no new Identity header field third-party service. In this case, no new Identity header field
would be generated, though the terminating user agent might receive a would be generated, though the terminating user agent might receive a
PASSporT object in return from the third-party service, and use the PASSporT object in return from the third-party service, and use the
"rcd" field in the object as a calling name to render to users while "rcd" field in the object as a calling name to render to users while
alerting. alerting.
9.1. Signing as a Third Party 9.1. Signing as a Third Party
When a third party issues a PASSporT with an "rcd" claim, the A third-party PASSporT, which contains such an "iss" element, will
PASSporT MUST contain the "rcd" "ppt" type in its header object. It necessarily be signed with credentials that do not have authority
moreover MUST include an "iss" claim as defined in [RFC7519] to over the identity that appears in the "orig" element of the PASSporT
indicate the source of this PASSporT; that field SHOULD be populated claims. The presence of "iss" signifies that a different category of
with the subject of the credential used to sign the PASSporT. credential is being used to sign a PASSporT than the [RFC8226]
certificates used to sign STIR calls; it is instead a certificate
A PASSporT with a "ppt" of "rcd" MAY be signed with credentials that that identifies the source of the "rcd" data. How those credentials
do not have authority over the identity that appears in the "orig" are issued and managed is outside the scope of this specification;
element of the PASSporT claims. Relying parties in STIR have always the value of "iss" however MUST reflect the Organization (O) field of
been left to make their own authorization decisions about whether or the certificate used to sign a third-party PASSporT. Relying parties
not the trust the signers of PASSporTs, and in the third-party case, in STIR have always been left to make their own authorization
where an entity has explicitly queried a service to acquire the decisions about whether or not the trust the signers of PASSporTs,
PASSporT object, it may be some external trust or business and in the third-party case, where an entity has explicitly queried a
relationship that induces the relying party to trust a PASSporT. service to acquire the PASSporT object, it may be some external trust
or business relationship that induces the relying party to trust a
PASSporT.
An example of a Third Party issued PASSporT claims object is as An example of a Third Party issued PASSporT claims object is as
follows. follows.
{ "orig":{"tn":"12025551000"}, { "orig":{"tn":"12025551000"},
"dest":{"tn":"12025551001"}, "dest":{"tn":"12025551001"},
"iat":1443208345, "iat":1443208345,
"iss":"Example, Inc.", "iss":"Example, Inc.",
"rcd":{"nam":"James Bond"} } "rcd":{"nam":"James Bond"} }
skipping to change at page 17, line 37 skipping to change at page 18, line 37
A Verification Service that supports "rcd" and "shaken" PASSporT A Verification Service that supports "rcd" and "shaken" PASSporT
extensions will be able to receive the above PASSporT and interpret extensions will be able to receive the above PASSporT and interpret
both the "shaken" claims as well as the "rcd" defined claim. both the "shaken" claims as well as the "rcd" defined claim.
If the Verification Service only understands the "shaken" extension If the Verification Service only understands the "shaken" extension
claims but doesn't support "rcd", the "rcd" can simply be ignored and claims but doesn't support "rcd", the "rcd" can simply be ignored and
disregarded. disregarded.
13. Acknowledgements 13. Acknowledgements
We would like to thank Robert Sparks, Russ Housley, and Eric Burger We would like to thank David Hancock, Robert Sparks, Russ Housley,
for helpful suggestions and comments. and Eric Burger for helpful suggestions and comments.
14. IANA Considerations 14. IANA Considerations
14.1. JSON Web Token Claim 14.1. JSON Web Token Claim
This specification requests that the IANA add two new claims to the This specification requests that the IANA add three new claims to the
JSON Web Token Claims registry as defined in [RFC7519]. JSON Web Token Claims registry as defined in [RFC7519].
Claim Name: "rcd" Claim Name: "rcd"
Claim Description: Rich Call Data Information Claim Description: Rich Call Data Information
Change Controller: IESG Change Controller: IESG
Specification Document(s): [RFCThis] Specification Document(s): [RFCThis]
Claim Name: "rcdi" Claim Name: "rcdi"
Claim Description: Rich Call Data Integrity Information Claim Description: Rich Call Data Integrity Information
Change Controller: IESG Change Controller: IESG
Specification Document(s): [RFCThis] Specification Document(s): [RFCThis]
Claim Name: "crn"
Claim Description: Call Reason
Change Controller: IESG
Specification Document(s): [RFCThis]
14.2. PASSporT Types 14.2. PASSporT Types
This specification requests that the IANA add a new entry to the This specification requests that the IANA add a new entry to the
PASSporT Types registry for the type "rcd" which is specified in PASSporT Types registry for the type "rcd" which is specified in
[RFCThis]. [RFCThis].
14.3. PASSporT RCD Types 14.3. PASSporT RCD Types
This document requests that the IANA create a new registry for This document requests that the IANA create a new registry for
PASSporT RCD types. Registration of new PASSporT RCD types shall be PASSporT RCD types. Registration of new PASSporT RCD types shall be
skipping to change at page 18, line 40 skipping to change at page 20, line 5
Revealing information such as the name, location, and affiliation of Revealing information such as the name, location, and affiliation of
a person necessarily entails certain privacy risks. Baseline a person necessarily entails certain privacy risks. Baseline
PASSporT has no particular confidentiality requirement, as the PASSporT has no particular confidentiality requirement, as the
information it signs over in a using protocol like SIP is all information it signs over in a using protocol like SIP is all
information that SIP carries in the clear anyway. Transport-level information that SIP carries in the clear anyway. Transport-level
security can hide those SIP fields from eavesdroppers, and the same security can hide those SIP fields from eavesdroppers, and the same
confidentiality mechanisms would protect any PASSporT(s) carried in confidentiality mechanisms would protect any PASSporT(s) carried in
SIP. SIP.
More TBD.
16. References 16. References
16.1. Normative References 16.1. Normative References
[I-D.ietf-stir-oob] [I-D.ietf-stir-oob]
Rescorla, E. and J. Peterson, "STIR Out-of-Band Rescorla, E. and J. Peterson, "STIR Out-of-Band
Architecture and Use Cases", draft-ietf-stir-oob-05 (work Architecture and Use Cases", draft-ietf-stir-oob-07 (work
in progress), July 2019. in progress), March 2020.
[I-D.wendt-sipcore-callinfo-rcd]
Wendt, C. and J. Peterson, "SIP Call-Info Parameters for
Rich Call Data", draft-wendt-sipcore-callinfo-rcd-00 (work
in progress), November 2019.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
[RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words
for Use in RFCs to Indicate Requirement Levels", RFC 6919, for Use in RFCs to Indicate Requirement Levels", RFC 6919,
DOI 10.17487/RFC6919, April 2013, DOI 10.17487/RFC6919, April 2013,
 End of changes. 32 change blocks. 
113 lines changed or deleted 170 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/