draft-ietf-stir-passport-rcd-12.txt   draft-ietf-stir-passport-rcd-13.txt 
Network Working Group C. Wendt Network Working Group C. Wendt
Internet-Draft Comcast Internet-Draft Comcast
Intended status: Standards Track J. Peterson Intended status: Standards Track J. Peterson
Expires: January 13, 2022 Neustar Inc. Expires: 13 March 2022 Neustar Inc.
July 12, 2021 9 September 2021
PASSporT Extension for Rich Call Data PASSporT Extension for Rich Call Data
draft-ietf-stir-passport-rcd-12 draft-ietf-stir-passport-rcd-13
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 the intended called party. This framework subsequently rendered to the called party. This framework is
is intended to include and extend caller and call specific intended to include and extend caller and call specific information
information beyond human-readable display name comparable to the beyond human-readable display name comparable to the "Caller ID"
"Caller ID" function common on the telephone network. The JSON function common on the telephone network. The JSON element defined
element defined for this purpose, Rich Call Data (RCD), is an for this purpose, Rich Call Data (RCD), is an extensible object
extensible object defined to either be used as part of STIR or with defined to either be used as part of STIR or with SIP Call-Info to
SIP Call-Info to include related information about calls that helps include related information about calls that helps people decide
people decide whether to pick up the phone. This signing of the RCD whether to pick up the phone. This signing of the RCD information is
information is also enhanced with a integrity mechanism that is also enhanced with a integrity mechanism that is designed to protect
designed to protect the authoring and transport of this information the authoring and transport of this information between authoritative
between authoritative and non-authoritative parties generating and and non-authoritative parties generating and signing the Rich Call
signing the Rich Call Data for support of different usage and content Data for support of different usage and content policies.
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 January 13, 2022. This Internet-Draft will expire on 13 March 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 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/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as 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 Claim "rcd" Defintion and Usage . . . . . . . . . . 6 5. PASSporT Claim "rcd" Defintion and Usage . . . . . . . . . . 7
5.1. PASSporT "rcd" Claim . . . . . . . . . . . . . . . . . . 6 5.1. PASSporT "rcd" Claim . . . . . . . . . . . . . . . . . . 7
5.1.1. "nam" key . . . . . . . . . . . . . . . . . . . . . . 7 5.1.1. "nam" key . . . . . . . . . . . . . . . . . . . . . . 7
5.1.2. "jcd" key . . . . . . . . . . . . . . . . . . . . . . 7 5.1.2. "apn" key . . . . . . . . . . . . . . . . . . . . . . 7
5.1.3. "jcl" key . . . . . . . . . . . . . . . . . . . . . . 7 5.1.3. "jcd" key . . . . . . . . . . . . . . . . . . . . . . 8
6. "rcdi" RCD Integrity Claim Definition and Usage . . . . . . . 8 5.1.4. "jcl" key . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Creation of the "rcd" element digests . . . . . . . . . . 9 6. "rcdi" RCD Integrity Claim Definition and Usage . . . . . . . 9
6.2. JWT Claim Constraint for "rcd" claims only . . . . . . . 12 6.1. Creation of the "rcd" element digests . . . . . . . . . . 10
7. JWT Claim Constraint usage for "rcd" and "rcdi" claims . . . 12 6.2. JWT Claim Constraint for "rcd" claims only . . . . . . . 13
8. PASSporT "crn" claim - Call Reason Defintion and Usage . . . 13 7. JWT Claim Constraint usage for "rcd" and "rcdi" claims . . . 13
8.1. JWT Constraint for "crn" claim . . . . . . . . . . . . . 13 8. PASSporT "crn" claim - Call Reason Defintion and Usage . . . 14
9. Rich Call Data Claims Usage Rules . . . . . . . . . . . . . . 13 8.1. JWT Constraint for "crn" claim . . . . . . . . . . . . . 14
9.1. Example "rcd" PASSporTs . . . . . . . . . . . . . . . . . 14 9. Rich Call Data Claims Usage Rules . . . . . . . . . . . . . . 15
10. Compact form of "rcd" PASSporT . . . . . . . . . . . . . . . 16 9.1. Verification rules . . . . . . . . . . . . . . . . . . . 15
10.1. Compact form of the "rcd" PASSporT claim . . . . . . . . 16 9.2. Example "rcd" PASSporTs . . . . . . . . . . . . . . . . . 15
10.2. Compact form of the "rcdi" PASSporT claim . . . . . . . 16 10. Compact form of "rcd" PASSporT . . . . . . . . . . . . . . . 17
10.3. Compact form of the "crn" PASSporT claim . . . . . . . . 16 10.1. Compact form of the "rcd" PASSporT claim . . . . . . . . 18
11. Further Information Associated with Callers . . . . . . . . . 16 10.2. Compact form of the "rcdi" PASSporT claim . . . . . . . 18
12. Third-Party Uses . . . . . . . . . . . . . . . . . . . . . . 17 10.3. Compact form of the "crn" PASSporT claim . . . . . . . . 18
12.1. Signing as a Third Party . . . . . . . . . . . . . . . . 19 11. Further Information Associated with Callers . . . . . . . . . 18
13. Levels of Assurance . . . . . . . . . . . . . . . . . . . . . 19 12. Third-Party Uses . . . . . . . . . . . . . . . . . . . . . . 19
14. Using "rcd" in SIP . . . . . . . . . . . . . . . . . . . . . 20 12.1. Signing as a Third Party . . . . . . . . . . . . . . . . 20
14.1. Authentication Service Behavior . . . . . . . . . . . . 20 13. Levels of Assurance . . . . . . . . . . . . . . . . . . . . . 21
14.2. Verification Service Behavior . . . . . . . . . . . . . 21 14. Using "rcd" in SIP . . . . . . . . . . . . . . . . . . . . . 21
15. Using "rcd" as additional claims to other PASSporT extensions 22 14.1. Authentication Service Behavior . . . . . . . . . . . . 22
15.1. Procedures for applying "rcd" as claims only . . . . . . 22 14.2. Verification Service Behavior . . . . . . . . . . . . . 22
15.2. Example for applying "rcd" as claims only . . . . . . . 23
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 15. Using "rcd" as additional claims to other PASSporT
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 extensions . . . . . . . . . . . . . . . . . . . . . . . 23
17.1. JSON Web Token Claim . . . . . . . . . . . . . . . . . . 24 15.1. Procedures for applying "rcd" as claims only . . . . . . 24
17.2. PASSporT Types . . . . . . . . . . . . . . . . . . . . . 24 15.2. Example for applying "rcd" as claims only . . . . . . . 24
17.3. PASSporT RCD Types . . . . . . . . . . . . . . . . . . . 24 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
18. Security Considerations . . . . . . . . . . . . . . . . . . . 25 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
18.1. The use of JWT Claim Constraints in delegate 17.1. JSON Web Token Claim . . . . . . . . . . . . . . . . . . 25
certificates to exclude unauthorized claims . . . . . . 25 17.2. PASSporT Types . . . . . . . . . . . . . . . . . . . . . 26
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 17.3. PASSporT RCD Types . . . . . . . . . . . . . . . . . . . 26
19.1. Normative References . . . . . . . . . . . . . . . . . . 25 18. Security Considerations . . . . . . . . . . . . . . . . . . . 26
19.2. Informative References . . . . . . . . . . . . . . . . . 27 18.1. The use of JWT Claim Constraints in delegate certificates
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 to exclude unauthorized claims . . . . . . . . . . . . . 27
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
19.1. Normative References . . . . . . . . . . . . . . . . . . 27
19.2. Informative References . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
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 parties 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
skipping to change at page 4, line 20 skipping to change at page 4, line 33
furthermore specifies a third-party profile that would allow external furthermore specifies a third-party profile that would allow external
authorities to convey rich information associated with a calling authorities to convey rich information associated with a calling
number via a new type of PASSporT. Finally, this document describes number via a new type of PASSporT. Finally, this document describes
how to preserve the integrity of the RCD in scenarios where there may how to preserve the integrity of the RCD in scenarios where there may
be non-authoritative users initiating and signing RCD and therefore a be non-authoritative users initiating and signing RCD and therefore a
constraint on the RCD data that a PASSporT can attest via constraint on the RCD data that a PASSporT can attest via
certificate-level controls. certificate-level controls.
2. Terminology 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as "OPTIONAL" in this document are to be interpreted as described in BCP
described in [RFC2119] and [RFC6919]. 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
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 for the STIR [RFC8224] and as a PASSporT extension [RFC8225] is for the
entity that originates a call, either directly the caller themselves, entity that originates a call, either directly the caller themselves,
if they are authoritative, or a service provider or third-party if they are authoritative, or a service provider or third-party
service that may be authoritative over the rich call data on behalf service that may be authoritative over the rich call data on behalf
of the caller. of the caller.
skipping to change at page 5, line 12 skipping to change at page 5, line 25
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.
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, preventing offensive language or icons or enforcing uniqueness,
potential trademark violations or other policy enforcement, there potential trademark violations or other policy enforcement, there
should be the desire to pre-certify or "vet" the specific use of rich might be the desire to pre-certify or "vet" the specific use of rich
call data. This document defines a mechanism that allows for a call data. This document defines a mechanism that allows for a
direct or indirect party that controls the policy to approve or direct or indirect party that controls the policy to approve or
certify the content, create a cryptographic digest that can be used certify the content, create a cryptographic digest that can be used
to validate that data and applies a constraint in the certificate to to validate that data and applies a constraint in the certificate to
allow the recipient and verifier to validate that the specific allow the recipient and verifier to validate that the specific
content of the RCD is as intended at its creation and approval or content of the RCD is as intended at its creation and approval or
certification. certification.
There are two mechanisms that are defined to accomplish that for two There are two mechanisms that are defined to accomplish that for two
distinct categories of purposes. The first of the mechanisms include distinct categories of purposes. The first of the mechanisms include
the definition of an integrity claim. The RCD integrity mechanism is the definition of an integrity claim. The RCD integrity mechanism is
a process of generating a sufficiently strong cryptographic digest a process of generating a sufficiently strong cryptographic digest
for both the "rcd" claim contents (e.g. "nam", "jcd", "jcl") defined for both the "rcd" claim contents (e.g. "nam", "jcd", "jcl") defined
below and the resources defined by one or more globally unique HTTPS below and the resources defined by one or more globally unique HTTPS
URLs referenced by the contents (e.g. an image file referenced by URLs referenced by the contents (e.g. an image file referenced by
"jcd" or a jCard referenced by "jcl"). This mechanism is inspired by "jcd" or a jCard referenced by "jcl"). This mechanism is inspired by
and based on the W3C Subresource Integrity specification and based on the W3C Subresource Integrity specification
(http://www.w3.org/TR/SRI/). The second of the mechanisms uses the (http://www.w3.org/TR/SRI/). The second of the mechanisms uses the
capability called JWT Claim Constraints, defined in [RFC8226] and capability called JWT Claim Constraints, defined in [RFC8226] and
extended in [I-D.housley-stir-enhance-rfc8226]. The JWT Claim extended in [I-D.ietf-stir-enhance-rfc8226]. The JWT Claim
Constraints specifically guide the verifier within the certificate Constraints specifically guide the verifier within the certificate
used to sign the PASSporT for the inclusion (or exclusion) of used to sign the PASSporT for the inclusion (or exclusion) of
specific claims and their values, so that the content intended by the specific claims and their values, so that the content intended by the
signer can be verified to be accurate. signer can be verified to be accurate.
Both of these mechanisms, integrity digests and JWT Claims Both of these mechanisms, integrity digests and JWT Claims
Constraints, can be used together or separately depending on the Constraints, can be used together or separately depending on the
intended purpose. The first category of purpose is whether the rich 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- 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 reference; i.e., is the information contained in the passport claims
skipping to change at page 7, line 12 skipping to change at page 7, line 24
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 alternatively from the P-Asserted-Identity header field request or alternatively from the P-Asserted-Identity header field
value, or a similar field in other PASSporT using protocols. This value, or a similar field in other PASSporT using protocols. This
key MUST be included once and MUST be included as part of the "rcd" key MUST be included once and be included as part of the "rcd" claim
claim value JSON object. If there is no string associated with a value JSON object. If there is no string associated with a display
display name, the claim value SHOULD then be an empty string. name, the claim value SHOULD then be an empty string.
5.1.2. "jcd" key 5.1.2. "apn" key
The "apn" key value is an optional alternate presentation number
associated with the originator of personal communications, which may
for example derive from the user component of the From header field
value of a SIP request (in cases where a network number is carried in
the P-Asserted-Identity), or alternatively from the Additional-
Identity header field value, or a similar field in other PASSporT
using protocols. Its intended semantics are to convey a number that
the originating user is authorized to show to called parties in lieu
of their default number, such as cases where a remote call agent uses
the main number of a call center instead of their personal telephone
number. The "apn" key value is a canonicalized telephone number per
[RFC8224] Section 8.3. If present, this key MUST be included once
and MUST be included as part of the "rcd" claim value JSON object.
The use of the optional "apn" key is intended for cases where the
signers of an rcd PASSporT authorizes the use of an alternate
presentation number by the user. How the signer determines that a
user is authorized to present the number in question is a policy
decision outside the scope of this document. This usage is intended
as an optimization for cases where a presentation number might be
placed in the "tel" key value of a jCard, in situations where no
other rich jCard data needs to be conveyed with the call. Only one
"apn" key may be present. "apn" MUST NOT be used when a "jcd" or
"jcl" keys are present in a PASSporT; in those cases, any alternate
presentation number will appear in the "tel" key value.
5.1.3. "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 represent [RFC7095] JSON object. This jCard object is intended to represent
and derives from the Call-Info header field value defined in and derives 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. It is an extensible object where the calling rules and procedures. It is an extensible object where the calling
party can provide both the standard types of information defined in party can provide both the standard types of information defined in
jCard or can use the built-in extensibility of the jCard jCard or can use the built-in extensibility of the jCard
skipping to change at page 7, line 44 skipping to change at page 8, line 36
specifications may extend this capability, but as stated in specifications may extend this capability, but as stated in
[I-D.ietf-sipcore-callinfo-rcd] it constrains the security properties [I-D.ietf-sipcore-callinfo-rcd] it constrains the security properties
of RCD information and the integrity of the content referenced by of RCD information and the integrity of the content referenced by
URIs. URIs.
Note: even though we refer to [I-D.ietf-sipcore-callinfo-rcd] as the Note: even though we refer to [I-D.ietf-sipcore-callinfo-rcd] as the
definition of the jcard properties for usage in a "rcd" PASSporT, definition of the jcard properties for usage in a "rcd" PASSporT,
other protocols can be adapted for use of "jcd" (or similarly "jcl" other protocols can be adapted for use of "jcd" (or similarly "jcl"
below) key beyond SIP and Call-Info. below) key beyond SIP and Call-Info.
5.1.3. "jcl" key 5.1.4. "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. The web server MUST use the MIME media type for JSON web server. The web server MUST use the MIME media type for JSON
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 use of "jcd" and be included if there is a "jcd" key included. The use of "jcd" and
"jcl" keys are mutually exclusive. "jcl" keys are mutually exclusive.
The jCard object value referenced in the URI value for "jcl" MUST The jCard object referenced by the URI value for "jcl" MUST NOT
only have referenced content for URI values that do not further contain any further referenced content (i.e. URIs as values in the
reference URIs. Future specifications may extend this capability, referenced jCard object). Future specifications may extend this
but as stated in [I-D.ietf-sipcore-callinfo-rcd] it constrains the capability, but as stated in [I-D.ietf-sipcore-callinfo-rcd] it
security properties of RCD information and the integrity of the constrains the security properties of RCD information and the
content referenced by URIs. integrity of the content referenced by URIs.
6. "rcdi" RCD Integrity Claim Definition and Usage 6. "rcdi" RCD Integrity Claim Definition and Usage
The "rcdi" claim is included for the second and fourth modes The "rcdi" claim is included for the second and fourth modes
described in integrity overview section of this document. If this described in integrity overview section of this document. If this
claim is present it MUST be only included once with the corresponding claim is present it MUST be only included once with the corresponding
single "rcd" claim. The value of the "rcdi" key pair is a JSON single "rcd" claim. The value of the "rcdi" key pair is a JSON
object that is defined as follows. object that is defined as follows.
The claim value of "rcdi" claim key is a JSON object with a set of The claim value of "rcdi" claim key is a JSON object with a set of
skipping to change at page 8, line 46 skipping to change at page 9, line 41
value using a JSON pointer defined in [RFC6901] with a minor value using a JSON pointer defined in [RFC6901] with a minor
additional rule to support external URI references that include JSON additional rule to support external URI references that include JSON
objects themselves, in particular for the specific case of the use of objects themselves, in particular for the specific case of the use of
"jcl". JSON pointer syntax is the key value that specifies exactly "jcl". JSON pointer syntax is the key value that specifies exactly
the part of JSON that is used to generate the digest which produce the part of JSON that is used to generate the digest which produce
the resulting string that makes up the value for the corresponding the resulting string that makes up the value for the corresponding
key. Detailed procedures are provided below, but an example "rcdi" key. Detailed procedures are provided below, but an example "rcdi"
is provided here: is provided here:
"rcdi" : { "rcdi" : {
"/jcd": "sha256-H8BRh8j48O9oAZzq6A9RINQZngK7T62em8MUt1FLm52", "/jcd": "sha256-7kdCBZqH0nqMSPsmABvsKlHPhZEStgjojhdSJGRr3rk",
"/jcd/1/2/3": "sha256-AZzq6A9RINQZngK7T62em8MUt1FLm52H8BRh8j48O9o" "/jcd/1/2/3": "sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI"
} }
The values of each key pair are a digest combined with a string that The values of each key pair are a digest combined with a string that
defines the crypto algorithm used to generate the digest. For RCD, defines the crypto algorithm used to generate the digest. For RCD,
implementations MUST support the following hash algorithms, "SHA256", implementations MUST support the following hash algorithms, "SHA256",
"SHA384", or "SHA512". The SHA-256, SHA-384, and SHA-512 are part of "SHA384", and "SHA512". The SHA-256, SHA-384, and SHA-512 are part
the SHA-2 set of cryptographic hash functions defined by the NIST. of the SHA-2 set of cryptographic hash functions defined by the NIST.
Implementations MAY support additional algorithms, but MUST NOT Implementations MAY support additional algorithms, but MUST NOT
support known weak algorithms such as MD5 or SHA-1. In the future, support known weak algorithms such as MD5 or SHA-1. In the future,
the list of algorithms may be re-evaluated based on security best the list of algorithms may be re-evaluated based on security best
practices. The algorithms are represented in the text by "sha256", practices. The algorithms are represented in the text by "sha256",
"sha384", or "sha512". The character following the algorithm string "sha384", or "sha512". The character following the algorithm string
MUST be a minus character, "-". The subsequent characters are the MUST be a minus character, "-". The subsequent characters are the
base64 encoded digest of a canonicalized and concatenated string base64 encoded [RFC4648] digest of a canonicalized and concatenated
based on the JSON pointer referenced elements of "rcd" claim or the string or binary data based on the JSON pointer referenced elements
URI referenced content contained in the claim. The details of the of "rcd" claim or the URI referenced content contained in the claim.
determination of the input string used to determine the digest are The details of the determination of the input string used to
defined in the next section. determine the digest are defined in the next section.
6.1. Creation of the "rcd" element digests 6.1. Creation of the "rcd" element digests
"rcd" claim objects can contain "nam", "jcd", or "jcl" keys as part "rcd" claim objects can contain "nam", "apn", "jcd", or "jcl" keys as
of the "rcd" JSON object claim value. This specification defines the part of the "rcd" JSON object claim value. This specification
use of JSON pointer [RFC6901] as a basic to reference specific defines the use of JSON pointer [RFC6901] as a basic to reference
elements. specific elements.
In the case of "nam", the only allowed value is a "string". In order In the case of "nam", the only allowed value is a "string". In order
to reference the "nam" string value for a digest, the JSON pointer to reference the "nam" string value for a digest, the JSON pointer
string would be "/nam" and the digest string would be created using 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 only the string pointed to by that "/nam" following the rules of JSON
pointer. pointer.
In the case of "apn", the only allowed value is a "string". In order
to reference the "apn" string value for a digest, the JSON pointer
string would be "/apn" and the digest string would be created using
only the string pointed to by that "/apn" following the rules of JSON
pointer.
In the case of "jcd", the value associated is a jCard JSON object, In the case of "jcd", the value associated is a jCard JSON object,
which happens to be a JSON array with sub-arrays. JSON pointer which happens to be a JSON array with sub-arrays. JSON pointer
notation uses numeric indexes into elements of arrays, including when notation uses numeric indexes into elements of arrays, including when
those elements are arrays themselves. those elements are arrays themselves.
As example, for the following "rcd" claim: As example, for the following "rcd" claim:
"rcd": { "rcd": {
"nam": "Q Branch Spy Gadgets", "nam": "Q Branch Spy Gadgets",
"jcd": ["vcard", "jcd": ["vcard",
[ ["version",{},"text","4.0"], [ ["version",{},"text","4.0"],
["fn",{},"text","Q Branch"], [“fn",{},"text","Q Branch"],
["org",{},"text","MI6;Q Branch Spy Gadgets"], [“org",{},"text","MI6;Q Branch Spy Gadgets"],
["photo",{},"uri", ["photo",{},"uri",
"https://example.com/photos/quartermaster-256x256.png"], "https://example.com/photos/quartermaster-256x256.png"],
["logo",{},"uri", ["logo",{},"uri",
"https://example.com/logos/mi6-256x256.jpg"], "https://example.com/logos/mi6-256x256.jpg"],
["logo",{},"uri", ["logo",{},"uri",
"https://example.com/logos/mi6-64x64.jpg"] "https://example.com/logos/mi6-64x64.jpg"]
] ]
] ]
} }
In order to use JSON pointer to refer to the URIs, the following In order to use JSON pointer to refer to the URIs, the following
example "rcdi" claim includes a digest for the entire "jcd" array example "rcdi" claim includes a digest for the entire "jcd" array
string as well as three additional digests for the URIs, where, as string as well as three additional digests for the URIs, where, as
defined in [RFC6901] zero-based array indexes are used to reference defined in [RFC6901] zero-based array indexes are used to reference
the URI strings. the URI strings.
"rcdi": { "rcdi": {
"/jcd": "sha256-30SFLGHL40498527", "/jcd": "sha256-7kdCBZqH0nqMSPsmABvsKlHPhZEStgjojhdSJGRr3rk",
"/jcd/1/3/3": "sha256-12938918VNJDSNCJ", "/jcd/1/3/3": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4",
"/jcd/1/4/3": "sha256-VNJDSNCJ12938918", "/jcd/1/4/3": "sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI",
"/jcd/1/5/3": "sha256-4049852730SFLGHL" "/jcd/1/5/3": "sha256-GKNxxqlLRarbyBNh7hc/4lbZAdK6B0kMRf1AMRWPkSo"
} }
} }
For the use of JSON pointer in "jcd" and because array indexes are For the use of JSON pointer in "jcd" and because array indexes are
dependent on the order of the elements in the jCard, the digest for dependent on the order of the elements in the jCard, the digest for
the "/jcd" corresponding to the entire jCard array string MUST be the "/jcd" corresponding to the entire jCard array string MUST be
included to avoid any possibility of substitution or insertion included to avoid any possibility of substitution or insertion
attacks that may be possible to avoid integrity detection, even attacks that may be possible to avoid integrity detection. Each URI
though unlikely. Each URI referenced in the jCard array string MUST referenced in the jCard array string MUST have a corresponding JSON
have a corresponding JSON pointer string key and digest value. pointer string key and digest value.
In the case of the use of a "jcl" URI reference to an external jCard, In the case of the use of a "jcl" URI reference to an external jCard,
the procedures are similar to "jcd" with the exception and the minor the procedures are similar to "jcd" with the exception and the minor
modification to JSON pointer, where "/jcl" is used to refer to the modification to JSON pointer, where "/jcl" is used to refer to the
external jCard array string and any following numeric array indexes 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 added to the "jcl" (e.g. "/jcl/1/2/3") are treated as if the
externally referenced jCard was directly part of the overall "rcd" externally referenced jCard was directly part of the overall "rcd"
claim JSON object. The following example illustrates a "jcl" version claim JSON object. The following example illustrates a "jcl" version
of the above "jcd" example. of the above "jcd" example.
"rcd": { "rcd": {
"nam": "Q Branch Spy Gadgets", "nam": "Q Branch Spy Gadgets",
"jcl": "https://example.com/qbranch.json" "jcl": "https://example.com/qbranch.json"
}, },
"rcdi": { "rcdi": {
"/jcl": "sha256-30SFLGHL40498527", "/jcl": "sha256-Gb0lOkj7Z9+plqbOkN32H+YX0Yav3fbioSk7DxQdGZU",
"/jcl/1/3/3": "sha256-12938918VNJDSNCJ", "/jcl/1/3/3": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4",
"/jcl/1/4/3": "sha256-VNJDSNCJ12938918", "/jcl/1/4/3": "sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI",
"/jcl/1/5/3": "sha256-4049852730SFLGHL" "/jcl/1/5/3": "sha256-GKNxxqlLRarbyBNh7hc/4lbZAdK6B0kMRf1AMRWPkSo"
} }
https://example.com/qbranch.json: https://example.com/qbranch.json:
["vcard", ["vcard",
[ ["version",{},"text","4.0"], [ ["version",{},"text","4.0"],
["fn",{},"text","Q Branch"], [“fn",{},"text","Q Branch"],
["org",{},"text","MI6;Q Branch Spy Gadgets"] [“org",{},"text","MI6;Q Branch Spy Gadgets"]
["photo",{},"uri", ["photo",{},"uri",
"https://example.com/photos/quartermaster-256x256.png"] "https://example.com/photos/quartermaster-256x256.png"]
["logo",{},"uri", ["logo",{},"uri",
"https://example.com/logos/mi6-256x256.jpg"] "https://example.com/logos/mi6-256x256.jpg"]
["logo",{},"uri", ["logo",{},"uri",
"https://example.com/logos/mi6-64x64.jpg"] "https://example.com/logos/mi6-64x64.jpg"]
] ]
] ]
In order to facilitate proper verification of the digests and whether In order to facilitate proper verification of the digests and whether
skipping to change at page 12, line 5 skipping to change at page 13, line 4
The procedure for the creation of each "rcd" element digest string The procedure for the creation of each "rcd" element digest string
corresponding to a JSON pointer string key is as follows. corresponding to a JSON pointer string key is as follows.
1. The JSON pointer either refers to an element that is a part or 1. The JSON pointer either refers to an element that is a part or
whole of a JSON object string or to a string that is a URI whole of a JSON object string or to a string that is a URI
referencing an external resource. referencing an external resource.
2. For a JSON formatted string, serialize the element JSON to remove 2. For a JSON formatted string, serialize the element JSON 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 are defined in [RFC8225], deterministic JSON serialization are defined in [RFC8225],
Section 9. The resulting string is used to create the digest. Section 9. The resulting string MUST be a Base64 encoded
[RFC4648] digest string (for sha256 this should result in
approximately 44 characters).
3. For any URI referenced content, the content can either be a 3. For any URI referenced content, the content can either be a
string as in jCard JSON objects or binary content. For example, string as in jCard JSON objects or binary content. For example,
image and audio files contain binary content. If the content is image and audio files contain binary content. If the URI
binary format it should be Base64 encoded to create a string, referenced content is JSON formatted, follow the procedures
otherwise the direct string content of the file is used to create defined in list item 2 above. Either the binary data or string
the digest. content of the file is used to create a resulting string which
MUST be a Base64 encoded [RFC4648] digest string (for sha256 this
should result in approximately 44 characters).
6.2. JWT Claim Constraint for "rcd" claims only 6.2. JWT Claim Constraint for "rcd" claims only
For the third mode described in the integrity overview section of For the third mode described in the integrity overview section of
this document, where only JWT Claim Constraint for "rcd" claims this document, where only JWT Claim Constraint for "rcd" claims
without an "rcdi" claim is required, the procedure should be, when without an "rcdi" claim is required, the procedure should be, when
creating the certificate, to include a JWT Claim Constraint on creating the certificate, to include a JWT Claim Constraint on
inclusion of an "rcd" claim as well as the contents of the certified inclusion of an "rcd" claim with the intended values required to be
"rcd" claim. constrained by the certificate used to sign the PASSporT.
The certificate JWT Claims Constraint MUST include the following: The certificate JWT Claims Constraint MUST include the following:
o a "mustInclude" for the "rcd" claim and a "permittedValues" equal * a "mustInclude" for the "rcd" claim and a "permittedValues" equal
to the created "rcd" claim value string. to the created "rcd" claim value string.
The "permitedValues" for the "rcd" claim may optionally contain The "permitedValues" for the "rcd" claim may optionally contain
multiple entries, to support the case where the certificate holder is multiple 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.
7. JWT Claim Constraint usage for "rcd" and "rcdi" claims 7. JWT Claim Constraint usage for "rcd" and "rcdi" claims
The integrity overview section of this document describes a fourth The integrity overview section of this document describes a fourth
mode where both "rcdi" and JWT Claim Constraints is used. The use of mode where both "rcdi" and JWT Claim Constraints is used. The use of
skipping to change at page 13, line 5 skipping to change at page 14, line 8
authoritative for the certificate being created and the construction authoritative for the certificate being created and the construction
of the "rcdi" claim is complete, the "rcdi" claim is linked to the of the "rcdi" claim is complete, the "rcdi" claim is linked to the
STIR certificate associated with the signature in the PASSporT via STIR certificate associated with the signature in the PASSporT via
JWT Claim Constraints as defined in [RFC8226] Section 8. It should JWT Claim Constraints as defined in [RFC8226] Section 8. It should
be recognized that the "rcdi" set of digests is intended to be unique be recognized that the "rcdi" set of digests is intended to be unique
for only a specific combination of "rcd" content and URI referenced for only a specific combination of "rcd" content and URI referenced
external content, and therefore provides a robust integrity mechanism external content, and therefore provides a robust integrity mechanism
for an authentication service being performed by a non-authoritative for an authentication service being performed by a non-authoritative
party. This would often be associated with the use of delegate party. This would often be associated with the use of delegate
certificates [I-D.ietf-stir-cert-delegation] for the signing of calls certificates [I-D.ietf-stir-cert-delegation] for the signing of calls
by the calling party directly as an example, even though they aren't by the calling party directly as an example, even though the
considered an "authorized party" in the STIR certificate eco-system. "authorized party" is not necessarily the subject of a STIR
certificate.
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, which simply constrains the * a "mustInclude" for the "rcd" claim, which simply constrains the
fact that an "rcd" should be included if there is a "rcdi" fact that an "rcd" should be included if there is a "rcdi"
o a "mustInclude" for the "rcdi" claim and a "permittedValues" equal * 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.
8. PASSporT "crn" claim - Call Reason Defintion and Usage 8. PASSporT "crn" claim - Call Reason Defintion and Usage
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
skipping to change at page 13, line 39 skipping to change at page 14, line 43
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"
8.1. JWT Constraint for "crn" claim 8.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. If this protection is used, a "mustInclude" for the certificate. If this protection is used, a "mustInclude" for the
"crn" claim and a "permittedValues" equal to the "crn" claim value "crn" claim indicates that a "crn" claim must be present. If the
string SHOULD be included. issuer of the certificate wants to constrain the contents of "crn",
then it may set "permittedValues" for "crn" in the certificate.
9. Rich Call Data Claims Usage Rules 9. Rich Call Data Claims Usage Rules
Either or both the "rcd" or "crn" claims may appear in any PASSporT Either or both the "rcd" or "crn" claims may appear in any PASSporT
claims object as optional elements. The creator of a PASSporT MAY claims object as optional elements. The creator of a PASSporT MAY
also add a "ppt" value of "rcd" to the header of a PASSporT as well, 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 in which case the PASSporT claims MUST contain either a "rcd" or
"crn" claim, and any entities verifying the PASSporT object are "crn" claim, and any entities verifying the PASSporT object are
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. An example PASSporT header with the "ppt" PASSporT in question. An example PASSporT header with the "ppt"
skipping to change at page 14, line 18 skipping to change at page 15, line 29
"x5u":"https://www.example.com/cert.cer" } "x5u":"https://www.example.com/cert.cer" }
The PASSporT claims object contains the "rcd" key with its The PASSporT claims object contains 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].
9.1. Example "rcd" PASSporTs 9.1. Verification rules
A PASSporT that uses claims defined in this specification, in order
to have a successful verification outcome, MUST abide by all rules
set forth in the proper construction of the claims or MUST abide by
JWT Claims Constraint rules defined in [RFC8226] Section 8 or
extended in [I-D.ietf-stir-enhance-rfc8226] if present in the
certificate used to sign the PASSporT or MUST pass integrity
verification using "rcdi" if present. Consistent with the
verification rules of PASSporTs more generally [RFC8225], if any of
the above criteria is not met, the PASSporT verification should be
considered a failed verification for all claims in the PASSporT.
9.2. Example "rcd" PASSporTs
An example of a "nam" only PASSporT claims object 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" and "apn" only PASSporT claims object is shown
claim is shown next (with line breaks for readability only). next (with line breaks for readability only).
{ "orig":{"tn":"12025551000"}, { "orig":{"tn":"12025551000"},
"dest":{"tn":["12025551001"]}, "dest":{"tn":["12155551001"]},
"iat":1443208345, "iat":1443208345,
"rcd":{"nam":"James Bond"}, "rcd":{
"rcdi":{"/nam": "sha256-918VNJD12938SNCJ"} "apn":"12025559990",
} "nam":"Her Majesty's Secret Service" } }
An example of a "nam" only PASSporT claims object with an "rcdi"
claim is shown next (with line breaks for readability only).
{ "orig":{"tn":"12025551000"},
"dest":{"tn":["12025551001"]},
"iat":1443208345,
"rcd":{"nam":"James Bond"},
"rcdi":{"/nam": "sha256-uDtvpG1xNw+MK0XEOh+2UNQ94MQJ5d2ftgmHxsjKeMw"}
}
An example of a "rcd" claims object that includes the "jcd" and also An example of a "rcd" claims object that includes the "jcd" and also
contains a URI which requires the inclusion of an "rcdi" claim. contains a URI which requires the inclusion of an "rcdi" claim.
{ {
"orig": { "tn": "12025551000"}, "orig": { "tn": "12025551000"},
"dest": { "tn": ["12155551001"]}, "dest": { "tn": ["12155551001"]},
"iat": 1443208345, "iat": 1443208345,
"rcd": { "rcd": {
"nam": "Q Branch Spy Gadgets", "nam": "Q Branch Spy Gadgets",
"jcd": ["vcard", "jcd": ["vcard",
[ ["version",{},"text","4.0"], [ ["version",{},"text","4.0"],
["fn",{},"text","Q Branch"], ["fn",{},"text","Q Branch"],
["org",{},"text","MI6;Q Branch Spy Gadgets"], ["org",{},"text","MI6;Q Branch Spy Gadgets"],
["photo",{},"uri","https://example.com/photos/q-256x256.png"], ["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-256x256.jpg"],
["logo",{},"uri","https://example.com/logos/mi6-64x64.jpg"] ["logo",{},"uri","https://example.com/logos/mi6-64x64.jpg"]
] ] ] ]
}, },
"crn": "Rendezvous for Little Nellie", "crn": "Rendezvous for Little Nellie",
"rcdi": { "rcdi": {
"/nam": "sha256-918VNJD12938SNCJ", "/nam": "sha256-sM275lTgzCte+LHOKHtU4SxG8shlOo6OS4ot8IJQImY",
"/jcd": "sha256-VNJDSNCJ12938918", "/jcd": "sha256-7kdCBZqH0nqMSPsmABvsKlHPhZEStgjojhdSJGRr3rk",
"/jcd/1/3/3": "sha256-12938918VNJDSNCJ", "/jcd/1/3/3": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4",
"/jcd/1/4/3": "sha256-VNJDSNCJ12938918", "/jcd/1/4/3": "sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI",
"/jcd/1/5/3": "sha256-4049852730SFLGHL" "/jcd/1/5/3": "sha256-GKNxxqlLRarbyBNh7hc/4lbZAdK6B0kMRf1AMRWPkSo"
}
} }
}
In an example PASSporT, where a jCard is linked via HTTPS URL using In an example PASSporT, where a jCard is linked via HTTPS URL using
"jcl", a jCard file served at a particular URL. "jcl", a jCard file served at a particular URL.
An example jCard JSON file is shown as follows: An example jCard JSON file is shown as follows:
https://example.com/qbranch.json: https://example.com/qbranch.json:
["vcard", ["vcard",
[ ["version",{},"text","4.0"], [ ["version",{},"text","4.0"],
["fn",{},"text","Q Branch"], ["fn",{},"text","Q Branch"],
["org",{},"text","MI6;Q Branch Spy Gadgets"], ["org",{},"text","MI6;Q Branch Spy Gadgets"],
["photo",{},"uri","https://example.com/photos/q-256x256.png"], ["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-256x256.jpg"],
["logo",{},"uri","https://example.com/logos/mi6-64x64.jpg"] ["logo",{},"uri","https://example.com/logos/mi6-64x64.jpg"]
] ]
] ]
If that jCard is hosted at the example address of If that jCard is hosted at the example address of
"https://example.com/qbranch.json", the corresponding PASSporT claims "https://example.com/qbranch.json", the corresponding PASSporT claims
object would be as follows: object would be as follows:
{ {
"orig": {"tn": "12025551000"}, "orig": {"tn": "12025551000"},
"dest": {"tn": ["12155551001"]}, "dest": {"tn": ["12155551001"]},
"iat": 1443208345, "iat": 1443208345,
"rcd": { "rcd": {
"nam": "Q Branch Spy Gadgets", "nam": "Q Branch Spy Gadgets",
"jcl": "https://example.com/qbranch.json" "jcl": "https://example.com/qbranch.json"
}, },
"crn": "Rendezvous for Little Nellie", "crn": "Rendezvous for Little Nellie",
"rcdi": { "rcdi": {
"/nam": "sha256-918VNJD12938SNCJ", "/nam": "sha256-Gb0lOkj7Z9+plqbOkN32H+YX0Yav3fbioSk7DxQdGZU",
"/jcl": "sha256-VNJDSNCJ12938918", "/jcl": "sha256-Gb0lOkj7Z9+plqbOkN32H+YX0Yav3fbioSk7DxQdGZU",
"/jcl/1/3/3": "sha256-12938918VNJDSNCJ", "/jcl/1/3/3": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4",
"/jcl/1/4/3": "sha256-VNJDSNCJ12938918", "/jcl/1/4/3": "sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI",
"/jcl/1/5/3": "sha256-4049852730SFLGHL" "/jcl/1/5/3": "sha256-GKNxxqlLRarbyBNh7hc/4lbZAdK6B0kMRf1AMRWPkSo"
}
} }
}
10. Compact form of "rcd" PASSporT 10. Compact form of "rcd" PASSporT
10.1. Compact form of the "rcd" PASSporT claim 10.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.
skipping to change at page 16, line 38 skipping to change at page 18, line 17
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.
10.2. Compact form of the "rcdi" PASSporT claim 10.2. Compact form of the "rcdi" PASSporT claim
Compact form of an "rcdi" PASSporT claim is not supported, so if Compact form of an "rcdi" PASSporT claim is not supported, so if
"rcdi" is required compact form should not be used. "rcdi" is required compact form MUST NOT be used.
10.3. Compact form of the "crn" PASSporT claim 10.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 "call-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].
11. Further Information Associated with Callers 11. 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
to receive. Such data could include: to receive. Such data could include:
o information related to the location of the caller, or * information related to the location of the caller, or
o any organizations or institutions that the caller is associated * any organizations or institutions that the caller is associated
with, or even categories of institutions (is this a government with, or even categories of institutions (is this a government
agency, or a bank, or what have you), or agency, or a bank, or what have you), or
o hyperlinks to images, such as logos or pictures of faces, or to * hyperlinks to images, such as logos or pictures of faces, or to
similar external profile information, or similar external profile information, or
o information processed by an application before rendering it to a * information processed by an application before rendering it to a
user, like social networking data that shows that an unknown user, like social networking data that shows that an unknown
caller is a friend-of-a-friend, or reputation scores derived from caller is a friend-of-a-friend, or reputation scores derived from
crowdsourcing, or confidence scores based on broader analytics crowdsourcing, or confidence scores based on broader analytics
about the caller and callee. about the caller and callee.
All of these data elements would benefit from the secure attestations All of these data elements would benefit from the secure attestations
provided by the STIR and PASSporT frameworks. A new IANA registry provided by the STIR and PASSporT frameworks. A new IANA registry
has been defined to hold potential values of the "rcd" array; see has been defined to hold potential values of the "rcd" array; see
Section 17.3. Specific extensions to the "rcd" PASSporT claim are Section 17.3. Specific extensions to the "rcd" PASSporT claim are
left for future specification. left for future specification.
skipping to change at page 19, line 19 skipping to change at page 20, line 47
A third-party PASSporT contains an "iss" element to distinguish its A third-party PASSporT contains an "iss" element to distinguish its
PASSporTs from first-party PASSporTs. Third-party "rcd" PASSporTs PASSporTs from first-party PASSporTs. Third-party "rcd" PASSporTs
are signed with credentials that do not have authority over the are signed with credentials that do not have authority over the
identity that appears in the "orig" element of the PASSporT claims. identity that appears in the "orig" element of the PASSporT claims.
The presence of "iss" signifies that a different category of The presence of "iss" signifies that a different category of
credential is being used to sign a PASSporT than the [RFC8226] credential is being used to sign a PASSporT than the [RFC8226]
certificates used to sign STIR calls; it is instead a certificate certificates used to sign STIR calls; it is instead a certificate
that identifies the source of the "rcd" data. How those credentials that identifies the source of the "rcd" data. How those credentials
are issued and managed is outside the scope of this specification; are issued and managed is outside the scope of this specification;
the value of "iss" however MUST reflect the Subject Name field of the the value of "iss" however MUST reflect the Subject of the
certificate used to sign a third-party PASSporT. The explicit certificate used to sign a third-party PASSporT. The explicit
mechanism for reflecting the Subject Name field of the certificate is mechanism for reflecting the subject field of the certificate is out
out of scope of this document and left to the certificate governance of scope of this document and left to the certificate governance
policies that define how to map the "iss" value in the PASSporT to policies that define how to map the "iss" value in the PASSporT to
the Subject Name field in the certificate. Relying parties in STIR the subject field in the certificate. Relying parties in STIR have
have always been left to make their own authorization decisions about always been left to make their own authorization decisions about
whether to trust the signers of PASSporTs, and in the third-party whether to trust the signers of PASSporTs, and in the third-party
case, where an entity has explicitly queried a service to acquire the case, where an entity has explicitly queried a service to acquire the
PASSporT object, it may be some external trust or business PASSporT object, it may be some external trust or business
relationship that induces the relying party to trust a PASSporT. 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"]},
skipping to change at page 20, line 11 skipping to change at page 21, line 39
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, third-party PASSporTs that of granularity or accuracy. Therefore, third-party PASSporTs that
carry "rcd" data MUST also carry an indication of the relationship of carry "rcd" data MUST also carry an indication of the relationship of
the generator of the PASSporT to the caller in the form of the "iss" the generator of the PASSporT to the caller in the form of the "iss"
claim. As stated in the previous section, the use of "iss" MUST claim. As stated in the previous section, the use of "iss" MUST
reflect the Subject Name of the certificate used to sign a third- reflect the subject field of the certificate used to sign a third-
party PASSporT to represent that relationship. party PASSporT to represent that relationship.
14. Using "rcd" in SIP 14. 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.
14.1. Authentication Service Behavior 14.1. Authentication Service Behavior
skipping to change at page 21, line 13 skipping to change at page 22, line 41
value, it MUST use the full form of the PASSporT object in SIP. value, it MUST use the full form of the PASSporT object in SIP.
14.2. Verification Service Behavior 14.2. Verification Service Behavior
[RFC8224] Section 6.2 Step 5 requires that specifications defining [RFC8224] Section 6.2 Step 5 requires that specifications defining
"ppt" values describe any additional verifier behavior. The behavior "ppt" values describe any additional verifier behavior. The behavior
specified for the "ppt" values of "rcd" is as follows. If the specified for the "ppt" values of "rcd" is as follows. If the
PASSporT is in compact form, then the verification service SHOULD PASSporT is in compact form, then the verification service SHOULD
extract the display-name from the From header field value, if any, extract the display-name from the From header field value, if any,
and use that as the value for the "nam" key when it recomputes the and use that as the value for the "nam" key when it recomputes the
header and claims of the PASSporT object. Optionally, if there header and claims of the PASSporT object. Additionally, if there
exists a Call-Info header field as defined in exists a Call-Info header field as defined in
[I-D.ietf-sipcore-callinfo-rcd], the "jcard" value can be derived to [I-D.ietf-sipcore-callinfo-rcd], the "jcard" value can be derived to
determine the "jcd" key when it recomputes the header and claims of determine the "jcd" key when it recomputes the header and claims of
the PASSporT object. If the signature validates over the recomputed the PASSporT object. If the signature validates over the recomputed
object, then the verification should be considered successful. object, then the verification should be considered successful.
However, if the PASSport is in full form with a "ppt" value of "rcd", However, if the PASSport is in full form with a "ppt" value of "rcd",
then the verification service MUST extract the value associated with then the verification service MUST extract the value associated with
the "rcd" "nam" key in the object. If the signature validates, then the "rcd" "nam" key in the object. If the signature validates, then
the verification service can use the value of the "rcd" "nam" key as the verification service can use the value of the "rcd" "nam" key as
skipping to change at page 23, line 22 skipping to change at page 25, line 9
apply both the SHAKEN PASSporT claims and extension and simply add apply both the SHAKEN PASSporT claims and extension and simply add
the "rcd" required claims defined in this document. the "rcd" required claims defined in this document.
For example, the PASSporT claims for the "shaken" PASSporT with "rcd" For example, the PASSporT claims for the "shaken" PASSporT with "rcd"
claims would be as follows: claims would be as follows:
Protected Header Protected Header
{ {
"alg":"ES256", "alg":"ES256",
"typ":"passport", "typ":"passport",
"ppt":"shaken", “ppt”:”shaken”,
"x5u":"https://cert.example.org/passport.cer" "x5u":"https://cert.example.org/passport.cer"
} }
Payload Payload
{ {
"attest":"A", “attest”:”A”,
"dest":{"tn":["12025551001"]}, "dest":{“tn”:["12025551001"]},
"iat":1443208345, "iat":1443208345,
"orig":{"tn":"12025551000"}, "orig":{“tn”:"12025551000"},
"origid":"123e4567-e89b-12d3-a456-426655440000", “origid”:”123e4567-e89b-12d3-a456-426655440000”,
"rcd":{"nam":"James Bond"} "rcd":{"nam":"James Bond"}
} }
A Verification Service that supports "rcd" and "shaken" PASSporT A Verification Service that supports "rcd" and "shaken" PASSporT
extensions is able to receive the above PASSporT and interpret both extensions is able to receive the above PASSporT and interpret both
the "shaken" claims as well as the "rcd" defined claim. 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" is ignored and claims but doesn't support "rcd", the "rcd" is ignored and
disregarded. disregarded.
16. Acknowledgements 16. Acknowledgements
We would like to thank David Hancock, Robert Sparks, Russ Housley, We would like to thank David Hancock, Robert Sparks, Russ Housley,
Eric Burger, Alec Fenichel, and Ben Campbell for helpful suggestions, Eric Burger, Alec Fenichel, Ben Campbell, Jack Rickard for helpful
review, and comments. suggestions, review, and comments.
17. IANA Considerations 17. IANA Considerations
17.1. JSON Web Token Claim 17.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"
skipping to change at page 24, line 48 skipping to change at page 26, line 30
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].
17.3. PASSporT RCD Types 17.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
under the Specification Required policy. under the Specification Required policy.
This registry is to be initially populated with three values, "nam", This registry is to be initially populated with four values, "nam",
"jcd", and "jcl", which are specified in [RFCThis]. "apn", "jcd", and "jcl", which are specified in [RFCThis].
18. Security Considerations 18. Security Considerations
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.
Since computation of "rcdi" digests for URIs requires the loading of Since computation of "rcdi" digests for URIs requires the loading of
referenced content, it would be best practice to validate that referenced content, it would be best practice to validate that
content at the creation of the "rcdi" or corresponding JWT claim content at the creation of the "rcdi" or corresponding JWT claim
constraint value by checking for content that may cause issues for constraint value by checking for content that may cause issues for
verification services or that doesn't follow the behavior defined in verification services or that doesn't follow the behavior defined in
this document, e.g. unreasonably sized data, the inclusion of this document, e.g. unreasonably sized data, the inclusion of
recursive URI references, etc. recursive URI references, etc. Along the same lines, the
verification service should also use precautionary best practices to
avoid attacks when accessing URI linked content.
18.1. The use of JWT Claim Constraints in delegate certificates to 18.1. The use of JWT Claim Constraints in delegate certificates to
exclude unauthorized claims exclude unauthorized claims
While this can apply to any PASSporT that is signed with a STIR While this can apply to any PASSporT that is signed with a STIR
Delegate Certificates [I-D.ietf-stir-cert-delegation], it is Delegate Certificates [I-D.ietf-stir-cert-delegation], it is
important to note that when constraining PASSporTs to include important to note that when constraining PASSporTs to include
specific claims or contents of claims, it is also important to specific claims or contents of claims, it is also important to
consider potential attacks by non-authorized signers that may include consider potential attacks by non-authorized signers that may include
other potential PASSporT claims that weren't originally vetted by the other potential PASSporT claims that weren't originally vetted by the
authorized entity providing the delegate certificate. The use of JWT authorized entity providing the delegate certificate. The use of JWT
claims constraints as defined in [I-D.housley-stir-enhance-rfc8226] claims constraints as defined in [I-D.ietf-stir-enhance-rfc8226] for
for preventing the ability to include claims beyond the claims preventing the ability to include claims beyond the claims defined in
defined in this document may need to be considered. this document may need to be considered.
[I-D.housley-stir-enhance-rfc8226] in the security considerations
also notes that the use of mustExclude for the "rcdi" when "rcd" is Certificate issuers SHOULD NOT include an entry in mustExclude for
used is discouraged, otherwise it would prevent the proper integrity the "rcdi" claim for a certificate that will be used with the
protection mechanism to be used. PASSporT Extension for Rich Call Data defined in this document.
Excluding this claim would prevent the integrity protection mechanism
from working properly.
19. References 19. References
19.1. Normative References 19.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-02 (work Rich Call Data", Work in Progress, Internet-Draft, draft-
in progress), February 2021. ietf-sipcore-callinfo-rcd-02, 22 February 2021,
<https://www.ietf.org/archive/id/draft-ietf-sipcore-
callinfo-rcd-02.txt>.
[I-D.ietf-stir-cert-delegation] [I-D.ietf-stir-cert-delegation]
Peterson, J., "STIR Certificate Delegation", draft-ietf- Peterson, J., "STIR Certificate Delegation", Work in
stir-cert-delegation-04 (work in progress), February 2021. Progress, Internet-Draft, draft-ietf-stir-cert-delegation-
04, 22 February 2021, <https://www.ietf.org/archive/id/
draft-ietf-stir-cert-delegation-04.txt>.
[I-D.ietf-stir-enhance-rfc8226]
Housley, R., "Enhanced JSON Web Token (JWT) Claim
Constraints for Secure Telephone Identity Revisited (STIR)
Certificates", Work in Progress, Internet-Draft, draft-
ietf-stir-enhance-rfc8226-05, 26 July 2021,
<https://www.ietf.org/archive/id/draft-ietf-stir-enhance-
rfc8226-05.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[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>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., [RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed.,
"JavaScript Object Notation (JSON) Pointer", RFC 6901, "JavaScript Object Notation (JSON) Pointer", RFC 6901,
DOI 10.17487/RFC6901, April 2013, DOI 10.17487/RFC6901, April 2013,
<https://www.rfc-editor.org/info/rfc6901>. <https://www.rfc-editor.org/info/rfc6901>.
[RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words
for Use in RFCs to Indicate Requirement Levels", RFC 6919,
DOI 10.17487/RFC6919, April 2013,
<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
Telephone Identity Problem Statement and Requirements", Telephone Identity Problem Statement and Requirements",
RFC 7340, DOI 10.17487/RFC7340, September 2014, RFC 7340, DOI 10.17487/RFC7340, September 2014,
<https://www.rfc-editor.org/info/rfc7340>. <https://www.rfc-editor.org/info/rfc7340>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>. <https://www.rfc-editor.org/info/rfc7519>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
"Authenticated Identity Management in the Session "Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 8224, Initiation Protocol (SIP)", RFC 8224,
DOI 10.17487/RFC8224, February 2018, DOI 10.17487/RFC8224, February 2018,
<https://www.rfc-editor.org/info/rfc8224>. <https://www.rfc-editor.org/info/rfc8224>.
[RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
<https://www.rfc-editor.org/info/rfc8225>. <https://www.rfc-editor.org/info/rfc8225>.
skipping to change at page 27, line 31 skipping to change at page 29, line 41
[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] [I-D.ietf-stir-oob]
Rescorla, E. and J. Peterson, "Secure Telephone Identity Rescorla, E. and J. Peterson, "Secure Telephone Identity
Revisited (STIR) Out-of-Band Architecture and Use Cases", Revisited (STIR) Out-of-Band Architecture and Use Cases",
draft-ietf-stir-oob-07 (work in progress), March 2020. Work in Progress, Internet-Draft, draft-ietf-stir-oob-07,
9 March 2020, <https://www.ietf.org/archive/id/draft-ietf-
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate stir-oob-07.txt>.
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Authors' Addresses Authors' Addresses
Chris Wendt Chris Wendt
Comcast Comcast
Comcast Technology Center Comcast Technology Center
Philadelphia, PA 19103 Philadelphia, PA 19103,
USA United States of America
Email: chris-ietf@chriswendt.net Email: chris-ietf@chriswendt.net
Jon Peterson Jon Peterson
Neustar Inc. Neustar Inc.
1800 Sutter St Suite 570 1800 Sutter St Suite 570
Concord, CA 94520 Concord, CA 94520,
US United States of America
Email: jon.peterson@neustar.biz Email: jon.peterson@neustar.biz
 End of changes. 70 change blocks. 
225 lines changed or deleted 305 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/