draft-ietf-stir-passport-rcd-09.txt   draft-ietf-stir-passport-rcd-10.txt 
Network Working Group J. Peterson Network Working Group C. Wendt
Internet-Draft Neustar Inc. Internet-Draft Comcast
Intended status: Standards Track C. Wendt Intended status: Standards Track J. Peterson
Expires: May 20, 2021 Comcast Expires: August 26, 2021 Neustar Inc.
November 16, 2020 February 22, 2021
PASSporT Extension for Rich Call Data PASSporT Extension for Rich Call Data
draft-ietf-stir-passport-rcd-09 draft-ietf-stir-passport-rcd-10
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 meta-data about a call and caller communications, to include rich meta-data about a call and caller
that can be signed and integrity protected, transmitted, and that can be signed and integrity protected, transmitted, and
subsequently rendered to users. This framework is intended to extend subsequently rendered to users. This framework is intended to extend
caller and call specific information beyond human-readable display caller and call specific information beyond human-readable display
name comparable to the "Caller ID" function common on the telephone name comparable to the "Caller ID" function common on the telephone
network. The JSON element defined for this purpose, Rich Call Data network. The JSON element defined for this purpose, Rich Call Data
(RCD), is an extensible object defined to either be used as part of (RCD), is an extensible object defined to either be used as part of
STIR or with SIP Call-Info to include related information about calls STIR or with SIP Call-Info to include related information about calls
that helps people decide whether to pick up the phone. This signing that helps people decide whether to pick up the phone. This signing
of the RCD information is also enhanced with a integrity mechanism of the RCD information is also enhanced with a integrity mechanism
that is designed to protect the authoring and transport of this that is designed to protect the authoring and transport of this
information between authoritative and non-authoritative parties information between authoritative and non-authoritative parties
authoring and signing the Rich Call Data for support of different generating and signing the Rich Call Data for support of different
usage and content policies. usage and content policies.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 20, 2021. This Internet-Draft will expire on August 26, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . . . . . 6 5. PASSporT Claims . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. PASSporT "rcd" Claim . . . . . . . . . . . . . . . . . . 6 5.1. PASSporT "rcd" Claim . . . . . . . . . . . . . . . . . . 6
5.1.1. "nam" key . . . . . . . . . . . . . . . . . . . . . . 6 5.1.1. "nam" key . . . . . . . . . . . . . . . . . . . . . . 7
5.1.2. "jcd" key . . . . . . . . . . . . . . . . . . . . . . 6 5.1.2. "jcd" key . . . . . . . . . . . . . . . . . . . . . . 7
5.1.3. "jcl" key . . . . . . . . . . . . . . . . . . . . . . 7 5.1.3. "jcl" key . . . . . . . . . . . . . . . . . . . . . . 7
5.1.4. "rcdi" RCD integrity Claim . . . . . . . . . . . . . 7 5.2. "rcdi" RCD Integrity Claim . . . . . . . . . . . . . . . 8
5.1.5. Creation of the "rcd" digest . . . . . . . . . . . . 7 5.2.1. Creation of the "rcd" element digests . . . . . . . . 9
5.1.6. JWT Constraint for "rcdi" claim . . . . . . . . . . . 9 5.2.2. JWT Claim Constraint for "rcd" claims only . . . . . 12
5.2. PASSporT "crn" claim - Call Reason . . . . . . . . . . . 9 5.2.3. JWT Claim Constraint for "rcd" and "rcdi" claims . . 12
5.2.1. JWT Constraint for "cdn" claim . . . . . . . . . . . 10 5.3. PASSporT "crn" claim - Call Reason . . . . . . . . . . . 13
6. "rcd" and "crn" Claims Usage . . . . . . . . . . . . . . . . 10 5.3.1. JWT Constraint for "crn" claim . . . . . . . . . . . 13
6.1. Example "rcd" PASSporTs . . . . . . . . . . . . . . . . . 10 6. "rcd" and "crn" Claims Usage . . . . . . . . . . . . . . . . 13
7. Compact form of "rcd" PASSporT . . . . . . . . . . . . . . . 12 6.1. Example "rcd" PASSporTs . . . . . . . . . . . . . . . . . 14
7.1. Compact form of the "rcd" PASSporT claim . . . . . . . . 13 7. Compact form of "rcd" PASSporT . . . . . . . . . . . . . . . 15
7.2. Compact form of the "rcdi" PASSporT claim . . . . . . . . 13 7.1. Compact form of the "rcd" PASSporT claim . . . . . . . . 15
7.3. Compact form of the "crn" PASSporT claim . . . . . . . . 13 7.2. Compact form of the "rcdi" PASSporT claim . . . . . . . . 16
8. Further Information Associated with Callers . . . . . . . . . 13 7.3. Compact form of the "crn" PASSporT claim . . . . . . . . 16
9. Third-Party Uses . . . . . . . . . . . . . . . . . . . . . . 14 8. Further Information Associated with Callers . . . . . . . . . 16
9.1. Signing as a Third Party . . . . . . . . . . . . . . . . 15 9. Third-Party Uses . . . . . . . . . . . . . . . . . . . . . . 17
10. Levels of Assurance . . . . . . . . . . . . . . . . . . . . . 16 9.1. Signing as a Third Party . . . . . . . . . . . . . . . . 18
11. Using "rcd" in SIP . . . . . . . . . . . . . . . . . . . . . 16 10. Levels of Assurance . . . . . . . . . . . . . . . . . . . . . 19
11.1. Authentication Service Behavior . . . . . . . . . . . . 16 11. Using "rcd" in SIP . . . . . . . . . . . . . . . . . . . . . 19
11.2. Verification Service Behavior . . . . . . . . . . . . . 17 11.1. Authentication Service Behavior . . . . . . . . . . . . 19
12. Using "rcd" as additional claims to other PASSporT extensions 18 11.2. Verification Service Behavior . . . . . . . . . . . . . 20
12.1. Procedures for applying "rcd" as claims only . . . . . . 18 12. Using "rcd" as additional claims to other PASSporT extensions 21
12.2. Example for applying "rcd" as claims only . . . . . . . 19 12.1. Procedures for applying "rcd" as claims only . . . . . . 22
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 12.2. Example for applying "rcd" as claims only . . . . . . . 22
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
14.1. JSON Web Token Claim . . . . . . . . . . . . . . . . . . 20 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
14.2. PASSporT Types . . . . . . . . . . . . . . . . . . . . . 20 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
14.3. PASSporT RCD Types . . . . . . . . . . . . . . . . . . . 20 14.1. JSON Web Token Claim . . . . . . . . . . . . . . . . . . 23
15. Security Considerations . . . . . . . . . . . . . . . . . . . 21 14.2. PASSporT Types . . . . . . . . . . . . . . . . . . . . . 23
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 14.3. PASSporT RCD Types . . . . . . . . . . . . . . . . . . . 24
16.1. Normative References . . . . . . . . . . . . . . . . . . 21 15. Security Considerations . . . . . . . . . . . . . . . . . . . 24
16.2. Informative References . . . . . . . . . . . . . . . . . 22 15.1. The use of JWT Claim Constraints in delegate
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 certificates to exclude unauthorized Claims . . . . . . 24
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
16.1. Normative References . . . . . . . . . . . . . . . . . . 24
16.2. Informative References . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
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 parties
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
no features for caller name. This specification documents an no features for caller name. This specification documents an
optional mechanism for PASSporT and the associated STIR procedures optional mechanism for PASSporT and the associated STIR procedures
which extend PASSporT objects to carry additional elements conveying which extend PASSporT objects to protect additional elements
richer information: information that is intended to be rendered to an conveying richer information: information that is intended to be
end user to assist a called party in determining whether to accept or rendered to an end user to assist a called party in determining
trust incoming communications. This includes the name of the person whether to accept or trust incoming communications. This includes
on one side of a communications session, the traditional "Caller ID" the name of the person on one side of a communications session, the
of the telephone network, along with related display information that traditional "Caller ID" of the telephone network, along with related
would be rendered to the called party during alerting, or potentially display information that would be rendered to the called party during
used by an automaton to determine whether and how to alert a called alerting, or potentially used by an automaton to determine whether
party. and how to alert a called party.
Traditional telephone network signaling protocols have long supported Traditional telephone network signaling protocols have long supported
delivering a 'calling name' from the originating side, though in delivering a 'calling name' from the originating side, though in
practice, the terminating side is often left to derive a name from practice, the terminating side is often left to derive a name from
the calling party number by consulting a local address book or an the calling party number by consulting a local address book or an
external database. SIP similarly can carry this information in a external database. SIP similarly can carry this information in a
'display-name' in the From header field value from the originating to 'display-name' in the From header field value from the originating to
terminating side, or alternatively in the Call-Info header field. terminating side, or alternatively in the Call-Info header field.
However, both are unsecured fields that really can not be trusted in However, both are unsecured fields that really cannot be trusted in
most interconnected SIP deployments, and therefore is a good starting most interconnected SIP deployments, and therefore is a good starting
point for a framework that utilizes STIR techniques and procedures point for a framework that utilizes STIR techniques and procedures
for protecting call related information including but not limited to for protecting call related information including but not limited to
calling name. calling name.
As such, the baseline use-case for this document will be extending As such, the baseline use-case for this document will be extending
PASSporT to provide cryptographic protection for the "display-name" PASSporT to provide cryptographic protection for the "display-name"
field of SIP requests as well as further "rich call data" (RCD) about field of SIP requests as well as further "rich call data" (RCD) about
the caller, which includes the contents of the Call-Info header field the caller, which includes the contents of the Call-Info header field
or other data structures that can be added to the PASSporT. This or other data structures that can be added to the PASSporT. This
document furthermore specifies a third-party profile that would allow document furthermore specifies a third-party profile that would allow
external authorities to convey rich information associated with a external authorities to convey rich information associated with a
calling number via a new type of PASSporT. Finally, this document calling number via a new type of PASSporT. Finally, this document
describes how to preserve the integrity of the RCD in scenarios where describes how to preserve the integrity of the RCD in scenarios where
there may be non-authoritative users that may be initiating and there may be non-authoritative users initiating and signing RCD and
signing RCD and therefore a constraint on the RCD data that a therefore a constraint on the RCD data that a PASSporT can attest via
PASSporT can attest via certificate-level controls. certificate-level controls.
2. Terminology 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in [RFC2119] and [RFC6919]. described in [RFC2119] and [RFC6919].
3. Overview of the use of the Rich Call Data PASSporT extension 3. Overview of the use of the Rich Call Data PASSporT extension
The main intended use of the signing of Rich Call Data (RCD) using The main intended use of the signing of Rich Call Data (RCD) using
STIR [RFC8224] and as a PASSporT extension [RFC8225] is from an STIR [RFC8224] and as a PASSporT extension [RFC8225] is for the
entity that is associated with the origination of a call. Either entity that originates a call, either directly the caller themselves,
directly the caller themselves, if they are authoritative, or a if they are authoritative, or a service provider or third-party
service provider or third-party service that may be authoritative service that may be authoritative over the rich call data on behalf
over the rich call data on behalf of the caller. of 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], typically a textual
calling name that is a textual description of the caller. The second description of the caller. The second category is a set of RCD that
data is a set of RCD that is defined as part of the jCard definitions is defined as part of the jCard definitions or extensions to that
or extensions to that data. [I-D.ietf-sipcore-callinfo-rcd] data. [I-D.ietf-sipcore-callinfo-rcd] describes the optional use of
describes the optional use of jCard in Call-Info header field as RCD jCard in Call-Info header field as RCD with the "jcard" Call-Info
with the "jcard" Call-Info purpose token. Either or both of these purpose token. Either or both of these two types of data can be
two types of data can be incorporated into a "rcd" claim defined in incorporated into a "rcd" claim defined in this document.
this document.
Additionally, [I-D.ietf-sipcore-callinfo-rcd] also describes a Additionally, [I-D.ietf-sipcore-callinfo-rcd] also describes a "call-
"reason" parameter intended for description of the intent or reason reason" parameter intended for description of the intent or reason
for a particular call. A new claim "crn", or call reason, can for a particular call. A new PASSporT claim "crn", or call reason,
contain the string or object that describes the intent of the call. can contain the string or object that describes the intent of the
This claim is intentionally kept separate from the "rcd" claim call. This claim is intentionally kept separate from the "rcd" claim
because it is envisioned that call reason is not the same as because it is envisioned that call reason is not the same as
information associated with the caller and may change on a more information associated with the caller and may change on a more
frequent, per call, type of basis. frequent, per call, type of basis.
In addition to the type of RCD that can be signed, there are three 4. Overview of Rich Call Data Integrity
modes of use of the signing of Rich Call Data (RCD). The first and
simplest mode is exclusively for when all RCD content is 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
PASSporT [RFC8225] and SIP identity header [RFC8224] procedures. The
second mode is an extension of the first where a "rcd" claim is
included and the content includes a URI identifying external
resources. In this mode, a "rcdi" integrity claim MUST be included.
This integrity claim is defined later in this document and provides a
digest of the content so that, particularly for the case where there
is URI references in the RCD, the content of that RCD can be
comprehensively validated that it was received as intended by the
signer of the PASSporT. The third mode is an extension to both the
first and second modes and incorporates the ability to include the
digest of the integrity claim as a required value, using JWT
Constraints as defined in [RFC8226], in the certificate used to
create the PASSporT digital signature. This mode allows for cases
where there is a different authoritative entity responsible for the
content of the RCD, separate from the signer of the PASSporT itself
allowing the ability to have policy around the content and potential
review or pre-determination of allowed RCD content.
More generally, either of the claims defined in this or future
specifications content can be protected by the authoritative
certificate creators by inclusion in the [RFC8226] defined
certificate's JWT Constraints.
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, preventing offensive language or icons or enforcing uniqueness,
potential copyright violations or other policy enforcement, there potential copyright violations or other policy enforcement, there
will likely be the desire to pre-certify the specific use of rich will likely be the desire to pre-certify or "vet" the specific use of
call data. This document defines a mechanism that allows for an rich call data. This document defines a mechanism that allows for a
indirect party that controls the policy to approve or certify the direct or indirect party that controls the policy to approve or
content, create a cryptographic digest that can be used to validate certify the content, create a cryptographic digest that can be used
that data and applies a constraint in the certificate to allow the to validate that data and applies a constraint in the certificate to
recipient and verifier to validate that the specific content of the allow the recipient and verifier to validate that the specific
RCD is as intended at its creation and approval or certification. content of the RCD is as intended at its creation and approval or
certification.
The integrity mechanism is a process of generating a sufficiently There are two mechanisms that will be defined to accomplish that for
strong cryptographic digest for both the "rcd" claim contents (e.g. two distinct categories of purposes. The first of the mechanisms
"nam" and "jcd") defined below and the resources defined by one or include the definition of an integrity claim. The RCD integrity
more globally unique HTTPS URLs referenced by the contents (e.g. an mechanism is a process of generating a sufficiently strong
image file referenced by "jcd"). This mechanism is inspired and cryptographic digest for both the "rcd" claim contents (e.g. "nam",
based on the W3C Subresource Integrity specification "jcd", "jcl") defined below and the resources defined by one or more
(http://www.w3.org/TR/SRI/). This mechanism additionally defines the globally unique HTTPS URLs referenced by the contents (e.g. an image
ability to constrain the digest and RCD integrity mechanism to be file referenced by "jcd" or a jCard referenced by "jcl"). This
mandatory without modification using JWT Constraints defined in mechanism is inspired by and based on the W3C Subresource Integrity
[RFC8226]. specification (http://www.w3.org/TR/SRI/). The second of the
mechanisms uses the capability called JWT Claim Constraints, defined
in [RFC8226] and extended in [I-D.housley-stir-enhance-rfc8226]. The
JWT Claim Constraints specifically guide the verifier within the
certificate used to sign the PASSporT for the inclusion (or
exclusion) of specific claims and their values, so that the content
intended by the signer can be verified to be accurate.
Both of these mechanisms, integrity digests and JWT Claims
Constraints, can be used together or separately depending on the
intended purpose. The first category of purpose is whether the rich
call data conveyed by the RCD passport is pass-by-value or passed-by-
reference; i.e., is the information contained in the passport claims
and therefor integrity protected by the passport signature, or is the
information contained in an external resource referenced by a URI in
the RCD PASSporT. The second category of purpose is whether the
signer is authoritative or has responsibility for the accuracy of the
RCD based on the policies of the eco-system the RCD PASSporTs are
being used.
The following table provides an overview of the framework for how
integrity should be used with RCD. (Auth represents authoritative in
this table)
+----------+---------------------+--------------------------------+
| Modes | No external URIs | Includes URI refs |
+----------+---------------------+--------------------------------+
| Auth | 1: No integrity req | 2: RDC Integrity |
+----------+---------------------+--------------------------------+
| Non-Auth | 3: JWT Claim Const. | 4: RCD Integ./JWT Claim Const. |
+----------+---------------------+--------------------------------+
The first and simplest mode is exclusively for when all RCD content
is directly included as part of the claims (i.e. no external
reference URIs are included in the content, for example, "photo" or
"logo" properties that aren't directly encoded into the JSON of the
jCard) and when the signer is authoritative over the content. In
this mode, integrity protection is not required and the set of claims
is simply protected by the signature of the standard PASSporT
[RFC8225] and SIP identity header [RFC8224] procedures. The second
mode is an extension of the first where the signer is authoritative
and a "rcd" claim contents include a URI identifying external
resources. In this mode, an RCD Integrity or "rcdi" claim MUST be
included. This integrity claim is defined later in this document and
provides a digest of the "rcd" claim content so that, particularly
for the case where there are URI references in the RCD, the content
of that RCD can be comprehensively validated that it was received as
intended by the signer of the PASSporT.
The third and fourth mode cover cases where there is a different
authoritative entity responsible for the content of the RCD, separate
from the signer of the PASSporT itself, allowing the ability to have
forward control at the time of the creation of the certificate of the
allowed or vetted content included in or referenced by the RCD claim
contents. The primary framework for allowing the separation of
authority and the signing of PASSporTs by non-authorized entities is
detailed in [I-D.ietf-stir-cert-delegation] although other cases may
apply. As with the first and second modes, the third and fourth
modes differ with the absence or inclusion of externally referenced
content using URIs.
5. PASSporT Claims 5. PASSporT Claims
5.1. PASSporT "rcd" Claim 5.1. PASSporT "rcd" Claim
This specification defines a new JSON Web Token claim for "rcd", Rich This specification defines a new JSON Web Token claim for "rcd", Rich
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.
skipping to change at page 7, line 20 skipping to change at page 8, line 5
text as application/json with a default encoding of UTF-8 [RFC4627]. text as application/json with a default encoding of UTF-8 [RFC4627].
This link may derive from the Call-Info header field value defined in This link may derive from the Call-Info header field value defined in
[I-D.ietf-sipcore-callinfo-rcd] with a type of "jcard". As also [I-D.ietf-sipcore-callinfo-rcd] with a type of "jcard". As also
defined in [I-D.ietf-sipcore-callinfo-rcd], format of the jCard and defined in [I-D.ietf-sipcore-callinfo-rcd], format of the jCard and
properties used should follow the normative usage and formatting properties used should follow the normative usage and formatting
rules and procedures. The "jcl" key is optional. If included, this rules and procedures. The "jcl" key is optional. If included, this
key MUST only be included once in the "rcd" JSON object and MUST NOT key MUST only be included once in the "rcd" JSON object and MUST NOT
be included if there is a "jcd" key included. The "jcd" and "jcl" be included if there is a "jcd" key included. The "jcd" and "jcl"
keys MUST be used mutually exclusively. keys MUST be used mutually exclusively.
5.1.4. "rcdi" RCD integrity Claim 5.2. "rcdi" RCD Integrity Claim
The "rcdi" claim is an optional claim that SHOULD be included if the The "rcdi" claim is claim that MUST be included for the second and
application requires integrity to be applied to the content of the fourth modes described in integrity overview section of this
"rcd" claim and if included MUST be included only once with a document. If this claim is present it MUST be only included once
corresponding "rcd" claim. The value of the "rcdi" key pair should with a corresponding single "rcd" claim. The value of the "rcdi" key
contain a string that is defined as follows. pair is a JSON object that is defined as follows.
The first part of the string should define the crypto algorithm used The claim value of "rcdi" claim key is a JSON object with a set of
to generate the digest. For RCD, implementations MUST support the JSON key/value pairs. These objects will correspond to each of the
following hash algorithms, "SHA256", "SHA384", or "SHA512". The SHA- elements of the "rcd" claim object that require integrity protection
256, SHA-384, and SHA-512 are part of the SHA-2 set of cryptographic with an associated digest over the content referenced by the key
hash functions defined by the NIST. Implementations MAY support string. The individual digest of different elements of the "rcd"
additional algorithms, but MUST NOT support known weak algorithms claim data and external URI referenced content is kept specifically
such as MD5 or SHA-1. In the future, the list of algorithms may re- separate to allow the ability to verify the integrity of only the
evaluated based on security best practices. The algorithms MUST be elements that are ultimately retrieved or downloaded or rendered to
represented in the text by "sha256", "sha384", or "sha512". The the end-user.
character following the algorithm string MUST be a minus character,
"-". The subsequent characters MUST be the base64 encoded digest of
a canonicalized and concatenated string based on the "rcd" claim and
the URLs contained in the claim. The details of the creation of this
string are defined in the next section.
Example: The key value will reference a specific object within the "rcd" claim
"rcdi" : "sha256-H8BRh8j48O9oYatfu5AZzq6A9RINQZngK7T62em8MUt1FLm52" value using a JSON pointer defined in [RFC6901] with a minor
additional rule to support external URI references that include JSON
objects themselves, in particular for the specific case of the use of
"jcl". JSON pointer syntax is the key value that specifies exactly
the part of JSON that should be used to generate the digest which
will be the resulting string that makes up the value for the
corresponding key. Detailed procedures are provided below, but an
example "rcdi" is provided here:
5.1.5. Creation of the "rcd" digest "rcdi" : {
"/jcd": "sha256-H8BRh8j48O9oAZzq6A9RINQZngK7T62em8MUt1FLm52",
"/jcd/1/2/3": "sha256-AZzq6A9RINQZngK7T62em8MUt1FLm52H8BRh8j48O9o"
}
In order to facilitate proper verification of the digest and whether The values of each key pair are a digest combined with a string that
the "rcd" content was modified, the input to the digest must be defines the crypto algorithm used to generate the digest. For RCD,
completely deterministic at three points in the process. First, at implementations MUST support the following hash algorithms, "SHA256",
the certification point where the content is evaluated to conform to "SHA384", or "SHA512". The SHA-256, SHA-384, and SHA-512 are part of
the application policy and the JWT Claim Constraints is applied to the SHA-2 set of cryptographic hash functions defined by the NIST.
the certificate containing the digest. Second, when the call is Implementations MAY support additional algorithms, but MUST NOT
signed at the Authentication Service, there may be a local policy to support known weak algorithms such as MD5 or SHA-1. In the future,
verify that the provided "rcd" claim corresponds to the digest. the list of algorithms may be re-evaluated based on security best
Third, when the "rcd" data is verified at the Verification Service, practices. The algorithms MUST be represented in the text by
it MUST verify the digest by constructing the "rcd" input digest "sha256", "sha384", or "sha512". The character following the
string. algorithm string MUST be a minus character, "-". The subsequent
characters MUST be the base64 encoded digest of a canonicalized and
concatenated string based on the JSON pointer referenced elements of
"rcd" claim or the URI referenced content contained in the claim.
The procedures for the creation of the "rcd" input digest string is The details of the determination of the input string used to
as follows. determine the digest are defined in the next section.
1. Arrange the keys in the "rcd" claim value to be in lexicographic 5.2.1. Creation of the "rcd" element digests
order.
2. Serialize the resulting "rcd" claim value JSON object to remove "rcd" claim objects can contain "nam", "jcd", or "jcl" keys as part
all white space and line breaks. The procedures of this of the "rcd" JSON object claim value. This specification defines the
deterministic JSON serialization is defined in [RFC8225], use of JSON pointer [RFC6901] as a basic to reference specific
Section 9. elements.
3. Identify, in order of where they appear in the serialized string, In the case of "nam", the only allowed value is a "string". In order
all of the URLs referencing external resource files. to reference the "nam" string value for a digest, the JSON pointer
string would be "/nam" and the digest string would be created using
only the string pointed to by that "/nam" following the rules of JSON
pointer.
4. Construct the "rcd" input string by first inserting the In the case of "jcd", the value associated is a jCard JSON object,
serialized "rcd" claim value. which happens to be a JSON array with sub-arrays. JSON pointer
notation uses numeric indexes into elements of arrays, including when
those elements are arrays themselves.
5. If there is at least one URL identified, insert a semicolon As example, for the following "rcd" claim:
character at the end of the "rcd" serialized string.
6. Follow the semicolon with the Base64 encoded contents of resource "rcd": {
file referenced by the first URL. "nam": "Q Branch Spy Gadgets",
"jcd": ["vcard",
[ ["version",{},"text","4.0"],
["fn",{},"text","Q Branch"],
["org",{},"text","MI6;Q Branch Spy Gadgets"],
["photo",{},"uri",
"https://example.com/photos/quartermaster-256x256.png"],
["logo",{},"uri",
"https://example.com/logos/mi6-256x256.jpg"],
["logo",{},"uri",
"https://example.com/logos/mi6-64x64.jpg"]
]
]
}
7. Repeat steps 5 and 6 for any additionally identified In order to use JSON pointer to refer to the URIs, the following
corresponding URLs including URLs contained in resources example "rcdi" claim includes a digest for the entire "jcd" array
referenced by other URLs. When or if these nested URLs occur in string as well as three additional digests for the URIs, where, as
the contents referred to by a parent URL, the insertion of the defined in [RFC6901] zero-based array indexes are used to reference
Base64 encoded contents should be included for all child URLs the URI strings.
before moving to any subsequent parent URL.
Once the input serialized string has been created, use this string to "rcdi": {
create the base64 encoded digest output that can be inserted into the "/jcd": "sha256-30SFLGHL40498527",
"rcdi" claim as discussed in the last section. "/jcd/1/3/3": "sha256-12938918VNJDSNCJ",
"/jcd/1/4/3": "sha256-VNJDSNCJ12938918",
"/jcd/1/5/3": "sha256-4049852730SFLGHL"
}
}
Example "rcd" claim with URL: For the use of JSON pointer in "jcd" and because array indexes are
"rcd": { "nam" : "James Bond", dependent on the order of the elements in the jCard, the digest for
"jcl" : "https://example.org/james_bond.json" the "/jcd" corresponding to the entire jCard array string MUST be
} included to avoid any possibility of substitution or insertion
attacks that may be possible to avoid integrity detection, even
though unlikely. Each URI referenced in the jCard array string MUST
have a corresponding JSON pointer string key and digest value.
Example "rcd" input digest string (with line breaks for readability): In the case of the use of a "jcl" URI reference to an external jCard,
{"nam":"James Bond","jcl":"https://example.org/james_bond.json"}; the procedures are similar to "jcd" with the exception and the minor
ONG##*NCCCDJK123...KLJASlkJlkjsadlf2e3 modification to JSON pointer, where "/jcl" is used to refer to the
external jCard array string and any following numeric array indexes
added to the "jcl" (e.g. "/jcl/1/2/3") are treated as if the
externally referenced jCard was part of the overall "rcd" claim JSON
object. The following example illustrates a "jcl" version of the
above "jcd" example.
Example "rcdi" claim: "rcd": {
"rcdi":"sha256-u5AZzq6A9RINQZngK7T62em8M" "nam": "Q Branch Spy Gadgets",
"jcl": "https://example.com/qbranch.json"
},
"rcdi": {
"/jcl": "sha256-30SFLGHL40498527",
"/jcl/1/3/3": "sha256-12938918VNJDSNCJ",
"/jcl/1/4/3": "sha256-VNJDSNCJ12938918",
"/jcl/1/5/3": "sha256-4049852730SFLGHL"
}
https://example.com/qbranch.json:
["vcard",
[ ["version",{},"text","4.0"],
["fn",{},"text","Q Branch"],
["org",{},"text","MI6;Q Branch Spy Gadgets"]
["photo",{},"uri",
"https://example.com/photos/quartermaster-256x256.png"]
["logo",{},"uri",
"https://example.com/logos/mi6-256x256.jpg"]
["logo",{},"uri",
"https://example.com/logos/mi6-64x64.jpg"]
]
]
5.1.6. JWT Constraint for "rcdi" claim In order to facilitate proper verification of the digest and whether
the "rcd" elements or content referenced by URIs were modified, the
input to the digest must be completely deterministic at three points
in the process. First, at the certification point where the content
is evaluated to conform to the application policy and the JWT Claim
Constraints is applied to the certificate containing the digest.
Second, when the call is signed at the Authentication Service, there
may be a local policy to verify that the provided "rcd" claim
corresponds to each digest. Third, when the "rcd" data is verified
at the Verification Service, it should verify each digest by
constructing the input digest string for the element being verified
and referenced by the JSON pointer string.
Once both the contents of the "rcd" claim is certified and the The procedure for the creation of each "rcd" element digest string
construction of the "rcdi" claim is complete, the "rcdi" digest is corresponding to a JSON pointer string key is as follows.
linked to the STIR certificate associated with the signature in the
PASSporT via JWT Claim Constraints as defined in [RFC8226] Section 8. 1. The JSON pointer will either refer to an element that is a part
or whole of a JSON object string or to a string that is a URI
referencing an external resource.
2. For a JSON formatted string, serialize the element JSON to remove
all white space and line breaks. The procedures of this
deterministic JSON serialization are defined in [RFC8225],
Section 9. The resulting string is used to create the digest.
3. For any URI referenced content, the content can either be a
string as in jCard JSON objects or binary content. For example,
image and audio files contain binary content. If the content is
binary format it should be Base64 encoded to create a string,
otherwise the direct string content of the file is used to create
the digest.
5.2.2. JWT Claim Constraint for "rcd" claims only
For the third mode described in the integrity overview section of
this document, where only JWT Claim Constraint for "rcd" claims,
without an "rcdi" claim, is required, the procedure should be, when
creating the certificate to include a constraint on inclusion of the
"rcd" claim as well as the contents of that claim.
The certificate JWT Claims Constraint MUST include the following:
o a "mustInclude" for the "rcd" claim and a "permittedValues" equal
to the created "rcd" claim value string.
The "permitedValues" for the "rcd" claim may contain multiple
entries, to support the case where the certificate holder is
authorized to use different sets of rich call data.
5.2.3. JWT Claim Constraint for "rcd" and "rcdi" claims
For the fourth mode described in the integrity overview section of
this document, if the signing of an "rcdi" claim is required to be
protected by the authoritative certificate creator using JWT
Constraints in the certificate, the procedure which is intended to
constrain the signer to construct the "rcd" and "rcdi" claims and
reference external content via URI in a pre-determined way. Once
both the contents of the "rcd" claim and any linked content is
certified and the construction of the "rcdi" claim is complete, the
"rcdi" claim is linked to the STIR certificate associated with the
signature in the PASSporT via JWT Claim Constraints as defined in
[RFC8226] Section 8. It should be recognized that the "rcdi" set of
digests is intended to be unique for only a specific combination of
"rcd" content and URI referenced external content.
The certificate JWT Claims Constraint MUST include both of the The certificate JWT Claims Constraint MUST include both of the
following: following:
o a "mustInclude" for the "rcd" claim o a "mustInclude" for the "rcd" claim, which simply constrains the
fact that an "rcd" should be included if there is a "rcdi"
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.
The "permitedValues" for the "rcdi" claim may contain multiple The "permitedValues" for the "rcdi" claim may contain multiple
entries, to support the case where the certificate holder is entries, to support the case where the certificate holder is
authorized to use different sets of rich call data. authorized to use different sets of rich call data.
5.2. PASSporT "crn" claim - Call Reason 5.3. PASSporT "crn" claim - Call Reason
This specification defines a new JSON Web Token claim for "crn", Call This specification defines a new JSON Web Token claim for "crn", Call
Reason, the value of which is a single string or object that can Reason, the value of which is a single string or object that can
contains information as defined in [I-D.ietf-sipcore-callinfo-rcd] contains information as defined in [I-D.ietf-sipcore-callinfo-rcd]
corresponding to the "reason" parameter for the Call-Info header. corresponding to the "reason" parameter for the Call-Info header.
This claim is optional. This claim is optional.
Example "crn" claim with "rcd": Example "crn" claim with "rcd":
"rcd": { "nam" : "James Bond", "rcd": { "nam": "James Bond",
"jcl" : "https://example.org/james_bond.json" "jcl": "https://example.org/james_bond.json"},
},
"crn" : "For your ears only" "crn" : "For your ears only"
5.2.1. JWT Constraint for "cdn" claim 5.3.1. JWT Constraint for "crn" claim
The integrity of the "crn" claim can optionally be protected by the The integrity of the "crn" claim can optionally be protected by the
authoritative certificate creator using JWT Constraints in the authoritative certificate creator using JWT Constraints in the
certificate. certificate. If this protection is used, a "mustInclude" for the
"rcdi" claim and a "permittedValues" equal to the "crn" claim value
string SHOULD be included.
6. "rcd" and "crn" Claims Usage 6. "rcd" and "crn" Claims Usage
Either the "rcd" or "crn" claim may appear in any PASSporT claims Either the "rcd" or "crn" claim may appear in any PASSporT claims
object as an optional element. The creator of a PASSporT MAY also 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 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" which case the PASSporT claims MUST contain either a "rcd" or "crn"
claim, and any entities verifying the PASSporT object will be claim, and any entities verifying the PASSporT object will be
required to understand the "ppt" extension in order to process the required to understand the "ppt" extension in order to process the
PASSporT in question. A PASSporT header with the "ppt" included will PASSporT in question. A PASSporT header with the "ppt" included will
skipping to change at page 10, line 37 skipping to change at page 14, line 7
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].
After the header and claims PASSporT objects have been constructed, After the header and claims PASSporT objects have been constructed,
their signature is generated normally per the guidance in [RFC8225]. their signature is generated normally per the guidance in [RFC8225].
6.1. Example "rcd" PASSporTs 6.1. Example "rcd" PASSporTs
An example of a "nam" only PASSporT claims obejct is shown next (with An example of a "nam" only PASSporT claims object is shown next (with
line breaks for readability only). line breaks for readability only).
{ "orig":{"tn":"12025551000"}, { "orig":{"tn":"12025551000"},
"dest":{"tn":["12025551001"]}, "dest":{"tn":["12025551001"]},
"iat":1443208345, "iat":1443208345,
"rcd":{"nam":"James Bond"} } "rcd":{"nam":"James Bond"} }
An example of a "nam" only PASSporT claims object with an "rcdi" An example of a "nam" only PASSporT claims object with an "rcdi"
claim is shown next (with line breaks for readability only). claim is shown next (with line breaks for readability only).
{ "orig":{"tn":"12025551000"}, { "orig":{"tn":"12025551000"},
"dest":{"tn":["12025551001"]}, "dest":{"tn":["12025551001"]},
"iat":1443208345, "iat":1443208345,
"rcd":{"nam":"James Bond"} "rcd":{"nam":"James Bond"},
"rcdi":"sha256-H8BRh8j48O9oYatfu5AZzq6A9R6dQZngK7T62em8MUt1FLm52" "rcdi":{"/nam": "sha256-918VNJD12938SNCJ"}
} }
An example of a PASSporT claims object that includes the "jcd" which An example of a "rcd" claims object that includes the "jcd" and also
is optional, but will also include the mandatory "nam" object is contains a URI which requires the inclusion of an "rcdi" claim.
shown next (with line breaks for readability only).
{ "orig":{"tn":"12025551000"},
"dest":{"tn":["12155551001"]},
"iat":1443208345,
"rcd":{"nam":"James Bond","jcd":["vcard",[["version",{},"text",
"4.0"],
["fn",{},"text", "James Bond"],
["n",{},"text",["Bond","James","","","Mr."]],
["adr",{"type":"work"},"text",
["","","3100 Massachusetts Avenue NW","Washington","DC",
"20008","USA"]
],
["email",{},"text","007@mi6-hq.com"],
["tel",{"type":["voice","text","cell"],"pref":"1"},"uri",
"tel:+1-202-555-1000"],
["tel",{"type":["fax"]},"uri","tel:+1-202-555-1001"],
["bday",{},"date","19241116"],
["logo",{},"uri",
"https://upload.wikimedia.org/wikipedia/en/c/c5
/Fleming007impression.jpg"
]]]}}
{
"orig": { "tn": "12025551000"},
"dest": { "tn": ["12155551001"]},
"iat": 1443208345,
"rcd": {
"nam": "Q Branch Spy Gadgets",
"jcd": ["vcard",
[ ["version",{},"text","4.0"],
["fn",{},"text","Q Branch"],
["org",{},"text","MI6;Q Branch Spy Gadgets"],
["photo",{},"uri","https://example.com/photos/q-256x256.png"],
["logo",{},"uri","https://example.com/logos/mi6-256x256.jpg"],
["logo",{},"uri","https://example.com/logos/mi6-64x64.jpg"]
] ]
},
"crn": "Rendezvous for Little Nellie",
"rcdi": {
"/nam": "sha256-918VNJD12938SNCJ",
"/jcd": "sha256-VNJDSNCJ12938918",
"/jcd/1/3/3": "sha256-12938918VNJDSNCJ",
"/jcd/1/4/3": "sha256-VNJDSNCJ12938918",
"/jcd/1/5/3": "sha256-4049852730SFLGHL"
}
}
In an example PASSporT where a jCard is linked via HTTPS URL and In an example PASSporT where a jCard is linked via HTTPS URL and
"jcl" a jCard file served at a particular URL will be created. "jcl" a jCard file served at a particular URL will be created.
An example jCard JSON file is shown as follows: An example jCard JSON file is shown as follows:
https://example.com/qbranch.json:
["vcard", ["vcard",
[ [ ["version",{},"text","4.0"],
["version", {}, "text", "4.0"], ["fn",{},"text","Q Branch"],
["fn", {}, "text", "James Bond"], ["org",{},"text","MI6;Q Branch Spy Gadgets"],
["n", {}, "text", ["Bond", "James", "", "", "Mr."]], ["photo",{},"uri","https://example.com/photos/q-256x256.png"],
["adr", {"type":"work"}, "text", ["logo",{},"uri","https://example.com/logos/mi6-256x256.jpg"],
["", "", "3100 Massachusetts Avenue NW", "Washington", "DC", ["logo",{},"uri","https://example.com/logos/mi6-64x64.jpg"]
"20008", "USA"]
],
["email", {}, "text", "007@mi6-hq.com"],
["tel", { "type": ["voice", "text", "cell"], "pref": "1" },
"uri", "tel:+1-202-555-1000"],
["tel", { "type": ["fax"] }, "uri", "tel:+1-202-555-1001"],
["bday", {}, "date", "19241116"]
["logo", {}, "uri",
"https://upload.wikimedia.org/wikipedia/en/c/c5
/Fleming007impression.jpg"]
] ]
] ]
If that jCard is hosted at the example address of If that jCard is hosted at the example address of
"https://example.org/james_bond.json", the corresponding PASSporT "https://example.com/qbranch.json", the corresponding PASSporT claims
claims object would be as follows (with line breaks for readability object would be as follows:
only):
{ "orig":{"tn":"12025551000"},
"dest":{"tn":["12155551001"]},
"iat":1443208345,
"rcd":{"nam":"James Bond","jcl":"https://example.org/jb.json"}
}
If we were to add a "rcdi" integrity claim to the last example, the
corresponding PASSporT claims object would be as follows (with line
breaks for readability only):
{ "orig":{"tn":"12025551000"}, {
"dest":{"tn":["12155551001"]}, "orig": {"tn": "12025551000"},
"iat":1443208345, "dest": {"tn": ["12155551001"]},
"rcd":{"nam":"James Bond","jcl":"https://example.org/jb.json"} "iat": 1443208345,
"rcdi":"sha256-H8BRh8j48O9oYatfu5AZzq6A9R6dQZngK7T62em8MUt1FLm" "rcd": {
} "nam": "Q Branch Spy Gadgets",
"jcl": "https://example.com/qbranch.json"
},
"crn": "Rendezvous for Little Nellie",
"rcdi": {
"/nam": "sha256-918VNJD12938SNCJ",
"/jcl": "sha256-VNJDSNCJ12938918",
"/jcl/1/3/3": "sha256-12938918VNJDSNCJ",
"/jcl/1/4/3": "sha256-VNJDSNCJ12938918",
"/jcl/1/5/3": "sha256-4049852730SFLGHL"
}
}
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 field. For re-construction of the "jcl", the Call- the From header field. For re-construction of the "jcl", the Call-
Info header as with purpose "jcard" defined in Info header as with purpose "jcard" defined in
[I-D.ietf-sipcore-callinfo-rcd] MUST be used. "jcd" claim MAY NOT be [I-D.ietf-sipcore-callinfo-rcd] MUST be used. "jcd" claim MAY NOT be
used as part of compact form. 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 is not supported, so if
following the same "rcdi" defined digest procedures in this document "rcdi" is required compact form should not be used.
of all of the content and referenced URI content once downloaded.
7.3. Compact form of the "crn" PASSporT claim 7.3. Compact form of the "crn" PASSporT claim
Compact form of a "crn" PASSporT claim shall be re-constructed using Compact form of a "crn" PASSporT claim shall be re-constructed using
the "reason" parameter of a Call-Info header as defined by the "call-reason" parameter of a Call-Info header as defined by
[I-D.ietf-sipcore-callinfo-rcd]. [I-D.ietf-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
skipping to change at page 14, line 40 skipping to change at page 17, line 34
intended to be used in cases when the originating side does not intended to be used in cases when the originating side does not
supply a display-name for the caller, so instead some entity in the supply a display-name for the caller, so instead some entity in the
call path invokes a third-party service to provide rich caller data call path invokes a third-party service to provide rich caller data
for a call. for a call.
In telephone operations today, a third-party information service is In telephone operations today, a third-party information service is
commonly queried with the calling party's number in order to learn commonly queried with the calling party's number in order to learn
the name of the calling party, and potentially other helpful the name of the calling party, and potentially other helpful
information could also be passed over that interface. The value of information could also be passed over that interface. The value of
using a PASSporT to convey this information from third parties lies using a PASSporT to convey this information from third parties lies
largely in the preservation of the original authority's signature largely in the preservation of the third party's signature over the
over the data, and the potential for the PASSporT to be conveyed from data, and the potential for the PASSporT to be conveyed from
intermediaries to endpoint devices. Effectively, these use cases intermediaries to endpoint devices. Effectively, these use cases
form a sub-case of out-of-band [I-D.ietf-stir-oob] use cases. The form a sub-case of out-of-band [I-D.ietf-stir-oob] use cases. The
manner in which third-party services are discovered is outside the manner in which third-party services are discovered is outside the
scope of this document. scope of this document.
An intermediary use case might look as follows: a SIP INVITE carries An intermediary use case might look as follows: a SIP INVITE carries
a display name in its From header field value and an initial PASSporT a display name in its From header field value and an initial PASSporT
object without the "rcd" claim. When the a terminating verification object without the "rcd" claim. When a terminating verification
service implemented at a SIP proxy server receives this request, and service implemented at a SIP proxy server receives this request, and
determines that the signature is valid, it might query a third-party determines that the signature is valid, it might query a third-party
service that maps telephone numbers to calling party names. Upon service that maps telephone numbers to calling party names. Upon
receiving the PASSport in a response from that third-party service, receiving the PASSport in a response from that third-party service,
the terminating side could add a new Identity header field to the the terminating side could add a new Identity header field to the
request for the "rcd" PASSporT object provided by the third-party request for the "rcd" PASSporT object provided by the third-party
service. It would then forward the INVITE to the terminating user service. It would then forward the INVITE to the terminating user
agent. If the display name in the "rcd" PASSporT object matches the agent. If the display name in the "rcd" PASSporT object matches the
display name in the INVITE, then the name would presumably be display name in the INVITE, then the name would presumably be
rendered to the end user by the terminating user agent. rendered to the end user by the terminating user agent.
skipping to change at page 15, line 27 skipping to change at page 18, line 22
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
A third-party PASSporT, which contains such an "iss" element, will A third-party PASSporT contains an "iss" element to distinguish its
necessarily be signed with credentials that do not have authority PASSporTs from first-party PASSporTs. Third-party "rcd" PASSporTs
over the identity that appears in the "orig" element of the PASSporT will necessarily be signed with credentials that do not have
claims. The presence of "iss" signifies that a different category of authority over the identity that appears in the "orig" element of the
credential is being used to sign a PASSporT than the [RFC8226] PASSporT claims. The presence of "iss" signifies that a different
certificates used to sign STIR calls; it is instead a certificate category of credential is being used to sign a PASSporT than the
that identifies the source of the "rcd" data. How those credentials [RFC8226] certificates used to sign STIR calls; it is instead a
are issued and managed is outside the scope of this specification; certificate that identifies the source of the "rcd" data. How those
the value of "iss" however MUST reflect the Subject Name field of the credentials are issued and managed is outside the scope of this
certificate used to sign a third-party PASSporT. Relying parties in specification; the value of "iss" however MUST reflect the Subject
STIR have always been left to make their own authorization decisions Name field of the certificate used to sign a third-party PASSporT.
about whether or not the trust the signers of PASSporTs, and in the Relying parties in STIR have always been left to make their own
third-party case, where an entity has explicitly queried a service to authorization decisions about whether to trust the signers of
acquire the PASSporT object, it may be some external trust or PASSporTs, and in the third-party case, where an entity has
business relationship that induces the relying party to trust a explicitly queried a service to acquire the PASSporT object, it may
PASSporT. 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 16, line 23 skipping to change at page 19, line 23
an enterprise, in which case the CSP might have little insight into an enterprise, in which case the CSP might have little insight into
the caller's name. In third party cases, a caller's name could the caller's name. In third party cases, a caller's name could
derive from any number of data sources, on a spectrum between public derive from any number of data sources, on a spectrum between public
data scraped from web searches to a direct business relationship to data scraped from web searches to a direct business relationship to
the caller. As multiple PASSporTs can be associated with the same the caller. As multiple PASSporTs can be associated with the same
call, potentially a verification service could receive attestations call, potentially a verification service could receive attestations
of the caller name from multiple sources, which have different levels of the caller name from multiple sources, which have different levels
of granularity or accuracy. Therefore, PASSporTs that carry "rcd" of granularity or accuracy. Therefore, PASSporTs that carry "rcd"
data SHOULD also carry an indication of the relationship of the data SHOULD also carry an indication of the relationship of the
generator of the PASSporT to the caller. As stated in the previous generator of the PASSporT to the caller. As stated in the previous
section, the use of "iss" MUST reflect the Organization (O) field of section, the use of "iss" MUST reflect the Subject Name of the
the certificate used to sign a third-party PASSporT to represent that certificate used to sign a third-party PASSporT to represent that
relationship. relationship.
11. Using "rcd" in SIP 11. Using "rcd" in SIP
This section specifies SIP-specific usage for the "rcd" claim in This section specifies SIP-specific usage for the "rcd" claim in
PASSporT, and in the SIP Identity header field value. Other using PASSporT, and in the SIP Identity header field value. Other using
protocols of PASSporT may define their own usages for the "rcd" protocols of PASSporT may define their own usages for the "rcd"
claim. claim.
11.1. Authentication Service Behavior 11.1. Authentication Service Behavior
skipping to change at page 18, line 39 skipping to change at page 21, line 39
security properties defined in [RFC8225]. For cases where the entity security properties defined in [RFC8225]. For cases where the entity
that is originating the personal communications and additionally is that is originating the personal communications and additionally is
supporting the authentication service and also is the authority of supporting the authentication service and also is the authority of
the Rich Call Data, rather than creating multiple identity headers the Rich Call Data, rather than creating multiple identity headers
with multiple PASSporT extensions or defining multiple combinations with multiple PASSporT extensions or defining multiple combinations
and permutations of PASSporT extension definitions, the and permutations of PASSporT extension definitions, the
authentication service can alternatively directly add the "rcd" authentication service can alternatively directly add the "rcd"
claims to the PASSporT it is creating, whether it is constructed with claims to the PASSporT it is creating, whether it is constructed with
a PASSporT extension or not. a PASSporT extension or not.
Note: There is one very important caveat to this capability, because
generally if there is URI referenced content in an "rcd" PASSporT
there is often the requirement to use "rcdi" and JWT Claims
Constraints. So, it is important for the user of this specification
to recognize that the certificates used must include the necessary
JWT Claims Constraints for proper integrity and security of the
values in the "rcd" claim incorporated into PASSporTs that are not
"rcd".
12.1. Procedures for applying "rcd" as claims only 12.1. Procedures for applying "rcd" as claims only
For a given PASSporT using some other extension than "rcd", the For a given PASSporT using some other extension than "rcd", the
Authentication Service MAY additionally include the "rcd" claim as Authentication Service MAY additionally include the "rcd" claim as
defined in this document. This would result in a set of claims that defined in this document. This would result in a set of claims that
correspond to the original intended extension with the addition of correspond to the original intended extension with the addition of
the "rcd" claim. the "rcd" claim.
The Verification service that receives the PASSporT, if it supports The Verification service that receives the PASSporT, if it supports
this specification and chooses to, should interpret the "rcd" claim this specification and chooses to, should interpret the "rcd" claim
skipping to change at page 19, line 46 skipping to change at page 23, line 12
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 David Hancock, Robert Sparks, Russ Housley, We would like to thank David Hancock, Robert Sparks, Russ Housley,
and Eric Burger for helpful suggestions and comments. Eric Burger, and Alec Fenichel 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 three 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
skipping to change at page 21, line 16 skipping to change at page 24, line 25
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.
15.1. The use of JWT Claim Constraints in delegate certificates to
exclude unauthorized Claims
While this can apply to any PASSporT that is signed with a STIR
Delegate Certificates [I-D.ietf-stir-cert-delegation], it is
important to note that when constraining PASSporTs to include
specific claims or contents of claims, it is also important to
consider potential attacks by non-authorized signers that may include
other potential PASSporT claims that weren't originally vetted by the
authorized entity providing the delegate certificate. The use of JWT
claims constraints as defined in [I-D.housley-stir-enhance-rfc8226]
for preventing the ability to include claims beyond the claims
defined in this document may need to be considered.
16. References 16. References
16.1. Normative References 16.1. Normative References
[I-D.housley-stir-enhance-rfc8226]
Housley, R., "Enhanced JWT Claim Constraints for STIR
Certificates", draft-housley-stir-enhance-rfc8226-00 (work
in progress), January 2021.
[I-D.ietf-sipcore-callinfo-rcd] [I-D.ietf-sipcore-callinfo-rcd]
Wendt, C. and J. Peterson, "SIP Call-Info Parameters for Wendt, C. and J. Peterson, "SIP Call-Info Parameters for
Rich Call Data", draft-ietf-sipcore-callinfo-rcd-00 (work Rich Call Data", draft-ietf-sipcore-callinfo-rcd-01 (work
in progress), November 2020. in progress), November 2020.
[I-D.ietf-stir-oob] [I-D.ietf-stir-cert-delegation]
Rescorla, E. and J. Peterson, "STIR Out-of-Band Peterson, J., "STIR Certificate Delegation", draft-ietf-
Architecture and Use Cases", draft-ietf-stir-oob-07 (work stir-cert-delegation-03 (work in progress), July 2020.
in progress), March 2020.
[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>.
[RFC4627] Crockford, D., "The application/json Media Type for [RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, JavaScript Object Notation (JSON)", RFC 4627,
DOI 10.17487/RFC4627, July 2006, DOI 10.17487/RFC4627, July 2006,
<https://www.rfc-editor.org/info/rfc4627>. <https://www.rfc-editor.org/info/rfc4627>.
[RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed.,
"JavaScript Object Notation (JSON) Pointer", RFC 6901,
DOI 10.17487/RFC6901, April 2013,
<https://www.rfc-editor.org/info/rfc6901>.
[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,
<https://www.rfc-editor.org/info/rfc6919>. <https://www.rfc-editor.org/info/rfc6919>.
[RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095,
DOI 10.17487/RFC7095, January 2014, DOI 10.17487/RFC7095, January 2014,
<https://www.rfc-editor.org/info/rfc7095>. <https://www.rfc-editor.org/info/rfc7095>.
[RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure
skipping to change at page 22, line 43 skipping to change at page 26, line 24
<https://www.rfc-editor.org/info/rfc8588>. <https://www.rfc-editor.org/info/rfc8588>.
16.2. Informative References 16.2. Informative References
[ATIS-1000074] [ATIS-1000074]
ATIS/SIP Forum NNI Task Group, "Signature-based Handling ATIS/SIP Forum NNI Task Group, "Signature-based Handling
of Asserted information using toKENs (SHAKEN) of Asserted information using toKENs (SHAKEN)
<https://access.atis.org/apps/group_public/ <https://access.atis.org/apps/group_public/
download.php/32237/ATIS-1000074.pdf>", January 2017. download.php/32237/ATIS-1000074.pdf>", January 2017.
[I-D.ietf-stir-oob]
Rescorla, E. and J. Peterson, "STIR Out-of-Band
Architecture and Use Cases", draft-ietf-stir-oob-07 (work
in progress), March 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
Authors' Addresses Authors' Addresses
Jon Peterson
Neustar Inc.
1800 Sutter St Suite 570
Concord, CA 94520
US
Email: jon.peterson@neustar.biz
Chris Wendt Chris Wendt
Comcast Comcast
Comcast Technology Center Comcast Technology Center
Philadelphia, PA 19103 Philadelphia, PA 19103
USA USA
Email: chris-ietf@chriswendt.net Email: chris-ietf@chriswendt.net
Jon Peterson
Neustar Inc.
1800 Sutter St Suite 570
Concord, CA 94520
US
Email: jon.peterson@neustar.biz
 End of changes. 70 change blocks. 
301 lines changed or deleted 477 lines changed or added

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