rfc9795xml2.original.xml   rfc9795.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.16 (Ruby 2.
6.0) -->
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<rfc ipr="trust200902" docName="draft-ietf-stir-passport-rcd-26" category="std" <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
consensus="true" tocInclude="true" sortRefs="true" symRefs="true"> -ietf-stir-passport-rcd-26" number="9795" submissionType="IETF" category="std" c
<front> onsensus="true" tocInclude="true" sortRefs="true" symRefs="true"
<title abbrev="RCD">PASSporT Extension for Rich Call Data</title> updates="" obsoletes="" xml:lang="en" version="3">
<front>
<title abbrev="RCD">Personal Assertion Token (PASSporT) Extension for Rich C
all Data</title>
<seriesInfo name="RFC" value="9795"/>
<author initials="C." surname="Wendt" fullname="Chris Wendt"> <author initials="C." surname="Wendt" fullname="Chris Wendt">
<organization>Somos Inc.</organization> <organization>Somos Inc.</organization>
<address> <address>
<email>chris-ietf@chriswendt.net</email> <email>chris-ietf@chriswendt.net</email>
</address> </address>
</author> </author>
<author initials="J." surname="Peterson" fullname="Jon Peterson"> <author initials="J." surname="Peterson" fullname="Jon Peterson">
<organization>Neustar Inc.</organization> <organization>Neustar Inc.</organization>
<address> <address>
<email>jon.peterson@neustar.biz</email> <email>jon.peterson@neustar.biz</email>
</address> </address>
</author> </author>
<date year="2025" month="June"/>
<date year="2023" month="June" day="05"/>
<area>art</area> <area>art</area>
<workgroup>stir</workgroup>
<keyword>Identity</keyword> <keyword>Identity</keyword>
<abstract> <abstract>
<t>This document extends Personal Assertion Token (PASSporT), a token for
<t>This document extends PASSporT, a token for conveying cryptographically-signe conveying cryptographically signed call information about personal communication
d call information about personal communications, to include rich meta-data abou s, to include rich metadata about a call and caller that can be signed and integ
t a call and caller that can be signed and integrity protected, transmitted, and rity protected, transmitted, and subsequently rendered to the called party. This
subsequently rendered to the called party. This framework is intended to includ framework is intended to include and extend caller- and call-specific informati
e and extend caller and call specific information beyond human-readable display on beyond human-readable display name, comparable to the "Caller ID" function co
name comparable to the "Caller ID" function common on the telephone network and mmon on the telephone network. It is also enhanced with an integrity mechanism t
is also enhanced with a integrity mechanism that is designed to protect the auth hat is designed to protect the authoring and transport of this information for d
oring and transport of this information for different authoritative use-cases.</ ifferent authoritative use cases.</t>
t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction">
<name>Introduction</name>
<t>PASSporT <xref target="RFC8225"/> is a token format based on JSON Web T
oken (JWT) <xref target="RFC7519"/> for conveying cryptographically signed infor
mation about the parties involved in personal communications; it is used to conv
ey a signed assertion of the identity of the participants in real-time communica
tions established via a protocol like SIP <xref target="RFC8224"/>. The Secure T
elephone Identity Revisited (STIR) problem statement <xref target="RFC7340"/> de
clared securing the display name of callers outside of STIR's initial scope. Thi
s document extends the use of JWT and PASSporT in the overall STIR framework by
defining a PASSporT extension and the associated STIR procedures to protect addi
tional caller- and call-related information. This is information beyond the cal
ling party originating identity (e.g., telephone number or SIP URI) that is inte
nded to be rendered to assist a called party in determining whether to accept or
trust incoming communications. This includes information such as the name of th
e person or entity on one side of a communications session, for example, the tra
ditional "Caller ID" of the telephone network along with related display informa
tion that would be rendered to the called party during alerting or potentially u
sed by an automaton to determine whether and how to alert a called party to a ca
ll and whom is calling.</t>
<t>Traditional telephone network signaling protocols have long supported d
elivering a 'calling name' from the originating side, though in practice the ter
minating side is often left to determine a name from the calling party number by
consulting a local address book or an external database. SIP, for example, simi
larly can carry this information in a display-name in the From header field valu
e (or alternatively the Call-Info header field) from the originating to terminat
ing side. In this document, we utilize the STIR framework to more generally exte
nd the assertion of an extensible set of identity information not limited to but
including calling name.</t>
<t>This document extends PASSporT to provide cryptographic protection for
the "display-name" field of SIP requests, or similar name fields in other protoc
ols, as well as further "rich call data" (RCD) about the caller, which includes
the contents of the Call-Info header field or other data structures that can be
added to the PASSporT. In addition, <xref target="use"/> describes use cases tha
t enable external third-party authorities to convey rich information associated
with a calling number via an "rcd" PASSporT while clearly identifying the third-
party as the source of the Rich Call Data information.
Finally, this document describes how to preserve the integrity of the RCD in sce
narios where there may be non-authoritative users initiating and signing RCD, th
erefore limiting a PASSporT and the RCD claims it asserts via certificate-level
controls.</t>
</section>
<section anchor="terminoloygy">
<name>Terminology</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section>
<section anchor="overview-of-the-use-of-the-rich-call-data-passport-extensio
n">
<name>Overview of the Use of the Rich Call Data PASSporT Extension</name>
<t>This document defines Rich Call Data (RCD), which is a PASSporT extensi
on <xref target="RFC8225"/> that defines an extensible claim for asserting infor
mation about the call beyond the telephone number. This includes more detailed i
nformation about the calling party, calling number, or the purpose of the call.
There are many use cases that this document describes around the entities respon
sible for the signing and integrity of this information, whether it is the entit
y that originates a call, a service provider acting on behalf of a caller, or wh
en third-party services may be authoritative over the RCD on behalf of the calle
r. In general, PASSporT <xref target="RFC8225"/> has been defined to be independ
ent of the communications protocol, but its initial usage as detailed in <xref t
arget="RFC8224"/> is with the SIP protocol <xref target="RFC3261"/>. There are
many SIP-specific references and definitions in this document, but future specif
ications may extend the usage of RCD PASSporTs and claims to other protocol-spec
ific usage and definitions.</t>
<t>The RCD associated with the identity of the calling party described in
this document is of two main categories. The first data is a more traditional se
t of information about a caller associated with "display-name" in SIP <xref targ
et="RFC3261"/>, typically a textual description of the caller, or alternate pres
entation numbers often used in the From header field <xref target="RFC3261"/> or
P-Asserted-Identity header field <xref target="RFC3325"/>, or an icon associate
d with the caller. The second category is a set of RCD that is defined as part o
f the jCard definitions or extensions to that data. <xref target="RFC9796"/> des
cribes the optional use of jCard in the Call-Info header field as RCD with the "
jcard" Call-Info purpose token. Either or both of these two types of data can be
incorporated into an "rcd" claim as defined in this document.</t>
<t>Additionally, in relation to the description of the specific communicat
ions event itself (versus the identity description in the previous paragraph), <
xref target="RFC9796"/> also describes a "call-reason" parameter intended for de
scription of the intent or reason for a particular call. A new PASSporT claim "c
rn", or call reason, can contain a string that describes the intent of the call.
This claim is intentionally kept separate from the "rcd" claim because it is en
visioned that call reason is not the same as information associated with the cal
ler and may change on a more frequent, per-call basis.</t>
</section>
<section anchor="rcdintegrity">
<name>Overview of Rich Call Data Integrity</name>
<t>When incorporating call data that represents a user, even in traditiona
l calling name services today, often there are policy and restrictions around wh
at data elements are allowed to be used. Whether preventing offensive language o
r icons, enforcing uniqueness, notifying about potential trademark or copyright
violations, or enforcing other policies, there might be the desire to pre-certif
y or "vet" the specific use of RCD.
This document defines a mechanism that allows for a direct or
indirect party that (a) enforces
the policies to approve or certify the content, (b) creates a
cryptographic digest that can be used to validate that data, and
(c) applies a constraint in the certificate to allow the recipient and
verifier to validate that the specific content of the RCD is as
intended at its creation and its approval or certification.</t>
<t>There are two mechanisms that are defined to accomplish that for two di
stinct categories of purposes. The first of the mechanisms include the definitio
n of an integrity claim. The RCD integrity mechanism is a process of generating
a cryptographic digest for each resource referenced by a URI within a claim valu
e (e.g., an image file referenced by "jcd" or a jCard referenced by "jcl"). This
mechanism is inspired by and based on the W3C Subresource Integrity specificati
on <xref target="W3C-SubresourceIntegrity"/>. The second of the mechanisms uses
the capability called JWT Claim Constraints, defined in <xref target="RFC8226"/>
and extended in <xref target="RFC9118"/>. The JWT Claim Constraints specificall
y guide the verifier within the certificate used to compute the signature in 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.</t>
<t>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 RCD conveyed in the PASSporT claims is passe
d by value or passed by reference; i.e., is the information contained in the PAS
SporT claims and therefore integrity protected by the PASSporT signature, or is
the information contained in an external resource referenced by a URI in the PAS
SporT? 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 ecos
ystem the "rcd" PASSporTs or "rcd" claims are being used.</t>
<t>The following table provides an overview of the framework for how integ
rity should be used with RCD. ("Auth" represents "authoritative" in this table.)
</t>
<section anchor="introduction"><name>Introduction</name> <table>
<thead>
<t>PASSporT <xref target="RFC8225"/> is a token format based on JWT <xref target <tr>
="RFC7519"/> for conveying cryptographically-signed information about the partie <th>Modes</th>
s involved in personal communications; it is used to convey a signed assertion o <th>No URI refs</th>
f the identity of the participants in real-time communications established via a <th>Includes URI refs</th>
protocol like SIP <xref target="RFC8224"/>. The STIR problem statement <xref ta </tr>
rget="RFC7340"/> declared securing the display name of callers outside of STIR's </thead>
initial scope. This document extends the use of JWT and PASSporT in the overall <tbody>
STIR framework by defining a PASSporT extension and the associated STIR procedu <tr>
res to protect additional caller and call related information. This is addition <th>Auth</th>
al information beyond the calling party originating identity (e.g. telephone num <td>1: No integrity req</td>
ber or SIP URI) that is intended to be rendered to assist a called party in dete <td>2: RCD Integrity</td>
rmining whether to accept or trust incoming communications. This includes inform </tr>
ation such as the name of the person or entity on one side of a communications s <tr>
ession, for example, the traditional "Caller ID" of the telephone network along <th>Non-Auth</th>
with related display information that would be rendered to the called party duri <td>3: JWT Claim Const.</td>
ng alerting or potentially used by an automaton to determine whether and how to <td>4: RCD Integ. / JWT Claim Const.</td>
alert a called party to a call and whom is calling.</t> </tr>
</tbody>
<t>Traditional telephone network signaling protocols have long supported deliver </table>
ing a 'calling name' from the originating side, though in practice, the terminat
ing side is often left to determine a name from the calling party number by cons
ulting a local address book or an external database. SIP, for example, similarly
can carry this information in a 'display-name' in the From header field value f
rom the originating to terminating side, or alternatively in the Call-Info heade
r field. In this document, we utilize the STIR framework to more generally exten
d the assertion of an extensible set of identity information not limited to but
including calling name.</t>
<t>This document extends PASSporT to provide cryptographic protection for the "d
isplay-name" field of SIP requests, or similar name fields in other protocols, a
s well as further "rich call data" (RCD) about the caller, which includes the co
ntents of the Call-Info header field or other data structures that can be added
to the PASSporT. In addition, Section 12 describes use-cases that enable externa
l third-party authorities to convey rich information associated with a calling n
umber via a "rcd" PASSporT while clearly identifying the third-party as the sour
ce of the Rich Call Data information. Finally, this document describes how to pr
eserve the integrity of the RCD in scenarios where there may be non-authoritativ
e users initiating and signing RCD and therefore a constraint on the RCD data th
at a PASSporT can attest via certificate-level controls.</t>
</section>
<section anchor="terminoloygy"><name>Terminology</name>
<t>The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this do
cument are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xr
ef target="RFC8174"/> when, and only when, they appear in all capitals, as shown
here.</t>
</section>
<section anchor="overview-of-the-use-of-the-rich-call-data-passport-extension"><
name>Overview of the use of the Rich Call Data PASSporT extension</name>
<t>This document defines Rich Call Data (RCD) which is a PASSporT extension <xre
f target="RFC8225"/> that defines an extensible claim for asserting information
about the call beyond the telephone number. This includes information such as mo
re detailed information about the calling party or calling number being presente
d or the purpose of the call. There are many use-cases that will be described in
this document around the entities responsible for the signing and integrity of
this information, whether it is the entity that originates a call, a service pro
vider acting on behalf of a caller or use-cases where third-party services may b
e authoritative over the rich call data on behalf of the caller. In general, PAS
SporT <xref target="RFC8225"/> has been defined to be a communications protocol
independent technology, but it's initial usage as detailed in <xref target="RFC8
224"/> is with the SIP protocol <xref target="RFC3261"/>. There are many SIP sp
ecific references and definitions in this document, but future specifications ma
y extend the usage of RCD PASSporTs and claims to other protocol specific usage
and definitions.</t>
<t>The RCD associated with the identity of the calling party described in this d
ocument is of two main categories. The first data is a more traditional set of i
nfo about a caller associated with "display-name" in SIP <xref target="RFC3261"/
>, typically a textual description of the caller, or alternate presentation numb
ers often used in From Header field <xref target="RFC3261"/> or P-Asserted-Ident
ity <xref target="RFC3325"/>, or an icon associated with the caller. The second
category is a set of RCD that is defined as part of the jCard definitions or ext
ensions to that data. <xref target="I-D.ietf-sipcore-callinfo-rcd"/> describes t
he optional use of jCard in Call-Info header field as RCD with the "jcard" Call-
Info purpose token. Either or both of these two types of data can be incorporate
d into an "rcd" claim defined in this document.</t>
<t>Additionally, in relation to the description of the specific communications e
vent itself (versus the identity description in previous paragraph), <xref targe
t="I-D.ietf-sipcore-callinfo-rcd"/> also describes a "call-reason" parameter int
ended for description of the intent or reason for a particular call. A new PASSp
orT claim "crn", or call reason, can contain a string that describes the intent
of the call. This claim is intentionally kept separate from the "rcd" claim beca
use it is envisioned that call reason is not the same as information associated
with the caller and may change on a more frequent, per call, type of basis.</t>
</section>
<section anchor="rcdintegrity"><name>Overview of Rich Call Data Integrity</name>
<t>When incorporating call data that represents a user, even in traditional call
ing name services today, often there are policy and restrictions around what dat
a elements are allowed to be used. Whether preventing offensive language or icon
s or enforcing uniqueness, potential trademark or copyright violations or other
policy enforcement, there might be the desire to pre-certify or "vet" the specif
ic use of rich call data. This document defines a mechanism that allows for a di
rect or indirect party that enforces the policies to approve or certify the cont
ent, create a cryptographic digest that can be used to validate that data and ap
plies a constraint in the certificate to allow the recipient and verifier to val
idate that the specific content of the RCD is as intended at its creation and ap
proval or certification.</t>
<t>There are two mechanisms that are defined to accomplish that for two distinct
categories of purposes. The first of the mechanisms include the definition of a
n integrity claim. The RCD integrity mechanism is a process of generating a cryp
tographic digest for each resource referenced by a URI within a claim value (e.g
., an image file referenced by "jcd" or a jCard referenced by "jcl"). This mecha
nism is inspired by and based on the W3C Subresource Integrity specification <xr
ef target="W3C-SubresourceIntegrity"/>. The second of the mechanisms uses the ca
pability called JWT Claim Constraints, defined in <xref target="RFC8226"/> and e
xtended in <xref target="RFC9118"/>. The JWT Claim Constraints specifically guid
e the verifier within the certificate used to compute the signature in the PASSp
orT for the inclusion (or exclusion) of specific claims and their values, so tha
t the content intended by the signer can be verified to be accurate.</t>
<t>Both of these mechanisms, integrity digests and JWT Claims Constraints, can b
e used together or separately depending on the intended purpose. The first categ
ory of purpose is whether the rich call data conveyed in the PASSporT claims is
pass-by-value or pass-by-reference; i.e., is the information contained in the PA
SSporT claims and therefore integrity protected by the PASSporT signature, or is
the information contained in an external resource referenced by a URI in the PA
SSporT. 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 or "rcd" claims are being used.</t>
<t>The following table provides an overview of the framework for how integrity s
hould be used with RCD. ("Auth" represents "authoritative" in this table.)</t>
<figure><artwork><![CDATA[
+----------+---------------------+--------------------------------+
| Modes | No URI refs | Includes URI refs |
+----------+---------------------+--------------------------------+
| Auth | 1: No integrity req | 2: RCD Integrity |
+----------+---------------------+--------------------------------+
| Non-Auth | 3: JWT Claim Const. | 4: RCD Integ./JWT Claim Const. |
+----------+---------------------+--------------------------------+
]]></artwork></figure>
<t>The first and simplest mode is exclusively for when all RCD content is direct
ly included as part of the claims (i.e. no URIs referencing external content are
included in the content) and when the signer is authoritative over the content.
In this mode, integrity protection is not required and the set of claims is sim
ply protected by the signature of the standard PASSporT <xref target="RFC8225"/>
and SIP identity header <xref target="RFC8224"/> procedures. The second mode is
an extension of the first where the signer is authoritative and an "rcd" claim
contents include a URI identifying external resources. In this mode, an RCD Inte
grity 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, particu
larly for the case where there are URI references in the RCD, the content of tha
t RCD can be comprehensively validated that it was received as intended by the s
igner of the PASSporT.</t>
<t>The third and fourth modes cover cases where there is a different authoritati
ve entity responsible for the content of the RCD, separate from the signer of th
e PASSporT itself, allowing the ability, in particular when delegating signing a
uthority for PASSporT, to enable a mechanism for allowing agreed or vetted conte
nt included in or referenced by the RCD claim contents. The primary framework fo
r allowing the separation of authority and the signing of PASSporTs by non-autho
rized entities is detailed in <xref target="RFC9060"/> although other cases may
apply. As with the first and second modes, the third and fourth modes differ wit
h the absence or inclusion of referenced external content using URIs.</t>
</section>
<section anchor="rcd_define"><name>PASSporT Claim "rcd" Definition and Usage</na
me>
<section anchor="syntax"><name>PASSporT "rcd" Claim</name>
<t>This document defines a new JSON Web Token claim for "rcd", Rich Call Data, t
he value of which is a JSON object that can contain one or more key value pairs.
This document defines a default set of key values.</t>
<section anchor="nam-key"><name>"nam" key</name>
<t>The "nam" key value is a display name, associated with the originator of pers
onal communications, which may for example match the display-name component of t
he From header field value of a SIP request <xref target="RFC3261"/> or alternat
ively from the P-Asserted-Identity header field value <xref target="RFC3325"/>,
or a similar field in other PASSporT using protocols. This key MUST be included
once as part of the "rcd" claim value JSON object. The key syntax of "nam" MUST
follow the display-name ABNF given in <xref target="RFC3261"/>. If there is no s
tring associated with a display name, the claim value MUST then be an empty stri
ng.</t>
</section>
<section anchor="apn-key"><name>"apn" key</name>
<t>The "apn" key value is an optional alternate presentation number associated w
ith the originator of personal communications, which may for example match the u
ser component of the From header field value of a SIP request (in cases where a
network number is carried in the P-Asserted-Identity <xref target="RFC3325"/>),
or alternatively from the Additional-Identity header field value [3GPP TS 24.229
v16.7.0], or a similar field in other PASSporT using protocols. Its intended se
mantics are to convey a number that the originating user is authorized to show t
o called parties in lieu of their default number, such as cases where a remote c
all agent uses the main number of a call center instead of their personal teleph
one number. The "apn" key value is a canonicalized telephone number per <xref ta
rget="RFC8224"/> Section 8.3. If present, this key MUST be included once as part
of the "rcd" claim value JSON object.</t>
<t>The use of the optional "apn" key is intended for cases where the signer of a
n "rcd" PASSporT or "rcd" claims authorizes the use of an alternate presentation
number by the user. How the signer determines that a user is authorized to pres
ent the number in question is a policy decision outside the scope of this docume
nt, however, the vetting of the alternate presentation number should follow the
same level of vetting as telephone identities or any other information contained
in an "rcd" PASSporT or "rcd" claims. This usage is intended as an alternative
to conveying the presentation number in the "tel" key value of a jCard, in situa
tions where no other rich jCard data needs to be conveyed with the call. Only on
e "apn" key may be present. "apn" MUST be used when it is the intent of the call
er or signer to display the alternate presentation number even if "jcd" or "jcl"
keys are present in a PASSporT with a "tel" key value.</t>
</section>
<section anchor="icn-key"><name>"icn" key</name>
<t>The "icn" key value is an optional HTTPS URL reference to an image resource t
hat can be used to pictorially represent the originator of personal communicatio
ns. This icon key value should be used as a base or default method of associatin
g an image with a calling party.</t>
<t>When being used for SIP <xref target="RFC3261"/> this claim key value used to
protect the Call-Info header field with a purpose parameter value of "icon" as
described in Section 20.9 <xref target="RFC3261"/>. Example as follows:</t>
<figure><artwork><![CDATA[ <t>The first and simplest mode is exclusively for when all RCD content is
directly included as part of the claims (i.e., no URIs referencing external cont
ent are included in the content) and when the signer is authoritative over the c
ontent. In this mode, integrity protection is not required, and the set of claim
s is simply protected by the signature of the standard PASSporT <xref target="RF
C8225"/> and SIP identity header <xref target="RFC8224"/> procedures. The second
mode is an extension of the first where the signer is authoritative, and an "rc
d" claim contents include a URI identifying external resources. In this mode, an
RCD Integrity or "rcdi" claim <bcp14>MUST</bcp14> be included. This integrity c
laim 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 recei
ved as intended by the signer of the PASSporT.</t>
<t>The third and fourth modes cover cases where there is a different autho
ritative entity responsible for the content of the RCD, separate from the signer
of the PASSporT itself, allowing the ability, in particular when delegating sig
ning authority for PASSporT, for agreed or vetted content to be included in or r
eferenced by the RCD claim contents. The primary framework for allowing the sepa
ration of authority and the signing of PASSporTs by non-authorized entities is d
etailed in <xref target="RFC9060"/>, although other cases may apply. As with the
first and second modes, the third and fourth modes differ with the absence or i
nclusion of referenced external content using URIs.</t>
</section>
<section anchor="rcd_define">
<name>"rcd" PASSporT Claim: Definition and Usage</name>
<section anchor="syntax">
<name>PASSporT "rcd" Claim</name>
<t>This document defines a new JSON Web Token claim for "rcd", Rich Call
Data, the value of which is a JSON object that can contain one or more key valu
e pairs. This document defines a default set of key values.</t>
<section anchor="nam-key">
<name>"nam" key</name>
<t>The "nam" key value is a display name, associated with the originat
or of personal communications, which may, for example, match the display-name co
mponent of the From header field value of a SIP request <xref target="RFC3261"/>
or alternatively of the P-Asserted-Identity header field value <xref target="RF
C3325"/>, or a similar field in other PASSporT using protocols. This key <bcp14>
MUST</bcp14> be included once as part of the "rcd" claim value JSON object. The
key syntax of "nam" <bcp14>MUST</bcp14> follow the display-name ABNF given in <x
ref target="RFC3261"/>. If there is no string associated with a display name, th
e claim value <bcp14>MUST</bcp14> be an empty string.</t>
</section>
<section anchor="apn-key">
<name>"apn" key</name>
<t>The "apn" key value is an optional alternate presentation number as
sociated with the originator of personal communications, which may, for example,
match the user component of the From header field value of a SIP request (in ca
ses where a network number is carried in the P-Asserted-Identity <xref target="R
FC3325"/>), or alternatively of the Additional-Identity header field value <xref
target="TS.3GPP.24.229"/>, or a similar field in other PASSporT-using protocols
. Its intended semantics are to convey a number that the originating user is aut
horized 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 thei
r personal telephone number. The "apn" key value is a canonicalized telephone nu
mber per <xref section="8.3" target="RFC8224" sectionFormat="comma"/>. If presen
t, this key <bcp14>MUST</bcp14> be included once as part of the "rcd" claim valu
e JSON object.</t>
<t>The use of the optional "apn" key is intended for cases where the s
igner of an "rcd" PASSporT or "rcd" claims authorizes the use of an alternate pr
esentation number by the user. How the signer determines that a user is authoriz
ed to present the number in question is a policy decision outside the scope of t
his document. However, the vetting of the alternate presentation number should f
ollow the same level of vetting as telephone identities or any other information
contained in an "rcd" PASSporT or "rcd" claims.
The use of the "apn" key is intended as an alternative to conveying the presenta
tion number 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 presen
t. "apn" <bcp14>MUST</bcp14> be used when it is the intent of the caller or sign
er to display the alternate presentation number even if "jcd" or "jcl" keys are
present in a PASSporT with a "tel" key value.</t>
</section>
<section anchor="icn-key">
<name>"icn" key</name>
<t>The "icn" key value is an optional HTTPS URL reference to an image
resource that can be used to pictorially represent the originator of personal co
mmunications. This icon key value should be used as a base or default method of
associating an image with a calling party.</t>
<t>When being used for SIP <xref target="RFC3261"/>, this claim key va
lue is used to protect the Call-Info header field with a purpose parameter value
of "icon" as described in <xref section="20.9" target="RFC3261"/>. For example
:</t>
<artwork><![CDATA[
Call-Info: <http://wwww.example.com/alice/photo.jpg>; Call-Info: <http://wwww.example.com/alice/photo.jpg>;
purpose=icon purpose=icon
]]></artwork></figure> ]]></artwork>
<t>Note that <xref target="RFC9796"/> extends the specific usage of "i
<t>Note that <xref target="I-D.ietf-sipcore-callinfo-rcd"/> extends the specific con" in SIP in the context of the larger rich call data framework with specific
usage of "icon" in SIP in the context of the larger rich call data framework wi guidance on referencing images and image types, sizes, and formats.</t>
th specific guidance on referencing images and image types, sizes and formats.</ <t>It should be also noted that with jCard, as described for "jcd" and
t> "jcl" key values (Sections <xref target="jcd-key" format="counter"/> and <xref
target="jcl-key" format="counter"/>) and in <xref target="RFC9796"/>, there are
<t>It should be also noted that with jCard, as described in the following "jcd" alternative ways of including photos and logos as HTTPS URL references. The "icn
and "jcl" key value sections and in <xref target="I-D.ietf-sipcore-callinfo-rcd" " key should be considered a base or default image, and jCard usage should be co
/>, there are alternative ways of including photos and logos as HTTPS URL refere nsidered for profiles and extensions that provide more direct guidance on the us
nces. The "icn" key should be then considered a base or default image and jCard age of what each image type represents for the proper rendering to end users.</t
usage should be considered for profiles and extensions that provide more direct >
guidance on the usage of specific defined usage of what each image type represen </section>
ts for the proper rendering to end users.</t> <section anchor="jcd-key">
<name>"jcd" key</name>
</section> <t>The "jcd" key value is defined to contain a jCard JSON object <xref
<section anchor="jcd-key"><name>"jcd" key</name> target="RFC7095"/>. The jCard is defined in this specification as an extensible
object format used to contain RCD information about the call initiator. This ob
<t>The "jcd" key value is defined to contain a jCard <xref target="RFC7095"/> JS ject is intended to directly match the Call-Info header field value defined in <
ON object. The jCard is defined in this specification as an extensible object fo xref target="RFC9796"/> with a type of "jcard", where the format of the jCard an
rmat used to contain RCD information about the call initiator. This object is in d properties used should follow the normative usage and formatting rules and pro
tended to directly match the Call-Info header field value defined in <xref targe cedures in that document. It is an extensible object where the calling party can
t="I-D.ietf-sipcore-callinfo-rcd"/> with a type of "jcard" where the format of t provide both the standard types of information defined in jCard or can use the
he jCard and properties used should follow the normative usage and formatting ru built-in extensibility of the jCard specification to add additional information.
les and procedures in that document. It is an extensible object where the callin The "jcd" key is optional. Either a "jcd" or "jcl" <bcp14>MAY</bcp14> appear in
g party can provide both the standard types of information defined in jCard or c the "rcd" claim, but not both.</t>
an use the built-in extensibility of the jCard specification to add additional i <t>The jCard object value for "jcd" <bcp14>MUST</bcp14> be a jCard JSO
nformation. The "jcd" key is optional. Either a "jcd" or "jcl" MAY appear in the N object that <bcp14>MAY</bcp14> have URI-referenced content, but that URI-refer
"rcd" claim, but not both.</t> enced content <bcp14>MUST NOT</bcp14> further reference URIs. Future specificati
ons may extend this capability, but <xref target="RFC9796"/> constrains the secu
<t>The jCard object value for "jcd" MUST be a jCard JSON object that MAY have UR rity properties of RCD information and the integrity of the content referenced b
I referenced content, but that URI referenced content MUST NOT further reference y URIs.</t>
URIs. Future specifications may extend this capability, but as stated in <xref <aside><t>Note: Even though we refer to <xref target="RFC9796"/> as th
target="I-D.ietf-sipcore-callinfo-rcd"/> it constrains the security properties o e definition of the jCard properties for usage in "rcd" claims, using the Call-I
f RCD information and the integrity of the content referenced by URIs.</t> nfo header field with RCD information in a SIP request beyond the use of identit
y header as defined in this document is not required. Identity header fields are
<t>Note: even though we refer to <xref target="I-D.ietf-sipcore-callinfo-rcd"/> generally encouraged for all transport of authenticated and protected RCD infor
as the definition of the jcard properties for usage in "rcd" claims, using Call- mation over Network-to-Network Interfaces (NNIs) between untrusted parties or ov
Info as protocol with the addition of an identity header carrying the PASSPorT i er untrusted networks. The use of Call-Info header fields to carry RCD informati
s not required. The identity header carrying a PASSporT with "rcd" claim includ on as defined in <xref target="RFC9796"/> is suggested for use in trusted networ
ing a "jcd" value can be used as the primary and only transport of the RCD infor ks relationships, generally for User-Network Interfaces (UNIs).</t></aside>
mation.</t> </section>
<section anchor="jcl-key">
</section> <name>"jcl" key</name>
<section anchor="jcl-key"><name>"jcl" key</name> <t>The "jcl" key value is an HTTPS URL that refers to a jCard JSON obj
ect <xref target="RFC7095"/> on a web server. The web server <bcp14>MUST</bcp14>
<t>The "jcl" key value is an HTTPS URL that refers to a jCard <xref target="RFC7 use the media type for JSON text as application/json with a default encoding of
095"/> JSON object on a web server. The web server MUST use the MIME media type UTF-8 <xref target="RFC8259"/>. This link may correspond to the Call-Info heade
for JSON text as application/json with a default encoding of UTF-8 <xref target= r field value defined in <xref target="RFC9796"/> with a type of "jcard". As als
"RFC8259"/>. This link may correspond to the Call-Info header field value define o defined in <xref target="RFC9796"/>, the format of the jCard and properties us
d in <xref target="I-D.ietf-sipcore-callinfo-rcd"/> with a type of "jcard". As a ed should follow the normative usage and formatting rules and procedures. The "j
lso defined in <xref target="I-D.ietf-sipcore-callinfo-rcd"/>, format of the jCa cl" key is optional. The "jcd" or "jcl" keys <bcp14>MAY</bcp14> only appear once
rd and properties used should follow the normative usage and formatting rules an in the "rcd" claim but <bcp14>MUST</bcp14> be mutually exclusive.</t>
d procedures. The "jcl" key is optional. The "jcd" or "jcl" keys MAY only appear <t>The jCard object referenced by the URI value for "jcl" <bcp14>MUST<
once in the "rcd" claim but MUST be mutually exclusive.</t> /bcp14> be a jCard JSON object that <bcp14>MAY</bcp14> have URI-referenced conte
nt, but that URI-referenced content <bcp14>MUST NOT</bcp14> further reference UR
<t>The jCard object referenced by the URI value for "jcl" MUST be a jCard JSON o Is. Future specifications may extend this capability, but <xref target="RFC9796"
bject that MAY have URI referenced content, but that URI referenced content MUST /> constrains the security properties of RCD information and the integrity of th
NOT further reference URIs. Future specifications may extend this capability, b e content referenced by URIs.</t>
ut as stated in <xref target="I-D.ietf-sipcore-callinfo-rcd"/> it constrains the </section>
security properties of RCD information and the integrity of the content referen </section>
ced by URIs.</t> </section>
<section anchor="rcdi_define">
</section> <name>"rcdi" PASSporT Claim: Definition and Usage</name>
</section> <t>The "rcdi" claim is included for the second and fourth modes described
</section> in the integrity overview (<xref target="rcdintegrity"/>). "rcdi" and "rcd" clai
<section anchor="rcdi_define"><name>"rcdi" RCD Integrity Claim Definition and Us ms <bcp14>MAY</bcp14> each appear once in a PASSporT, but if "rcdi" is included,
age</name> the "rcd" <bcp14>MUST</bcp14> be present correspondingly. The value of the "rcd
i" claim is a JSON object that is defined as follows.</t>
<t>The "rcdi" claim is included for the second and fourth modes described in the <t>The claim value of the "rcdi" claim key is a JSON object with a set of
integrity overview <xref target="rcdintegrity"/> of this document. "rcdi" and " JSON key/value pairs. Each "rcdi" claim key/value pair corresponds to each of th
rcd" claims MAY each appear once in a PASSporT, but if "rcdi" is included the "r e elements of the "rcd" claim object that require integrity protection with an a
cd" MUST correspondingly be present also. The value of the "rcdi" claim is a JSO ssociated digest over the content referenced by the key string. The individual d
N object that is defined as follows.</t> igest of different elements of the "rcd" claim data and URI-referenced external
content is kept specifically separate to allow the ability to verify the integri
<t>The claim value of "rcdi" claim key is a JSON object with a set of JSON key/v ty of only the elements that are ultimately retrieved, downloaded, or rendered t
alue pairs. These objects correspond to each of the elements of the "rcd" claim o the end user.</t>
object that require integrity protection with an associated digest over the cont <t>The key value references a specific object within the "rcd" claim value
ent referenced by the key string. The individual digest of different elements of using a JSON pointer defined in <xref target="RFC6901"/> with a minor additiona
the "rcd" claim data and URI referenced external content is kept specifically s l rule to support URI references to external content that include JSON objects t
eparate to allow the ability to verify the integrity of only the elements that a hemselves, for the specific case of the use of "jcl", defined in <xref target="j
re ultimately retrieved or downloaded or rendered to the end-user.</t> cl_element"/>. JSON pointer syntax is the key value that documents exactly the p
art of JSON that is used to generate the digest that produces the resulting stri
<t>The key value references a specific object within the "rcd" claim value using ng that makes up the value for the corresponding key. Detailed procedures are pr
a JSON pointer defined in <xref target="RFC6901"/> with a minor additional rule ovided below, but an example "rcdi" is provided here:</t>
to support URI references to external content that include JSON objects themsel <sourcecode type="json"><![CDATA[
ves, for the specific case of the use of "jcl", defined in <xref target="jcl_ele
ment"/>. JSON pointer syntax is the key value that documents exactly the part of
JSON that is used to generate the digest which produce the resulting string tha
t makes up the value for the corresponding key. Detailed procedures are provided
below, but an example "rcdi" is provided here:</t>
<figure><artwork><![CDATA[
"rcdi" : { "rcdi" : {
"/jcl": "sha256-7kdCBZqH0nqMSPsmABvsKlHPhZEStgjojhdSJGRr3rk", "/jcl": "sha256-7kdCBZqH0nqMSPsmABvsKlHPhZEStgjojhdSJGRr3rk",
"/jcl/1/2/3": "sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI" "/jcl/1/2/3": "sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI"
} }
]]></artwork></figure> ]]></sourcecode>
<t>The values of each key/value pair consists of a digest across one of th
<t>The values of each key/value pair consists of a digest across one of the foll e following objects referenced by the JSON pointer key:</t>
owing objects referenced by the JSON pointer key,</t> <ul spacing="normal">
<li>the content inline to the referenced object, </li>
<t><list style="symbols"> <li>the content of a resource referenced by an inline URI object, or</li
<t>content inline to the referenced object</t> >
<t>the content of a resource referenced by an inline URI object</t> <li>the content of a resource specified by a URI that is in embedded in
<t>the content of a resource specified by a URI that is in embedded in content content specified by an inline URI object (e.g., "jcl")</li>
specified by an inline URI object(e.g., jcl)</t> </ul>
</list></t> <t>This is combined with a string that defines the cryptographic algorithm
used to generate the digest. RCD implementations <bcp14>MUST</bcp14> support th
<t>This is combined with a string that defines the crypto algorithm used to gene e hash algorithms SHA-256, SHA-384, and SHA-512. These hash algorithms are iden
rate the digest. RCD implementations MUST support the hash algorithms SHA-256, S tified by "sha256", "sha384", and "sha512", respectively. SHA-256, SHA-384, and
HA-384, and SHA-512. These hash algorithms are identified by "sha256", "sha384" SHA-512 are part of the SHA-2 set of cryptographic hash functions <xref target=
, and "sha512", respectively. SHA-256, SHA-384, and SHA-512 are part of the SHA "RFC6234"/> defined by the US National Institute of Standards and Technology (NI
-2 set of cryptographic hash functions <xref target="RFC6234"/> defined by the U ST). Implementations <bcp14>MAY</bcp14> support additional recommended hash alg
S National Institute of Standards and Technology (NIST). Implementations MAY su orithms in <xref target="IANA-COSE-ALG"/>, that is, the hash algorithms with "Ye
pport additional recommended hash algorithms in <xref target="IANA-COSE-ALG"/>; s" in the "Recommended" column of the IANA registry. Hash algorithm identifiers
that is, the hash algorithm has "Yes" in the "Recommended" column of the IANA re <bcp14>MUST</bcp14> use only lowercase letters, and they <bcp14>MUST NOT</bcp14
gistry. Hash algorithm identifiers MUST use only lowercase letters, and they MU > contain hyphen characters. The character following the algorithm string <bcp14
ST NOT contain hyphen characters. The character following the algorithm string M >MUST</bcp14> be a hyphen character ("-", %x2D). The subsequent characters are t
UST be a hyphen character, "-", or ASCII 45. The subsequent characters are the b he base64 encoded <xref target="RFC4648"/> digest of a canonicalized and concate
ase64 encoded <xref target="RFC4648"/> digest of a canonicalized and concatenate nated string or binary data based on the JSON pointer referenced elements of the
d string or binary data based on the JSON pointer referenced elements of "rcd" c "rcd" claim or the URI-referenced content contained in the claim. The next sect
laim or the URI referenced content contained in the claim. The details of the de ion covers the details of the determination of the input string used to determin
termination of the input string used to determine the digest are defined in the e the digest.</t>
next section.</t>
<section anchor="creation-of-the-rcd-element-digests"><name>Creation of the "rcd
" element digests</name>
<t>"rcd" claim objects can contain "nam", "apn", "icn", "jcd", or "jcl" keys as
part of the "rcd" JSON object claim value. This document defines the use of JSON
pointer <xref target="RFC6901"/> as a mechanism to reference specific "rcd" cla
im elements.</t>
<t>In order to facilitate proper verification of the digests and whether the "rc
d" 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 t
he 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 eac
h digest. Third, when the "rcd" data is verified at the Verification Service, th
e verification is performed for each digest by constructing the input digest str
ing for the element being verified and referenced by the JSON pointer string.</t
>
<t>The procedure for the creation of each "rcd" element digest string correspond
ing to a JSON pointer string key is as follows.</t>
<t><list style="numbers">
<t>The JSON pointer either refers to a value that is a part or the whole of a
JSON object or to a string that is a URI referencing an external resource.</t>
<t>For a JSON value, serialize the JSON to remove all white space and line bre
aks. The procedures of this deterministic JSON serialization are defined in <xr
ef target="RFC8225"></xref>, Section 9. The resulting string is the input for t
he hash function.</t>
<t>For any URI referenced content, the bytes of the body of the HTTP response
is the input for the hash function.</t>
</list></t>
<t>Note that the digest is computed on the Json representation of the string, wh
ich necessarily includes the beginning and ending double-quote characters.</t>
<section anchor="nam_apn_element"><name>"nam" and "apn" elements</name>
<t>In the case of "nam" and "apn", the only allowed value is a string. For both
of these key values an "rcdi" JSON pointer or integrity digest is optional becau
se the direct value is protected by the signature and can be constrained directl
y with JWTClaimConstraints.</t>
</section>
<section anchor="icn_element"><name>"icn" elements</name>
<t>In the case of "icn", the only allowed value is a URI value that references a
n image file. If the URI references externally linked content there MUST be a JS
ON pointer and digest entry for the content in that linked resource. When creati
ng a key/value representing "icn", the key is the JSON pointer string "/icn" and
the digest value string would be created using the image file byte data referen
ced in the URI.</t>
</section>
<section anchor="jcd_element"><name>"jcd" elements</name>
<t>In the case of "jcd", the value associated is a jCard JSON object, which happ
ens to be a JSON array with sub-arrays. JSON pointer notation uses numeric indic
es into elements of arrays, including when those elements are arrays themselves.
</t>
<t>As example, for the following "rcd" claim:</t>
<figure><artwork><![CDATA[ <section anchor="creation-of-the-rcd-element-digests">
<name>Creation of the "rcd" Element Digests</name>
<t>"rcd" claim objects can contain "nam", "apn", "icn", "jcd", or "jcl"
keys as part of the "rcd" JSON object claim value. This document defines the use
of JSON pointer <xref target="RFC6901"/> as a mechanism to reference specific "
rcd" claim elements.</t>
<t>In order to facilitate proper verification of the digests and to dete
rmine whether the "rcd" elements or content referenced by URIs were modified, th
e input to the digest must be completely deterministic at three points in the pr
ocess. First, it must be deterministic at the certification point when the conte
nt is evaluated to conform to the application policy and when the JWT Claim Cons
traints are applied to the certificate containing the digest. Second, when the c
all is signed at the Authentication Service, there may be a local policy to veri
fy that the provided "rcd" claim corresponds to each digest. Third, when the "rc
d" data is verified at the verification service, the verification is performed f
or each digest by constructing the input digest string for the element being ver
ified and referenced by the JSON pointer string.</t>
<t>The procedure for the creation of each "rcd" element digest string co
rresponding to a JSON pointer string key is as follows.</t>
<ol spacing="normal" type="1"><li>The JSON pointer either refers to a va
lue that is a part or the whole of a JSON object or to a string that is a URI re
ferencing an external resource.</li>
<li>For a JSON value, serialize the JSON to remove all white space and
line breaks. The procedures of this deterministic JSON serialization are defin
ed in <xref section="9" target="RFC8225" sectionFormat="comma"/>. The resulting
string is the input for the hash function.</li>
<li>For any URI-referenced content, the bytes of the body of the HTTP
response are the input for the hash function.</li>
</ol>
<t>Note that the digest is computed on the JSON representation of the st
ring, which necessarily includes the beginning and ending double-quote character
s.</t>
<section anchor="nam_apn_element">
<name>"nam" and "apn" Elements</name>
<t>In the case of "nam" and "apn", the only allowed value is a string.
For both of these key values, an "rcdi" JSON pointer or integrity digest is opt
ional because the direct value is protected by the signature and can be constrai
ned directly with JWT Claim Constraints.</t>
</section>
<section anchor="icn_element">
<name>"icn" Elements</name>
<t>In the case of "icn", the only allowed value is a URI value that re
ferences an image file. If the URI references externally linked content, there <
bcp14>MUST</bcp14> be a JSON pointer and digest entry for the content in that li
nked resource. When creating a key/value representing "icn", the key is the JSON
pointer string "/icn", and the digest value string is created using the image f
ile byte data referenced in the URI.</t>
</section>
<section anchor="jcd_element">
<name>"jcd" Elements</name>
<t>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 notation uses num
eric indices into elements of arrays, including when those elements are arrays t
hemselves.</t>
<t>As an example, we have the following "rcd" claim:</t>
<sourcecode type="json"><![CDATA[
"rcd": { "rcd": {
"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"]
] ]
], ],
"nam": "Q Branch Spy Gadgets" "nam": "Q Branch Spy Gadgets"
} }
]]></artwork></figure> ]]></sourcecode>
<t>In order to use a JSON pointer to refer to the URIs, the following
<t>In order to use JSON pointer to refer to the URIs, the following example "rcd example "rcdi" claim includes a digest for the entire "jcd" array string as well
i" claim includes a digest for the entire "jcd" array string as well as three ad as three additional digests for the URIs, where, as defined in <xref target="RF
ditional digests for the URIs, where, as defined in <xref target="RFC6901"/> zer C6901"/>, zero-based array indices are used to reference the URI strings.</t>
o-based array indices are used to reference the URI strings.</t> <sourcecode type="json"><![CDATA[
<figure><artwork><![CDATA[
"rcdi": { "rcdi": {
"/jcd": "sha256-7kdCBZqH0nqMSPsmABvsKlHPhZEStgjojhdSJGRr3rk", "/jcd": "sha256-7kdCBZqH0nqMSPsmABvsKlHPhZEStgjojhdSJGRr3rk",
"/jcd/1/3/3": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4", "/jcd/1/3/3": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4",
"/jcd/1/4/3": "sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI", "/jcd/1/4/3": "sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI",
"/jcd/1/5/3": "sha256-GKNxxqlLRarbyBNh7hc/4lbZAdK6B0kMRf1AMRWPkSo" "/jcd/1/5/3": "sha256-GKNxxqlLRarbyBNh7hc/4lbZAdK6B0kMRf1AMRWPkSo"
} }
} }
]]></artwork></figure> ]]></sourcecode>
<t>The use of a JSON pointer and integrity digest for the "jcd" claim
<t>The use of a JSON pointer and integrity digest for the "jcd" claim key and va key and value is optional. The "jcd" value is the directly included jCard array;
lue is optional. The "jcd" value is the directly included jCard array and can be it can be protected by the signature and can be constrained directly with JWT C
protected by the signature and can be constrained directly with JWTClaimConstra laim Constraints. However, for data length reasons (as with "icn" above) or mor
ints. However, for data length reasons (as with "icn" above) or more importantl e importantly for potential privacy and/or security considerations with a public
y for potential privacy and/or security considerations with a publically accessi ly accessible certificate, the use of the "rcdi" JSON pointer and integrity dige
ble certificate, the use of the "rcdi" JSON pointer and integrity digest as the st as the constraint value in JWT Claim Constraints over the jCard data is <bcp1
constraint value in JWTClaimConstraints over the jCard data is RECOMMENDED.</t> 4>RECOMMENDED</bcp14>.</t>
<t>It is important to remember the array indices for JSON pointer are
<t>It is important to remember the array indices for JSON Pointer are dependent dependent on the order of the elements in the jCard. The use of digest for the "
on the order of the elements in the jCard. The use of digest for the "/jcd" corr /jcd" corresponding to the entire jCard array string can be included as a redund
esponding to the entire jCard array string can be included as a redundant mechan ant mechanism to avoid any possibility of substitution, insertion attacks, or ot
ism to avoid any possibility of substitution, insertion attacks, or other potent her potential techniques to undermine integrity detection.</t>
ial techniques that may be possible to avoid integrity detection.</t> <t>Each URI referenced in the jCard array string <bcp14>MUST</bcp14> h
ave a corresponding JSON pointer string key and digest value.</t>
<t>Each URI referenced in the jCard array string MUST have a corresponding JSON </section>
pointer string key and digest value.</t> <section anchor="jcl_element">
<name>"jcl" Elements</name>
</section> <t>
<section anchor="jcl_element"><name>"jcl" elements</name> In the case of the use of a "jcl" URI reference to an external jCard,
the procedures are similar to "jcd" with the minor
<t>In the case of the use of a "jcl" URI reference to an external jCard, the pro modification to the JSON pointer, where "/jcl" is used to refer to the
cedures are similar to "jcd" with the exception and the minor modification to JS external jCard array string. Also, any following numeric array indices
ON pointer, where "/jcl" is used to refer to the external jCard array string and added to the "jcl" (e.g., "/jcl/1/2/3") are treated as if the
any following numeric array indices added to the "jcl" (e.g., "/jcl/1/2/3") are external content referenced by the jCard were directly part of the
treated as if the external content referenced by the jCard was directly part of overall "rcd" claim JSON object. The following example illustrates a "jcl" ve
the overall "rcd" claim JSON object. The following example illustrates a "jcl" rsion of the above "jcd" example.</t>
version of the above "jcd" example.</t> <sourcecode type="json"><![CDATA[
<figure><artwork><![CDATA[
"rcd": { "rcd": {
"jcl": "https://example.com/qbranch.json", "jcl": "https://example.com/qbranch.json",
"nam": "Q Branch Spy Gadgets" "nam": "Q Branch Spy Gadgets"
}, },
"rcdi": { "rcdi": {
"/jcl": "sha256-7kdCBZqH0nqMSPsmABvsKlHPhZEStgjojhdSJGRr3rk", "/jcl": "sha256-7kdCBZqH0nqMSPsmABvsKlHPhZEStgjojhdSJGRr3rk",
"/jcl/1/3/3": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4", "/jcl/1/3/3": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4",
"/jcl/1/4/3": "sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI", "/jcl/1/4/3": "sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI",
"/jcl/1/5/3": "sha256-GKNxxqlLRarbyBNh7hc/4lbZAdK6B0kMRf1AMRWPkSo" "/jcl/1/5/3": "sha256-GKNxxqlLRarbyBNh7hc/4lbZAdK6B0kMRf1AMRWPkSo"
} }
]]></artwork></figure> ]]></sourcecode>
<t>The "rcdi" <bcp14>MUST</bcp14> have a "/jcl" key value and digest v
<t>The "rcdi" MUST have a "/jcl" key value and digest value to protect the refer alue to protect the referenced jCard object, and each URI referenced in the refe
enced jCard object and each URI referenced in the referenced jCard array string renced jCard array string <bcp14>MUST</bcp14> have a corresponding JSON pointer
MUST have a corresponding JSON pointer string key and digest value.</t> string key and digest value.</t>
<t>The following is the example contents of the resource pointed to by
<t>The following is the example contents of resource pointed to by https://examp https://example.com/qbranch.json; it is used to calculate the above digest for
le.com/qbranch.json used to calculate the above digest for "/jcl"</t> "/jcl"</t>
<sourcecode type="json"><![CDATA[
<figure><artwork><![CDATA[
["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"]
] ]
] ]
]]></artwork></figure> ]]></sourcecode>
</section>
</section> </section>
</section> <section anchor="jwt-claim-constraints-for-rcd-claims">
<section anchor="jwt-claim-constraints-for-rcd-claims"><name>JWT Claim Constrain <name>JWT Claim Constraints for "rcd" Claims</name>
ts for "rcd" claims</name> <t>When using JWT Claim Constraints for "rcd" claims, the procedure when
creating the signing certificate should adhere to the following guidelines.</t>
<t>When using JWT Claim Constraints for "rcd" claims the procedure when creating <t>The "permittedValues" for the "rcd" claim <bcp14>MAY</bcp14> contain
the signing certificate should follow the following guidelines.</t> a single entry or optionally <bcp14>MAY</bcp14> contain multiple entries with th
e intent of supporting cases where the certificate holder is authorized to use d
<t>The "permittedValues" for the "rcd" claim MAY contain a single entry or optio ifferent sets of rich call data corresponding to different call scenarios.</t>
nally MAY contain multiple entries with the intent of supporting cases where the <t>Only including "permittedValues" for "rcd", with no "mustInclude", pr
certificate holder is authorized to use different sets of rich call data corres ovides the ability for the construction a valid PASSporT that can either have no
ponding to different call scenarios.</t> "rcd" claim within or only the set of constrained "permittedValues" values for
an included "rcd" claim.</t>
<t>Only including "permittedValues" for "rcd", with no "mustInclude", provides t </section>
he ability for the construction a valid PASSPorT that can either have no "rcd" c <section anchor="jwt-claim-constraints-usage-for-rcd-and-rcdi-claims">
laim within or only the set of constrained "permittedValues" values for an inclu <name>JWT Claim Constraints for "rcd" and "rcdi" Claims</name>
ded "rcd" claim.</t> <t>The use of JWT Claim Constraints with an "rcdi" claim is for cases where URI-
referenced content is to be protected by the authoritative certificate issuer. T
</section> he objective for the use of JWT Claim Constraints for the combination of both "r
<section anchor="jwt-claim-constraints-usage-for-rcd-and-rcdi-claims"><name>JWT cd" and "rcdi" claims is to constrain the signer to only construct the "rcd" and
Claim Constraints usage for "rcd" and "rcdi" claims</name> "rcdi" claims inside a PASSporT to contain and reference only a predetermined s
et of content. Once both the contents of the "rcd" claim and any referenced cont
<t>The use of JWT Claim Constraints with an "rcdi" claim is for cases where URI ent are certified by the party that is authoritative for the certificate being i
referenced content is to be protected by the authoritative certificate issuer. T ssued to the signer, the "rcdi" claim is constructed and linked to the STIR cert
he objective for the use of JWT Claim Constraints for the combination of both "r ificate associated with the signature in the PASSporT via the JWT Claim Constrai
cd" and "rcdi" claims is to constrain the signer to only construct the "rcd" and nts extension as defined in <xref section="8" target="RFC8226" sectionFormat="co
"rcdi" claims inside a PASSporT to contain and reference only a pre-determined mma"/> and extended in <xref target="RFC9118"/>. It should be recognized that th
set of content. Once both the contents of the "rcd" claim and any referenced con e "rcdi" set of digests is intended to be unique for only a specific combination
tent is certified by the party that is authoritative for the certificate being i of "rcd" content and URI-referenced external content, and therefore the set pro
ssued to the signer, the "rcdi" claim is constructed and linked to the STIR cert vides a robust integrity mechanism for an authentication service being performed
ificate associated with the signature in the PASSporT via JWT Claim Constraints by a non-authoritative party.
extension as defined in <xref target="RFC8226"/> Section 8 and extended in <xref For example, this may be used with delegate certificates [RFC9060]
target="RFC9118"/>. It should be recognized that the "rcdi" set of digests is i for the signing of calls by the calling party directly, even though
ntended to be unique for only a specific combination of "rcd" content and URI re the "authorized party" is not necessarily the subject of a STIR
ferenced external content, and therefore provides a robust integrity mechanism f certificate.</t>
or an authentication service being performed by a non-authoritative party. This <t>For the cases where both "rcd" and "rcdi" claims should always be inc
would often be associated with the use of delegate certificates <xref target="RF luded in the PASSporT, the certificate JWT Claims Constraint extension <bcp14>MU
C9060"/> for the signing of calls by the calling party directly as an example, e ST</bcp14> include both of the following:</t>
ven though the "authorized party" is not necessarily the subject of a STIR certi <ul spacing="normal">
ficate.</t> <li>a "mustInclude" for the "rcd" claim, which simply constrains the f
act that an "rcd" must be included</li>
<t>For the cases that there should always be both "rcd" and "rcdi" claims includ <li>a "mustInclude" for the "rcdi" claim and a "permittedValues" equal
ed in the PASSporT, the certificate JWT Claims Constraint extension MUST include to the created "rcdi" claim value string.</li>
both of the following:</t> </ul>
<t>Note that optionally the "rcd" claims may be included in the "permitt
<t><list style="symbols"> edValues"; however, it is recognized that this may be redundant with the "rcdi"
<t>a "mustInclude" for the "rcd" claim, which simply constrains the fact that permittedValues because the "rcdi" digest will imply the content of the "rcd" cl
an "rcd" must be included</t> aims themselves.</t>
<t>a "mustInclude" for the "rcdi" claim and a "permittedValues" equal to the c <t>The "permittedValues" for the "rcdi" claims (or "rcd" claims more gen
reated "rcdi" claim value string.</t> erally) may contain multiple entries to support the case where the certificate h
</list></t> older is authorized to use different sets of RCD.</t>
</section>
<t>Note that optionally the "rcd" claims may be included in the "permittedValues </section>
" however it is recognized that this may be redundant with the "rcdi" permittedV <section anchor="crn_define">
alues because the "rcdi" digest will imply the content of the "rcd" claims thems <name>"crn" PASSporT Claim: Definition and Usage</name>
elves.</t> <t>This document defines a new JSON Web Token claim for "crn", Call Reason
, the value of which is a single string that can contain information as defined
<t>The "permittedValues" for the "rcdi" claims (or "rcd" claims more generally) in <xref target="RFC9796"/> and corresponding to the "call-reason" parameter for
may contain multiple entries, to support the case where the certificate holder i the Call-Info header. This claim is optional.</t>
s authorized to use different sets of rich call data.</t> <sourcecode type="json"><![CDATA[
</section>
</section>
<section anchor="crn_define"><name>PASSporT "crn" claim - Call Reason Definition
and Usage</name>
<t>This document defines a new JSON Web Token claim for "crn", Call Reason, the
value of which is a single string that can contain information as defined in <xr
ef target="I-D.ietf-sipcore-callinfo-rcd"/> corresponding to the "call-reason" p
arameter for the Call-Info header. This claim is optional.</t>
<figure><artwork><![CDATA[
Example "crn" claim with "rcd": Example "crn" claim with "rcd":
"crn" : "For your ears only", "crn" : "For your ears only",
"rcd": { "nam": "James Bond", "rcd": { "nam": "James Bond",
"jcl": "https://example.org/james_bond.json"} "jcl": "https://example.org/james_bond.json"}
]]></artwork></figure> ]]></sourcecode>
<section anchor="jwt-constraint-for-crn-claim">
<section anchor="jwt-constraint-for-crn-claim"><name>JWT Constraint for "crn" cl <name>JWT Constraint for "crn" Claim</name>
aim</name> <t>The integrity of the "crn" claim contents can optionally be protected
by the authoritative certificate issuer using JWT Claim Constraints in the cert
<t>The integrity of the "crn" claim contents can optionally be protected by the ificate. When the signer of the PASSporT intends to always include a call reason
authoritative certificate issuer using JWT Constraints in the certificate. When string of any value, a "mustInclude" for the "crn" claim in the JWT Claim Const
the signer of the PASSporT intends to always include a call reason string of any raints indicates that a "crn" claim must always be present and is <bcp14>RECOMME
value, a "mustInclude" for the "crn" claim in the JWT Claim Constraints indicat NDED</bcp14> to be included by the certificate issuer. If the signer of the "crn
es that a "crn" claim must always be present and is RECOMMENDED to be included b " claim wants to constrain the contents of "crn", then "permittedValues" for "cr
y the certificate issuer. If the signer of the "crn" claim wants to constrain th n" in JWT Claim Constraints should match the contents of the allowed strings and
e contents of "crn", then "permittedValues" for "crn" in JWT Claim Constraints s is <bcp14>RECOMMENDED</bcp14> to be included by the certificate issuer.</t>
hould match the contents of the allowed strings and is RECOMMENDED to be include </section>
d by the certificate issuer.</t> </section>
<section anchor="rich-call-data-claims-usage-rules">
</section> <name>Rich Call Data Claims Usage Rules</name>
</section> <t>The "rcd" or "crn" claims <bcp14>MAY</bcp14> appear in any PASSporT cla
<section anchor="rich-call-data-claims-usage-rules"><name>Rich Call Data Claims ims object as optional elements. The creator of a PASSporT <bcp14>MAY</bcp14> al
Usage Rules</name> so add a PASSporT extension ("ppt") value, defined in <xref section="8.1" target
="RFC8225" sectionFormat="comma"/>, of "rcd" to the header of a PASSporT. In tha
<t>The "rcd" or "crn" claims MAY appear in any PASSporT claims object as optiona t case, the PASSporT claims <bcp14>MUST</bcp14> contain at least one "rcd" or "c
l elements. The creator of a PASSporT MAY also add a PASSporT extension ("ppt") rn" claim (or both). Any entities verifying the PASSporT claims defined in this
value, defined in <xref target="RFC8225"/> Section 8.1, of "rcd" to the header o document are required to understand the PASSporT extension in order to process t
f a PASSporT as well, in which case the PASSporT claims MUST contain at least on he PASSporT in question. An example PASSporT header with the PASSporT extension
e or both an "rcd" or "crn" claim. Any entities verifying the PASSporT claims de ("ppt") value of "rcd" included is shown as follows:</t>
fined in this document are required to understand the PASSporT extension in orde <sourcecode type=""><![CDATA[
r to process the PASSporT in question. An example PASSporT header with the PASSp
orT extension ("ppt") value of "rcd" included is shown as follows:</t>
<figure><artwork><![CDATA[
{ "typ":"passport", { "typ":"passport",
"ppt":"rcd", "ppt":"rcd",
"alg":"ES256", "alg":"ES256",
"x5u":"https://www.example.com/cert.cer" } "x5u":"https://www.example.com/cert.cer" }
]]></artwork></figure> ]]></sourcecode>
<t>The PASSporT claims object contains the "rcd" key with its correspondin
<t>The PASSporT claims object contains the "rcd" key with its corresponding valu g value. The value of "rcd" is an array of JSON objects, of which one, the "nam"
e. The value of "rcd" is an array of JSON objects, of which one, the "nam" key a key and value, is mandatory.</t>
nd value, is mandatory.</t> <t>After the header and claims PASSporT objects have been constructed, the
ir signature is computed normally per the guidance in <xref target="RFC8225"/>.<
<t>After the header and claims PASSporT objects have been constructed, their sig /t>
nature is computed normally per the guidance in <xref target="RFC8225"/>.</t> <section anchor="rcd_passport_verification">
<name>"rcd" PASSporT Verification</name>
<section anchor="rcd_passport_verification"><name>"rcd" PASSporT Verification</n <t>A verifier that successfully verifies a PASSporT that contains an "rc
ame> d" claim <bcp14>MUST</bcp14> ensure the following about the PASSporT:</t>
<ul spacing="normal">
<t>A verifier that successfully verifies a PASSportT that contains an "rcd" clai <li>It has a valid signature per the verification procedures detailed
m MUST ensure the following about the PASSporT:</t> in <xref target="RFC8225"/>.</li>
<li>It abides by all rules set forth in the proper construction of the
<t><list style="symbols"> claims defined in <xref target="rcd_define"/>.</li>
<t>it has a valid signature per the verification procedures detailed in <xref <li>It abides by JWT Claims Constraint rules defined in <xref section=
target="RFC8225"/></t> "8" target="RFC8226" sectionFormat="comma"/> or extended by <xref target="RFC911
<t>it abides by all rules set forth in the proper construction of the claims d 8"/> if present in the certificate used to compute the signature in the PASSporT
efined in <xref target="rcd_define"/> of this document</t> .</li>
<t>it abides by JWT Claims Constraint rules defined in <xref target="RFC8226"/ </ul>
> Section 8 or extended in <xref target="RFC9118"/> if present in the certificat <t>In addition, if the "iss" claim is included in the PASSporT, verifica
e used to compute the signature in the PASSporT</t> tion should follow procedures described in <xref target="thirdsignverify"/>.</t>
</list></t> <t>Consistent with the verification rules of PASSporTs more generally <x
ref target="RFC8225"/>, if any of the above criteria is not met, relying parties
<t>In addition if the "iss" claim is included in the PASSPorT, verification shou <bcp14>MUST NOT</bcp14> use any of the claims in the PASSporT.</t>
ld follow procedures described in <xref target="thirdsignverify"/>.</t> </section>
<section anchor="rcdi-integrity-verification">
<t>Consistent with the verification rules of PASSporTs more generally <xref targ <name>"rcdi" Integrity Verification</name>
et="RFC8225"/>, if any of the above criteria is not met, relying parties MUST NO <t>When the "rcdi" claim exists, the verifier should verify the digest f
T use any of the claims in the PASSporT.</t> or each JSON pointer key. Any digest string that doesn't match a generated dige
st <bcp14>MUST</bcp14> be considered a failure of the verification of the conten
</section> t referenced by the JSON pointer.</t>
<section anchor="rcdi-integrity-verification"><name>"rcdi" Integrity Verificatio <t>If there is any issue with completing the integrity verification proc
n</name> edures for referenced external content, including HTTP or HTTPS errors, the refe
renced content <bcp14>MUST</bcp14> be considered not verified. However, this <b
<t>When the "rcdi" claim exists, the verifier should verify the digest for each cp14>SHOULD NOT</bcp14> impact the result of base PASSporT verification for clai
JSON pointer key. Any digest string that doesn't match a generated digest MUST ms content that is directly included in the claims of the PASSporT.</t>
be considered a failure of the verification of the content referenced by the JSO <t>As a potential optimization of verification procedures, an entity tha
N pointer.</t> t does not otherwise need to dereference a URI from the "rcd" claim for display
to the end user is <bcp14>NOT RECOMMENDED</bcp14> to unnecessarily dereference t
<t>If there is any issue with completing the integrity verification procedures f he URI solely to perform integrity verification.</t>
or referenced external content, including HTTP or HTTPS errors, the referenced c </section>
ontent MUST be considered not verified. This SHOULD NOT however impact the resu <section anchor="example-rcd-passports">
lt of base PASSporT verification for claims content that is directly included in <name>Example "rcd" PASSporTs</name>
the claims of the PASSporT.</t> <t>An example of a "nam"-only PASSporT claims object is shown next (with
line breaks for readability only).</t>
<t>As a potential optimization of verification procedure, an entity that does no <sourcecode type=""><![CDATA[
t otherwise need to dereference a URI from the "rcd" claim for display to end-us
er is NOT RECOMMENDED to unnecessarily dereference the URI solely to perform int
egrity verification.</t>
</section>
<section anchor="example-rcd-passports"><name>Example "rcd" PASSporTs</name>
<t>An example of a "nam" only PASSporT claims object is shown next (with line br
eaks for readability only).</t>
<figure><artwork><![CDATA[
{ "orig":{"tn":"12025551000"}, { "orig":{"tn":"12025551000"},
"dest":{"tn":["12025551001"]}, "dest":{"tn":["12025551001"]},
"iat":1443208345, "iat":1443208345,
"rcd":{"nam":"James Bond"} } "rcd":{"nam":"James Bond"} }
]]></artwork></figure> ]]></sourcecode>
<t>An example of a "nam", "apn", and "icn" using an https URI PASSporT c
<t>An example of a "nam", "apn", and "icn" using an https URI PASSporT claims ob laims object is shown next (with line breaks for readability only). Note, in thi
ject is shown next (with line breaks for readability only). Note, in this exampl s example, there is no integrity protection over the "icn" element in the "rcd"
e, there is no integrity protection over the "icn" element in the "rcd" claim.</ claim.</t>
t> <sourcecode type=""><![CDATA[
<figure><artwork><![CDATA[
{ "orig":{"tn":"12025551000"}, { "orig":{"tn":"12025551000"},
"dest":{"tn":["12155551001"]}, "dest":{"tn":["12155551001"]},
"iat":1443208345, "iat":1443208345,
"rcd":{ "rcd":{
"apn":"12025559990", "apn":"12025559990",
"icn":"https://example.com/photos/quartermaster-256x256.png", "icn":"https://example.com/photos/quartermaster-256x256.png",
"nam":"Her Majesty's Secret Service" } } "nam":"Her Majesty's Secret Service" } }
]]></artwork></figure> ]]></sourcecode>
<t>An example of a "nam", "apn", and "icn" using data URI PASSporT claim
<t>An example of a "nam", "apn", and "icn" using data URI PASSporT claims object s object is shown next (with line breaks for readability only). Note, in this ex
is shown next (with line breaks for readability only). Note, in this example, t ample, the "icn" data is incorporated directly in the "rcd" claim, and therefore
he "icn" data is incorporated directly in the "rcd" claim and therefore separate separate integrity protection is not required.</t>
integrity protection is not required.</t> <sourcecode type=""><![CDATA[
<figure><artwork><![CDATA[
{ "orig":{"tn":"12025551000"}, { "orig":{"tn":"12025551000"},
"dest":{"tn":["12155551001"]}, "dest":{"tn":["12155551001"]},
"iat":1443208345, "iat":1443208345,
"rcd":{ "rcd":{
"apn":"12025559990", "apn":"12025559990",
"icn":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAY "icn":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAY
AAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OH AAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OH
wAAAABJRU5ErkJggg==", wAAAABJRU5ErkJggg==",
"nam":"Her Majesty's Secret Service" } } "nam":"Her Majesty's Secret Service" } }
]]></artwork></figure> ]]></sourcecode>
<t>An example of an "rcd" claims object that includes the "jcd" and also
<t>An example of an "rcd" claims object that includes the "jcd" and also contain contains URI references to content, which require the inclusion of an "rcdi" cl
s URI references to content which requires the inclusion of an "rcdi" claim and aim and corresponding digests. Note, in this example, the "rcdi" claim includes
corresponding digests. Note, in this example, the "rcdi" claim includes integrit integrity protection of the URI-referenced content.</t>
y protection of the URI referenced content.</t> <sourcecode type=""><![CDATA[
<figure><artwork><![CDATA[
{ {
"crn": "Rendezvous for Little Nellie", "crn": "Rendezvous for Little Nellie",
"orig": { "tn": "12025551000"}, "orig": { "tn": "12025551000"},
"dest": { "tn": ["12155551001"]}, "dest": { "tn": ["12155551001"]},
"iat": 1443208345, "iat": 1443208345,
"rcd": { "rcd": {
"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"],
skipping to change at line 423 skipping to change at line 370
["logo",{},"uri","https://example.com/logos/mi6-64x64.jpg"] ["logo",{},"uri","https://example.com/logos/mi6-64x64.jpg"]
] ], ] ],
"nam": "Q Branch Spy Gadgets" "nam": "Q Branch Spy Gadgets"
}, },
"rcdi": { "rcdi": {
"/jcd/1/3/3":"sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4", "/jcd/1/3/3":"sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4",
"/jcd/1/4/3":"sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI", "/jcd/1/4/3":"sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI",
"/jcd/1/5/3":"sha256-GKNxxqlLRarbyBNh7hc/4lbZAdK6B0kMRf1AMRWPkSo" "/jcd/1/5/3":"sha256-GKNxxqlLRarbyBNh7hc/4lbZAdK6B0kMRf1AMRWPkSo"
} }
} }
]]></artwork></figure> ]]></sourcecode>
<t>In an example PASSporT, where a jCard is linked via HTTPS URL using "jcl", a
jCard file served at a particular URL.</t>
<t>An example jCard JSON file hosted at the example web address of https://examp <t>In the following PASSporT example, a jCard is linked via HTTPS URL
le.com/qbranch.json is shown as follows:</t> using "jcl", and a jCard file is served at a particular URL.</t>
<figure><artwork><![CDATA[ <t>Example jCard JSON file hosted at https://example.com/qbranch.json:</t>
<sourcecode type="json"><![CDATA[
["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"]
] ]
] ]
]]></artwork></figure> ]]></sourcecode>
<t>For the above referenced jCard, the corresponding PASSporT claims obj
<t>For the above referenced jCard, the corresponding PASSporT claims object woul ect would be as follows:</t>
d be as follows:</t> <sourcecode type=""><![CDATA[
<figure><artwork><![CDATA[
{ {
"crn": "Rendezvous for Little Nellie", "crn": "Rendezvous for Little Nellie",
"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"
}, },
"rcdi": { "rcdi": {
"/jcl":"sha256-qCn4pEH6BJu7zXndLFuAP6DwlTv5fRmJ1AFkqftwnCs", "/jcl":"sha256-qCn4pEH6BJu7zXndLFuAP6DwlTv5fRmJ1AFkqftwnCs",
"/jcl/1/3/3":"sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4", "/jcl/1/3/3":"sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4",
"/jcl/1/4/3":"sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI", "/jcl/1/4/3":"sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI",
"/jcl/1/5/3":"sha256-GKNxxqlLRarbyBNh7hc/4lbZAdK6B0kMRf1AMRWPkSo" "/jcl/1/5/3":"sha256-GKNxxqlLRarbyBNh7hc/4lbZAdK6B0kMRf1AMRWPkSo"
} }
} }
]]></artwork></figure> ]]></sourcecode>
<t>An example "rcd" PASSporT that uses "nam" and "icn" keys with "rcdi"
<t>An example "rcd" PASSporT that uses "nam" and "icn" keys with "rcdi" for call for calling name and referenced icon image content:</t>
ing name and referenced icon image content:</t> <sourcecode type=""><![CDATA[
<figure><artwork><![CDATA[
{ {
"crn": "Rendezvous for Little Nellie", "crn": "Rendezvous for Little Nellie",
"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",
"icn": "https://example.com/photos/q-256x256.png" "icn": "https://example.com/photos/q-256x256.png"
}, },
"rcdi": { "rcdi": {
"/nam": "sha256-sM275lTgzCte+LHOKHtU4SxG8shlOo6OS4ot8IJQImY", "/nam": "sha256-sM275lTgzCte+LHOKHtU4SxG8shlOo6OS4ot8IJQImY",
"/icn": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4" "/icn": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4"
} }
} }
]]></artwork></figure> ]]></sourcecode>
</section>
</section> </section>
</section> <section anchor="compact-form-of-rcd-passport">
<section anchor="compact-form-of-rcd-passport"><name>Compact form of "rcd" PASSp <name>Compact Form of "rcd" PASSporT</name>
orT</name> <section anchor="compact-form-of-the-rcd-passport-claim">
<name>Compact Form of the "rcd" PASSporT Claim</name>
<section anchor="compact-form-of-the-rcd-passport-claim"><name>Compact form of t <t>The specific usage of the compact form of an "rcd" PASSporT claim, de
he "rcd" PASSporT claim</name> fined in <xref section="7" target="RFC8225" sectionFormat="comma"/>, has some re
strictions that will be enumerated below, but it mainly follows standard PASSpor
<t>The specific usage of compact form of an "rcd" PASSporT claim, defined in <xr T compact form procedures. Compact form only provides the signature from the PAS
ef target="RFC8225"/> Section 7, has some restrictions that will be enumerated b SporT, requiring the reconstruction of the other PASSporT claims from the SIP he
elow, but mainly follows standard PASSporT compact form procedures. Compact form ader fields as discussed in <xref section="4.1" target="RFC8224"/>.</t>
only provides the signature from the PASSporT, requiring the re-construction of <t>The reconstruction of the "nam" claim, if using the SIP protocol, sho
the other PASSporT claims from the SIP header fields as discussed in <xref targ uld use the display-name string in the From header field. For other protocols, i
et="RFC8224"/> Section 4.1.</t> f there is a display name field that exists, the string should be used; otherwis
e, the string should be an empty string, e.g., "". The claims "jcl" and "jcd" <b
<t>The re-construction of the "nam" claim, if using SIP protocol, should use the cp14>MUST NOT</bcp14> be used with compact form because the integrity rules and
display-name string in the From header field. For other protocols, if there is URI reference rules defined in this document would lead a set of constraints th
a display name field that exists, the string should be used, otherwise the strin at is too restrictive. Future specifications may revisit this to propose a consi
g should be an empty string, e.g., "". "jcl" and "jcd" MUST NOT be used with com stent and comprehensive way of addressing integrity and security of information
pact form due to integrity rules and URI reference rules in this document leadin and to provide specific guidance for other protocol usage.</t>
g to too restrictive of a set of constraints. Future specifications may revisit </section>
this to propose a consistent and comprehensive way of addressing integrity and s <section anchor="compact-form-of-the-rcdi-passport-claim">
ecurity of information and to provide specific guidance for other protocol usage <name>Compact Form of the "rcdi" PASSporT Claim</name>
.</t> <t>The use of the compact form of a PASSporT using an "rcdi" claim is no
t supported, so if "rcdi" is required, compact form <bcp14>MUST NOT</bcp14> be u
</section> sed.</t>
<section anchor="compact-form-of-the-rcdi-passport-claim"><name>Compact form of </section>
the "rcdi" PASSporT claim</name> <section anchor="compact-form-of-the-crn-passport-claim">
<name>Compact Form of the "crn" PASSporT Claim</name>
<t>The use of compact form of a PASSporT using an "rcdi" claim is not supported, <t>Compact form of a "crn" PASSporT claim shall be reconstructed using t
so if "rcdi" is required compact form MUST NOT be used.</t> he "call-reason" parameter of a Call-Info header as defined by <xref target="RFC
9796"/>.</t>
</section> </section>
<section anchor="compact-form-of-the-crn-passport-claim"><name>Compact form of t </section>
he "crn" PASSporT claim</name> <section anchor="parties">
<name>Third-Party Uses</name>
<t>Compact form of a "crn" PASSporT claim shall be re-constructed using the "cal <t>While rich data about the call can be provided by an originating authen
l-reason" parameter of a Call-Info header as defined by <xref target="I-D.ietf-s tication service, an intermediary in the call path could also acquire rich call
ipcore-callinfo-rcd"/>.</t> data by querying a third-party service. Such a service effectively acts as a STI
R Authentication Service, generating its own PASSporT, and that PASSporT could b
</section> e attached to a call by either the originating or terminating side. This third-p
</section> arty PASSporT attests information about the calling number, rather than the call
<section anchor="parties"><name>Third-Party Uses</name> or caller itself, and as such its RCD <bcp14>MUST NOT</bcp14> be used when a ca
ll lacks a first-party PASSporT that assures verification services that the call
<t>While rich data about the call can be provided by an originating authenticati ing party number is not spoofed. A third-party PASSporT is intended to be used i
on service, an intermediary in the call path could also acquire rich call data b n cases when the originating side does not supply a display-name for the caller,
y querying a third-party service. Such a service effectively acts as a STIR Auth so instead some entity in the call path invokes a third-party service to provid
entication Service, generating its own PASSporT, and that PASSporT could be atta e rich caller data for a call.</t>
ched to a call by either the originating or terminating side. This third-party P <t>In telephone operations today, a third-party information service is com
ASSporT attests information about the calling number, rather than the call or ca monly queried with the calling party's number in order to learn the name of the
ller itself, and as such its RCD MUST NOT be used when a call lacks a first-part calling party, and potentially other helpful information could also be passed ov
y PASSporT that assures verification services that the calling party number is n er that interface. The value of using a PASSporT to convey this information from
ot spoofed. It is intended to be used in cases when the originating side does no third parties lies largely in the preservation of the third party's signature o
t supply a display-name for the caller, so instead some entity in the call path ver the data, and the potential for the PASSporT to be conveyed from intermediar
invokes a third-party service to provide rich caller data for a call.</t> ies to endpoint devices. Effectively, these use cases form a sub-case of out-of-
band use cases <xref target="RFC8816"/>. The manner in which third-party service
<t>In telephone operations today, a third-party information service is commonly s are discovered is outside the scope of this document.</t>
queried with the calling party's number in order to learn the name of the callin <t>An intermediary use case might look as follows using the SIP protocol f
g party, and potentially other helpful information could also be passed over tha or this example: a SIP INVITE carries a display name in its From header field va
t interface. The value of using a PASSporT to convey this information from third lue and an initial PASSporT object without the "rcd" claim. When a terminating v
parties lies largely in the preservation of the third party's signature over th erification service implemented at a SIP proxy server receives this request and
e data, and the potential for the PASSporT to be conveyed from intermediaries to determines that the signature is valid, it might query a third-party service tha
endpoint devices. Effectively, these use cases form a sub-case of out-of-band < t maps telephone numbers to calling party names. Upon receiving the PASSporT in
xref target="RFC8816"/> use cases. The manner in which third-party services are a response from that third-party service, the terminating side could add a new I
discovered is outside the scope of this document.</t> dentity header field to the request for the PASSporT object provided by the thir
d-party service. It would then forward the INVITE to the terminating user agent.
<t>An intermediary use case might look as follows using SIP protocol for this ex If the display name in the PASSporT object matches, or is string-equivalent to,
ample: a SIP INVITE carries a display name in its From header field value and an the display name in the INVITE, then the name would presumably be rendered to t
initial PASSporT object without the "rcd" claim. When a terminating verificatio he end user by the terminating user agent.</t>
n service implemented at a SIP proxy server receives this request, and determine <t>A very similar flow could be followed by an intermediary closer to the
s that the signature is valid, it might query a third-party service that maps te origination of the call. Presumably such a service could be implemented at an or
lephone numbers to calling party names. Upon receiving the PASSporT in a respons iginating network in order to decouple the systems that sign for calling party n
e from that third-party service, the terminating side could add a new Identity h umbers from the systems that provide rich data about calls.</t>
eader field to the request for the PASSporT object provided by the third-party s <t>In an alternative use case, the terminating user agent might query a th
ervice. It would then forward the INVITE to the terminating user agent. If the d ird-party service. In this case, no new Identity header field would be generated
isplay name in the PASSporT object matches, or is string equivelent to, the disp , though the terminating user agent might receive a PASSporT object in return fr
lay name in the INVITE, then the name would presumably be rendered to the end us om the third-party service, and use the "rcd" field in the object as a calling n
er by the terminating user agent.</t> ame to render to users while alerting.</t>
<t>While in the traditional telephone network, the business relationship b
<t>A very similar flow could be followed by an intermediary closer to the origin etween calling customers and their telephone service providers is the ultimate r
ation of the call. Presumably such a service could be implemented at an originat oot of information about a calling party's name, some other forms of data like c
ing network in order to decouple the systems that sign for calling party numbers rowdsourced reputation scores might derive from third parties. When those elemen
from the systems that provide rich data about calls.</t> ts are present, they <bcp14>MUST</bcp14> be in a third-party "rcd" PASSporT usin
g the "iss" claim described in the next section.</t>
<t>In an alternative use case, the terminating user agent might query a third-pa <section anchor="thirdsign">
rty service. In this case, no new Identity header field would be generated, thou <name>Signing as a Third Party</name>
gh the terminating user agent might receive a PASSporT object in return from the <t>A third-party PASSporT contains an "iss" element to distinguish its P
third-party service, and use the "rcd" field in the object as a calling name to ASSporTs from first-party PASSporTs. Third-party "rcd" PASSporTs are signed with
render to users while alerting.</t> credentials that do not have authority over the identity that appears in the "o
rig" element of the PASSporT claims. The presence of "iss" signifies that a diff
<t>While in the traditional telephone network, the business relationship between erent category of credential is being used to sign a PASSporT than the certifica
calling customers and their telephone service providers is the ultimate root of tes (as defined in <xref target="RFC8226"/>) used to sign STIR calls; it is inst
information about a calling party's name, some other forms of data like crowdso ead a certificate that identifies the source of the "rcd" data. How those creden
urced reputation scores might derive from third parties. When those elements are tials are issued and managed is outside the scope of this document; however, the
present, they MUST be in a third-party "rcd" PASSporT using "iss" claim describ value of "iss" <bcp14>MUST</bcp14> reflect the Subject of the certificate used
ed in the next section.</t> to sign a third-party PASSporT. The explicit mechanism for reflecting the Subjec
t field of the certificate is out of scope of this document and left to the cert
<section anchor="thirdsign"><name>Signing as a Third Party</name> ificate governance policies that define how to map the "iss" value in the PASSpo
rT to the Subject field in the certificate. Relying parties in STIR have always
<t>A third-party PASSporT contains an "iss" element to distinguish its PASSporTs been left to make their own authorization decisions about whether to trust the s
from first-party PASSporTs. Third-party "rcd" PASSporTs are signed with credent igners of PASSporTs; in the third-party case, where an entity has explicitly que
ials that do not have authority over the identity that appears in the "orig" ele ried a service to acquire the PASSporT object, it may be some external trust or
ment of the PASSporT claims. The presence of "iss" signifies that a different ca business relationship that induces the relying party to trust a PASSporT.</t>
tegory of credential is being used to sign a PASSporT than the <xref target="RFC <t>An example of a PASSporT claims object issued by a third party is as
8226"/> certificates used to sign STIR calls; it is instead a certificate that i follows.</t>
dentifies the source of the "rcd" data. How those credentials are issued and man <sourcecode type=""><![CDATA[
aged is outside the scope of this document; the value of "iss" however MUST refl
ect the Subject of the certificate used to sign a third-party PASSporT. The expl
icit mechanism for reflecting the subject field of the certificate is out of sco
pe of this document and left to the certificate governance policies that define
how to map the "iss" value in the PASSporT to the subject field in the certifica
te. Relying parties in STIR have always been left to make their own authorizatio
n decisions about whether to trust the signers of PASSporTs, and in the third-pa
rty case, where an entity has explicitly queried a service to acquire the PASSpo
rT object, it may be some external trust or business relationship that induces t
he relying party to trust a PASSporT.</t>
<t>An example of a Third Party issued PASSporT claims object is as follows.</t>
<figure><artwork><![CDATA[
{ "orig":{"tn":"12025551000"}, { "orig":{"tn":"12025551000"},
"dest":{"tn":["12025551001"]}, "dest":{"tn":["12025551001"]},
"iat":1443208345, "iat":1443208345,
"iss":"Zorin Industries", "iss":"Zorin Industries",
"rcd":{"nam":"James St. John Smythe"} } "rcd":{"nam":"James St. John Smythe"} }
]]></artwork></figure> ]]></sourcecode>
</section>
</section> <section anchor="thirdsignverify">
<section anchor="thirdsignverify"><name>Verification using Third Party RCD</name <name>Verification Using Third-Party RCD</name>
> <t>The third-party "rcd" PASSporT cases must be considered in the verifi
cation service, as an attacker could attempt to cut and paste such a third-party
<t>The third-party "rcd" PASSporT cases must be considered in the verification s PASSporT into a SIP request in an effort to get the terminating user agent to r
ervice, as an attacker could attempt to cut-and-paste such a third-party PASSpor ender the display name or confidence values it contains to a call that should ha
T into a SIP request in an effort to get the terminating user agent to render th ve no such assurance. Following the rules of <xref target="RFC8225"/> and in par
e display name or confidence values it contains to a call that should have no su ticular if there are multiple identity headers (as in the case of the inclusion
ch assurance. Following the rules of <xref target="RFC8225"/> and in particular of an "rcd" and "shaken" PASSporTs from two different signing providers), a veri
if there is multiple identity headers, for example with the case of the inclusio fication service <bcp14>MUST</bcp14> determine that the calling party number sho
n of an "rcd" and "shaken" PASSporTs from two different signing providers, a ver wn in the "orig" of the "rcd" PASSporT corresponds to the calling party number o
ification service MUST determine that the calling party number shown in the "ori f the call it has received, and that the "iat" field of the "rcd" PASSporT is wi
g" of the "rcd" PASSporT corresponds to the calling party number of the call it thin the date interval that the verification service would ordinarily accept for
has received, and that the "iat" field of the "rcd" PASSporT is within the date a PASSporT. It is possible that if multiple identity headers are present, only
interval that the verification service would ordinarily accept for a PASSporT. I the verified identity information should be considered when presenting call info
t is possible that if there is multiple identity headers are present, only the v rmation to an end user.</t>
erified identity information should be considered when presenting call informati <t>Verification services may alter their authorization policies for the
on to an end user.</t> credentials accepted to sign PASSporTs when third parties generate PASSporT obje
cts, per <xref target="thirdsign"/>. This may include accepting a valid signatur
<t>Verification services may alter their authorization policies for the credenti e over a PASSporT even if it is signed with a credential that does not attest au
als accepted to sign PASSporTs when third parties generate PASSporT objects, per thority over the identity in the "orig" claim of the PASSporT, provided that the
<xref target="thirdsign"/>. This may include accepting a valid signature over a verification service has some other reason to trust the signer. No further guid
PASSporT even if it is signed with a credential that does not attest authority ance on verification service authorization policy is given here.</t>
over the identity in the "orig" claim of the PASSporT, provided that the verific </section>
ation service has some other reason to trust the signer. No further guidance on </section>
verification service authorization policy is given here.</t> <section anchor="loa">
<name>Levels of Assurance</name>
</section> <t>A set of "rcd" claims can be provided by either first-party providers t
</section> hat are directly authorized to sign PASSporTs in the STIR ecosystem or third-par
<section anchor="loa"><name>Levels of Assurance</name> ty providers that are indirectly or delegated authority to sign PASSporTs. Relyi
ng parties could benefit from an additional claim that indicates the identificat
<t>As "rcd" can be provided by either first party providers that are directly au ion, in the form of a uniquely identifiable name, of the attesting party to the
thorized to sign PASSporTs in the STIR eco-system or third party providers that caller. Even in first-party cases, the Communications Service Provider (CSP) to
are indirectly or delegated authority to sign PASSporTs. Relying parties could b which a number was assigned might in turn delegate the number to a reseller, who
enefit from an additional claim that indicates the identification, in the form o would then sell the number to an enterprise, in which case the CSP might have l
f a uniquely identifiable name, of the attesting party to the caller. Even in fi ittle insight into the caller's name. In third-party cases, a caller's name coul
rst party cases, the Communications Service Provider (CSP) to which a number was d be determined from any number of data sources, on a spectrum between public da
assigned might in turn delegate the number to a reseller, who would then sell t ta scraped from web searches to a direct business relationship to the caller. As
he number to an enterprise, in which case the CSP might have little insight into multiple PASSporTs can be associated with the same call, potentially a verifica
the caller's name. In third party cases, a caller's name could be determined fr tion service could receive attestations of the caller name from multiple sources
om any number of data sources, on a spectrum between public data scraped from we , which have different levels of granularity or accuracy. Therefore, third-party
b searches to a direct business relationship to the caller. As multiple PASSporT PASSporTs that carry "rcd" data are <bcp14>RECOMMENDED</bcp14> to also carry an
s can be associated with the same call, potentially a verification service could indication of the identity of the generator of the PASSporT in the form of the
receive attestations of the caller name from multiple sources, which have diffe 'iss' claim.</t>
rent levels of granularity or accuracy. Therefore, third-party PASSporTs that ca </section>
rry "rcd" data are RECOMMENDED to also carry an indication of the identity of th <section anchor="use">
e generator of the PASSporT in the form of the 'iss' claim.</t> <name>Use of "rcd" PASSporTs in SIP</name>
<t>This section documents SIP-specific usage for "rcd" PASSporTs in the SI
</section> P Identity header field value. Other protocols using PASSporT may define their o
<section anchor="use"><name>Use of "rcd" PASSporTs in SIP</name> wn guidance for "rcd" PASSporTs.</t>
<section anchor="authentication-service-behavior-for-sip-protocol">
<t>This section documents SIP-specific usage for "rcd" PASSporTs and in the SIP <name>Authentication Service Behavior for SIP Protocol</name>
Identity header field value. Other using protocols of PASSporT may define their <t>An authentication service creating a PASSporT containing an "rcd" cla
own usages for the "rcd" PASSporTs.</t> im <bcp14>MAY</bcp14> include a PASSporT extension ("ppt" value) of "rcd". Third
-party authentication services following the behavior in <xref target="thirdsign
<section anchor="authentication-service-behavior-for-sip-protocol"><name>Authent "/> <bcp14>MUST</bcp14> include a PASSporT extension value of "rcd". If the PASS
ication Service Behavior for SIP protocol</name> porT extension does contain an "rcd", then any SIP authentication services <bcp1
4>MUST</bcp14> add a PASSporT extension "ppt" parameter to the Identity header f
<t>An authentication service creating a PASSporT containing an "rcd" claim MAY i ield containing that PASSporT with a value of "rcd". The resulting Identity head
nclude a PASSporT extension ("ppt" value) of "rcd" or not. Third-party authentic er field might look as follows:</t>
ation services following the behavior in <xref target="thirdsign"/> MUST include <sourcecode type=""><![CDATA[
a PASSporT extension value of "rcd". If PASSporT extension does contain an "rcd
", then any SIP authentication services MUST add a PASSporT extension "ppt" para
meter to the Identity header field containing that PASSporT with a value of "rcd
". The resulting Identity header field might look as follows:</t>
<figure><artwork><![CDATA[
Identity: sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9 Identity: sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9
dlxkWzoeU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgt dlxkWzoeU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgt
w0Lu5csIppPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs=; w0Lu5csIppPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs=;
info=<https://biloxi.example.org/biloxi.cer>;alg=ES256; info=<https://biloxi.example.org/biloxi.cer>;alg=ES256;
ppt="rcd" ppt="rcd"
]]></artwork></figure> ]]></sourcecode>
<t>This document assumes that by default when using the SIP protocol, an
<t>This document assumes that by default when using the SIP protocol, an authent authentication service determines the value of "rcd", specifically only for the
ication service determines the value of "rcd", specifically only for the "nam" k "nam" key value, from the display-name component of the From header field value
ey value, from the display-name component of the From header field value of the of the request. Alternatively, for some calls this may come from the P-Asserted
request, alternatively for some calls this may come from the P-Asserted-ID heade -ID header. It is however a matter of authentication service policy to decide ho
r. It is however a matter of authentication service policy to decide how it popu w it populates the value of the "nam" key, which <bcp14>MAY</bcp14> also match o
lates the value of "nam" key, which MAY also match or be determined by other fie r be determined by other fields in the request, from customer profile data or fr
lds in the request, from customer profile data, or from access to external servi om access to external services. If the authentication service generates an "rcd"
ces. If the authentication service generates an "rcd" claim containing "nam" wit claim containing "nam" with a value that is not string-equivalent to the From h
h a value that is not string equivalent to the From header field display-name va eader field display-name value, it <bcp14>MUST</bcp14> use the full form of the
lue, it MUST use the full form of the PASSporT object in SIP.</t> PASSporT object in SIP.</t>
<t>In addition, <xref target="RFC9796"/> defines a Call-Info header fie
<t>In addition, {I-D.ietf-sipcore-callinfo-rcd}} defines a Call-Info header fiel ld that <bcp14>MAY</bcp14> be used as a source of RCD information that an authen
d that MAY be used as a source of RCD information that an authentication service tication service uses to construct the appropriate PASSporT RCD claim types used
s uses to construct the appropriate PASSporT RCD claim types used.</t> .</t>
<t>Note also that, as a best practice, the accuracy and legitimacy of Ri
<t>Note also that, as a best practice, the accuracy and legitimacy of Rich Call ch Call Data information that is included in the claims is <bcp14>RECOMMENDED</b
Data information that is included in the claims is RECOMMENDED to follow a trust cp14> to follow a trust framework that is out of scope of this document. As with
framework that is out of scope of this document. As with telephone numbers for telephone numbers for the STIR framework, the authentication of Rich Call Data
the STIR framework the authentication of Rich Call Data should follow some type should follow some type of vetting process by an entity that is authoritative ov
of vetting process by an entity that is authoritative over determining the accur er determining the accuracy and legitimacy of that information. This includes th
acy and legitimacy of that information. This includes the mechanisms for how and e mechanisms for how and from whom that information is received by the authentic
from whom that information is received by the authentication service. For examp ation service. For example, the general use of Call-Info via SIP as a trusted so
le, the general use of Call-Info via SIP as a trusted source of RCD information urce of RCD information on the authentication side is <bcp14>NOT RECOMMENDED</bc
on the authentication side is NOT RECOMMENDED.</t> p14>.</t>
</section>
</section> <section anchor="verification-service-behavior-for-sip-protocol">
<section anchor="verification-service-behavior-for-sip-protocol"><name>Verificat <name>Verification Service Behavior for SIP Protocol</name>
ion Service Behavior for SIP protocol</name> <t><xref section="6.2" target="RFC8224" sectionFormat="comma"/>, Step 5
requires that future specifications defining PASSporT extension ("ppt") values d
<t><xref target="RFC8224"/> Section 6.2 Step 5 requires that future specificatio escribe any additional verifier behavior specific to the SIP protocol. The gener
ns defining PASSporT extension ("ppt") values describe any additional verifier b al verification procedures defined in <xref target="rcd_passport_verification"/>
ehavior specific to the SIP protocol. The general verification proceedures defin
ed in <xref target="rcd_passport_verification"/>
should be followed, but the following paragraphs describe some of the specifics needed to implement a verification service using the SIP protocol.</t> should be followed, but the following paragraphs describe some of the specifics needed to implement a verification service using the SIP protocol.</t>
<t>If the PASSporT is in compact form, then the verification service <bc
<t>If the PASSporT is in compact form, then the verification service MUST extrac p14>MUST</bcp14> extract the display-name from the From header field value, if a
t the display-name from the From header field value, if any, and MUST use that a ny, and <bcp14>MUST</bcp14> use that as the string value for the "nam" key when
s the string value for the "nam" key when it recomputes the header and claims of it recomputes the header and claims of the PASSporT object. Additionally, if the
the PASSporT object. Additionally, if there exists a Call-Info header field as re exists a Call-Info header field as defined in <xref target="RFC9796"/>, the "
defined in <xref target="I-D.ietf-sipcore-callinfo-rcd"/>, the "jcard" JSON obje jcard" JSON object value <bcp14>MUST</bcp14> be used to construct the "jcd" key
ct value MUST be used to construct the "jcd" key value when it recomputes the he value when it recomputes the header and claims of the PASSporT object. If the si
ader and claims of the PASSporT object. If the signature validates over the reco gnature validates over the recomputed object, then the verification is considere
mputed object, then the verification is considered successful.</t> d successful.</t>
<t>If the PASSporT is in full form with a PASSporT extension value of "r
<t>If the PASSporT is in full form with a PASSporT extension value of "rcd", the cd", then the verification service <bcp14>MUST</bcp14> extract the value associa
n the verification service MUST extract the value associated with the "rcd" clai ted with the "rcd" claim "nam" key in the object. If the PASSporT signature is v
m "nam" key in the object. If the PASSporT signature is verified successfully th erified successfully, then the verification service <bcp14>MUST</bcp14> addition
en the verification service MUST additionally compare the string value of the "r ally compare the string value of the "rcd" claim "nam" key value with the From h
cd" claim "nam" key value with the From header field value or the preferred valu eader field value or the preferred value. The preferred value depends on local
e. The preferred value depends on local policy of the SIP network technique tha policy of the SIP network technique that conveys the display name string through
t conveys the display name string through a field other than the From header fie a field other than the From header field to interoperate with this specificatio
ld to interoperate with this specification (e.g. P-Asserted-Identity) as discuss n (e.g., P-Asserted-Identity) as discussed in <xref target="RFC8224"/>.
ed in <xref target="RFC8224"/>. Similarly, "jcd" or "jcl" jcard information, "ic Similarly, "jcd", "jcl", "icn", "apn", or "crn" elements
n", "apn", or "crn" can be optionally, based on local policy for devices that su can be used optionally (based on local policy for devices that support it)
pport it, used to populate a Call-Info header field following the format of <xre to populate a Call-Info header field following the format of
f target="I-D.ietf-sipcore-callinfo-rcd"/>. If future defined PASSporT RCD claim <xref target="RFC9796"/>. If PASSporT RCD claims types defined in the future are
s types are present, they should follow similar defined proceedures and policies present, they should follow similar defined proceedures and policies.</t>
.</t> <t>The behavior of a SIP User Agent Server (UAS) upon receiving an INVIT
E or other type of session initiation request containing a PASSporT object with
<t>The behavior of a SIP UAS upon receiving an INVITE or other type of session i an "rcd" claim largely remains a matter of implementation policy. In most cases,
nitiation request containing a PASSporT object with an "rcd" claim largely remai implementations would render this calling party name information to the user wh
ns a matter of implementation policy. In most cases, implementations would rende ile alerting. Any user interface additions to express confidence in the veracity
r this calling party name information to the user while alerting. Any user inter of this information are outside the scope of this specification.</t>
face additions to express confidence in the veracity of this information are out </section>
side the scope of this specification.</t> </section>
<section anchor="using-rcd-rcdi-crn-as-additional-claims-to-other-passport-e
</section> xtensions">
</section> <name>Using "rcd", "rcdi", and "crn" as Additional Claims to Other PASSpor
<section anchor="using-rcd-rcdi-crn-as-additional-claims-to-other-passport-exten T Extensions</name>
sions"><name>Using "rcd", "rcdi", "crn" as additional claims to other PASSporT e <t>Rich Call Data, including calling name information, as a common example
xtensions</name> , is often data that is additive to the personal communications information defi
ned in the core PASSporT data required to support the security properties define
<t>Rich Call Data, including calling name information, as a common example, is o d in <xref target="RFC8225"/>. For cases where the entity originating the person
ften data that is additive to the personal communications information defined in al communications is supporting the authentication service for the calling ident
the core PASSporT data required to support the security properties defined in < ity and is the authority of the Rich Call Data, rather than creating multiple Id
xref target="RFC8225"/>. For cases where the entity originating the personal com entity header fields corresponding to multiple PASSporT extensions, the authenti
munications is supporting the authentication service for the calling identity an cation service can alternatively directly add the "rcd" claim to a PASSporT that
d is the authority of the Rich Call Data, rather than creating multiple Identity authenticates the calling identity.</t>
header fields corresponding to multiple PASSporT extensions, the authentication <section anchor="procedures-for-applying-rcd-claims-as-claims-only">
service can alternatively directly add the "rcd" claim to a PASSporT that authe <name>Procedures for Applying RCD Claims as Claims Only</name>
nticates the calling identity.</t> <t>For a given PASSporT using some other extension than "rcd", the Authe
ntication Service <bcp14>MAY</bcp14> additionally include the "rcd" defined in <
<section anchor="procedures-for-applying-rcd-claims-as-claims-only"><name>Proced xref target="rcd_define"/>, "rcdi" defined in <xref target="rcdi_define"/>, and
ures for applying RCD claims as claims only</name> "crn" defined in <xref target="crn_define"/> claims. This would result in a set
of claims that correspond to the original intended extension with the addition o
<t>For a given PASSporT using some other extension than "rcd", the Authenticatio f the "rcd" claim.</t>
n Service MAY additionally include the "rcd" defined in {#rcd_define}, "rcdi" de <t>The verification service that receives the PASSporT, if it supports t
fined in {#rcdi_define}, and "crn" defined in {#crn_define} claims. This would r his specification and chooses to, should interpret the "rcd" claim as simply jus
esult in a set of claims that correspond to the original intended extension with t an additional claim intended to deliver and/or validate delivered Rich Call Da
the addition of the "rcd" claim.</t> ta.</t>
</section>
<t>The Verification service that receives the PASSporT, if it supports this spec <section anchor="example-for-applying-rcd-claims-as-claims-only">
ification and chooses to, should interpret the "rcd" claim as simply just an add <name>Example for Applying RCD Claims as Claims Only</name>
itional claim intended to deliver and/or validate delivered Rich Call Data.</t> <t>In the case of <xref target="RFC8588"/>, which is the PASSporT extens
ion supporting the Signature-based Handling of Asserted information using toKENs
</section> (SHAKEN) specification <xref target="ATIS-1000074.v003"/>, a common case is for
<section anchor="example-for-applying-rcd-claims-as-claims-only"><name>Example f an authentication service to coexist in a CSP network along with the authority
or applying RCD claims as claims only</name> over the calling name used for the call. Rather than require two identity header
s, the CSP authentication service can apply both the SHAKEN PASSporT claims and
<t>In the case of <xref target="RFC8588"/> which is the PASSporT extension suppo extension and simply add the "rcd" required claims defined in this document.</t>
rting the SHAKEN specification <xref target="ATIS-1000074.v002"/>, a common case <t>For example, the PASSporT claims for the "shaken" PASSporT with "rcd"
for an Authentication service to co-exist in a CSP network along with the autho claims would be as follows:</t>
rity over the calling name used for the call. Rather than require two identity h <sourcecode type=""><![CDATA[
eaders, the CSP Authentication Service can apply both the SHAKEN PASSporT claims
and extension and simply add the "rcd" required claims defined in this document
.</t>
<t>For example, the PASSporT claims for the "shaken" PASSporT with "rcd" claims
would be as follows:</t>
<figure><artwork><![CDATA[
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"}
} }
]]></artwork></figure> ]]></sourcecode>
<t>A verification service that understands and supports claims defined i
<t>A Verification Service that understands and supports claims defined in the "r n the "rcd" and "shaken" PASSporT extensions is able to receive the above PASSpo
cd" and "shaken" PASSporT extensions is able to receive the above PASSporT and i rT and interpret both the "shaken" claims as well as the "rcd" claims.</t>
nterpret both the "shaken" claims as well as the "rcd" defined claims.</t> <t>If the verification service only understands the "shaken" PASSporT ex
tension claims and doesn't support the "rcd" PASSporT extension or claims, then
<t>If the Verification Service only understands the "shaken" PASSporT extension the "rcd" claim in this example is used during PASSporT signature validation but
claims and doesn't support "rcd" PASSporT extension or claims, then the "rcd" cl is otherwise ignored and disregarded.</t>
aim, in this example, is used during PASSporT signature validation but is otherw </section>
ise ignored and disregarded.</t> </section>
<section anchor="extend">
</section> <name>Further Information Associated with Callers</name>
</section> <t>Beyond naming information and the information that can be contained in
<section anchor="extend"><name>Further Information Associated with Callers</name a jCard object <xref target="RFC7095"/>, there may be additional human-readable
> information about the calling party that should be rendered to the end user in o
rder to help the called party decide whether or not to pick up the phone. This i
<t>Beyond naming information and the information that can be contained in a jCar s not limited to information about the caller; it includes information about the
d <xref target="RFC7095"/> object, there may be additional human-readable inform call itself, which may derive from analytics that determine (based on call patt
ation about the calling party that should be rendered to the end user in order t erns or similar data) if the call is likely to be one the called party wants to
o help the called party decide whether or not to pick up the phone. This is not receive. Such data could include:</t>
limited to information about the caller, but includes information about the call <ul spacing="normal">
itself, which may derive from analytics that determine based on call patterns o <li>information related to the location of the caller, or</li>
r similar data if the call is likely to be one the called party wants to receive <li>any organizations or institutions that the caller is associated with
. Such data could include:</t> , or even categories of institutions (whether this a government agency, a bank,
or what have you), or</li>
<t><list style="symbols"> <li>hyperlinks to images, such as logos or pictures of faces, or to simi
<t>information related to the location of the caller, or</t> lar external profile information, or</li>
<t>any organizations or institutions that the caller is associated with, or ev <li>information processed by an application before rendering it to a use
en categories of institutions (is this a government agency, or a bank, or what h r, like social networking data that shows that an unknown caller is a friend-of-
ave you), or</t> a-friend, or reputation scores derived from crowdsourcing, or confidence scores
<t>hyperlinks to images, such as logos or pictures of faces, or to similar ext based on broader analytics about the caller and callee.</li>
ernal profile information, or</t> </ul>
<t>information processed by an application before rendering it to a user, like <t>All of these data elements would benefit from the secure attestations p
social networking data that shows that an unknown caller is a friend-of-a-frien rovided by the STIR and PASSporT frameworks. A new IANA registry has been define
d, or reputation scores derived from crowdsourcing, or confidence scores based o d to hold potential values of the "rcd" array; see <xref target="rcdtypes"/>. Sp
n broader analytics about the caller and callee.</t> ecific extensions to the "rcd" PASSporT claim are left for future specification.
</list></t> </t>
<t>There are a few ways RCD can be extended in the future; jCard is an ext
<t>All of these data elements would benefit from the secure attestations provide ensible object and the key/values in the RCD claim object can also be extended.
d by the STIR and PASSporT frameworks. A new IANA registry has been defined to h General guidance for future extensibility that was followed by the authors is th
old potential values of the "rcd" array; see <xref target="rcdtypes"/>. Specific at jCard typically should refer to data that references the caller as an individ
extensions to the "rcd" PASSporT claim are left for future specification.</t> ual or entity, whereas other claims, such as "crn", refer to data regarding the
specific call. There may be other considerations discovered in the future, but t
<t>There is a few ways RCD can be extended in the future, jCard is an extensible his logical grouping of data should be followed to the extent possible for futur
object and the key/values in the RCD claim object can also be extended. General e extensibility.</t>
guidance for future extensibility that were followed by the authors is that jCa </section>
rd generally should refer to data that references the caller as an individual or <section anchor="IANA">
entity, where other claims, such as "crn" refer to data regarding the specific <name>IANA Considerations</name>
call. There may be other considerations discovered in the future, but this logic <section anchor="json-web-token-claim">
al grouping of data to the extent possible should be followed for future extensi <name>JSON Web Token Claim</name>
bility.</t> <t>Per this document, IANA has added three new claims to the "JSON Web T
oken Claims" registry as defined in <xref target="RFC7519"/>.</t>
</section> <dl spacing="compact" newline="false">
<section anchor="acknowledgements"><name>Acknowledgements</name> <dt>Claim Name:</dt><dd>"rcd"</dd>
<dt>Claim Description:</dt><dd>Rich Call Data Information</dd>
<t>We would like to thank David Hancock, Robert Sparks, Russ Housley, Eric Burge <dt>Change Controller:</dt><dd>IETF</dd>
r, Alec Fenichel, Ben Campbell, Jack Rickard, Jordan Simpson for helpful suggest <dt>Reference:</dt><dd>RFC 9795</dd>
ions, review, and comments.</t> </dl>
<dl spacing="compact" newline="false">
</section> <dt>Claim Name:</dt><dd>"rcdi"</dd>
<section anchor="IANA"><name>IANA Considerations</name> <dt>Claim Description:</dt><dd>Rich Call Data Integrity Information</dd>
<dt>Change Controller:</dt><dd>IETF</dd>
<section anchor="json-web-token-claim"><name>JSON Web Token Claim</name> <dt>Reference:</dt><dd>RFC 9795</dd>
</dl>
<t>This document requests that the IANA add three new claims to the JSON Web Tok <dl spacing="compact" newline="false">
en Claims registry as defined in <xref target="RFC7519"/>.</t> <dt>Claim Name:</dt><dd>"crn"</dd>
<dt>Claim Description:</dt><dd>Call Reason</dd>
<t>Claim Name: "rcd"</t> <dt>Change Controller:</dt><dd>IETF</dd>
<dt>Reference:</dt><dd>RFC 9795</dd>
<t>Claim Description: Rich Call Data Information</t> </dl>
</section>
<t>Change Controller: IESG</t> <section anchor="personal-assertion-token-passport-extensions">
<name>Personal Assertion Token (PASSporT) Extensions</name>
<t>Specification Document(s): [RFCThis]</t> <t>Per this document, IANA has added a new entry to the "Personal Assert
ion Token (PASSporT) Extensions" registry for the type "rcd" which is specified
<t>Claim Name: "rcdi"</t> in this document.</t>
</section>
<t>Claim Description: Rich Call Data Integrity Information</t> <section anchor="rcdtypes">
<name>PASSporT RCD Claim Types</name>
<t>Change Controller: IESG</t> <t>IANA has created a new "PASSporT RCD Claim Types" registry in the "Pe
rsonal Assertion Token (PASSporT)" registry group. Registration of new PASSporT
<t>Specification Document(s): [RFCThis]</t> RCD claim types shall be under the Specification Required policy <xref target="R
FC8126"/>.</t>
<t>Claim Name: "crn"</t> <t>This registry is initially populated with five claim name values, "na
m", "apn", "icn", "jcd", and "jcl", which are specified in this document. The co
<t>Claim Description: Call Reason</t> lumns are "Name" and "Reference". Any new registrations should consist of only o
f the name and the reference document. There is an obligation for expert review,
<t>Change Controller: IESG</t> where the designated expert should validate that the proposed new PASSporT RCD
claim type has a scope that doesn't potentially conflict or overlap with the usa
<t>Specification Document(s): [RFCThis]</t> ge or interpretation of the other existing types in the registry.</t>
</section>
</section> </section>
<section anchor="personal-assertion-token-passport-extensions"><name>Personal As <section anchor="Security">
sertion Token (PASSporT) Extensions</name> <name>Security Considerations</name>
<t>The process of signing information contained in a "rcd" PASSporT (wheth
<t>This document requests that the IANA add a new entry to the Personal Assertio er the identities, identifiers, alternate identities or identifiers, images, log
n Token (PASSporT) Extensions registry for the type "rcd" which is specified in os, physical addresses, or otherwise) should follow some vetting process in whic
[RFCThis].</t> h an authoritative entity follows an appropriate consistent policy defined and g
overned by the ecosystem using RCD and the STIR framework. This can be of many f
</section> orms, depending on the setup and constraints of the policy requirements of the e
<section anchor="rcdtypes"><name>PASSporT RCD Claim Types</name> cosystem, and is therefore out of scope of this document. However, the general c
hain of trust that signers of "rcd" PASSporT are either directly authoritative o
<t>This document requests that the IANA create a new registry for PASSporT RCD c r have been delegated authority through certificates using JWT Claim Constraints
laim types. This new registry should be added to the "Personal Assertion Token ( and integrity mechanisms defined in this and related documents is critical to m
PASSporT)" group. Registration of new PASSporT RCD claim types shall be under th aintain the integrity of the ecosystem utilizing this and other STIR-related spe
e Specification Required policy.</t> cifications.</t>
<t>Revealing information such as the name, location, and affiliation of a
<t>This registry is to be initially populated with five claim name values, "nam" person necessarily entails certain privacy risks. Baseline PASSporT has no parti
, "apn", "icn", "jcd", and "jcl", which are specified in [RFCThis]. This is a tw cular confidentiality requirement, as the information it signs in many current b
o column registry with column1 = "Name" and column2 = "Reference Document". Any ase communications protocols (for example, SIP) is information that is carried i
new registrations should consist of only of the name and the reference document. n the clear anyway. Transport-level security can hide those SIP fields from eave
There is an obligation for expert review, where the designated expert should va sdroppers, and the same confidentiality mechanisms would protect any PASSporT(s)
lidate that the proposed new PASSporT RCD claim type has a scope that doesn't po carried in SIP.</t>
tentially conflict or overlap with the usage or interpretation of the other exis <t>The dereferencing and download of any RCD URI-linked resources as part
ting types in the registry.</t> of verification either in-network or on device could provide some level of infor
mation about calling patterns, so this should be considered when making these re
</section> sources available.</t>
</section> <t>The use of JWT Claim Constraints, a mechanism defined in <xref target="
<section anchor="Security"><name>Security Considerations</name> RFC8226"/> and extended in <xref target="RFC9118"/>, to constrain any of the RCD
information in the public certificate by including that information in the cert
<t>The process of signing information contained in a "rcd" PASSporT, whether the ificate, depending on the availability in the deployment of the PKI system, may
identities, identifiers, alternate identities or identifiers, images, logos, ph present a privacy issue. The use of the "rcdi" claim and digests for representin
ysical addresses, or otherwise should follow some vetting process in which an au g JWT claim contents is <bcp14>RECOMMENDED</bcp14> for the prevention of the exp
thoritative entity should follow an appropriate consistent policy defined and go osure of that information through the certificates that are often publicly acces
verned by the eco-system using RCD and the STIR framework. This can be of many f sible and available.</t>
orms, depending on the setup and constraints of the policy requirements of the e <t>Since computation of "rcdi" digests for URIs requires the loading of re
co-system and is therefore out-of-scope of this document. However, the general c ferenced content, it would be best practice to validate that content at the crea
hain of trust that signers of "rcd" PASSporT are either directly authoritative o tion of the "rcdi" or corresponding JWT claim constraint value by checking for c
r have been delegated authority through certificates using JWT Claim Constraints ontent that may cause issues for verification services or that doesn't follow th
and integrity mechanisms defined in this and related documents is critical to m e behavior defined in this document, e.g., unreasonably sized data, the inclusio
aintain the integrity of the eco-system utilizing this and other STIR related sp n of recursive URI references, etc. Along the same lines, the verification servi
ecifications.</t> ce should also use precautionary best practices to avoid attacks when accessing
URI-linked content.</t>
<t>Revealing information such as the name, location, and affiliation of a person <t>As general guidance, the use of URLs and URIs that reference potentiall
necessarily entails certain privacy risks. Baseline PASSporT has no particular y dangerous or intentionally harmful content should be considered in implementin
confidentiality requirement, as the information it signs in many current base co g this specification. <xref section="7" target="RFC3986" sectionFormat="comma"/
mmunications protocols, for example SIP, is information that carried in the clea > contains good additional guidance to consider when communicating or dereferenc
r anyway. Transport-level security can hide those SIP fields from eavesdroppers, ing URLs and URIs.</t>
and the same confidentiality mechanisms would protect any PASSporT(s) carried i <section anchor="the-use-of-jwt-claim-constraints-in-delegate-certificates
n SIP.</t> -to-exclude-unauthorized-claims">
<name>Use of JWT Claim Constraints in Delegate Certificates to Exclude U
<t>The dereferencing and download of any RCD URI linked resources as part of ver nauthorized Claims</name>
ification either in-network or on device could provide some level of information <t>While this can apply to any PASSporT that is signed with a STIR Deleg
about calling patterns, so this should be considered when making these resource ate Certificate <xref target="RFC9060"/>, it is important to note that when cons
s available.</t> training PASSporTs to include specific claims or contents of claims, it is also
important to consider potential attacks by non-authorized signers that may inclu
<t>The use of JWTClaimConstraints, a mechanism defined in <xref target="RFC8226" de other potential PASSporT claims that weren't originally vetted by the authori
/> and extended in <xref target="RFC9118"/> to constrain any of the RCD informat zed entity providing the delegate certificate. The use of JWT claims constraints
ion in the public certificate by including that information in the certificate, (as defined in <xref target="RFC9118"/>) for preventing the ability to include
depending on the availability in the deployment of the PKI system, may present a claims beyond the claims defined in this document may need to be considered.</t>
privacy issue. The use of "rcdi" claim and digests for representing JWT claim c </section>
ontents is RECOMMENDED for the prevention of the exposure of that information th </section>
rough the certificates which are often publically accessible and available.</t>
<t>Since computation of "rcdi" digests for URIs requires the loading of referenc
ed content, it would be best practice to validate that content at the creation o
f the "rcdi" or corresponding JWT claim constraint value by checking for content
that may cause issues for verification services or that doesn't follow the beha
vior defined in this document, e.g., unreasonably sized data, the inclusion of r
ecursive URI references, etc. Along the same lines, the verification service sho
uld also use precautionary best practices to avoid attacks when accessing URI li
nked content.</t>
<t>As general guidance, the use of URLs and URIs that reference potentially dang
erous or intentionally harmful content should be considered in implimenting this
specification. <xref target="RFC3986"/> Section 7 contains good additional gui
dance to consider when communicating or dereferencing URLs and URIs.</t>
<section anchor="the-use-of-jwt-claim-constraints-in-delegate-certificates-to-ex
clude-unauthorized-claims"><name>The use of JWT Claim Constraints in delegate ce
rtificates to exclude unauthorized claims</name>
<t>While this can apply to any PASSporT that is signed with a STIR Delegate Cert
ificates <xref target="RFC9060"/>, it is important to note that when constrainin
g PASSporTs to include specific claims or contents of claims, it is also importa
nt to consider potential attacks by non-authorized signers that may include othe
r potential PASSporT claims that weren't originally vetted by the authorized ent
ity providing the delegate certificate. The use of JWT claims constraints as def
ined in <xref target="RFC9118"/> for preventing the ability to include claims be
yond the claims defined in this document may need to be considered.</t>
</section>
</section>
</middle> </middle>
<back> <back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<references title='Normative References'> <!-- [I-D.ietf-sipcore-callinfo-rcd] companion document RFC 9796 -->
<reference anchor="RFC9796" target="https://www.rfc-editor.org/info/rfc9796">
<reference anchor='I-D.ietf-sipcore-callinfo-rcd' target='https://datatracker.ie
tf.org/doc/html/draft-ietf-sipcore-callinfo-rcd-06'>
<front>
<title>SIP Call-Info Parameters for Rich Call Data</title>
<author fullname='Chris Wendt' initials='C.' surname='Wendt'>
<organization>Somos Inc.</organization>
</author>
<author fullname='Jon Peterson' initials='J.' surname='Peterson'>
<organization>Neustar Inc.</organization>
</author>
<date day='3' month='June' year='2023'/>
<abstract>
<t> This document describes a SIP Call-Info header field usage defined
to
include Rich Call Data (RCD) associated with the identity of the
calling party that can be rendered to a called party for providing
more descriptive information about the caller or more details about
the reason for the call. This includes extended information about
the caller beyond the telephone number such as a calling name, a logo
or photo representing the caller or a jCard object representing the
calling party. The elements defined for this purpose are intended to
be extensible to accommodate related information about calls that
helps people decide whether to pick up the phone and with the use of
icon and newly defined jCard and other elements to be compatible and
complimentary with the STIR/PASSporT Rich Call Data framework.
</t>
</abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-sipcore-callinfo-rcd-06'/
>
</reference>
<reference anchor='RFC3261' target='https://www.rfc-editor.org/info/rfc3261'>
<front>
<title>SIP: Session Initiation Protocol</title>
<author fullname='J. Rosenberg' initials='J.' surname='Rosenberg'><organization/
></author>
<author fullname='H. Schulzrinne' initials='H.' surname='Schulzrinne'><organizat
ion/></author>
<author fullname='G. Camarillo' initials='G.' surname='Camarillo'><organization/
></author>
<author fullname='A. Johnston' initials='A.' surname='Johnston'><organization/><
/author>
<author fullname='J. Peterson' initials='J.' surname='Peterson'><organization/><
/author>
<author fullname='R. Sparks' initials='R.' surname='Sparks'><organization/></aut
hor>
<author fullname='M. Handley' initials='M.' surname='Handley'><organization/></a
uthor>
<author fullname='E. Schooler' initials='E.' surname='Schooler'><organization/><
/author>
<date month='June' year='2002'/>
<abstract><t>This document describes Session Initiation Protocol (SIP), an appli
cation-layer control (signaling) protocol for creating, modifying, and terminati
ng sessions with one or more participants. These sessions include Internet tele
phone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TR
ACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='3261'/>
<seriesInfo name='DOI' value='10.17487/RFC3261'/>
</reference>
<reference anchor='RFC3986' target='https://www.rfc-editor.org/info/rfc3986'>
<front>
<title>Uniform Resource Identifier (URI): Generic Syntax</title>
<author fullname='T. Berners-Lee' initials='T.' surname='Berners-Lee'><organizat
ion/></author>
<author fullname='R. Fielding' initials='R.' surname='Fielding'><organization/><
/author>
<author fullname='L. Masinter' initials='L.' surname='Masinter'><organization/><
/author>
<date month='January' year='2005'/>
<abstract><t>A Uniform Resource Identifier (URI) is a compact sequence of charac
ters that identifies an abstract or physical resource. This specification defin
es the generic URI syntax and a process for resolving URI references that might
be in relative form, along with guidelines and security considerations for the u
se of URIs on the Internet. The URI syntax defines a grammar that is a superset
of all valid URIs, allowing an implementation to parse the common components of
a URI reference without knowing the scheme-specific requirements of every possi
ble identifier. This specification does not define a generative grammar for URI
s; that task is performed by the individual specifications of each URI scheme.
[STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='STD' value='66'/>
<seriesInfo name='RFC' value='3986'/>
<seriesInfo name='DOI' value='10.17487/RFC3986'/>
</reference>
<reference anchor='RFC4648' target='https://www.rfc-editor.org/info/rfc4648'>
<front>
<title>The Base16, Base32, and Base64 Data Encodings</title>
<author fullname='S. Josefsson' initials='S.' surname='Josefsson'><organization/
></author>
<date month='October' year='2006'/>
<abstract><t>This document describes the commonly used base 64, base 32, and bas
e 16 encoding schemes. It also discusses the use of line-feeds in encoded data,
use of padding in encoded data, use of non-alphabet characters in encoded data,
use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK
]</t></abstract>
</front>
<seriesInfo name='RFC' value='4648'/>
<seriesInfo name='DOI' value='10.17487/RFC4648'/>
</reference>
<reference anchor='RFC6234' target='https://www.rfc-editor.org/info/rfc6234'>
<front>
<title>US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)</title>
<author fullname='D. Eastlake 3rd' initials='D.' surname='Eastlake 3rd'><organiz
ation/></author>
<author fullname='T. Hansen' initials='T.' surname='Hansen'><organization/></aut
hor>
<date month='May' year='2011'/>
<abstract><t>Federal Information Processing Standard, FIPS</t></abstract>
</front>
<seriesInfo name='RFC' value='6234'/>
<seriesInfo name='DOI' value='10.17487/RFC6234'/>
</reference>
<reference anchor='RFC6901' target='https://www.rfc-editor.org/info/rfc6901'>
<front>
<title>JavaScript Object Notation (JSON) Pointer</title>
<author fullname='P. Bryan' initials='P.' role='editor' surname='Bryan'><organiz
ation/></author>
<author fullname='K. Zyp' initials='K.' surname='Zyp'><organization/></author>
<author fullname='M. Nottingham' initials='M.' role='editor' surname='Nottingham
'><organization/></author>
<date month='April' year='2013'/>
<abstract><t>JSON Pointer defines a string syntax for identifying a specific val
ue within a JavaScript Object Notation (JSON) document.</t></abstract>
</front>
<seriesInfo name='RFC' value='6901'/>
<seriesInfo name='DOI' value='10.17487/RFC6901'/>
</reference>
<reference anchor='RFC7095' target='https://www.rfc-editor.org/info/rfc7095'>
<front>
<title>jCard: The JSON Format for vCard</title>
<author fullname='P. Kewisch' initials='P.' surname='Kewisch'><organization/></a
uthor>
<date month='January' year='2014'/>
<abstract><t>This specification defines &quot;jCard&quot;, a JSON format for vCa
rd data. The vCard data format is a text format for representing and exchanging
information about individuals and other entities, for example, telephone numbers
, email addresses, structured names, and delivery addresses. JSON is a lightwei
ght, text-based, language- independent data interchange format commonly used in
Internet applications.</t></abstract>
</front>
<seriesInfo name='RFC' value='7095'/>
<seriesInfo name='DOI' value='10.17487/RFC7095'/>
</reference>
<reference anchor='RFC7519' target='https://www.rfc-editor.org/info/rfc7519'>
<front>
<title>JSON Web Token (JWT)</title>
<author fullname='M. Jones' initials='M.' surname='Jones'><organization/></autho
r>
<author fullname='J. Bradley' initials='J.' surname='Bradley'><organization/></a
uthor>
<author fullname='N. Sakimura' initials='N.' surname='Sakimura'><organization/><
/author>
<date month='May' year='2015'/>
<abstract><t>JSON Web Token (JWT) is a compact, URL-safe means of representing c
laims to be transferred between two parties. The claims in a JWT are encoded as
a JSON object that is used as the payload of a JSON Web Signature (JWS) structu
re or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the cl
aims to be digitally signed or integrity protected with a Message Authentication
Code (MAC) and/or encrypted.</t></abstract>
</front>
<seriesInfo name='RFC' value='7519'/>
<seriesInfo name='DOI' value='10.17487/RFC7519'/>
</reference>
<reference anchor='RFC8224' target='https://www.rfc-editor.org/info/rfc8224'>
<front>
<title>Authenticated Identity Management in the Session Initiation Protocol (SIP
)</title>
<author fullname='J. Peterson' initials='J.' surname='Peterson'><organization/><
/author>
<author fullname='C. Jennings' initials='C.' surname='Jennings'><organization/><
/author>
<author fullname='E. Rescorla' initials='E.' surname='Rescorla'><organization/><
/author>
<author fullname='C. Wendt' initials='C.' surname='Wendt'><organization/></autho
r>
<date month='February' year='2018'/>
<abstract><t>The baseline security mechanisms in the Session Initiation Protocol
(SIP) are inadequate for cryptographically assuring the identity of the end use
rs that originate SIP requests, especially in an interdomain context. This docu
ment defines a mechanism for securely identifying originators of SIP requests.
It does so by defining a SIP header field for conveying a signature used for val
idating the identity and for conveying a reference to the credentials of the sig
ner.</t><t>This document obsoletes RFC 4474.</t></abstract>
</front>
<seriesInfo name='RFC' value='8224'/>
<seriesInfo name='DOI' value='10.17487/RFC8224'/>
</reference>
<reference anchor='RFC8225' target='https://www.rfc-editor.org/info/rfc8225'>
<front>
<title>PASSporT: Personal Assertion Token</title>
<author fullname='C. Wendt' initials='C.' surname='Wendt'><organization/></autho
r>
<author fullname='J. Peterson' initials='J.' surname='Peterson'><organization/><
/author>
<date month='February' year='2018'/>
<abstract><t>This document defines a method for creating and validating a token
that cryptographically verifies an originating identity or, more generally, a UR
I or telephone number representing the originator of personal communications. T
he Personal Assertion Token, PASSporT, is cryptographically signed to protect th
e integrity of the identity of the originator and to verify the assertion of the
identity information at the destination. The cryptographic signature is define
d with the intention that it can confidently verify the originating persona even
when the signature is sent to the destination party over an insecure channel.
PASSporT is particularly useful for many personal-communications applications ov
er IP networks and other multi-hop interconnection scenarios where the originati
ng and destination parties may not have a direct trusted relationship.</t></abst
ract>
</front>
<seriesInfo name='RFC' value='8225'/>
<seriesInfo name='DOI' value='10.17487/RFC8225'/>
</reference>
<reference anchor='RFC8226' target='https://www.rfc-editor.org/info/rfc8226'>
<front>
<title>Secure Telephone Identity Credentials: Certificates</title>
<author fullname='J. Peterson' initials='J.' surname='Peterson'><organization/><
/author>
<author fullname='S. Turner' initials='S.' surname='Turner'><organization/></aut
hor>
<date month='February' year='2018'/>
<abstract><t>In order to prevent the impersonation of telephone numbers on the I
nternet, some kind of credential system needs to exist that cryptographically as
serts authority over telephone numbers. This document describes the use of cert
ificates in establishing authority over telephone numbers, as a component of a b
roader architecture for managing telephone numbers as identities in protocols li
ke SIP.</t></abstract>
</front>
<seriesInfo name='RFC' value='8226'/>
<seriesInfo name='DOI' value='10.17487/RFC8226'/>
</reference>
<reference anchor='RFC8259' target='https://www.rfc-editor.org/info/rfc8259'>
<front>
<title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
<author fullname='T. Bray' initials='T.' role='editor' surname='Bray'><organizat
ion/></author>
<date month='December' year='2017'/>
<abstract><t>JavaScript Object Notation (JSON) is a lightweight, text-based, lan
guage-independent data interchange format. It was derived from the ECMAScript P
rogramming Language Standard. JSON defines a small set of formatting rules for
the portable representation of structured data.</t><t>This document removes inco
nsistencies with other specifications of JSON, repairs specification errors, and
offers experience-based interoperability guidance.</t></abstract>
</front>
<seriesInfo name='STD' value='90'/>
<seriesInfo name='RFC' value='8259'/>
<seriesInfo name='DOI' value='10.17487/RFC8259'/>
</reference>
<reference anchor='RFC8588' target='https://www.rfc-editor.org/info/rfc8588'>
<front>
<title>Personal Assertion Token (PaSSporT) Extension for Signature-based Handlin
g of Asserted information using toKENs (SHAKEN)</title>
<author fullname='C. Wendt' initials='C.' surname='Wendt'><organization/></autho
r>
<author fullname='M. Barnes' initials='M.' surname='Barnes'><organization/></aut
hor>
<date month='May' year='2019'/>
<abstract><t>This document extends the Personal Assertion Token (PASSporT), whic
h is a token object that conveys cryptographically signed information about the
participants involved in communications. The extension is defined based on the
&quot;Signature-based Handling of Asserted i
nformation using toKENs (SHAKEN)&quot; specification by the ATIS/SIP Forum IP-NN
I Task Group. It provides both (1) a specific set of levels of confidence in th
e correctness of the originating identity of a call originated in a SIP-based te
lephone network as well as (2) an identifier that allows the Service Provider (S
P) to uniquely identify the origin of the call within its network.</t></abstract
>
</front>
<seriesInfo name='RFC' value='8588'/>
<seriesInfo name='DOI' value='10.17487/RFC8588'/>
</reference>
<reference anchor='RFC9060' target='https://www.rfc-editor.org/info/rfc9060'>
<front>
<title>Secure Telephone Identity Revisited (STIR) Certificate Delegation</title>
<author fullname='J. Peterson' initials='J.' surname='Peterson'><organization/><
/author>
<date month='September' year='2021'/>
<abstract><t>The Secure Telephone Identity Revisited (STIR) certificate profile
provides a way to attest authority over telephone numbers and related identifier
s for the purpose of preventing telephone number spoofing. This specification de
tails how that authority can be delegated from a parent certificate to a subordi
nate certificate. This supports a number of use cases, including those where ser
vice providers grant credentials to enterprises or other customers capable of si
gning calls with STIR.</t></abstract>
</front>
<seriesInfo name='RFC' value='9060'/>
<seriesInfo name='DOI' value='10.17487/RFC9060'/>
</reference>
<reference anchor='RFC9118' target='https://www.rfc-editor.org/info/rfc9118'>
<front> <front>
<title>Enhanced JSON Web Token (JWT) Claim Constraints for Secure Telephone Iden <title>SIP Call-Info Parameters for Rich Call Data</title>
tity Revisited (STIR) Certificates</title> <author initials='C' surname='Wendt' fullname='Chris Wendt'>
<author fullname='R. Housley' initials='R.' surname='Housley'><organization/></a <organization />
uthor> </author>
<date month='August' year='2021'/> <author initials='J' surname='Peterson' fullname='Jon Peterson'>
<abstract><t>RFC 8226 specifies the use of certificates for Secure Telephone Ide <organization />
ntity Credentials; these certificates are often called &quot;Secure Telephone Id </author>
entity Revisited (STIR) Certificates&quot;. RFC 8226 provides a certificate exte <date year='2025' month='June'/>
nsion to constrain the JSON Web Token (JWT) claims that can be included in the P
ersonal Assertion Token (PASSporT), as defined in RFC 8225. If the PASSporT sig
ner includes a JWT claim outside the constraint boundaries, then the PASSporT re
cipient will reject the entire PASSporT. This document updates RFC 8226; it prov
ides all of the capabilities available in the original certificate extension as
well as an additional way to constrain the allowable JWT claims. The enhanced e
xtension can also provide a list of claims that are not allowed to be included i
n the PASSporT.</t></abstract>
</front> </front>
<seriesInfo name='RFC' value='9118'/> <seriesInfo name="RFC" value="9796"/>
<seriesInfo name='DOI' value='10.17487/RFC9118'/> <seriesInfo name="DOI" value="10.17487/RFC9796"/>
</reference>
<reference anchor="IANA-COSE-ALG" >
<front>
<title>COSE Algorithms &lt;https://www.iana.org/assignments/cose/cose.xhtml&
gt;</title>
<author >
<organization></organization>
</author>
<date year="n.d."/>
</front>
</reference> </reference>
<reference anchor='RFC2119' target='https://www.rfc-editor.org/info/rfc2119'> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
<front> 261.xml"/>
<title>Key words for use in RFCs to Indicate Requirement Levels</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
<author fullname='S. Bradner' initials='S.' surname='Bradner'><organization/></a 986.xml"/>
uthor> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<date month='March' year='1997'/> 648.xml"/>
<abstract><t>In many standards track documents several words are used to signify <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
the requirements in the specification. These words are often capitalized. This 234.xml"/>
document defines these words as they should be interpreted in IETF documents. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
This document specifies an Internet Best Current Practices for the Internet Comm 901.xml"/>
unity, and requests discussion and suggestions for improvements.</t></abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
</front> 095.xml"/>
<seriesInfo name='BCP' value='14'/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<seriesInfo name='RFC' value='2119'/> 519.xml"/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</reference> 224.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
225.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
226.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
259.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
588.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
060.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
118.xml"/>
<reference anchor='RFC8174' target='https://www.rfc-editor.org/info/rfc8174'> <reference anchor="IANA-COSE-ALG" target="https://www.iana.org/assignmen
<front> ts/cose">
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <front>
<author fullname='B. Leiba' initials='B.' surname='Leiba'><organization/></autho <title>COSE Algorithms</title>
r> <author>
<date month='May' year='2017'/> <organization>IANA</organization>
<abstract><t>RFC 2119 specifies common key words that may be used in protocol s </author>
pecifications. This document aims to reduce the ambiguity by clarifying that on </front>
ly UPPERCASE usage of the key words have the defined special meanings.</t></abs </reference>
tract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>
</references> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<references title='Informative References'> </references>
<references>
<name>Informative References</name>
<reference anchor='RFC3325' target='https://www.rfc-editor.org/info/rfc3325'> <reference anchor="TS.3GPP.24.229"
<front> target="https://www.3gpp.org/ftp/Specs/html-info/24229.htm">
<title>Private Extensions to the Session Initiation Protocol (SIP) for Asserted <front>
Identity within Trusted Networks</title> <title>IP multimedia call control protocol based on Session Initiati
<author fullname='C. Jennings' initials='C.' surname='Jennings'><organization/>< on Protocol (SIP) and Session Description Protocol (SDP); Stage 3</title>
/author> <author>
<author fullname='J. Peterson' initials='J.' surname='Peterson'><organization/>< <organization abbrev="3GPP">3rd Generation Partnership Project</or
/author> ganization>
<author fullname='M. Watson' initials='M.' surname='Watson'><organization/></aut </author>
hor> <date month="September" year="2020"/>
<date month='November' year='2002'/> </front>
</front> <seriesInfo name="3GPP TS" value="24.229"/>
<seriesInfo name='RFC' value='3325'/> <refcontent>16.7.0</refcontent>
<seriesInfo name='DOI' value='10.17487/RFC3325'/> </reference>
</reference>
<reference anchor='RFC7340' target='https://www.rfc-editor.org/info/rfc7340'> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
<front> 325.xml"/>
<title>Secure Telephone Identity Problem Statement and Requirements</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<author fullname='J. Peterson' initials='J.' surname='Peterson'><organization/>< 340.xml"/>
/author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
<author fullname='H. Schulzrinne' initials='H.' surname='Schulzrinne'><organizat 26.xml"/>
ion/></author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<author fullname='H. Tschofenig' initials='H.' surname='Tschofenig'><organizatio 816.xml"/>
n/></author>
<date month='September' year='2014'/>
<abstract><t>Over the past decade, Voice over IP (VoIP) systems based on SIP hav
e replaced many traditional telephony deployments. Interworking VoIP systems wi
th the traditional telephone network has reduced the overall level of calling pa
rty number and Caller ID assurances by granting attackers new and inexpensive to
ols to impersonate or obscure calling party numbers when orchestrating bulk comm
ercial calling schemes, hacking voicemail boxes, or even circumventing multi-fac
tor authentication systems trusted by banks. Despite previous attempts to provi
de a secure assurance of the origin of SIP communications, we still lack effecti
ve standards for identifying the calling party in a VoIP session. This document
examines the reasons why providing identity for telephone numbers on the Intern
et has proven so difficult and shows how changes in the last decade may provide
us with new strategies for attaching a secure identity to SIP sessions. It also
gives high-level requirements for a solution in this space.</t></abstract>
</front>
<seriesInfo name='RFC' value='7340'/>
<seriesInfo name='DOI' value='10.17487/RFC7340'/>
</reference>
<reference anchor='RFC8816' target='https://www.rfc-editor.org/info/rfc8816'> <reference anchor="ATIS-1000074.v003" target="https://access.atis.org/hi
<front> gherlogic/ws/public/download/67436">
<title>Secure Telephone Identity Revisited (STIR) Out-of-Band Architecture and U <front>
se Cases</title> <title>Signature-based Handling of Asserted information using toKENs
<author fullname='E. Rescorla' initials='E.' surname='Rescorla'><organization/>< (SHAKEN)</title>
/author> <author>
<author fullname='J. Peterson' initials='J.' surname='Peterson'><organization/>< <organization>Alliance for Telecommunications Industry Solutions</
/author> organization>
<date month='February' year='2021'/> </author>
<abstract><t>The Personal Assertion Token (PASSporT) format defines a token that <date year="2022" month="August"/>
can be carried by signaling protocols, including SIP, to cryptographically atte </front>
st the identity of callers. However, not all telephone calls use Internet signal <refcontent>ATIS-1000074.v003</refcontent>
ing protocols, and some calls use them for only part of their signaling path, wh </reference>
ile some cannot reliably deliver SIP header fields end-to-end. This document des
cribes use cases that require the delivery of PASSporT objects outside of the si
gnaling path, and defines architectures and semantics to provide this functional
ity.</t></abstract>
</front>
<seriesInfo name='RFC' value='8816'/>
<seriesInfo name='DOI' value='10.17487/RFC8816'/>
</reference>
<reference anchor="ATIS-1000074.v002" > <reference anchor="W3C-SubresourceIntegrity" target="https://www.w3.org/
<front> TR/2025/WD-sri-2-20250422/">
<title>Signature-based Handling of Asserted information using toKENs (SHAKEN <front>
) &lt;https://access.atis.org/apps/group_public/download.php/62391/ATIS-1000074. <title>Subresource Integrity</title>
v002.pdf&gt;</title> <author fullname="Frederik Braun" role="editor" />
<author > <date year="2025" month="April" day="25"/>
<organization>ATIS/SIP Forum NNI Task Group</organization> </front>
</author> <refcontent>W3C First Public Working Draft</refcontent>
<date year="2021" month="November"/> </reference>
</front>
</reference>
<reference anchor="W3C-SubresourceIntegrity" >
<front>
<title>Subresource Integrity &lt;https://www.w3.org/TR/SRI/&gt;</title>
<author >
<organization>W3C</organization>
</author>
<date year="2016" month="June" day="23"/>
</front>
</reference>
</references>
</references> </references>
<section anchor="acknowledgements" numbered="false">
<name>Acknowledgements</name>
<t>We would like to thank <contact fullname="David Hancock"/>, <contact fu
llname="Robert Sparks"/>, <contact fullname="Russ Housley"/>, <contact fullname=
"Eric Burger"/>, <contact fullname="Alec Fenichel"/>, <contact fullname="Ben Cam
pbell"/>, <contact fullname="Jack Rickard"/>, <contact fullname="Jordan Simpson"
/> for helpful suggestions, review, and comments.</t>
</section>
</back> </back>
<!-- ##markdown-source:
H4sIAHrdfWQAA+19a3PbVpbgd/0KLPMh9jRJPS3byqRrZVmO5PjVkpx0OpXq
AkmQhAUCDABKZtye377nee+5ACg7iXtqdmtTM26SAu7j3HPP+zEYDLbqtM6S
o+jN8eXlsiivotP3dZJXaZFH06KMLtLxPDqJsyx6GtfxVjwalcnNUXRx8nRr
UozzeAGvTsp4Wg/SpJ4OqjotB8u4qmCoelCOJ4O9w61xXCezolwfRVU92dpK
l+VRVJerqt7b2Xm8s7cVl0l8FMVlvXWdrG+LcnIUXV6dX5hv52/8l/NJksOa
11tbVR3nk3/GWZHDItZJtbVMj6Kf62LcjyqYvkymFXxaL/DDL1tb8aqeF+XR
1mArSvPqKDoZRj8m+aTeingbJ/MyrfSnopzBvMWiqKLzfDzcipJFnGZH0Rgf
or3+b/p4i48P86TecuM+H0ZvkjopqyLXoZ8DNP1vNParBAAQl+Ho74p8uJTn
/nfOTwxH6W9bW1t5US7iOr1Jjrai6HzwdMjwTpfjokwGYzihNJ8WCHJ84OLZ
yf7e4a5+fPzoUD4eHB48ko+He/sH+vHxjj77cOfxA/34YPexfHy0t3fgPz7w
Hw/dxwfu2QePdIrHO4c7+nF3l349P351PDh5fXk6OH7x3VEEv0SRoCD+Gh1n
gCppPV9U0X/O63pZHW1v397eDtM4j4cAuW1ArnSWLwAJqu1xUSX0z/D9vF5k
f91CGBg44d733XIf7h/oah492qWVH1+dXw52d+C/hwfDm52dvSO7oEuYKK5X
AN9RXCWT6AzwDcA8i4ppdFxVSVnDj25KOONVhX+ti+9PX1XRvcuzY/hw3+8j
Ho+TqhrCsxVvZbmstmdlsVr+c7kaZel4e1Lc5lkRT4bL+XIbDujx7nZricPl
ZPpXWqZidET/wYhxnv5GKzminW3DxYmeFeVqEb16dR5dxdV19B1OR29M4Foe
RXs7e7uD3V345cf9k8HlCu53VazKcXKew62Fk1iHIPEPRO6J8KRu92lzVxfb
lxfn259eKcwbrGf3cLBzONjbhxs1GETxqKrLeAz362oO1xOIzgrPPkqQTE0q
R7f6UQyAv06YbI2L/CZZ42GMy/WyLmZlvJyneEvWA0QfODf8EhxePCpWdbSk
yxdnMMRiscrhHfwjEJK6gKfH2WqSRCUSxUVSxwNYcywvxjwioAh9SMqonsc1
fM6jURLJpPjX1IFtWRZ1MgYkgtHLOK8WaU1f8KlqNaqSX1ew1WwdlbDVpIT3
YRH1POEJJtESaOZ6GBFgpiVQGqCQ1xF8wSngjYldNA7KQNP16VKjapmM02k6
DsAxStYFPDBfLeJ8ABR6Eo+yJJqk1TKL10TXEESwBPpdFtY74aHPn/ai6Sof
00gISfgf+D98pE6yZDkHmh0B1aQFE1CqKM6qIkryeZyPYeW3QAMAph5Yi2QM
f0qrBcMVcSERqMLkAkqagZENDx9HJsgiO8JbW88JOn6XiCyTdDoF6AJSyZs1
ERC4zUhYq6QaMiou0skkS7a2vkLML4vJira3teVY54cPQh8/fqQNeYSE2SKm
ITDn8x/lUSSw8OhnImwbV3GziANpgpu6KbIbemwTDn8TpQS3VcUw4zlhmYqc
RNJweIJUEqXCavU7zTVOlzHQXpwHsCIb1CljgpkoSoBxAT2r5jDqTQo3hM6n
GBdZlKXXCTJ0B6yDjx8RhRPi+fgcoNMCJAWgBnTRGVJAugFSk2ScxXgPqmS8
ohPGZQU4CUtl9K4iAFEFW8CfcOyvcc1pnQJcqnGxTOTitCgKDgkgwtfwpBCH
3AmnjMPFTVLixaEl+5s3WsMKpzAJop5/KXESFeEjYmhVFeM0RvahuwacB0ZT
WVyOJ5MU4YkH2bixZZLFDeYzjHg/iHj+xY4brQQEV0kUBOhxOkuB0+Ev7szv
JcPZ0N7W1WIESwBcxdN7e3F+311ES26A1llqhdy6UuKoJAvBOEExZ8Gwup0n
sKiSngcWuaxxFpIQkXoVC7oWAYbJ2QltC690tQLqHPM5KkoQ9tKtwKEVq5Em
IWlmHImbWAw3H0+tTxc0eR8vllnSZxpWxg7CluTJTB0kDoTUGdM0PTrFWrt0
AuhtscomTTg2qX40YfyPM7yyKJKU0RLQJkf8Bo5BdxzwEbgPELUCxsfhCwf2
xAEdcWpe3BLwcbDmWeHvnrXdzosFHrkgEFDGKwOL9saRtMSMakIBqmgeA3El
gFSrJVJmhEaSAcnlLUVfK3ri8X0NF6xY8LUzeIqnhodRrGZzonkoJKRjPSDa
pH8Sl1xMATxRlkzrEBAxY4mbJbwbgvYASiCX1SqreYlZAY/hRYM7W0WjorjG
EwBo42UvERYoGiDJH+J9aeBQlS5SIGRwTigejOOyXLdZE2wKQCFoMmBQCP15
hmudA0+GlU3TBNDlJs5WSTekEHsa4OjTYjNaKbK6bK0jIzIPzmEVwfBD4Hi8
QKWW/egWqGSdZulvCb3YIIUw6QIUk2iW5EQq1yp7CPnzjEZgBgQS5YgqIT7t
qJAFSF7UwD5ASBJKs6qFABB9MCgz/JSwKFT2BjEj4LdKe1U0IJnGHkFP4I08
BchgiSJaVVcEUDlVQSd8jLhkQdfMoX8fadNtgvcJpLZVSX/tkUhJtwzxphfd
Aw37vmHzzAAA6nN80NE9+lOB5LeulPp0HyEukFdCMisI1SC+MMcxYiogtKc3
Ci06feUp/ehS4LO7hxLYuExHSeVlJR4uyUkqdJcBcKecDPhGqZCVMrcTKaTk
fRkRx/NIkQXdEfOVZMGiBxpvzx8swAfmHWcJ3S5Go+laJYVgGQw90WUEdqG5
I2Svz+AGASL3w4tgYCBUdAlATcobvhZeftUZTp4iUlRjAFGZFhXS4ZKehX8X
wA/gFPIiH7RE0VLFl1olW6St+BmHFMmiTKZ462IiVsClYHqVu/EpOno6ICOe
4NHHoHgAt0WQjvFqTpEJJoMsAdpACFYC5g5R9L0iUlJkxWwdffiq1m/r2foj
3rokEkNNFfVevr286vX5f6NXr+nzxenf3p5fnD7Fz6Afv3jhPugTl2ev3754
6j/5N09ev3x5+uopvwy/Ro2fXh7/1GPlqff6zdX561fHL3pM1+x5xWUicgqe
TQmnVZPs6w6SROgnJ2+i3QMQPv8XSJ97uySn85dHuw9BZMVjy3myIgdM468A
Z0Cs5RKwj8h3hpLbEg5Rrn0FKJJHeEwEy9fA8W7S5FZxQ6TODkRsy5JNEkeC
JyBh40WmI0I1qm6p1KothBw6VkiaQfROF0QVhX6jtNipkxAdM9JmU4j8HOmN
uAcw6TjNNuo+TSm2SSFGCQsecB9zPGQh6MtVuSw8qPEl0kDw4tAlzNdNenab
0o5CHGniVbGS/RLvQvIGMy8LAZ+yE721oSmgQzftOxGN1TY38prXpDweD4o2
gSYQpDwgBSl3g7Mas3iI5H0eZ1ORdFlmhSX5jSoh8iRSBquULoU0CZUgWlTI
u8KpPO8iLiLiQD/q1JnncO6jJMkFAVWfaAnmTplMQUBeopQM8Ae2PWe61GfR
oDYK36qKZwlfcodRVgNF+BKXIVEGGLubgh5CWyqqqU0swSed8QRoL1oRxnRx
JqIJ8oKbyMIrnK6QAbsBZHMIayMr8coBkki/FWo8A11I4qGhiOGXJNsOVzNk
Ok1co8Fju5T+8JLdcQFSlkBuQfIDvhOJ1R+uAav307QEDkMYQoSILrhVpFT0
Q8nFmtSSsrXOhkgGszmLAh8VkOL1ks0naIYBeK5QJKfFL62JQ+UqIw8nSjFE
6iRaouoD6VUwH0ngZ1a+MrPjaG8GaiEeqMdCHtlHXO+LupCOO0Qde2kQdFUy
LkjzZz8Kw0/AhcfoDWJ8bQDP8bR0j+9O4jLER9JFhPxXLO7FfDZDWOSd3gWy
wqjEQ6rGUs5PuBfPBiDaIIfC4nDNbqO9d6D/gAjnH1f6TNazYXSaEnbDmkeA
57Ip/DNgGpxyQmhHeCVCLNoMYIRSLCSowOYiJzIPUzg1URhuxrEznaCkRzau
THRzFoo7cMhdt6YV7IauRV0lQAvvAbWsVlV4xexgpMMmN2mxotOLSSO53/+M
8yDDqT8UkInxAbTZVkXeo8EWqO16Ow1ZPdsbob+T8YXfZWYvZr8VqjbMK49B
vb81AiQBtTcu815fubCM0GcFFwTImNRZkElZFo/rBhrp3CFPRksDja5WJj0b
EDOXNdwB3FxtFF97zKNkHCNSMvtM8psU8R3ZCms8bpX4Z1Qu6TBReYtDmWTz
/STaihQbbdNIp3OlbNOSrfd9tDsJe0ZsxR2O4iqtWhJgQ3Lz3pUPX8GmnKgA
YvaPIGwaLFf114j3ZSI0DNEBlYc+YSNhvCG5Vmn23L4uJjEgPxO82nG8ZZGl
4zXtGMaGgxwzmovgc6skJAJpb8FT45tZVtw6Vo7kcxj9KHIN4jseKXnUpkiO
0DAEgFwRzyuJOjK1wtMY44NwvxCuSQUStTN40aaSRVySFWZcLNcgG81Rnymy
2JE84ZK8DR4xYW4s2he9M0r0nqesKSzxxpFSRDJm7yape+G9F8oXykFN87IT
qpueDIJQJXdtApOO6QqCbMOfxQzHajUtmm8MbUSUaNA5QOAjmOlSjWkAbiEg
ek2SVGDtmKQzVPusBUCdAzdxlqJHzrMGOnmYKEtZ4vQaptiOjObI1sQMFWIU
EAFOy5SEZBgCzXzACsr2LA1iGlAE0psrvplCxWIirrw3ta4zIAAjHCSEHLPU
I6hMQoqegoj4MekbTu6Mx+jdQh8G/5nEd3gNJA9A2HFt5BtcovCsQNaRlZuJ
1BfHCKb8WKxgXhkg8sUjsbmg7QMjEYDcBhXNz4K1GCc7D5kMkPEYDdBi83AC
K1uK0aZP9I0oNZNQNiuSK6BPa1zgzZyijSV8G7g40F1CYRYAWn/OevflSgS7
SPNqmZZqrJ54LxnC6Mf9kw0e50BoBh65yXmtziURodpHsqrUjBYv41GaEfzZ
/o3enxMCw4nDdaA6RnpQDeIQubDzr5q/YdSDLqFzOL8RZGqzVSrY4S6JHEjz
fnkf3mK5qhOnWVK4gl5Ix6FV9yT8I53/HomA8u0+wsVfPFYrxKKUlowEGEpT
+Guqt9NdxtHarYH4HRET2YVT5MbjFbJruItPAlHOn0ffYDsjLq/EAa8KDyOk
WrNERUWVDDIUslBFFCXYiRq4Zrm09s46GdvfadIN1UPVVnfZfqnSZNIQi8gf
hwFRg9F6wLcJPTXyg7sk30TpMIErlqow5IUPEZ42TxCa/jqiC/Rs3IsOUUhc
+9Sc1qlxJ+1orK9bd9kMV0EdpGyhnaEkw4CzpfAdVZRmnBoH9tWAhjg2KQ/A
egbVuqoTKzB6xRo5vJchWYZhOxLJLqw7TwvkbSTJkp1brC1kMSsaRj3vE8El
o43YH1E1V18fITAJl7CBYXSvdwww6Fk5rhdAxRs2aQXD+1tb/2X/2/rLwP1n
Pg4+9at9YOtfURS9LHBfEXx8VdApYzRdJP/9i//nXA15zb9H//pi60B40Iy7
R7gSD0OQs+HXPYpJNAwi/O9LreNVkQ9oJf+K9o+aFH0Ivx6YdQy32w98kXWE
J73lqRd7BdDHCF8WBfs9hcyTlw9REE3VZJrGhTo6XonoSa5AOs6WHUFuxD0k
VaAv4WlXjhDgZXBkQkeNy8SPplyM/3Zf3MmsYmy+/GpklNe8JxK312+Tu9Sr
c6iBkWihYRdiMvGEmWDVQSk9J1UVH0NNUazptFvi+GiAcnq9GDysgdGHeAR0
UQ/Jm9q9Os5n6vxDG2FEcm9o4XA+QRf9xRTa+MNaNL1qwhbGDO+U0MZUZyHH
zsgfsbPrB4KstUxh6EPZYTuHHXgaqhKrgKFjXyqK9I1tIvM8Ae3ZgV8N8VBo
k5poU+cV6wcCDU0KQg5dDhYuUMYqkznrpzCNKi1iSEjhjIg/jZP0hm/NBqlI
NuQYJF9dsrgTCKYFuoMJ+qDWEOqHpnn8N2UIdYesCf51+R3a+lS/w37SvVIx
YvVZp1NvqojLZCYzNiK605MkS2YacCAOD1kpn5OP26wLdRdb1ZjUYZ0tnpUJ
+29A+UbAe/HTExcyW1mpRMWB8Erw9VuWoMqAOBJy52B7AhxV0NzqHTWRfcEf
vfgA0xrv7W+wEOcMSju8DxggTRY8CWRhEwUfOpqVUN1eD6Nj450wlN6TkErC
XrpRibHFDxGPKgQSWxlUI0ADhgdfi5RzaDOSfDJcOcxg9sZ39KlXaXENb8n7
QNarfzIB+Aivmnf5LR7hw1fVGoTO9x83OTZjMjo+v3z9KvoxGUVXFFrpfZI0
Vr9hRGOoiNg9tW5QGqcYveOYUTF/qJ0SPZUwJNnxrpO1DLCMAfKbrTrwKV5l
tTIZ9x7BC3bdy+NFD3/mW+++yuhyrX0kY7/T7KhOv4Lu6MZgZd4pYpCJO4Lv
9ZiHsf4Tom+wZU8bNoUXkevQhL00fR5hRJGjKV2ukI7RW94RF1DDT7lQGoc/
jJMuskbOBmHa5ExwpOOkKc9YxsJLMFjBZALHYrzEl/jMaGzWANqwPH7y6lk0
S8XWGjgPz6eegoP0JKbwdphLiARO8JIl0uw1klhUqEFqWCxRkaDBFNPiZW4x
Tb8aTMu92+ZOt9e/EwfRLP0ncO8e+Rg9d4xdzKEsnaIUyzI1mvPdPrn7HWFx
Dom9Y+hOJP55/7s3b6Kry2jvYLi39zi62T0cPhzu/PJHMfq8NtJElSximHlc
aRCLi+CWLTvzjI3/Izh7ofE3NsdUEq1kYj05jDzK0mQlp5GWjqzxDH0XnxGC
vkwWIEJLmOiM+YXY1cgZrMHDGnsQjTEiA9kPKOLxxE/nsKkrZqQbl5F0F4h3
Ge+tGbG8bEjiGr/2aLhPl1LQXuK6vhD14KtnAnrcffNbsJHTlAMQynpGFnPS
vUOUlplCDzeIX8fIrjuvt0hJiCLD6EwImszrImTVQL4Bk2RcelWvXh7RJRVl
LFanyyQZpyxsSGg+TYfB+C4AxodIAIImN4hybA+txU/EEsyduxKziqHR5NXj
aDYYQQfDEECHLaK8kaUI/XpruZt32cXuPhThRxyEYQ87ruzJoNzu7rIKn13b
EirWgzXbO0CXiozuJIlXab0SnxejUq7xIWS4lGAAtFzmIFNXYpp1VszAwTmM
XmNwG4LHo60EA8kKh/IXvTNsyCIHZe1Ni03frhhpGdHqwvG8T58tuzGn3uFA
rgVcGFNFxUZyYviwUGatDdApv0zHAb/Ur9388uzq6s0lCMIvvLgccYgBO0ec
ibTLq7ZMx8A2OUTf2fY+n6mqgo1BI36BDSsiYheZQKPCk+9FAleW6KxydI5B
k0U3ImwlsUw8zd78SWSqEWrD15bpoF+T27DJy9oQECJzq1XYhys49O7hhnut
GE0l5Hs7w8eNOK1TkTYwxJqoQHXUNJC61Rxx+iJnL94ORVAZAuS3gaWMk22g
D3UxfLec/fUbzFeVhX6Li2qa4l4V6sv8dNiGzTdqRGz5PUtok7WdvXc3CSSJ
md5r75DwKi1B1g2NzqWY1L48sNoRBrAbgZGBgmowSeE3+ZkJICoy57XBNoo7
yQtnCKHphBA1z6oOrOZ8eSlSV2+v4nKiUQW5aMmfAKM67znWwFPU23hdcTiZ
ZgjQMfLAWTEryJfccZnFQOCpgN8wid3o9045L6d9zRiAOAXTWT5OP4J5Ga8S
3A70pVbeeSgRWQhOTVDgSFiOBbBnyIxb0MWdslra3F8oLoMcv/50rV9B7UMw
HUpKnHQkeSMYhEih50op6dw8pdSvnlIaD7qP+mFYcCLfzmO0mLYULYkaq1qx
WaGjN24GJYsKLymWJrORpmbv+cYQZYmnLzQgWQZrZLQ5u7hXXTZQMoZC4B/+
FBEQ4qeRQRoM54VA2VkQyifm0mXCMjvtui3zuIoBJgyURyPaX64U8Uz2YSo5
aC4iDhSQ0DxtgO4XGcaIIs9T5KWQvcCC7kL27MEYmPEWC/YhoxyLb49WaVYP
Ur8KdgIGUAkxBVnyZLIhFVKuuENfPHvh7y7eMG6KGC+PfzKx/Q0VgCN60euA
OxbxX7bC0JIMLR5u4gUmvR4tixTOR6lygeXa2T55Rnqy+4FI8y5clpEXWMiO
Fz37dAAyKdFLZ+nFKTGPoZbYys/AcBADXaiQMDtK3mWXjeKwRLIGl1XsrK0U
Gt1faO0V0yRy4COWEsWmeiveakSJzwim5DWG0TmEZHgz7ZKnFD1Psn3gfAHW
yWq8pxKxiVn3VlhBTQ3/aVgVKCtQ1QEUZN+QIT50bXFI+uZ3myKwVVo9Z1RU
ZxS1IqtAQ63lLt2lkVSfNA/P84ss5BdZW7L2PFhCF6cYbk1pp3cyDg62vE1G
FLmoFgL/nfFfKcjL85enIAVPUiG2eHo0GAlUyFcwso3vwPY7DApVc5ywdkC0
YiIq6NurZ4NHalR48JgjfGA3gEjXHA5alOyDccl0/26WQU4CiQT+/MH6/738
xdHdrIPuepIcanVIBwnphPiSMaZNgYk2KVFdrDDgn7JOxfndRZLb7iKkpAGh
zv4/of43Eeqv1Jcc+pjZG7TZk5R6V9KVIIDzR/ucsolPt2InWdsn1tROzOo1
gufDhyDw+mPLSDXU+UmVsfY4xAkSuhtIGxvHJ2UpTXUIu3iP2oQanprAxcqs
9YVuPF8dpy3XHWDpcHiF+SKiJcstsVbNYhqOJvc2HFFokvi+6C/w3HbDcYah
fvxC1aCQBCoN0NLw8Q5Dq92A8MDuEBBeUBC6r1EFjYiSDipAWh97VJi9AuBB
mqUUIhea4F3wdy3YBU43rn7Lv0qmZ0xpsPGgzj8fhFNrmCrGT2OA5bp9+5hJ
W2C6GGcsYbDgyMgygU0mN+xZ19JT/K1ZewK+DshK7JJ8BT1s1pvXQg1adFBq
NRGx7EHYsiwoG7cVXIuVyTzPw1zj0sr0yGTIm8GFJJpBHohZTUAz8ktYjMFh
InmLKslu0PjhyIeLio29LV+s68QeGvHA8NM/BeYoFQR7E0eiGEU9CAONC+O1
YlI3SfAShwNLKnJtVcuVmG8JJ2fEZKfbkqoT8R/glknVCpt8s4ivkbMvjYPc
B4oYaoPLHAI5lrgFoyqysZW0PDRtAHIK18mdr89TNvcgqowNU9yWPHYUfdiK
ot42QvUo6lXzeO/B4eDh9eTkyT9+PdvJf315+aZaHD+5qb7Pzt7M/3F6Wc/e
Fe/mk8vn312U++V1r6/vb+9u723vm1HevTiYHjycPnu092J1Oy5fl5fr8fXx
weWPZXaaTY8vzq5/PLz+qdh9PjnvbX0Ml7flqCvdcCJVIXFjs07FFMCFL8Xj
ssDg/NzhjTeAKcq1aU+AMTBNP9ra+g8T75JhyRK5lOZtHhCetJSNVrMpZDfX
wfDOfMbrchNswK+v/xMlC2ClEojjgrSCNzrmk7wCOLD7WxL2gWJMsRjRhVKm
EuSMTcUhpYU7gC5KwcC77sWQhRbEyoV6FCpmrko68OF5XM39gFV0eXY8APTp
04f9Rwec8I9fHuzuse5Vtd+iqEeOtJPNCxpikQL4BANpnQL4BiPBN7xxyLrQ
6QwD3zkxXz3jiqSnXXRjkPxBa9NKbJXQ1L39A0rjZLqlou9l9CoWsnoOYmBa
Y14B1jkRyw0L81cuzTq69+r88uo+rPa8CVcQfhSsllgn6M1gu1oTZiyh2tqQ
Hz9+owjW7zgcignv/ZRUPacLXPjxgdMU2WrhlHccGeafwSUtEb5n4VjutMrK
a43EQzF5rSTan2HkWVn1Vdxde7FdzY3z9ZIsxPMYixElIvT47zZunBxdOr+g
uNc0miMB4gw4ufL48uT8PDp4IFGkrkqgmZWjA9BqBus+PGDNNRE9GguA4uE7
OabpP6fMchBX4QLlJDfJ4jD/Ns3RCkAyTRBjHxAtK+UYySgQ40qnbXWoQ62M
B5MPxRF0TtRSH3VsLTVpvgQ+JMtWouDrPRluaXO+ZK4czQHihSArRnSi+WWB
eCdb0ySVra22mFoFQWUUPNRnb2mf3Qt91nf7TTdmV6CBlbaNFLUpHs2IKcHh
WKEqbiQjFkbvdHKP3ZYeJzqCMN5ywka1aTxGgZQ9tuRE4LyfcQA2m81j0z4C
cFacv7lJbYxuKU+zmBBl7ZvT1uxsPtcFlo6TyF24t5wFJPXmgLKNIwqTKZOE
4eKigSWhDmv9lBUo7prsZBMJ+RVr/PYSfIJnEtfOCYE6si7N2JdsKi1dn87M
sFRsUl4Itwlggla+BiKzuUtSd/s+sJ4dHZWr8cg7whwGJHmynktO/XWJsFLu
Q6qcyWqtuiHDOLEujNFW+bFyqp0u7woDVM3q+D0tCuHSxWT4Hywa2TWGCIby
ZVIirEXvN1Nq4TYqd6XAYpSRB4ROqPSr95qd3n5FeTOlsUX3XAzelWISCspe
rDZkhBbYRUd0NaEMTrbQjrmcLm71912xCQfPJ6m3K4lt1egeHKJDJIfXejsv
MgksCQyuXKIxkMjoXUvIJa6glV4AS0OR6RnFwdGotAIMQseACK0jx5pOQRFl
N5Q+jjpNjRQpHrORkaTIEYDzupK9GrXEmWiC+06j6kRitQpp/8+SzvGLL3D2
WEZvaVAurAXRSM83kLRgs/u62Xy90TBITHpd++S0UTFx1jO0i2skf/J5c/rw
A0MMWaTGLFHPryuKAQjia1ymC25RozfzBOlhXKY+LYjXMQJZKnd1jCS/clKs
Rlky+HVFsYBeCrIB0CT2UsSQI/kfvoK//BN+c5oz8RemXqJqh+8y5NgoLPUF
TDygmm6etUqG+KBsjd5Ke+FFKcpWAqq1UruaEgzf0jv2WMndlEbEhVtzDQEg
Ek8mKXEtk6oDbIC4gGECGIPjQ5QMxOD7HdBi4eIuGHlDt3e6aO0ik+WtUctN
w4rebpSQ0/zaCG/MQbwkG0CXKhExUOHZ0mTsOP2W1yODOtoRUSASk1AyGnkF
3KExBZb4nQtt3ECmo942gVRZsKxKglD4EVeIlasnTLS8O15DnweP95c5mLnh
Ik8A1NwJvgvEnA9fwfc7TpDlQm+cMXZMOr+WK0Jv7BwNzrmG9Qn847KMBclA
YxjQ16phncqLWovYwwHnIE6WVBF8knK6FLJyI87zGH3jRRSmjjFcYQUQetJY
17DMTuWLoSoOmPAgL0102Yp6Yil6Rx9/7t2QA6xPReR/xu9Ac2Ajvf6Hj/0e
uvd6/d7BcKf3S1/qz//cm4Z//Vv0pIzz8dw+UpSz4JmX54ff6HPR5XIdfRdP
Zkld2XcoxIjfWpVpT/8Aa9UC+Ta6jAOStn9dAecFXhVX8C9q/e/h/4fLfGZH
xoilzx6Ywpu2F+mhG+3d8kuMdnjw/vCAx6JX8F8alcjzUdTrhE/LnmZ1B6Sl
ARqqFqIyL4r9/QZ+NOyL1p1t8wedSAe0oVTfIl8Fl3zhKrGyOmCsFaqvTL2y
SkkNSZlIeFunpfq3pCykXQRPpTeIbO+ijJrIUaGtvCC8Gh2mUW8ZnfxJy+hk
e3d7P7CMXhTvZj/evj18/7Y+P/j10d5frs/erM8Wu8+/Hy0e/uXwcH/08ua3
9WJ+nR0Eoxz8YfuqHeVBMMp33796//7X7MVFXI7WT17NH87H2wfZ6B/Hk+8P
n+xcv7yY7h6/vPjxzfVl0YNBPnZaajX0vc15WozdVfh957UXZBtUpUZ5ZZeD
2v3RiwE2b1q86HT8hvP/W+QDjNrnMHkq6oV8KEvyGRUax9pWVXQvluxBFiLi
EcjV911+W7pAM11MbSamtog4Bn3cxKylblNFDXEGawyjBplr+C42MOGCe9Tm
hGuGeo21b20Sxkf56WOKXZ1jLTgk8M+7QOIdfCbUHY7KFIvlQFa0NuvmReNI
JIsmadxdFyzyRtdJyoOWnhSpmola04spogAthnFIYNBEwm3GwqbmZyiYxStV
FF3JO5eyj4LIZJVPcFuBdSe+KdIJ6SPLorIxdGhFJHsvVR1Nc63OHdd1PL7m
4tZaPMtV3EI7MJbiqtShxH7pQk7ezWeOMxHvLMpEp6gCN/QiC6pwmyRPUoxF
3IDQJrXYiJpBrD+Z2QIxLNsshtWWnvCrwZIl8N/puhL87ExJ3lOmiV/wApMQ
FwaWvMeOBzaOgr2cbOXy0Yx2o8KHxFlmfYIB7wzX1WB9OaOC56oq8jXYlq0I
ziAQt431tN1nm7PIyZgBPw1XsNnZzmvDDHpH7az1U1ttWAtTK3q4LRqkWbZC
isDVcXndIhe6HCIkhCqXi7xzp7RJbskuCenXEUk9Qwwb632GPNRv8fUv4fH8
83w9+yJ8PftzfL2LpwursFRAUN970ZsXvpl9YjAvCAIj+8VmYtR67cvTpRCD
tdKzILKt7u98sTwul9VaR59CSR8WH2dYokE8o4z/hgsxSBtXwKpXn6FcfVK1
+v2K1Ua16k8pVZuUoN+vUP3BkUJl6petXxp4D8yq2y/gqh1IrJlkabFx4vNe
CTkUa+7OuKKSKYkXxuPQjgD1SEuF69AuqxFkvSVaX7FWxw9kb+t5OccQcnQU
m+KwGN2WiGUIRY6lq/ZqH1ygMXYpD2JIoi9d7eIWxPvMElKYVWu3NC+ySVdK
K/J8H99VJXL9moXfGpKaf4O7qmmLBwAJpVF6U0k3dKSEBW0nBzkBvVhSWgt+
dvVx+O6GVdC8i4OCoqlCjQ8ad5mI4gYggoUzmKOQUC0Eu8aOaUCBUUjaCxdz
6lTKWascaoYe3oHLHDns0VPjKFOP3EZi7h5DQ/2aMY/NlOoN3uZUbWUt9Sws
rWPxJq2qlQacMxvBJ/Qw7lytPzGMcnGmd7JTb4CBLNGdg7uhLOnReTkEMHes
YyDS3GxWgM3Tsi4uMRxT8VvnOp8YlOBiXK/xUZfj0+xEY/FL5c3uExDgetib
oretelcOhOZE2F1H5+KkVQZR3yqbDjkcvMS3JwZneZOaGdnhu8pgbC63iW1U
uk/ftIJrW5CkkKirT3B3SdEgFRNDa4Bi/6apmGbLcmRqzmokt2GiB6lxBFU5
dFvQ3CKpnKcWd/t0VKsLlpHilKbGV1mMuL9bu7at0JI49FFrZwtp6uEcvhSN
1u6YY3tjsiGf61mPug9TdXIuWxXgVhWUamq28Si432CliNtol6AqjSYuis3b
5ifRWRn+Q2/2NNPHeuBo3pX4YqkeSgNPgdQ+MzXQKocMpWPfcUaZsaPkEySn
UbXPlOtq3LzOyqwG0UlE1nhb447z0sMRRjjGIb/rEhfUxSFV+xrJCtNYA8Nd
YQYNA9HNfGqeNCBWHcwu+RVjwDUaQ7Td4E3rQAocskaYaWzLtVdpwrw9v5TE
kNIK7UufurG8Ccg3WuB1NgYNPJryiMYSY9MbhrX10bWJe8O582n5z+PZvaZk
GnaNuy/ZVN2SX9+Gfju7zZcX9cKKZ9ToQI57wLXGLriNwIasFXjeJq38keJm
3FvBzLW5splI0TZGw4ahhX0Nfl/mWadtclOzCT3vZuJbs62Ds683FE8t4WDB
7XMYgWbwH46iHpK8NSjGoMZjnxbgYb2+M904W8xzWFcVPYHFG4fXRrMOdrB+
h2/8cwRvsGWnaZlQqdZTPXdWvF6+Cq20KLsjJzKNTY0RTfH5nfKoVQFtHFmr
eri4040Y2ar3mEttikIZhi8kahtnaGzolGQ7CejZSGLNvmVRGyLf0PZInFcK
D9k3iah7LuYSobiJtLHyuy5vQlWVQXfI8RLkEAIjQDxqedwSwq3AK3cUZZZN
+h0NyF6LrkrwzKB9lYGmOK1hHOIr/FNbRorWaDgiTJyp1gVmb3rjG+dkeoBU
jWx4PP1mXXK1r5noGRdAynHRyEALqQrm3qaBMY+V0ve7+tXd6y2Xde++oluH
GP0gKPO12/fCqxAtycENZxZvMFVRYoJK/CS4GLp7TssTxamOMrgOtdaNJCHH
CSEh4IbRcb72NUE5oNJmedtZNvUpImO7q26MTAyTtajCQjiOh1lqfO7aNqJx
413JLlyjsz+6BwRkTpz41MF4mHu5RjsgbizLswX0ul4ve0c9LJGPfJ3Nyjju
EdtH8GuczeDr6SXlVOAP7x+s4Acl4s0yPoj/Q/inF3UZlzfgrZxuZYQdtN/S
/tMggZECRTUYO2ntnot9kdVYo7ElPrzvWTegjiiqri6o80JTW4AFJmHAbVlj
9My0FjelHIrpBueLkUkMOhl7qKue0XlprrS0OqyJEqTMbuRCS5nGlZ0J7xhb
dhpF0IKgXS7+qmf5Txu2C7LQsekFg4S+WpHneLrCueVPpmdlrZYsPZlG0Wu6
lICKK1c6xdUPdnVfdJmAd1H0HyhIz8llyhYzDw7deRBobHx6XX0EASI6aDwi
NXdEsXeSCo+KOLCBem6izak3lLXdaeZ0iwBQLrKKke1M5PbE3XoZL+WTloei
3GR4QM+eqbHWZC+/qy8J+VtdGQxxGfaAQ3UldJt335AiGhxNaJwODsrkeX/4
QBWScUFMeQmHTzh7L7HKUjA4A62wdZ4bza0NCvRxI1Q+0LoZYQ01hh+rWg8y
MiZ9ZWu1FSCmu4QiVErMEE4nD6Dnbx+oUz6B3t4/cQ209NvkfUpNq/1OfdVE
k1Lc7BzUzE0cRsTNwtB1yWZNqvzrWoSZ2KXkOd+XBogG1bSmcKVM0f2uLJLN
fmS7OAwwsOV2EZYk+PABS1qITwdQ2G267dOwtnjbzOVN+xS1DY9zVZOkLItS
AL2p8EMIBUQOzTqg+PMU0xC1EbK3ACyWsXNsYng6GZFRXPFWSLsZMoYzGoWJ
0F19H2zaVdXUDRC2x1zTU2NBUL5baFw91dfsAiM1FEhMA1tEEtovxZbcplVC
JSk5W8tbojlYubPDH4U8aenIwiWp464a/aFZSrLGNDsFjktReEWGuUIoI7F9
cQNu8NU7NWGIpoUMgMeLTxw5QjydjKsbhA0nGVH62T3CUpPmIAgYT9Tvg2Pd
b2rMH0AQwjKSvaMPvToHeWh3b2fvwYMHuzs7O72PpPT2gBzW+vefzQO7vV/k
iTSGB3YPDvb3dh7tHzzgH0mZ/sCqtNWkP7Ykqs69u7Q3MjRSGJpk/+fsvSbo
f1HYRGh66zvR2Vlea1OCu7NyhAsfC2LuOwrOfAnw7z74HeBnqwVB0g3++PHj
HbVn0IKP/phXXIfgEz7D6knxO1js+usKxYISZBdJwAIh+k8eOnlP/zsPXGbX
SMCgP6yhfp0+K++8cMU4PqfnzP9U5EAYHFH2wjYc+zecIdxPf3jy+uJ25/vv
ZsUx/Pfq8u389O0MP77Ff56dHP+kJjP4evJqtB5l+Iez0+z0bz/87Xx3783B
9vaj7dv9R9+dH//96fmT7093np69n2XvXj05Pn79+OrvL3Z+Onh9pqPc4ttP
nl+8fXBaXj+fzWbffvtlUTCsyBYWvrF5TL4SKdkcnGrRLiSibJP1NTlnTcoy
TTSanmjOp7a6orji7sbYztD2boLVkaHjRAzk1iEiorqM9ogjTJgHAf+3G+w4
jHfqRVrXAL5XSZalCevVjLJoRa3pjRbWCtK6J7rwltE2CvHWhNb9X5HKcSdZ
/cysjS+SrPF7czQiGerumMQo+qinonGJYcLAH40rDBMG/mhcYZgw8MXyBc5z
W67G+zi1rYGrSivhAejY9+UKmZtJFSB9mHLCqAAhpTEH3bPhpWFAqUwWF703
L6rapz/rU1jSELTkUlq9fjLc7zPMbP8To/p+9w37Avfrz92udtCeet9Z6W/G
jmqnMcsMNshALvfwDlPpH6LknyTkf4qO30Vj+krqPy+OeiNJyjwB+PUkP1ie
nh0+eb56+Nvf88mLZ6vjN4dPb7OrmwfTi8Xz3eNn179O69v8pPJkJPsiJC37
IiQt++Ik7Tgsv2UMsyT8UHKnyabWKueV962mPQmdM73hG+UPqAEB58CKnPH/
CHKSkHx3YHFAiTqRFE5WppJDrV7uPXyQXc1+O6mTv7w4e/39Wf324PL9d4+q
efa6OHx9eVDUj86f/+188ZMuZFtW8gdQtBMtvopOCjYZkVnDeSe8Kfar9iNe
HwqpFPtN2j0Lxo332x1SJI7nEy67h32yylfFgqxbdZlK+SppM5BhHn6UUMIK
KXGm/By2G8o0raXqaNwZLNKWpg13n3NfUB9y663YvrGZExhYHVCDIkZOdBj1
G72ehOC70bDPg60NTHU9Jmk1XlVVCCvbxehguIsy/tXmafm2C+TTqYgtOJvW
pO6r7ddXNjAtzbToBevHrf5cXGdB0sO0cVVfrPm+X6XvaSaVj+ksrSFa5gm7
mfSNcbDzoUYLtH4kyUm9oWT9SJcJraWKdsGg33KADxPOGzHdhV0V4zDxi39v
OWYzAIzGxhSFR94bMYw0Q6rrO4v7lslNWqUS2MWOW2qREmvBQQ18CDqUYusL
mo1FRj473Y/0jVxpPEqrjm/hSve3G4dMWwfNd394J/VIu8mHRFy2aEazGVpH
ZDcaWiTsCzEE9PagjK7zjAdjN0//jkWTu7655uaTcedzgJkxkyd7G4PaEZsC
pmjMVplwE6M1Wn86RosCO6jK0uANRaC+RYb/4StxMX1EjxBqGhTgxsVpw54Y
PldZKntS6UbbT647LrfP4f9oXcQi66UzqNGoy5huGgegYmzHmGv3NlIqYLJf
V4mWridf3YADaWWWYXRJ/edcNHAynWrZRBi0rjgBluJiN9W4El8U3QsMrgFF
yRNyNvkBZTL8QikNZsPO2T8hUVCwXkmpIPpugIR6gFamox64Ey3VZnflQ0/q
mqOzNzYrkQxN6sEHq+c5YwNiEdkoOlSa9eaUikkd+3CnWAKzTQOpGzgPkWG2
L/rhsPpZc4kcilVV5BALfa8MWR9t3AiC9v0Y6eIui2KKvq3zVqcVXZPt7Ji3
QEspDM53hHSAgtYDnuU7QSNEmERIq0GSKsQN1ULRNL8prinmoAP5LHF0iJtI
0j0FrXPTNE4jdo3l0MkvRL0uJvG63xjdnrnOxNEYC5JC8EakSaMzm4Pu15Vp
D+dCfIAPlVLPEMGhzlP7IuOHc+Jl2u9unmTL6Spol2JvLtKGmAQScZTEHMRf
TuNxMwBGKzw3sk2wZWXNjcL9FCIGYf9idYdn9A/2uPLmeQo9KG8Cn7B/C6Fh
ererJ2dCrYA1Osr7LRVL7PpsLzxak6FpqZSUzidcA3CSEN4Po1NPhUiWqZi9
MRITw4ip8I7mlcPFHhTTwQiXxELdo10MwHAvMSAXcZ7zwbLRuQMnObscpUTc
LcdYfbq5IluhAmqtU0eLdDYHQaYoro3toUNoFOh5w/WRNGg9f/XD+dWp9F5t
CX8Yggy0aFObV+llz52ZsmY0E90BpYrWFccBrXFAc7tolC8BrOY52dL7tXYN
kT7uFe9Nus0y9jQ7YjaCWyqOIupjHA5DkZjZJmLCVROWVatjaaV9WQ0JRZfr
MHq7pLptuMBWzCClULpycXKdOCugObc0C2/wJ73lFHaJ4ejdfW5d7Wluw9u6
Q3JSVoBwl7TJzM/V0EVRszDULXWIgscFiWQyu1Ry8FOPWRe320SwrvVQJErC
tSzQQMp6BEqKcGspHKLobxyMVyPBvY6q8tKRIq0W8SiTvItW3XxesYKheycS
C7f2DYIxjMmJHnwLE19I21zccVZUvuSDY5QmZIYaeb7xy6xCEcrN0rwbodin
3ZUtm5kk8DKamugmrIHBLuRq4LUIzEhWFDBKb/BSwFyNcEoJVkM119suf0q1
2hjtgfvpuwiIJIocj5UXd+C/s8y6mCac3GVy3bkGoS2WJarPG+81kJHcg6bz
4sa519KZALpW0nT8LuY6Dg14VBok90W3ShSuUBGIs4TypIeqGchIoJ66UliG
QDESSOVKZArolCiTjAWceboEyNS3FG0q049XVQ0iV1kpA05LM6AioRx9WWn9
A21TEZVFUbc0VUKLuC0JUct0kvBYmMFXyGnChZHSa4zEK24nXEcBbZrLlZS9
q1CbquSgsAXiTdIhlLjUiVaZO9NGOmgh3UC5hkFMfEgm5rHVmKZdkfpScg/p
mEnZi1jZ+/CVi2+k8NpOXSMIn6WJNcaFG/EiNqzSinUGH/FIsOjSDCop69u5
Qa1+M3MF/cdAHVn+qjQMjAR5rqIhKS5rL7y53masgFDKgYuFZMux20AzjcX3
YdbzGUuBTNw2pXBSiLGkmdgE/jqZFeWaC+rrghE3TTNcTD5DMhcHShIvzIbV
BrmkwZucv4nU7RvJ6VMtJQ6ialnK1iL1Yo/kUiCBmZaS1aSPNyKohTV1JeD8
aLyIIFsCZfpMefEb+pvpx1uZZERC9TKZZlpp5dKnqNYbwoMFbl34yaeVvMdq
2WndSAuWaVyZCpmJaWDHfLw7qgjRuTHO/U6mroC4fXmGOJiT5YtKYDtMYYMM
AgBfAxmOj4Cg4kqTNRWL9nq7ErMuGiHBqSAJ3w7NegIKpIvGRi5CVcnlK8mN
2laT+61XQjFd3XVYTol5VCrBIuG18c197b/bZETMIMU/7sI50VqvJ2Y01thq
zmry6RDOWGLmxFVWzzXAlleJOTWdvEa0T+x1U4lU6sG39tv0N3TYDlazBFQu
yObAtKDU9p+O8PrM6EtErKPeP2D0HCSVCRa2AtzobQzNvATR+HkxB9RZrAEq
HVGawESCPA1mQxYSaCwy7ETC5dl0ewc/Y5XX1993cc2CS11KWV+y47ncHGVE
kCJS12jZJ2UI9GVASJiywkI0LL92MjeqU8tanWooKQd5TKeUJYztYeq7JDUj
KTW1Ae5NMEVCPHYtgVKbKuQsgywEs5dCy63wutGChjQF/Sa2G4hLMrAeMbmF
JobE+lVcPnSj/6f0r3LxI95w5MvadcWs9VxTmusk7zV5P0h+NlNaZBAnuKFZ
q1PlJv5g22/cZSTkwJWQu2/wRIZtBjaOaLQgTfcRMXxizL1MwOHyhbykMWda
2ZZmEw0GLW/izA/TCQQpQVFOsIVKKkUyl7WYDT3vY6Oor6JIBO5zjjyUQV0N
H9fAwD0fmBu7GpOT0dXU1JZW2f4tKXoomi3QwR86rcFI0ElXE/YUsibHUU1/
BC+rEHCMqOBRUUzC1k7o+j01c9/6lMZlkn5co9ZF7NIdZDK2VDbTwEgKtUmo
WLcDzoOFNSvWxlZODNMb2Lh/p2wbIrw0kQmF2b43qdyNas51ziqQZGp3sHwM
QHUtR21n+c5hO46PCqzPUoQJ4if5nl4AiLg/z7FSOuAjWRF/pLQRMdq1nUzi
RyEFQy6w1wld80JfTyUo4tDAEYEmCU7JuBiwkYGbWzhTcdfwmHguE2BmiRSD
mZija03WFtnUnpKDlFgz6YxzW1maj1dlF5fp7puGMeT7ug/vceRSPWgNlydj
JBKs9Wq6GSFbKAM5R8gwOiUEzgM4E89mlf6kWCxWuXNCi88seiOgiu6dXL65
j2OyQTpWIovlO4Gz8X1gFRoXj/YMV1KHdFl+nPgkUhj2ztzOC2sHxJ+bT5Oo
mZTLMq2SrgRtWJfMS9w24xgjrHfFawnAIJYCNfs4jBBAxOFj3kBmCmHJsVou
QyYG1srQzJhLISW4dQtnFOEqyfLouIyXOhS3rY5LtFEyeKS7xAbBNzzVY8MY
/DWQW9ZZu4r2FWOyu/UAbeDgDABnvCIMEwwx3BV7CJDvDffjluMAou0Jbmy9
lcxRixmQChRwiD6WSJSBeIypgpMkYPQ7JT65vdTx3LYTwuvcyP/iCH96kIyo
k0ZuoaPG8l34StFVHiO4mPj5axDSv/YF79Dv3o6yYn0OZNMPXwHr1GowYtsx
LUDhkUEjvMrXyDOmFa+jkeOl014pmemvibyynO/CdKzORzxRNFuvT9Lknkk3
VsDmqG5He/QkgcNOC64EYz1HW1tYYGBDeS/T46NpsTLRILaApK9MsrEkAQPh
vj+QgvpdhIar7gWpvqdi+kh3FaYTg6weFLrqXExYGYDcFx1Pkdzgi/JpWUgi
jUhxEJSb1kpr2Fg4g2HhI06EinTjTdBgzAZEiLjT3MzV3HZK6h6z07fYDB3V
V4+i6ubByVWx8+D7X5eXi/qs3p+MT9PX27snP15d/qPOv9tPf/jLbr5YlS/+
/sP22aJev7p8+KIuZ481zWiSvb/+8bcieftw8vD1D4/ObpOrq6fF6If9tL5a
zN7cnjx7F58uXq5Pz/cnDy/Xr/Z216+eFnunF9uvb2a1S1baebF6MK7Ol8s3
v76e7a7+nk9+Oxt993BxcXiRPX6Sv52fraY/XIyWD3Zf5vu3O7Pp2+rbb/Rt
lJy//U+NKB2lWfE+HdoyQ/LTOCn/+k2czb6lshbudTiybwnCrcoVgRkLZK2F
mqdGdI9jTAq+9ZVhlUr4oL/NNfYCR2ezokU/7FFd5JmvQ+qrV0jlCufNCMIz
MDCryI3FdpM7WP7svbDe9yOzkqTLFfhc/bNxsbBRmgOQRBMMFRucP3VFqFjR
UhtmjP5BDcLqhonvgodWtQmb/0DAWxZLqqncBJVCQjmfq2vDOfFo0wokipEG
YEjwp6s/LVun/agzBU+RMkY4tAGJLAkkYy7sYtpeK2lwztIN21MlqlVVw9AB
3lNw/zWJnEJxjE81Fp/qhtMNsEGLnNS+9ypx11WWBSy2w2cGCD0Mqkj0o09W
MfM111rBdiYyFY9L45HIz+Lt7dRK2OrDUnRwE1GmmHtXO0prtMZLDOcs00Bx
xaFFPVgvxVuA4b1UR5CwBydjgxksD0V4bLLmfPoqNolde5aiE21MEk2j2lNr
Ax21Nnz52YYkJWU2YlEpp8hQyDmsI91pdCd5lUXRVuSDEhLS3ey4LcRtbyms
AUKEAaHIFQnqWiQfuiHsR7eOpVaVWVLSXRdBbdm7Gb6izzmoiqUhyDZ1zgze
KFIQHIg1gHmxaA0iZR7JWmXLwLXRjMOwgxxSKU+ikbYe2zGNjaSISo8Qq4pt
xG9pb9KcF2lgu9DCsG1c/gyBsCuy/XC4F13WyTJ6YLNtAT7TzoBputZBRtWG
wlS+JgyJU0Yxd6VQnJDnhHAtDGxWzSKPArld88IVoGnU8OmuhvRxyxvjNNyD
MxpY01AZFKU3au5ttsHWHqlhJyuuqJYGm0dcYMcmBa9bQhhqEZXAAEoN3n0o
tAmK2Wz9hZMotVxJGKepTHqDAKDFdNhSa9hD7NoCCddhdtSWQ0gCSmtuPo4l
ifitduGsbiYDtMrhBwb3OVssZy5sZiK/s7amZH2/o6zMoOkqb0zjCXx9paDe
9zstT8ZP/+lNm4KIbAglwyiJB8546QafODdeNypIuW0xL/siXxvxy3N+kTU+
qUv9bixsdVUMyuSq7OPRKIivcfBx6wqjANXmHtQz+4wFxgbV+JKVSRvHO4qr
N8Ruv5mNcjUf4ZISWvBUxEqgkRL2V2l0hZVVw4bQshAkGRoc5rpCRVqp7SZZ
V/beRzanqJ6XFDgVq9elDuLa26uX3JySY6rdRtGIYrkBtygKJH9RKu/flVQ1
jC45/A5vOt8p15mdbqZli76HO1c58XUe2ezmi7n2I+4H2IQfVS9KTOi8ljJO
4SrpRVf1YjOlCe0TvD72I34qVwTRWJip0qq2JFqJKNqOcWrIWxK5qCNZHsiR
5uzwkQLRjsVyIXPAobfHl9EqDHAFSEogqMs8UomuwtSmQiOFuUybOHytuagz
grip4miMeZksODDKaIOOd1q/B1mOFwXOxSbj8CmtOO/8yBRZ2IznbfrU8PTI
D90IzKMaa1zWSuPsHaUQXW9JtQGMb9p72+Oxs2g2Iu7xQDeH/gT3SSyarjdr
X7Kt+oLycdXyb9DKGhmPjnpXW1uh7G4rqAVxi8GF47BGyovwki5qG1TZn8y+
Tpan5dwkCligFxUvLvRwWIAE5VYpT99QeOnw62uu2rrjLqOOSzqSG6g7x5XF
9GZPGrU7m3DbOxdd2QY3dyj1Ng2G8p3UKielg/XVwpanbp6MzTZy1lln3+80
9DWro2KcUtM/YbChf9cexmHIb2abKkwmLVZIvpNG0pIfWAShJjxYaXkTFvyL
MbEInzKkMK6c5JRna673EIsLtBHTaVywXmohIHqJZZPpnGxFVhhQs7LfrUWv
r0xpUL2arQdS/wRFedDFDR4ydepN5GTqqRnVGeRWTZLHqtX/idfriTdi0TOf
4+UB4SQUV/6zLdYIp+iKLoika7lL1bB+cvbPyw2pusQDkoDnRcGGGZf+nLKL
MWnll1AaHXdCeEfxZB3+XJvIhr2wbljSxtapKjzr7/BQeMnCeoKfi3yNZpVM
ZR48wiKtrh9AIKV68DfIx+XZ8fenrxpA+vDh+Or8coDxazsPD4Y3Ozt7qKc4
CkzzSq+W4+67S4rKgFQlxht006qsGGcFTO8RoR0eEXACEogsQRtGF4YyCWmm
KKV2OFQtLuIN941oDOURul5GApJmJKBryVMpHglehLTIpyDfXclbGrYEZptW
gQDVaZtxWaYdgj776bIx/7X1xvUVOCPwbHFllWZN7c5C3FqJW5bCP4XFt6nY
tvVv6ABUgXvr49abeJ0V8USnJW8yvH/c+1Mxkp8KvSRiNKG/7ScHDw4fDpJH
j0eD3b3J/iCG74ODvcPDBw8ODhDdN4dWctXLRnkNqrvSbfPioiuuPDsjkCNN
XdiR3BWKZ5gmSTnSaVdd83SPqPSQzyzOLV1z6O1G9rTFd0Jv8hhhBk5d79wp
+YHsTrtx1l8ec6O0XLDKVI2wO/+Oq2JrFP6gQ1CrmJ72xgW+HhgHW6YNHB7N
bShP1lpyAh4qSomYB62xTGagBXLtgOiZRE6dGxHyuGFQOKG4CEzA53LaH7e2
niRr5JGAVFyZoVF/Yd7QC7R/C8fo1bEiitYbI6r/cOcxRosaM0yZaEC1YVTz
1SLOB1w6MwvnaSebmw5sts/YhvQ2mxWGGcRuKG1opV4zDUFnDzxpuOn4GhQ/
lnjRGaCWc/YqZaBXSijg5gVjFBEdnq+UuOlRlx7PPJKjHny2TwyAWtdoP5VQ
f41bdTq8ZoujSFrhPpzmS34VG25aUcoRVxRGk0CetOHiWovIJZYSB9JiksUS
2hS1ybL7ooggfxZoW2jm/SFcipL6XmE58XIW5xLBRyvHbBPp+93I3pdWSSE6
k5GDQiAlPybliOVgmHupiFyxJFCw4XkGeumaBogBlPk1fbzFKSkkaF2s7utS
56Dil1hxr2LjNUag9DV6OqJibPgy4E1NwjqsAJVizu2kAD0+D+cDVWdpoEzy
XBae4hxyaZYoESiVG3ENWMZ/Lh3BqgZif58zywhWmco3rtKtXqFbDTTMgUxe
5xhdYyAN2Jdi/epiOogH/Jn2085QY2wVr5HPZqPiN2GEurzgMHdUFmIAVhxv
3iKWjPEjRnMeY1kJQqaKPc0+4+22HeToFOFGiFgzE5hceziPo8XOzwcKxzGn
Xh6/Ooatz0BwLDm9hJJelCEhkSkyU71APTuBEkE9N76BNSXseSE7Fln51Ktj
uKl2s+qoV0WWEsq3QVGsy/vEmooWO5rCBihRh2R3pt22mwKZ6WiUvq8wKW3k
c477Nr2p8enrZL2t6Qb8vncUa7sSUpO5QINONoy+E+9UUMJHdqDTcRFlLq2F
e7DJxl4wl8RMeIiX7HsfCHdwnec90tsCugbFKg2/A7TAfnpIVEhe18Qi1pqV
0evFZ401nIYZsksHc30rST24smxQxhQ/hPoMTd2E8FzY8ZYSucFAl2hWFqul
9LriHQoHfE9VmFzEftuLtxHmJEUcj5EUADuY8c3a2vpRswWIqNA0QC9BTwRw
RWdwisUYqOdFMQJBG1A5hmsDX1dVFZ0VqyrDiJPTEoDwZFXOkDYdZ8k4epbk
wO2SrB89gXt0AsLRiFodPY+B+YIyek3lKZ8DD4ezuQSVppKmAVoOpFrNZtwe
qOpTYarktq+1p7inE+6G7u1JCOQPX+GvH7lfWtjh7kTLQdlYJjHjGoZEo7KC
VSYJEQhvY8QHuoatPP3o6LX68MHuY27+QZfoFRCgI778+tNT8q6SEf+oGWlg
RD54HI5nhqHTeV0WiOFH0fnp5XdbW5eBOv1U9nevun8U/QxLwF3/0l5A+pkr
0Ipe/7a14HXrXIppQ/inZ0Szm1o52VmDT/Mx3lMyfD86NZbjz8YWrmKRUDtx
QZTfN5fHINXByfvAPMKZWITqMHK5rYlJ0bpTGJRX5E0hkxwzpM/cEbcblU0F
C9sUPSRydPC8KZw3mXjZsfcZgOkxDcSEBxrMCZs4wcYIJlcPbeVy6kLMuFBT
ibhWBBxuxa4/t9SEwbqM4hMTJWtK7RBpTh9PBlQq7EKg3rp3ZHyVqoBYuVlS
GTxPb56kU0disi6Ni2y1yP0CpYog/rgbfRv18Pr0hDTij3v444WrHKg3oceO
HXM6Qi/liKTEH5ULQtVaRBtXjpVd8Dqqj63ygggczihLZ1JficxM6Jxw1Nv7
H0BjInWYTLT0jDYDUsulw0WpQTi569SlpxY7lIJ+QDbZAAVVOHFK70UmnMVL
24+ZaoqW3nYR6DZqV+dqBYJqLmKSD4YY0qV6ZlpMSf8iOa0aGYauRUltDCtg
Bbp3KCb2fWL13KURUH9al7NP+ZHixbCP0BbtQ6rukJrTB4V4XZH8IdUcRcvx
FoqOoLdmsJvLlonzRoybmEnDMVjzcbGJptSk+K2VlyIWsornhUWTbsVuEMQM
RdcwqE8bwYq7fIolCdZcsaMvMQckb0mj0qReLeVW+Z6Zgg6yMLG6LmzTTLMg
7/SSjh5ShmtTlOIZBweHwXTjOYbl48OSTSfFbiSDvqE/IFWRzLZm6pqGGZam
Q19nxpnESDSqSLhOr60+omrxa7RVbxuhuagzE1Kfe4JHAm8S0lF9gZQzEdgy
1Whla4+7BqH2NxbFZXC+pXTqOk8YtAdX9AJAHGfN66Yyv1K8vrNuSFnDKSj0
qSMJsbhKg27p6I1Ps4oAhxsAfL7BWM0yrVDRfAJaMXWVcYeFVCsvbLK16tJI
sagarEewvi4viNZkXKArR9gMJIbynKgzV8OLa4rl2mzty/M3/ajhqncpTqkN
zsXeqzAJqJpwlco4Jyv7gFKqvEcar9ecXfxYEQQDLcRFS0p7ArhXTeCyL5lE
yU3l/LDG7g0qaekr8iQE3V9BwLMr5QDtK+Ixyq04sgNx7jZHTwBnoHPJAayy
K80WgNxx7hhCGg+l1VpMblaaD9SnhKQxl6AasZ65crZIGhk4ndWEvN2TLXtU
NJJ9hxuzpBfxteieVWLXewOIhybWYVDqFq4r3VZzWdGd5iucbGjL6HxOHd0Y
g5bEpmVgM4ZXyydy/qGtcjJS77LL9Ol4z7zQQZtlv2xI0OT4ZJkV66Aqz/fn
Uu6rT0q569zsbiZV3+Cw2pVPnws66UjvHCkGY7LUkRY2Wmo34tZVhoeXbvAl
L02AzFNUrvFgAwJKfxtgqIzcyPEnDFvOo6S4P7IHELUy+HCZ5uNE2mM6+qUu
e7M5uAiuknEl9l2uLQ3Pt/v8UPqE8/4FmQGII6Ecp62M1N5LQR2hCz7tsS3R
RnEEINaGohwiCEg0nidjug1TNkL6HoOUkhPjidIB8/66K8gWZSgvikhS24Cx
Tb5ULf29yjnlnWvdUYo4Z8kwtTZlL0okklQyO2z3BCPVYxDPyUHtyCEyi6Bn
ZsPZLWSCjHC4WcAz2DW5Xsp1eCSc4ntTpBMpeiJ1DQRvYFZDB7WTE+XPzxoG
vb5Iy4S7by9euFrlVcMEF4jeE9TZS2zIIBJ27iJN5nG5QHuPnmAn8cMinsCs
0oVcvo6IsYjJ1P7jR7az7ENfK2VWFBPrnHImSiFplG9OUDF8kysrh6wk2DWr
3SHR7eww7/PSg0tN4XQca7PKTZEBtjdpjbxaBVcOGqAE9Wap5FZ9CJKDnuqs
J3ZWpug7hzvUPpZzcRbIzWNOosoLvboCENmJ9Wiys0TihLwlVAJGSk8WXdyO
TkUYG8zn4O8N7IqncNPzIh8Y0Kj06+66LkJKxbshmoENzuSMN12Dhajzc103
zc80k6grzNHV6Nt1jsMmBvjWp15MbhsFhacieVImofF1aiX3IJYhR+zOZYns
7q7tCBttcBrcJ0DawWAAQuL4euv/ABKLMmaTAQEA
</rfc> </rfc>
 End of changes. 52 change blocks. 
2074 lines changed or deleted 1173 lines changed or added

This html diff was produced by rfcdiff 1.48.