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="May"/>
<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.
<!--[rfced] For clarity, may the last phrase of this sentence be reworded
as follows or otherwise? It's not clear what is placing the constraint on
the RCD.
<section anchor="introduction"><name>Introduction</name> Original:
Finally, this document describes how to preserve the integrity of the
<t>PASSporT <xref target="RFC8225"/> is a token format based on JWT <xref target RCD in scenarios where there may be non-authoritative users
="RFC7519"/> for conveying cryptographically-signed information about the partie initiating and signing RCD and therefore a constraint on the RCD data
s involved in personal communications; it is used to convey a signed assertion o that a PASSporT can attest via certificate-level controls.
f the identity of the participants in real-time communications established via a
protocol like SIP <xref target="RFC8224"/>. The STIR problem statement <xref ta
rget="RFC7340"/> declared securing the display name of callers outside of STIR's
initial scope. This document extends the use of JWT and PASSporT in the overall
STIR framework by defining a PASSporT extension and the associated STIR procedu
res to protect additional caller and call related information. This is addition
al information beyond the calling party originating identity (e.g. telephone num
ber or SIP URI) that is intended to be rendered to assist a called party in dete
rmining whether to accept or trust incoming communications. This includes inform
ation such as the name of the person or entity on one side of a communications s
ession, for example, the traditional "Caller ID" of the telephone network along
with related display information that would be rendered to the called party duri
ng alerting or potentially used by an automaton to determine whether and how to
alert a called party to a call and whom is calling.</t>
<t>Traditional telephone network signaling protocols have long supported deliver
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> Option A:
<section anchor="rcdintegrity"><name>Overview of Rich Call Data Integrity</name> Finally, this document describes how to preserve the integrity of the RCD
in scenarios where there may be non-authoritative users initiating and
signing RCD, therefore limiting whether a PASSporT can attest the RCD via
certificate-level controls.
<t>When incorporating call data that represents a user, even in traditional call Option B:
ing name services today, often there are policy and restrictions around what dat Finally, this document describes how to preserve the integrity of the RCD
a elements are allowed to be used. Whether preventing offensive language or icon in scenarios where there may be non-authoritative users initiating and
s or enforcing uniqueness, potential trademark or copyright violations or other signing RCD by specifying the use of JWT claims constraints on the RCD data
policy enforcement, there might be the desire to pre-certify or "vet" the specif that a PASSporT can attest to via certificate-level controls.
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 Finally, this document describes how to preserve the integrity of the RCD in sce
ent, create a cryptographic digest that can be used to validate that data and ap narios where there may be non-authoritative users initiating and signing RCD and
plies a constraint in the certificate to allow the recipient and verifier to val therefore a constraint on the RCD that a PASSporT can attest via certificate-le
idate that the specific content of the RCD is as intended at its creation and ap vel controls.</t>
proval or certification.</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.
<!--[rfced] Please clarify the list in this sentence.
<t>There are two mechanisms that are defined to accomplish that for two distinct Original:
categories of purposes. The first of the mechanisms include the definition of a This document defines a
n integrity claim. The RCD integrity mechanism is a process of generating a cryp mechanism that allows for a direct or indirect party that enforces
tographic digest for each resource referenced by a URI within a claim value (e.g the policies to approve or certify the content, create a
., an image file referenced by "jcd" or a jCard referenced by "jcl"). This mecha cryptographic digest that can be used to validate that data and
nism is inspired by and based on the W3C Subresource Integrity specification <xr applies a constraint in the certificate to allow the recipient and
ef target="W3C-SubresourceIntegrity"/>. The second of the mechanisms uses the ca verifier to validate that the specific content of the RCD is as
pability called JWT Claim Constraints, defined in <xref target="RFC8226"/> and e intended at its creation and approval or certification.
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 Option A:
e used together or separately depending on the intended purpose. The first categ This document defines a mechanism that allows for a party that
ory of purpose is whether the rich call data conveyed in the PASSporT claims is (a) enforces X, (b) creates Y, and (c) applies Z.
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 Option B:
hould be used with RCD. ("Auth" represents "authoritative" in this table.)</t> This document defines a mechanism that
(a) allows for a party that enforces X, (b) creates Y, and (c) applies Z.
<figure><artwork><![CDATA[ Perhaps (if Option A is accurate):
+----------+---------------------+--------------------------------+ This document defines a mechanism that allows for a direct or
| Modes | No URI refs | Includes URI refs | indirect party that (a) enforces
+----------+---------------------+--------------------------------+ the policies to approve or certify the content, (b) creates a
| Auth | 1: No integrity req | 2: RCD Integrity | cryptographic digest that can be used to validate that data, and
+----------+---------------------+--------------------------------+ (c) applies a constraint in the certificate to allow the recipient and
| Non-Auth | 3: JWT Claim Const. | 4: RCD Integ./JWT Claim Const. | verifier to validate that the specific content of the RCD is as
+----------+---------------------+--------------------------------+ intended at its creation and its approval or certification.
]]></artwork></figure> -->
This document defines a mechanism that allows for a direct or indirect party tha
t enforces the policies to approve or certify the content, create a cryptographi
c digest that can be used to validate that data and applies a constraint in the
certificate to allow the recipient and verifier to validate that the specific co
ntent of the RCD is as intended at its creation and its approval or certificatio
n.</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>
<t>The first and simplest mode is exclusively for when all RCD content is direct <table>
ly included as part of the claims (i.e. no URIs referencing external content are <thead>
included in the content) and when the signer is authoritative over the content. <tr>
In this mode, integrity protection is not required and the set of claims is sim <th>Modes</th>
ply protected by the signature of the standard PASSporT <xref target="RFC8225"/> <th>No URI refs</th>
and SIP identity header <xref target="RFC8224"/> procedures. The second mode is <th>Includes URI refs</th>
an extension of the first where the signer is authoritative and an "rcd" claim </tr>
contents include a URI identifying external resources. In this mode, an RCD Inte </thead>
grity or "rcdi" claim MUST be included. This integrity claim is defined later in <tbody>
this document and provides a digest of the "rcd" claim content so that, particu <tr>
larly for the case where there are URI references in the RCD, the content of tha <th>Auth</th>
t RCD can be comprehensively validated that it was received as intended by the s <td>1: No integrity req</td>
igner of the PASSporT.</t> <td>2: RCD Integrity</td>
</tr>
<tr>
<th>Non-Auth</th>
<td>3: JWT Claim Const.</td>
<td>4: RCD Integ. / JWT Claim Const.</td>
</tr>
</tbody>
</table>
<t>The third and fourth modes cover cases where there is a different authoritati <t>The first and simplest mode is exclusively for when all RCD content is
ve entity responsible for the content of the RCD, separate from the signer of th directly included as part of the claims (i.e., no URIs referencing external cont
e PASSporT itself, allowing the ability, in particular when delegating signing a ent are included in the content) and when the signer is authoritative over the c
uthority for PASSporT, to enable a mechanism for allowing agreed or vetted conte ontent. In this mode, integrity protection is not required, and the set of claim
nt included in or referenced by the RCD claim contents. The primary framework fo s is simply protected by the signature of the standard PASSporT <xref target="RF
r allowing the separation of authority and the signing of PASSporTs by non-autho C8225"/> and SIP identity header <xref target="RFC8224"/> procedures. The second
rized entities is detailed in <xref target="RFC9060"/> although other cases may mode is an extension of the first where the signer is authoritative, and an "rc
apply. As with the first and second modes, the third and fourth modes differ wit d" claim contents include a URI identifying external resources. In this mode, an
h the absence or inclusion of referenced external content using URIs.</t> 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>
<!--[rfced] May this phrase be reworded for clarity?
Seems "allowing the ability to enable a mechanism for allowing"
could be simplified.
</section> Original:
<section anchor="rcd_define"><name>PASSporT Claim "rcd" Definition and Usage</na The third and fourth modes cover cases where there is a different
me> authoritative entity responsible for the content of the RCD, separate
from the signer of the PASSporT itself, allowing the ability, in
particular when delegating signing authority for PASSporT, to enable
a mechanism for allowing agreed or vetted content included in or
referenced by the RCD claim contents.
<section anchor="syntax"><name>PASSporT "rcd" Claim</name> Specifically, regarding the last part:
allowing the ability, in particular when [...],
to enable a mechanism for allowing agreed or vetted content included in or
referenced by the RCD claim contents.
<t>This document defines a new JSON Web Token claim for "rcd", Rich Call Data, t Option A:
he value of which is a JSON object that can contain one or more key value pairs. allowing the ability, in particular when [...],
This document defines a default set of key values.</t> to enable a mechanism for agreed or vetted content to be included
in or referenced by the RCD claim contents.
<section anchor="nam-key"><name>"nam" key</name> Option B:
allowing the ability, in particular when [...],
for agreed or vetted content to be included in or
referenced by the RCD claim contents.
-->
<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, to enable a mechanism for allowing agreed or vetted
content included in or referenced by the RCD claim contents. The primary framew
ork for allowing the separation of authority and the signing of PASSporTs by non
-authorized entities is detailed in <xref target="RFC9060"/>, although other cas
es may apply. As with the first and second modes, the third and fourth modes dif
fer with the absence or inclusion of referenced external content using URIs.</t>
</section>
<section anchor="rcd_define">
<name>PASSporT Claim "rcd" 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 "nam" key value is a display name, associated with the originator of pers <!-- [rfced] This sentence appeared to intend to cite 3GPP TS 24.229, but
onal communications, which may for example match the display-name component of t there was not a corresponding reference. We added an informative reference
he From header field value of a SIP request <xref target="RFC3261"/> or alternat as follows; please review and let us know if this is accurate.
ively from the P-Asserted-Identity header field value <xref target="RFC3325"/>, Would you like to update this to the most recent version? (We see
or a similar field in other PASSporT using protocols. This key MUST be included version 19.0.2 from March 2025.)
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> Original:
<section anchor="apn-key"><name>"apn" key</name> The "apn" key value is an optional alternate presentation number
associated 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 cases where a network number is carried in the
P-Asserted-Identity [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.
<t>The "apn" key value is an optional alternate presentation number associated w Current:
ith the originator of personal communications, which may for example match the u The "apn" key value is an optional alternate presentation number
ser component of the From header field value of a SIP request (in cases where a associated with the originator of personal communications, which may
network number is carried in the P-Asserted-Identity <xref target="RFC3325"/>), for example match the user component of the From header field value
or alternatively from the Additional-Identity header field value [3GPP TS 24.229 of a SIP request (in cases where a network number is carried in the
v16.7.0], or a similar field in other PASSporT using protocols. Its intended se P-Asserted-Identity [RFC3325]), or alternatively of the Additional-
mantics are to convey a number that the originating user is authorized to show t Identity header field value [TS.3GPP.24.229], or a similar
o called parties in lieu of their default number, such as cases where a remote c field in other PASSporT-using protocols.
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> Added in Section 18.2:
</section> [TS.3GPP.24.229]
<section anchor="icn-key"><name>"icn" key</name> 3GPP, "IP multimedia call control protocol based on
Session Initiation Protocol (SIP) and Session Description
Protocol (SDP); Stage 3", 16.7.0, 3GPP TS 24.229,
September 2020,
<https://www.3gpp.org/ftp/Specs/html-info/24229.htm>.
-->
<t>The "icn" key value is an optional HTTPS URL reference to an image resource t <t>The "apn" key value is an optional alternate presentation number as
hat can be used to pictorially represent the originator of personal communicatio sociated with the originator of personal communications, which may, for example,
ns. This icon key value should be used as a base or default method of associatin match the user component of the From header field value of a SIP request (in ca
g an image with a calling party.</t> 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.
<!--[rfced] What does "This usage" refer to? The preceding sentence
is included for context. Perhaps it refers to the use of the "apn"
key in general?
<t>When being used for SIP <xref target="RFC3261"/> this claim key value used to Original:
protect the Call-Info header field with a purpose parameter value of "icon" as How the signer determines
described in Section 20.9 <xref target="RFC3261"/>. Example as follows:</t> that a user is authorized to present the number in question is a
policy decision outside the scope of this document, 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 situations where no other rich
jCard data needs to be conveyed with the call.
<figure><artwork><![CDATA[ Perhaps:
How the signer determines [...]
The use of the "apn" key is intended as an alternative to conveying
the presentation number ...
-->
This usage is intended as an alternative to conveying the presentation
number in the "tel" key value of a jCard, in situations where no other rich jCar
d data needs to be conveyed with the call. Only one "apn" key may be present. "a
pn" <bcp14>MUST</bcp14> be used when it is the intent of the caller or signer to
display the alternate presentation number even if "jcd" or "jcl" keys are prese
nt 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 <!--[rfced] Please clarify "using Call-Info as protocol".
target="I-D.ietf-sipcore-callinfo-rcd"/> it constrains the security properties o
f RCD information and the integrity of the content referenced by URIs.</t>
<t>Note: even though we refer to <xref target="I-D.ietf-sipcore-callinfo-rcd"/>
as the definition of the jcard properties for usage in "rcd" claims, using Call-
Info as protocol with the addition of an identity header carrying the PASSPorT i
s not required. The identity header carrying a PASSporT with "rcd" claim includ
ing a "jcd" value can be used as the primary and only transport of the RCD infor
mation.</t>
</section>
<section anchor="jcl-key"><name>"jcl" key</name>
<t>The "jcl" key value is an HTTPS URL that refers to a jCard <xref target="RFC7
095"/> JSON object on a web server. The web server MUST use the MIME media type
for JSON text as application/json with a default encoding of UTF-8 <xref target=
"RFC8259"/>. This link may correspond to the Call-Info header field value define
d in <xref target="I-D.ietf-sipcore-callinfo-rcd"/> with a type of "jcard". As a
lso defined in <xref target="I-D.ietf-sipcore-callinfo-rcd"/>, format of the jCa
rd and properties used should follow the normative usage and formatting rules an
d procedures. The "jcl" key is optional. The "jcd" or "jcl" keys MAY only appear
once in the "rcd" claim but MUST be mutually exclusive.</t>
<t>The jCard object referenced by the URI value for "jcl" MUST be a jCard JSON o
bject that MAY have URI referenced content, but that URI referenced content MUST
NOT further reference URIs. Future specifications may extend this capability, b
ut as stated in <xref target="I-D.ietf-sipcore-callinfo-rcd"/> it constrains the
security properties of RCD information and the integrity of the content referen
ced by URIs.</t>
</section>
</section>
</section>
<section anchor="rcdi_define"><name>"rcdi" RCD Integrity Claim Definition and Us
age</name>
<t>The "rcdi" claim is included for the second and fourth modes described in the
integrity overview <xref target="rcdintegrity"/> of this document. "rcdi" and "
rcd" claims MAY each appear once in a PASSporT, but if "rcdi" is included the "r
cd" MUST correspondingly be present also. The value of the "rcdi" claim is a JSO
N object that is defined as follows.</t>
<t>The claim value of "rcdi" claim key is a JSON object with a set of JSON key/v
alue pairs. These objects correspond to each of the elements of the "rcd" claim
object that require integrity protection with an associated digest over the cont
ent referenced by the key string. The individual digest of different elements of
the "rcd" claim data and URI referenced external content is kept specifically s
eparate to allow the ability to verify the integrity of only the elements that a
re ultimately retrieved or downloaded or rendered to the end-user.</t>
<t>The key value references a specific object within the "rcd" claim value using Original:
a JSON pointer defined in <xref target="RFC6901"/> with a minor additional rule Note: even though we refer to [RFC9796] as the definition of the
to support URI references to external content that include JSON objects themsel jcard properties for usage in "rcd" claims, using Call-Info as
ves, for the specific case of the use of "jcl", defined in <xref target="jcl_ele protocol with the addition of an identity header carrying the
ment"/>. JSON pointer syntax is the key value that documents exactly the part of PASSPorT is not required.
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 <t>Note: Even though we refer to <xref target="RFC9796"/> as the defin
below, but an example "rcdi" is provided here:</t> ition of the jCard properties for usage in "rcd" claims, using Call-Info as prot
ocol with the addition of an identity header carrying the PASSporT is not requir
ed. The identity header carrying a PASSporT with an "rcd" claim including a "jc
d" value can be used as the primary and only transport of the RCD information.</
t>
</section>
<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>
use the media type for JSON text as application/json with a default encoding of
UTF-8 <xref target="RFC8259"/>. This link may correspond to the Call-Info heade
r field value defined in <xref target="RFC9796"/> with a type of "jcard". As als
o defined in <xref target="RFC9796"/>, the format of the jCard and properties us
ed should follow the normative usage and formatting rules and procedures. The "j
cl" key is optional. The "jcd" or "jcl" keys <bcp14>MAY</bcp14> only appear once
in the "rcd" claim but <bcp14>MUST</bcp14> be mutually exclusive.</t>
<t>The jCard object referenced by the URI value for "jcl" <bcp14>MUST<
/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
Is. Future specifications may extend this capability, but <xref target="RFC9796"
/> constrains the security properties of RCD information and the integrity of th
e content referenced by URIs.</t>
</section>
</section>
</section>
<section anchor="rcdi_define">
<name>"rcdi" RCD Integrity Claim Definition and Usage</name>
<t>The "rcdi" claim is included for the second and fourth modes described
in the integrity overview (<xref target="rcdintegrity"/>). "rcdi" and "rcd" clai
ms <bcp14>MAY</bcp14> each appear once in a PASSporT, but if "rcdi" is included,
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>
<!--[rfced] Is this a 1:1 relationship? In other words,
should this be "Each of these claims corresponds to each of the elements"?
<figure><artwork><![CDATA[ Original:
These objects correspond to each of the
elements of the "rcd" claim object that require integrity protection
with an associated digest over the content referenced by the key
string.
-->
<t>The claim value of the "rcdi" claim key is a JSON object with a set of
JSON key/value pairs. These objects correspond to each of the elements of the "r
cd" claim object that require integrity protection with an associated digest ove
r the content referenced by the key string. The individual digest of different e
lements of the "rcd" claim data and URI-referenced external content is kept spec
ifically separate to allow the ability to verify the integrity of only the eleme
nts that are ultimately retrieved, downloaded, or rendered to the end user.</t>
<t>The key value references a specific object within the "rcd" claim value
using a JSON pointer defined in <xref target="RFC6901"/> with a minor additiona
l rule to support URI references to external content that include JSON objects t
hemselves, for the specific case of the use of "jcl", defined in <xref target="j
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
ng that makes up the value for the corresponding key. Detailed procedures are pr
ovided below, but an example "rcdi" is provided here:</t>
<sourcecode type="json"><![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, "-", or ASCII 45. The subsequent characters
UST be a hyphen character, "-", or ASCII 45. The subsequent characters are the b are the base64 encoded <xref target="RFC4648"/> digest of a canonicalized and c
ase64 encoded <xref target="RFC4648"/> digest of a canonicalized and concatenate oncatenated string or binary data based on the JSON pointer referenced elements
d string or binary data based on the JSON pointer referenced elements of "rcd" c of the "rcd" claim or the URI-referenced content contained in the claim. The nex
laim or the URI referenced content contained in the claim. The details of the de t section covers the details of the determination of the input string used to de
termination of the input string used to determine the digest are defined in the termine the digest.</t>
next section.</t> <!--[rfced] Would you like to list the codepoint for this character
in a more typical manner? "ASCII 45" was last used in RFC 1849.
<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 Original:
of these key values an "rcdi" JSON pointer or integrity digest is optional becau MUST be a hyphen character, "-", or ASCII 45.
se the direct value is protected by the signature and can be constrained directl
y with JWTClaimConstraints.</t>
</section> Perhaps:
<section anchor="icn_element"><name>"icn" elements</name> MUST be a hyphen character ("-", %x2D).
<t>In the case of "icn", the only allowed value is a URI value that references a Or:
n image file. If the URI references externally linked content there MUST be a JS MUST be a hyphen character, "-" (HYPHEN-MINUS, U+002D).
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 <section anchor="creation-of-the-rcd-element-digests">
the digest value string would be created using the image file byte data referen <name>Creation of the "rcd" Element Digests</name>
ced in the URI.</t> <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>
</section> <!--[rfced] How should the first point be changed to a complete sentence? (The
<section anchor="jcd_element"><name>"jcd" elements</name> second and third points are complete sentences.)
Also, for subject/verb agreement, should "the JWT Claim Constraints is applied"
be "the JWT Claim Constraints certificate extension is applied"
or "the JWT Claim Constraints are applied" or otherwise?
<t>In the case of "jcd", the value associated is a jCard JSON object, which happ Preceding sentence for context:
ens to be a JSON array with sub-arrays. JSON pointer notation uses numeric indic In order to facilitate proper verification of the digests and to
es into elements of arrays, including when those elements are arrays themselves. determine whether the "rcd" elements or content referenced by URIs
</t> were modified, the input to the digest must be completely
deterministic at three points in the process:
<t>As example, for the following "rcd" claim:</t> Original:
First, at the certification point where the content
is evaluated to conform to the application policy and the JWT Claim
Constraints is applied to the certificate containing the digest.
<figure><artwork><![CDATA[ Perhaps:
First, it must be deterministic at the certification point when the content
is evaluated to conform to the application policy and when the JWT Claim
Constraints are applied to the certificate containing the digest.
-->
<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, at the certification point where the content is evaluated to confo
rm to the application policy and the JWT Claim Constraints is applied to the cer
tificate containing the digest. Second, when the call is signed at the Authentic
ation Service, there may be a local policy to verify that the provided "rcd" cla
im corresponds to each digest. Third, when the "rcd" data is verified at the ver
ification service, the verification is performed for each digest by constructing
the input digest string for the element being verified and referenced by the JS
ON 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 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 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 JWTCl
protected by the signature and can be constrained directly with JWTClaimConstra aimConstraints. However, for data length reasons (as with "icn" above) or more
ints. However, for data length reasons (as with "icn" above) or more importantl importantly for potential privacy and/or security considerations with a publicly
y for potential privacy and/or security considerations with a publically accessi accessible certificate, the use of the "rcdi" JSON pointer and integrity digest
ble certificate, the use of the "rcdi" JSON pointer and integrity digest as the as the constraint value in JWTClaimConstraints over the jCard data is <bcp14>RE
constraint value in JWTClaimConstraints over the jCard data is RECOMMENDED.</t> COMMENDED</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> <!--[rfced] Please clarify this sentence. In particular, what does
<section anchor="jcl_element"><name>"jcl" elements</name> "with the exception and the minor modification" mean?
We suggest making this into two sentences.
<t>In the case of the use of a "jcl" URI reference to an external jCard, the pro Original:
cedures are similar to "jcd" with the exception and the minor modification to JS In the case of the use of a "jcl" URI reference to an external jCard,
ON pointer, where "/jcl" is used to refer to the external jCard array string and the procedures are similar to "jcd" with the exception and the minor
any following numeric array indices added to the "jcl" (e.g., "/jcl/1/2/3") are modification to JSON pointer, where "/jcl" is used to refer to the
treated as if the external content referenced by the jCard was directly part of external jCard array string and any following numeric array indices
the overall "rcd" claim JSON object. The following example illustrates a "jcl" added to the "jcl" (e.g., "/jcl/1/2/3") are treated as if the
version of the above "jcd" example.</t> external content referenced by the jCard was directly part of the
overall "rcd" claim JSON object.
<figure><artwork><![CDATA[ Perhaps:
In the case of the use of a "jcl" URI reference to an external jCard,
the procedures are similar to "jcd" with the minor
modification to the JSON pointer, where "/jcl" is used to refer to the
external jCard array string. Also, any following numeric array indices
added to the "jcl" (e.g., "/jcl/1/2/3") are treated as if the
external content referenced by the jCard were directly part of the
overall "rcd" claim JSON object.
-->
<t>In the case of the use of a "jcl" URI reference to an external jCar
d, the procedures are similar to "jcd" with the exception and the minor modifica
tion to JSON pointer, where "/jcl" is used to refer to the external jCard array
string and any following numeric array indices added to the "jcl" (e.g., "/jcl/1
/2/3") are treated as if the external content referenced by the jCard was direct
ly part of the overall "rcd" claim JSON object. The following example illustrate
s a "jcl" version of the above "jcd" example.</t>
<sourcecode type="json"><![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 Usage for "rcd" and "rcdi" Claims</name>
ded "rcd" claim.</t> <!--[rfced] May 'usage' be cut from the title of Section 6.3 for
consistency with the title of Section 6.2?
</section>
<section anchor="jwt-claim-constraints-usage-for-rcd-and-rcdi-claims"><name>JWT
Claim Constraints usage for "rcd" and "rcdi" claims</name>
<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
he objective for the use of JWT Claim Constraints for the combination of both "r
cd" and "rcdi" claims is to constrain the signer to only construct the "rcd" and
"rcdi" claims inside a PASSporT to contain and reference only a pre-determined
set of content. Once both the contents of the "rcd" claim and any referenced con
tent is certified by the party that is authoritative for the certificate being i
ssued to the signer, the "rcdi" claim is constructed and linked to the STIR cert
ificate associated with the signature in the PASSporT via JWT Claim Constraints
extension as defined in <xref target="RFC8226"/> Section 8 and extended in <xref
target="RFC9118"/>. It should be recognized that the "rcdi" set of digests is i
ntended to be unique for only a specific combination of "rcd" content and URI re
ferenced external content, and therefore provides a robust integrity mechanism f
or an authentication service being performed by a non-authoritative party. This
would often be associated with the use of delegate certificates <xref target="RF
C9060"/> for the signing of calls by the calling party directly as an example, e
ven though the "authorized party" is not necessarily the subject of a STIR certi
ficate.</t>
<t>For the cases that there should always be both "rcd" and "rcdi" claims includ Original:
ed in the PASSporT, the certificate JWT Claims Constraint extension MUST include 6.2. JWT Claim Constraints for "rcd" claims
both of the following:</t> 6.3. JWT Claim Constraints usage for "rcd" and "rcdi" claims
<t><list style="symbols"> Perhaps:
<t>a "mustInclude" for the "rcd" claim, which simply constrains the fact that 6.2. JWT Claim Constraints for "rcd" Claims
an "rcd" must be included</t> 6.3. JWT Claim Constraints for "rcd" and "rcdi" Claims
<t>a "mustInclude" for the "rcdi" claim and a "permittedValues" equal to the c -->
reated "rcdi" claim value string.</t> <t>The use of JWT Claim Constraints with an "rcdi" claim is for cases where URI-
</list></t> referenced content is to be protected by the authoritative certificate issuer. T
he objective for the use of JWT Claim Constraints for the combination of both "r
cd" and "rcdi" claims is to constrain the signer to only construct the "rcd" and
"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
ent are certified by the party that is authoritative for the certificate being i
ssued to the signer, the "rcdi" claim is constructed and linked to the STIR cert
ificate associated with the signature in the PASSporT via the JWT Claim Constrai
nts extension as defined in <xref section="8" target="RFC8226" sectionFormat="co
mma"/> and extended in <xref target="RFC9118"/>. It should be recognized that th
e "rcdi" set of digests is intended to be unique for only a specific combination
of "rcd" content and URI-referenced external content, and therefore the set pro
vides a robust integrity mechanism for an authentication service being performed
by a non-authoritative party. This would often be associated with the use of de
legate certificates <xref target="RFC9060"/> for the signing of calls by the cal
ling party directly, as an example, even though the "authorized party" is not ne
cessarily the subject of a STIR certificate.</t>
<!--[rfced] Is this whole sentence describing an example? If so, we
suggest moving "as an example" to the start.
<t>Note that optionally the "rcd" claims may be included in the "permittedValues Original:
" however it is recognized that this may be redundant with the "rcdi" permittedV This would often be associated with the use of delegate
alues because the "rcdi" digest will imply the content of the "rcd" claims thems certificates [RFC9060] for the signing of calls by the calling party
elves.</t> directly as an example, even though the "authorized party" is not
necessarily the subject of a STIR certificate.
<t>The "permittedValues" for the "rcdi" claims (or "rcd" claims more generally) Perhaps:
may contain multiple entries, to support the case where the certificate holder i For example, this may be used with delegate certificates [RFC9060]
s authorized to use different sets of rich call data.</t> for the signing of calls by the calling party directly, even though
the "authorized party" is not necessarily the subject of a STIR
certificate.
-->
<t>For the cases where both "rcd" and "rcdi" claims should always be inc
luded in the PASSporT, the certificate JWT Claims Constraint extension <bcp14>MU
ST</bcp14> include both of the following:</t>
<ul spacing="normal">
<li>a "mustInclude" for the "rcd" claim, which simply constrains the f
act that an "rcd" must be included</li>
<li>a "mustInclude" for the "rcdi" claim and a "permittedValues" equal
to the created "rcdi" claim value string.</li>
</ul>
<t>Note that optionally the "rcd" claims may be included in the "permitt
edValues"; however, it is recognized that this may be redundant with the "rcdi"
permittedValues because the "rcdi" digest will imply the content of the "rcd" cl
aims themselves.</t>
<t>The "permittedValues" for the "rcdi" claims (or "rcd" claims more gen
erally) may contain multiple entries to support the case where the certificate h
older is authorized to use different sets of RCD.</t>
</section>
</section>
<section anchor="crn_define">
<name>PASSporT "crn" Claim - Call Reason Definition and Usage</name>
<!--[rfced] May we update these section titles to make them parallel
and simplified?
</section> Original:
</section> 5. PASSporT Claim "rcd" Definition and Usage
<section anchor="crn_define"><name>PASSporT "crn" claim - Call Reason Definition 6. "rcdi" RCD Integrity Claim Definition and Usage
and Usage</name> 7. PASSporT "crn" claim - Call Reason Definition and Usage
<t>This document defines a new JSON Web Token claim for "crn", Call Reason, the Option A:
value of which is a single string that can contain information as defined in <xr 5. PASSporT Claim "rcd" Definition and Usage
ef target="I-D.ietf-sipcore-callinfo-rcd"/> corresponding to the "call-reason" p 6. PASSporT Claim "rcdi" Definition and Usage
arameter for the Call-Info header. This claim is optional.</t> 7. PASSporT Claim "crn" Definition and Usage
<figure><artwork><![CDATA[ Option B (as this word order is also used within this document):
5. "rcd" PASSporT Claim: Definition and Usage
6. "rcdi" PASSporT Claim: Definition and Usage
7. "crn" PASSporT Claim: Definition and Usage
-->
<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 <xref target="RFC9796"/> and corresponding to the "call-reason" parameter for
the Call-Info header. This claim is optional.</t>
<sourcecode type="json"><![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> <!--[rfced] There is one instance of "JWT Constraints" (plural) in this
document; should it be "JWT Claim Constraints" to match usage elsewhere
<t>The integrity of the "crn" claim contents can optionally be protected by the within this document?
authoritative certificate issuer using JWT Constraints in the certificate. When
the signer of the PASSporT intends to always include a call reason string of any
value, a "mustInclude" for the "crn" claim in the JWT Claim Constraints indicat
es that a "crn" claim must always be present and is RECOMMENDED to be included b
y the certificate issuer. If the signer of the "crn" claim wants to constrain th
e contents of "crn", then "permittedValues" for "crn" in JWT Claim Constraints s
hould match the contents of the allowed strings and is RECOMMENDED to be include
d by the certificate issuer.</t>
</section> Original:
</section> The integrity of the "crn" claim contents can optionally be protected
<section anchor="rich-call-data-claims-usage-rules"><name>Rich Call Data Claims by the authoritative certificate issuer using JWT Constraints in the
Usage Rules</name> certificate.
-->
<t>The integrity of the "crn" claim contents can optionally be protected
by the authoritative certificate issuer using JWT Constraints in the certificat
e. When the signer of the PASSporT intends to always include a call reason strin
g of any value, a "mustInclude" for the "crn" claim in the JWT Claim Constraints
indicates that a "crn" claim must always be present and is <bcp14>RECOMMENDED</
bcp14> to be included by the certificate issuer. If the signer of the "crn" clai
m wants to constrain the contents of "crn", then "permittedValues" for "crn" in
JWT Claim Constraints should match the contents of the allowed strings and is <b
cp14>RECOMMENDED</bcp14> to be included by the certificate issuer.</t>
</section>
</section>
<section anchor="rich-call-data-claims-usage-rules">
<name>Rich Call Data Claims Usage Rules</name>
<!--[rfced] May this be rephrased to clarify "at least one or both an"?
<t>The "rcd" or "crn" claims MAY appear in any PASSporT claims object as optiona Original:
l elements. The creator of a PASSporT MAY also add a PASSporT extension ("ppt") ... in which case the PASSporT
value, defined in <xref target="RFC8225"/> Section 8.1, of "rcd" to the header o claims MUST contain at least one or both an "rcd" or "crn" claim.
f a PASSporT as well, in which case the PASSporT claims MUST contain at least on
e or both an "rcd" or "crn" claim. Any entities verifying the PASSporT claims de
fined in this document are required to understand the PASSporT extension in orde
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[ Perhaps:
In that case,
the PASSporT MUST contain at least one "rcd" or "crn" claim (or both).
-->
<t>The "rcd" or "crn" claims <bcp14>MAY</bcp14> appear in any PASSporT cla
ims object as optional elements. The creator of a PASSporT <bcp14>MAY</bcp14> al
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 case, the PASSporT claims <bcp14>MUST</bcp14> contain at least one or both an
"rcd" or "crn" claim. Any entities verifying the PASSporT claims defined in this
document are required to understand the PASSporT extension in order to process
the PASSporT in question. An example PASSporT header with the PASSporT extension
("ppt") value of "rcd" included is shown as follows:</t>
<sourcecode type=""><![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 621
["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>
<!--[rfced] Do both of these sentences refer to the example that follows? Perah
ps the text can be clarified?
<t>In an example PASSporT, where a jCard is linked via HTTPS URL using "jcl", a Original:
jCard file served at a particular URL.</t> In an example PASSporT, where a jCard is linked via HTTPS URL using
"jcl", a jCard file served at a particular URL.
<t>An example jCard JSON file hosted at the example web address of https://examp An example jCard JSON file hosted at the example web address of
le.com/qbranch.json is shown as follows:</t> https://example.com/qbranch.json is shown as follows:
<figure><artwork><![CDATA[ Perhaps:
In the following PASSporT example, a jCard is linked via HTTPS URL using
"jcl", and a jCard file is served at a particular URL.
Example jCard JSON file hosted at https://example.com/qbranch.json:
-->
<t>In an example PASSporT, where a jCard is linked via HTTPS URL using "
jcl", a jCard file is served at a particular URL.</t>
<t>An example jCard JSON file hosted at the example web address of https
://example.com/qbranch.json is shown as follows:</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 <!--[rfced] Please clarify this sentence. Specifically,
the other PASSporT claims from the SIP header fields as discussed in <xref targ what is "leading to too restrictive a set of constraints"?
et="RFC8224"/> Section 4.1.</t> Also, please consider starting with "The claims" or similar
to make a clearer break with the preceding sentence (which ends
<t>The re-construction of the "nam" claim, if using SIP protocol, should use the with the example of the empty string "".).
display-name string in the From header field. For other protocols, if there is
a display name field that exists, the string should be used, otherwise the strin
g should be an empty string, e.g., "". "jcl" and "jcd" MUST NOT be used with com
pact form due to integrity rules and URI reference rules in this document leadin
g to too restrictive of a set of constraints. Future specifications may revisit
this to propose a consistent and comprehensive way of addressing integrity and s
ecurity of information and to provide specific guidance for other protocol usage
.</t>
</section>
<section anchor="compact-form-of-the-rcdi-passport-claim"><name>Compact form of
the "rcdi" PASSporT claim</name>
<t>The use of compact form of a PASSporT using an "rcdi" claim is not supported,
so if "rcdi" is required compact form MUST NOT be used.</t>
</section>
<section anchor="compact-form-of-the-crn-passport-claim"><name>Compact form of t
he "crn" PASSporT claim</name>
<t>Compact form of a "crn" PASSporT claim shall be re-constructed using the "cal
l-reason" parameter of a Call-Info header as defined by <xref target="I-D.ietf-s
ipcore-callinfo-rcd"/>.</t>
</section>
</section>
<section anchor="parties"><name>Third-Party Uses</name>
<t>While rich data about the call can be provided by an originating authenticati
on service, an intermediary in the call path could also acquire rich call data b
y querying a third-party service. Such a service effectively acts as a STIR Auth
entication Service, generating its own PASSporT, and that PASSporT could be atta
ched to a call by either the originating or terminating side. This third-party P
ASSporT attests information about the calling number, rather than the call or ca
ller itself, and as such its RCD MUST NOT be used when a call lacks a first-part
y PASSporT that assures verification services that the calling party number is n
ot spoofed. It is intended to be used in cases when the originating side does no
t supply a display-name for the caller, so instead some entity in the call path
invokes a third-party service to provide rich caller data for a call.</t>
<t>In telephone operations today, a third-party information service is commonly
queried with the calling party's number in order to learn the name of the callin
g party, and potentially other helpful information could also be passed over tha
t interface. The value of using a PASSporT to convey this information from third
parties lies largely in the preservation of the third party's signature over th
e data, and the potential for the PASSporT to be conveyed from intermediaries to
endpoint devices. Effectively, these use cases form a sub-case of out-of-band <
xref target="RFC8816"/> use cases. The manner in which third-party services are
discovered is outside the scope of this document.</t>
<t>An intermediary use case might look as follows using SIP protocol for this ex
ample: a SIP INVITE carries a display name in its From header field value and an
initial PASSporT object without the "rcd" claim. When a terminating verificatio
n service implemented at a SIP proxy server receives this request, and determine
s that the signature is valid, it might query a third-party service that maps te
lephone numbers to calling party names. Upon receiving the PASSporT in a respons
e from that third-party service, the terminating side could add a new Identity h
eader field to the request for the PASSporT object provided by the third-party s
ervice. It would then forward the INVITE to the terminating user agent. If the d
isplay name in the PASSporT object matches, or is string equivelent to, the disp
lay name in the INVITE, then the name would presumably be rendered to the end us
er by the terminating user agent.</t>
<t>A very similar flow could be followed by an intermediary closer to the origin
ation of the call. Presumably such a service could be implemented at an originat
ing network in order to decouple the systems that sign for calling party numbers
from the systems that provide rich data about calls.</t>
<t>In an alternative use case, the terminating user agent might query a third-pa
rty service. In this case, no new Identity header field would be generated, thou
gh the terminating user agent might receive a PASSporT object in return from the
third-party service, and use the "rcd" field in the object as a calling name to
render to users while alerting.</t>
<t>While in the traditional telephone network, the business relationship between
calling customers and their telephone service providers is the ultimate root of
information about a calling party's name, some other forms of data like crowdso
urced reputation scores might derive from third parties. When those elements are
present, they MUST be in a third-party "rcd" PASSporT using "iss" claim describ
ed in the next section.</t>
<section anchor="thirdsign"><name>Signing as a Third Party</name>
<t>A third-party PASSporT contains an "iss" element to distinguish its PASSporTs Original:
from first-party PASSporTs. Third-party "rcd" PASSporTs are signed with credent "jcl" and "jcd" MUST NOT be used with compact form due to
ials that do not have authority over the identity that appears in the "orig" ele integrity rules and URI reference rules in this document leading to
ment of the PASSporT claims. The presence of "iss" signifies that a different ca too restrictive of a set of constraints.
tegory of credential is being used to sign a PASSporT than the <xref target="RFC
8226"/> certificates used to sign STIR calls; it is instead a certificate that i
dentifies the source of the "rcd" data. How those credentials are issued and man
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> Perhaps:
The claims
"jcl" and "jcd" MUST NOT be used with compact form because
the integrity rules and URI reference rules defined in this document
would lead to a set of constraints that is too restrictive.
-->
<t>The reconstruction of the "nam" claim, if using the SIP protocol, sho
uld use the display-name string in the From header field. For other protocols, i
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., "". "jcl" and "jcd" <bcp14>MUST N
OT</bcp14> be used with compact form due to integrity rules and URI reference ru
les in this document leading to too restrictive of a set of constraints. Future
specifications may revisit this to propose a consistent and comprehensive way of
addressing integrity and security of information and to provide specific guidan
ce for other protocol usage.</t>
</section>
<section anchor="compact-form-of-the-rcdi-passport-claim">
<name>Compact Form of the "rcdi" PASSporT Claim</name>
<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
sed.</t>
</section>
<section anchor="compact-form-of-the-crn-passport-claim">
<name>Compact Form of the "crn" PASSporT Claim</name>
<t>Compact form of a "crn" PASSporT claim shall be reconstructed using t
he "call-reason" parameter of a Call-Info header as defined by <xref target="RFC
9796"/>.</t>
</section>
</section>
<section anchor="parties">
<name>Third-Party Uses</name>
<t>While rich data about the call can be provided by an originating authen
tication service, an intermediary in the call path could also acquire rich call
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
e attached to a call by either the originating or terminating side. This third-p
arty PASSporT attests information about the calling number, rather than the call
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
ing party number is not spoofed.
<!--[rfced] What is "It" in "It is intended"? The third-party PASSporT?
(The preceding sentence is included for context.)
<figure><artwork><![CDATA[ Original:
This third-party
PASSporT attests information about the calling number, rather than
the call or caller itself, and as such its RCD MUST NOT be used when
a call lacks a first-party PASSporT that assures verification
services that the calling party number is not spoofed. It is
intended to be used in cases when the originating side does not
supply a display-name for the caller, so instead some entity in the
call path invokes a third-party service to provide rich caller data
for a call.
-->
It is intended to be used in cases when the originating side does not supp
ly a display-name for the caller, so instead some entity in the call path invoke
s a third-party service to provide rich caller data for a call.</t>
<t>In telephone operations today, a third-party information service is com
monly queried with the calling party's number in order to learn the name of the
calling party, and potentially other helpful information could also be passed ov
er that interface. The value of using a PASSporT to convey this information from
third parties lies largely in the preservation of the third party's signature o
ver the data, and the potential for the PASSporT to be conveyed from intermediar
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
s are discovered is outside the scope of this document.</t>
<t>An intermediary use case might look as follows using the SIP protocol f
or this example: a SIP INVITE carries a display name in its From header field va
lue and an initial PASSporT object without the "rcd" claim. When a terminating v
erification service implemented at a SIP proxy server receives this request and
determines that the signature is valid, it might query a third-party service tha
t maps telephone numbers to calling party names. Upon receiving the PASSporT in
a response from that third-party service, the terminating side could add a new I
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.
If the display name in the PASSporT object matches, or is string-equivalent to,
the display name in the INVITE, then the name would presumably be rendered to t
he end user by the terminating user agent.</t>
<t>A very similar flow could be followed by an intermediary closer to the
origination of the call. Presumably such a service could be implemented at an or
iginating network in order to decouple the systems that sign for calling party n
umbers from the systems that provide rich data about calls.</t>
<t>In an alternative use case, the terminating user agent might query a th
ird-party service. In this case, no new Identity header field would be generated
, though the terminating user agent might receive a PASSporT object in return fr
om the third-party service, and use the "rcd" field in the object as a calling n
ame to render to users while alerting.</t>
<t>While in the traditional telephone network, the business relationship b
etween calling customers and their telephone service providers is the ultimate r
oot of information about a calling party's name, some other forms of data like c
rowdsourced reputation scores might derive from third parties. When those elemen
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>
<section anchor="thirdsign">
<name>Signing as a Third Party</name>
<t>A third-party PASSporT contains an "iss" element to distinguish its P
ASSporTs from first-party PASSporTs. Third-party "rcd" PASSporTs are signed with
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
erent category of credential is being used to sign a PASSporT than the certifica
tes (as defined in <xref target="RFC8226"/>) used to sign STIR calls; it is inst
ead a certificate that identifies the source of the "rcd" data. How those creden
tials are issued and managed is outside the scope of this document; however, the
value of "iss" <bcp14>MUST</bcp14> reflect the Subject of the certificate used
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
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
been left to make their own authorization decisions about whether to trust the s
igners of PASSporTs; in the third-party case, where an entity has explicitly que
ried a service to acquire the PASSporT object, it may be some external trust or
business relationship that induces the relying party to trust a PASSporT.</t>
<t>An example of a PASSporT claims object issued by a third party is as
follows.</t>
<sourcecode type=""><![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>
</section>
<section anchor="loa"><name>Levels of Assurance</name>
<t>As "rcd" can be provided by either first party providers that are directly au
thorized to sign PASSporTs in the STIR eco-system or third party providers that
are indirectly or delegated authority to sign PASSporTs. Relying parties could b
enefit from an additional claim that indicates the identification, in the form o
f a uniquely identifiable name, of the attesting party to the caller. Even in fi
rst party cases, the Communications Service Provider (CSP) to which a number was
assigned might in turn delegate the number to a reseller, who would then sell t
he number to an enterprise, in which case the CSP might have little insight into
the caller's name. In third party cases, a caller's name could be determined fr
om any number of data sources, on a spectrum between public data scraped from we
b searches to a direct business relationship to the caller. As multiple PASSporT
s can be associated with the same call, potentially a verification service could
receive attestations of the caller name from multiple sources, which have diffe
rent levels of granularity or accuracy. Therefore, third-party PASSporTs that ca
rry "rcd" data are RECOMMENDED to also carry an indication of the identity of th
e generator of the PASSporT in the form of the 'iss' claim.</t>
</section>
<section anchor="use"><name>Use of "rcd" PASSporTs in SIP</name>
<t>This section documents SIP-specific usage for "rcd" PASSporTs and in the SIP <!--[rfced] Please clarify "providers that are indirectly or delegated
Identity header field value. Other using protocols of PASSporT may define their authority to sign PASSporTs". What is the intended meaning? Is a word missing?
own usages for the "rcd" PASSporTs.</t>
<section anchor="authentication-service-behavior-for-sip-protocol"><name>Authent Original:
ication Service Behavior for SIP protocol</name> As "rcd" can be provided by either first party providers that are
directly authorized to sign PASSporTs in the STIR eco-system or third
party providers that are indirectly or delegated authority to sign
PASSporTs.
-->
<t>As "rcd" can be provided by either first-party providers that are direc
tly authorized to sign PASSporTs in the STIR ecosystem or third-party providers
that are indirectly or delegated authority to sign PASSporTs. Relying parties co
uld benefit from an additional claim that indicates the identification, in the f
orm of a uniquely identifiable name, of the attesting party to the caller. Even
in first-party cases, the Communications Service Provider (CSP) to which a numbe
r was assigned might in turn delegate the number to a reseller, who would then s
ell the number to an enterprise, in which case the CSP might have little insight
into the caller's name. In third-party cases, a caller's name could be determin
ed from any number of data sources, on a spectrum between public data scraped fr
om web searches to a direct business relationship to the caller. As multiple PAS
SporTs can be associated with the same call, potentially a verification service
could receive attestations of the caller name from multiple sources, which have
different levels of granularity or accuracy. Therefore, third-party PASSporTs th
at carry "rcd" data are <bcp14>RECOMMENDED</bcp14> to also carry an indication o
f the identity of the generator of the PASSporT in the form of the 'iss' claim.<
/t>
</section>
<section anchor="use">
<name>Use of "rcd" PASSporTs in SIP</name>
<!--[rfced] Please note that we have removed "and" from the sentence below. Ple
ase let us know if this incorrect.
<t>An authentication service creating a PASSporT containing an "rcd" claim MAY i Original:
nclude a PASSporT extension ("ppt" value) of "rcd" or not. Third-party authentic This section documents SIP-specific usage for "rcd" PASSporTs and in
ation services following the behavior in <xref target="thirdsign"/> MUST include the SIP Identity header field value.
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[ Current:
This section documents SIP-specific usage for "rcd" PASSporTs in
the SIP Identity header field value.
-->
<t>This section documents SIP-specific usage for "rcd" PASSporTs and in th
e SIP Identity header field value. Other protocols using PASSporT may define the
ir own guidance for "rcd" PASSporTs.</t>
<section anchor="authentication-service-behavior-for-sip-protocol">
<name>Authentication Service Behavior for SIP Protocol</name>
<t>An authentication service creating a PASSporT containing an "rcd" cla
im <bcp14>MAY</bcp14> include a PASSporT extension ("ppt" value) of "rcd". Third
-party authentication services following the behavior in <xref target="thirdsign
"/> <bcp14>MUST</bcp14> include a PASSporT extension value of "rcd". If the PASS
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
ield containing that PASSporT with a value of "rcd". The resulting Identity head
er field might look as follows:</t>
<sourcecode type=""><![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
p14>MUST</bcp14> extract the display-name from the From header field value, if a
ny, and <bcp14>MUST</bcp14> use that as the string value for the "nam" key when
it recomputes the header and claims of the PASSporT object. Additionally, if the
re exists a Call-Info header field as defined in <xref target="RFC9796"/>, the "
jcard" JSON object value <bcp14>MUST</bcp14> be used to construct the "jcd" key
value when it recomputes the header and claims of the PASSporT object. If the si
gnature validates over the recomputed object, then the verification is considere
d successful.</t>
<!--[rfced] Is this a list of five elements? If so, may it be rephrased
as follows or otherwise?
<t>If the PASSporT is in compact form, then the verification service MUST extrac Original:
t the display-name from the From header field value, if any, and MUST use that a Similarly, "jcd" or "jcl" jcard information, "icn", "apn", or "crn"
s the string value for the "nam" key when it recomputes the header and claims of can be optionally, based on local policy for devices that support it,
the PASSporT object. Additionally, if there exists a Call-Info header field as used to populate a Call-Info header field following the format of
defined in <xref target="I-D.ietf-sipcore-callinfo-rcd"/>, the "jcard" JSON obje [I-D.ietf-sipcore-callinfo-rcd].
ct value MUST be used to construct the "jcd" key value when it recomputes the he
ader and claims of the PASSporT object. If the signature validates over the reco
mputed object, then the verification is considered successful.</t>
<t>If the PASSporT is in full form with a PASSporT extension value of "rcd", the
n the verification service MUST extract the value associated with the "rcd" clai
m "nam" key in the object. If the PASSporT signature is verified successfully th
en the verification service MUST additionally compare the string value of the "r
cd" claim "nam" key value with the From header field value or the preferred valu
e. The preferred value depends on local policy of the SIP network technique tha
t conveys the display name string through a field other than the From header fie
ld to interoperate with this specification (e.g. P-Asserted-Identity) as discuss
ed in <xref target="RFC8224"/>. Similarly, "jcd" or "jcl" jcard information, "ic
n", "apn", or "crn" can be optionally, based on local policy for devices that su
pport it, used to populate a Call-Info header field following the format of <xre
f target="I-D.ietf-sipcore-callinfo-rcd"/>. If future defined PASSporT RCD claim
s types are present, they should follow similar defined proceedures and policies
.</t>
<t>The behavior of a SIP UAS upon receiving an INVITE or other type of session i
nitiation request containing a PASSporT object with an "rcd" claim largely remai
ns a matter of implementation policy. In most cases, implementations would rende
r this calling party name information to the user while alerting. Any user inter
face additions to express confidence in the veracity of this information are out
side the scope of this specification.</t>
</section>
</section>
<section anchor="using-rcd-rcdi-crn-as-additional-claims-to-other-passport-exten
sions"><name>Using "rcd", "rcdi", "crn" as additional claims to other PASSporT e
xtensions</name>
<t>Rich Call Data, including calling name information, as a common example, is o
ften data that is additive to the personal communications information defined in
the core PASSporT data required to support the security properties defined in <
xref target="RFC8225"/>. For cases where the entity originating the personal com
munications is supporting the authentication service for the calling identity an
d is the authority of the Rich Call Data, rather than creating multiple Identity
header fields corresponding to multiple PASSporT extensions, the authentication
service can alternatively directly add the "rcd" claim to a PASSporT that authe
nticates the calling identity.</t>
<section anchor="procedures-for-applying-rcd-claims-as-claims-only"><name>Proced
ures for applying RCD claims as claims only</name>
<t>For a given PASSporT using some other extension than "rcd", the Authenticatio
n Service MAY additionally include the "rcd" defined in {#rcd_define}, "rcdi" de
fined in {#rcdi_define}, and "crn" defined in {#crn_define} claims. This would r
esult in a set of claims that correspond to the original intended extension with
the addition of the "rcd" claim.</t>
<t>The Verification service that receives the PASSporT, if it supports this spec
ification and chooses to, should interpret the "rcd" claim as simply just an add
itional claim intended to deliver and/or validate delivered Rich Call Data.</t>
</section>
<section anchor="example-for-applying-rcd-claims-as-claims-only"><name>Example f
or applying RCD claims as claims only</name>
<t>In the case of <xref target="RFC8588"/> which is the PASSporT extension suppo
rting the SHAKEN specification <xref target="ATIS-1000074.v002"/>, a common case
for an Authentication service to co-exist in a CSP network along with the autho
rity over the calling name used for the call. Rather than require two identity h
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[ Perhaps:
Similarly, "jcd", "jcl", "icn", "apn", or "crn" elements
can be used optionally (based on local policy for devices that support it)
to populate a Call-Info header field following the format of
[RFC9796].
-->
<t>If the PASSporT is in full form with a PASSporT extension value of "r
cd", then the verification service <bcp14>MUST</bcp14> extract the value associa
ted with the "rcd" claim "nam" key in the object. If the PASSporT signature is v
erified successfully, then the verification service <bcp14>MUST</bcp14> addition
ally compare the string value of the "rcd" claim "nam" key value with the From h
eader field value or the preferred value. The preferred value depends on local
policy of the SIP network technique that conveys the display name string through
a field other than the From header field to interoperate with this specificatio
n (e.g., P-Asserted-Identity) as discussed in <xref target="RFC8224"/>. Similarl
y, "jcd" or "jcl" jCard information, "icn", "apn", or "crn" can be optionally, b
ased on local policy for devices that support it, used to populate a Call-Info h
eader field following the format of <xref target="RFC9796"/>. If PASSporT RCD cl
aims types defined in the future are present, they should follow similar defined
proceedures and policies.</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
an "rcd" claim largely remains a matter of implementation policy. In most cases,
implementations would render this calling party name information to the user wh
ile alerting. Any user interface additions to express confidence in the veracity
of this information are outside the scope of this specification.</t>
</section>
</section>
<section anchor="using-rcd-rcdi-crn-as-additional-claims-to-other-passport-e
xtensions">
<name>Using "rcd", "rcdi", and "crn" as Additional Claims to Other PASSpor
T Extensions</name>
<t>Rich Call Data, including calling name information, as a common example
, 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
d in <xref target="RFC8225"/>. For cases where the entity originating the person
al communications is supporting the authentication service for the calling ident
ity and is the authority of the Rich Call Data, rather than creating multiple Id
entity header fields corresponding to multiple PASSporT extensions, the authenti
cation service can alternatively directly add the "rcd" claim to a PASSporT that
authenticates the calling identity.</t>
<section anchor="procedures-for-applying-rcd-claims-as-claims-only">
<name>Procedures for Applying RCD Claims as Claims Only</name>
<t>For a given PASSporT using some other extension than "rcd", the Authe
ntication Service <bcp14>MAY</bcp14> additionally include the "rcd" defined in <
xref target="rcd_define"/>, "rcdi" defined in <xref target="rcdi_define"/>, and
"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
f the "rcd" claim.</t>
<t>The verification service that receives the PASSporT, if it supports t
his specification and chooses to, should interpret the "rcd" claim as simply jus
t an additional claim intended to deliver and/or validate delivered Rich Call Da
ta.</t>
</section>
<section anchor="example-for-applying-rcd-claims-as-claims-only">
<name>Example for Applying RCD Claims as Claims Only</name>
<t>In the case of <xref target="RFC8588"/>, which is the PASSporT extens
ion supporting the Signature-based Handling of Asserted information using toKENs
(SHAKEN) specification <xref target="ATIS-1000074.v002"/>, a common case is for
an authentication service to coexist in a CSP network along with the authority
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
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>
<sourcecode type=""><![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 JWTClaimConstraints, a mechanism defined in <xref target="RF
<section anchor="Security"><name>Security Considerations</name> C8226"/> and extended in <xref target="RFC9118"/>, to constrain any of the RCD i
nformation in the public certificate by including that information in the certif
<t>The process of signing information contained in a "rcd" PASSporT, whether the icate, depending on the availability in the deployment of the PKI system, may pr
identities, identifiers, alternate identities or identifiers, images, logos, ph esent a privacy issue. The use of the "rcdi" claim and digests for representing
ysical addresses, or otherwise should follow some vetting process in which an au JWT claim contents is <bcp14>RECOMMENDED</bcp14> for the prevention of the expos
thoritative entity should follow an appropriate consistent policy defined and go ure of that information through the certificates that are often publicly accessi
verned by the eco-system using RCD and the STIR framework. This can be of many f ble 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
de other potential PASSporT claims that weren't originally vetted by the authori
zed entity providing the delegate certificate. The use of JWT claims constraints
(as defined in <xref target="RFC9118"/>) for preventing the ability to include
claims beyond the claims defined in this document may need to be considered.</t>
</section>
</section>
</middle>
<back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<t>The use of JWTClaimConstraints, a mechanism defined in <xref target="RFC8226" <!-- [I-D.ietf-sipcore-callinfo-rcd] companion document RFC 9796 -->
/> and extended in <xref target="RFC9118"/> to constrain any of the RCD informat <reference anchor="RFC9796" target="https://www.rfc-editor.org/info/rfc9796">
ion in the public certificate by including that information in the certificate, <front>
depending on the availability in the deployment of the PKI system, may present a <title>SIP Call-Info Parameters for Rich Call Data</title>
privacy issue. The use of "rcdi" claim and digests for representing JWT claim c <author initials='C' surname='Wendt' fullname='Chris Wendt'>
ontents is RECOMMENDED for the prevention of the exposure of that information th <organization />
rough the certificates which are often publically accessible and available.</t> </author>
<author initials='J' surname='Peterson' fullname='Jon Peterson'>
<organization />
</author>
<date year='2025' month='May'/>
</front>
<seriesInfo name="RFC" value="9796"/>
<seriesInfo name="DOI" value="10.17487/RFC9796"/>
</reference>
<t>Since computation of "rcdi" digests for URIs requires the loading of referenc <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
ed content, it would be best practice to validate that content at the creation o 261.xml"/>
f the "rcdi" or corresponding JWT claim constraint value by checking for content <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
that may cause issues for verification services or that doesn't follow the beha 986.xml"/>
vior defined in this document, e.g., unreasonably sized data, the inclusion of r <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
ecursive URI references, etc. Along the same lines, the verification service sho 648.xml"/>
uld also use precautionary best practices to avoid attacks when accessing URI li <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
nked content.</t> 234.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
901.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
095.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
519.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
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"/>
<t>As general guidance, the use of URLs and URIs that reference potentially dang <reference anchor="IANA-COSE-ALG" target="https://www.iana.org/assignmen
erous or intentionally harmful content should be considered in implimenting this ts/cose">
specification. <xref target="RFC3986"/> Section 7 contains good additional gui <front>
dance to consider when communicating or dereferencing URLs and URIs.</t> <title>COSE Algorithms</title>
<author>
<organization>IANA</organization>
</author>
</front>
</reference>
<section anchor="the-use-of-jwt-claim-constraints-in-delegate-certificates-to-ex <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
clude-unauthorized-claims"><name>The use of JWT Claim Constraints in delegate ce 119.xml"/>
rtificates to exclude unauthorized claims</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<t>While this can apply to any PASSporT that is signed with a STIR Delegate Cert </references>
ificates <xref target="RFC9060"/>, it is important to note that when constrainin <references>
g PASSporTs to include specific claims or contents of claims, it is also importa <name>Informative References</name>
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> <reference anchor="TS.3GPP.24.229"
</section> target="https://www.3gpp.org/ftp/Specs/html-info/24229.htm">
<front>
<title>IP multimedia call control protocol based on Session Initiati
on Protocol (SIP) and Session Description Protocol (SDP); Stage 3</title>
<author>
<organization abbrev="3GPP">3rd Generation Partnership Project</or
ganization>
</author>
<date month="September" year="2020"/>
</front>
<seriesInfo name="3GPP TS" value="24.229"/>
<refcontent>16.7.0</refcontent>
</reference>
</middle> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
325.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
340.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
26.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
816.xml"/>
<back> <!-- [rfced] Regarding [ATIS-1000074.v002], the original URL provided
yields "Sorry, the document could not be found".
We found the following URL of a more recent version of this standard:
https://access.atis.org/higherlogic/ws/public/download/67436
(which appears to be Version 3 of this standard and was published
16 August 2022). May we update this reference to that version?
<references title='Normative References'> Original:
[ATIS-1000074.v002]
ATIS/SIP Forum NNI Task Group, "Signature-based Handling
of Asserted information using toKENs (SHAKEN)
<https://access.atis.org/apps/group_public/
download.php/62391/ATIS-1000074.v002.pdf>", November
2021.
<reference anchor='I-D.ietf-sipcore-callinfo-rcd' target='https://datatracker.ie Perhaps:
tf.org/doc/html/draft-ietf-sipcore-callinfo-rcd-06'> [ATIS-1000074.v003]
<front> Alliance for Telecommunications Industry Solutions,
<title>SIP Call-Info Parameters for Rich Call Data</title> "Signature-based Handling of Asserted information using
<author fullname='Chris Wendt' initials='C.' surname='Wendt'> toKENs (SHAKEN)", August 2022,
<organization>Somos Inc.</organization> <https://access.atis.org/higherlogic/ws/public/
</author> download/67436>.
<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> <reference anchor="ATIS-1000074.v002">
</abstract> <front>
</front> <title>Signature-based Handling of Asserted information using toKENs
<seriesInfo name='Internet-Draft' value='draft-ietf-sipcore-callinfo-rcd-06'/ (SHAKEN)</title>
> <author>
<organization>Alliance for Telecommunications Industry Solutions</
organization>
</author>
<date year="2021" month="November"/>
</front>
</reference>
</reference> <!-- Here's XML if the update to [ATIS-1000074.v003] is preferred.
<reference anchor='RFC3261' target='https://www.rfc-editor.org/info/rfc3261'> <reference anchor="ATIS-1000074.v003" target="https://access.atis.org/hi
<front> gherlogic/ws/public/download/67436">
<title>SIP: Session Initiation Protocol</title> <front>
<author fullname='J. Rosenberg' initials='J.' surname='Rosenberg'><organization/ <title>Signature-based Handling of Asserted information using toKENs
></author> (SHAKEN)</title>
<author fullname='H. Schulzrinne' initials='H.' surname='Schulzrinne'><organizat <author>
ion/></author> <organization>Alliance for Telecommunications Industry Solutions</
<author fullname='G. Camarillo' initials='G.' surname='Camarillo'><organization/ organization>
></author> </author>
<author fullname='A. Johnston' initials='A.' surname='Johnston'><organization/>< <date year="2022" month="August"/>
/author> </front>
<author fullname='J. Peterson' initials='J.' surname='Peterson'><organization/>< <refcontent>ATIS-1000074.v003</refcontent>
/author> </reference>
<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'> <!-- [rfced] Regarding [W3C-SubresourceIntegrity], the original URL
<front> for this reference directed the reader to a W3C First Public Working Draft
<title>Uniform Resource Identifier (URI): Generic Syntax</title> with a date of 22 April 2025. However, the original date provided for
<author fullname='T. Berners-Lee' initials='T.' surname='Berners-Lee'><organizat this reference was 23 June 2016, which matches that of the W3C
ion/></author> Recommendation titled "Subresource Integrity"
<author fullname='R. Fielding' initials='R.' surname='Fielding'><organization/>< (https://www.w3.org/TR/2016/REC-SRI-20160623/). We have updated this
/author> reference to that.
<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'> However, please let us know if you intended to point to
<front> the First Public Working Draft (https://www.w3.org/TR/2025/WD-sri-2-20250422/)
<title>The Base16, Base32, and Base64 Data Encodings</title> or otherwise.
<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'> Original:
<front> [W3C-SubresourceIntegrity]
<title>US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)</title> W3C, "Subresource Integrity <https://www.w3.org/TR/SRI/>",
<author fullname='D. Eastlake 3rd' initials='D.' surname='Eastlake 3rd'><organiz 23 June 2016.
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'> Current:
<front> [W3C-SubresourceIntegrity]
<title>JavaScript Object Notation (JSON) Pointer</title> Akhawe, D., Ed., Braun, F., Ed., Marier, F., Ed., and J.
<author fullname='P. Bryan' initials='P.' role='editor' surname='Bryan'><organiz Weinberger, Ed., "Subresource Integrity", W3C
ation/></author> Recommendation, 23 June 2016,
<author fullname='K. Zyp' initials='K.' surname='Zyp'><organization/></author> <https://www.w3.org/TR/2016/REC-SRI-20160623/>.
<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'> <reference anchor="W3C-SubresourceIntegrity" target="https://www.w3.org/
<front> TR/2016/REC-SRI-20160623/">
<title>jCard: The JSON Format for vCard</title> <front>
<author fullname='P. Kewisch' initials='P.' surname='Kewisch'><organization/></a <title>Subresource Integrity</title>
uthor> <author fullname="Devdatta Akhawe" role="editor" />
<date month='January' year='2014'/> <author fullname="Frederik Braun" role="editor" />
<abstract><t>This specification defines &quot;jCard&quot;, a JSON format for vCa <author fullname="Francois Marier" role="editor" />
rd data. The vCard data format is a text format for representing and exchanging <author fullname="Joel Weinberger" role="editor" />
information about individuals and other entities, for example, telephone numbers <date year="2016" month="June" day="23"/>
, email addresses, structured names, and delivery addresses. JSON is a lightwei </front>
ght, text-based, language- independent data interchange format commonly used in <refcontent>W3C Recommendation</refcontent>
Internet applications.</t></abstract> </reference>
</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'> <!-- Here's XML for the W3C First Public Working Draft of
<front> [W3C-SubresourceIntegrity] if that is preferred.
<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'> <reference anchor="W3C-SubresourceIntegrity" target="https://www.w3.org/
<front> TR/2025/WD-sri-2-20250422/">
<title>Authenticated Identity Management in the Session Initiation Protocol (SIP <front>
)</title> <title>Subresource Integrity</title>
<author fullname='J. Peterson' initials='J.' surname='Peterson'><organization/>< <author fullname="Frederik Braun" role="editor" />
/author> <date year="2025" month="April" day="25"/>
<author fullname='C. Jennings' initials='C.' surname='Jennings'><organization/>< </front>
/author> <refcontent>W3C First Public Working Draft</refcontent>
<author fullname='E. Rescorla' initials='E.' surname='Rescorla'><organization/>< </reference>
/author> -->
<author fullname='C. Wendt' initials='C.' surname='Wendt'><organization/></autho </references>
r> </references>
<date month='February' year='2018'/> <section anchor="acknowledgements" numbered="false">
<abstract><t>The baseline security mechanisms in the Session Initiation Protocol <name>Acknowledgements</name>
(SIP) are inadequate for cryptographically assuring the identity of the end use <t>We would like to thank <contact fullname="David Hancock"/>, <contact fu
rs that originate SIP requests, especially in an interdomain context. This docu llname="Robert Sparks"/>, <contact fullname="Russ Housley"/>, <contact fullname=
ment defines a mechanism for securely identifying originators of SIP requests. "Eric Burger"/>, <contact fullname="Alec Fenichel"/>, <contact fullname="Ben Cam
It does so by defining a SIP header field for conveying a signature used for val pbell"/>, <contact fullname="Jack Rickard"/>, <contact fullname="Jordan Simpson"
idating the identity and for conveying a reference to the credentials of the sig /> for helpful suggestions, review, and comments.</t>
ner.</t><t>This document obsoletes RFC 4474.</t></abstract> </section>
</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'> </back>
<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'> <!--[rfced] Terminology
<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'> a) We updated the following terms to the form on the right
<front> based on common usage. Please let us know if you prefer otherwise.
<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'> Verification Service -> verification service
<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'> JSON Pointer -> JSON pointer
<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'> 'display-name', "display-name" -> display-name
<front> (because it most often appeared without quotes)
<title>Enhanced JSON Web Token (JWT) Claim Constraints for Secure Telephone Iden
tity Revisited (STIR) Certificates</title>
<author fullname='R. Housley' initials='R.' surname='Housley'><organization/></a
uthor>
<date month='August' year='2021'/>
<abstract><t>RFC 8226 specifies the use of certificates for Secure Telephone Ide
ntity Credentials; these certificates are often called &quot;Secure Telephone Id
entity Revisited (STIR) Certificates&quot;. RFC 8226 provides a certificate exte
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>
<seriesInfo name='RFC' value='9118'/>
<seriesInfo name='DOI' value='10.17487/RFC9118'/>
</reference>
<reference anchor="IANA-COSE-ALG" > b) JWTClaimConstraints (4 instances) vs.
<front> JWT Claim Constraints (15 instances)
<title>COSE Algorithms &lt;https://www.iana.org/assignments/cose/cose.xhtml& Do these have the same meaning? If so, should one be used
gt;</title> consistently?
<author >
<organization></organization>
</author>
<date year="n.d."/>
</front>
</reference>
<reference anchor='RFC2119' target='https://www.rfc-editor.org/info/rfc2119'> c) Note that we added hyphens as shown on the right below. Please let us know i
<front> f you have any concerns.
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname='S. Bradner' initials='S.' surname='Bradner'><organization/></a
uthor>
<date month='March' year='1997'/>
<abstract><t>In many standards track documents several words are used to signify
the requirements in the specification. These words are often capitalized. This
document defines these words as they should be interpreted in IETF documents.
This document specifies an Internet Best Current Practices for the Internet Comm
unity, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>
<reference anchor='RFC8174' target='https://www.rfc-editor.org/info/rfc8174'> URI referenced content -> URI-referenced content
<front> URI linked content -> URI-linked content
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> -->
<author fullname='B. Leiba' initials='B.' surname='Leiba'><organization/></autho
r>
<date month='May' year='2017'/>
<abstract><t>RFC 2119 specifies common key words that may be used in protocol s
pecifications. This document aims to reduce the ambiguity by clarifying that on
ly UPPERCASE usage of the key words have the defined special meanings.</t></abs
tract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>
</references> <!-- [rfced] Please review the "type" attribute of each sourcecode element
in the XML file to ensure correctness. If the current list of preferred
values for "type"
(https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types)
does not contain an applicable type, then feel free to let us know.
Also, it is acceptable to leave the "type" attribute not set.
<references title='Informative References'> In addition, review each artwork element. Specifically,
should any artwork element be tagged as sourcecode or another
element?
-->
<reference anchor='RFC3325' target='https://www.rfc-editor.org/info/rfc3325'> <!-- [rfced] Please review whether any of the notes in this document
<front> should be in the <aside> element. It is defined as "a container for
<title>Private Extensions to the Session Initiation Protocol (SIP) for Asserted content that is semantically less important or tangential to the
Identity within Trusted Networks</title> content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside)
<author fullname='C. Jennings' initials='C.' surname='Jennings'><organization/>< .
/author> -->
<author fullname='J. Peterson' initials='J.' surname='Peterson'><organization/>< <!-- [rfced] Please review the "Inclusive Language" portion of the online
/author> Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
<author fullname='M. Watson' initials='M.' surname='Watson'><organization/></aut and let us know if any changes are needed. Updates of this nature typically
hor> result in more precise language, which is helpful for readers.
<date month='November' year='2002'/>
</front>
<seriesInfo name='RFC' value='3325'/>
<seriesInfo name='DOI' value='10.17487/RFC3325'/>
</reference>
<reference anchor='RFC7340' target='https://www.rfc-editor.org/info/rfc7340'> Note that our script did not flag any words in particular, but this should
<front> still be reviewed as a best practice.
<title>Secure Telephone Identity Problem Statement and Requirements</title>
<author fullname='J. Peterson' initials='J.' surname='Peterson'><organization/><
/author>
<author fullname='H. Schulzrinne' initials='H.' surname='Schulzrinne'><organizat
ion/></author>
<author fullname='H. Tschofenig' initials='H.' surname='Tschofenig'><organizatio
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'> In addition, please consider whether "traditional" should be updated for clarity
<front> in the instances listed below. While the NIST website
<title>Secure Telephone Identity Revisited (STIR) Out-of-Band Architecture and U <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-l
se Cases</title> ibrary/nist-technical-series-publications-author-instructions#table1>
<author fullname='E. Rescorla' initials='E.' surname='Rescorla'><organization/>< indicates that this term is potentially biased, it is also ambiguous.
/author> "Tradition" is a subjective term, as it is not the same for everyone.
<author fullname='J. Peterson' initials='J.' surname='Peterson'><organization/><
/author>
<date month='February' year='2021'/>
<abstract><t>The Personal Assertion Token (PASSporT) format defines a token that
can be carried by signaling protocols, including SIP, to cryptographically atte
st the identity of callers. However, not all telephone calls use Internet signal
ing protocols, and some calls use them for only part of their signaling path, wh
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" > ... the traditional "Caller ID" of the telephone network
<front>
<title>Signature-based Handling of Asserted information using toKENs (SHAKEN
) &lt;https://access.atis.org/apps/group_public/download.php/62391/ATIS-1000074.
v002.pdf&gt;</title>
<author >
<organization>ATIS/SIP Forum NNI Task Group</organization>
</author>
<date year="2021" month="November"/>
</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> Traditional telephone network signaling protocols ...
</back> The first data is a more
traditional set of info about a caller associated with "display-name"
in SIP ...
<!-- ##markdown-source: ... even in traditional calling name services today ...
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
While in the traditional telephone network, ...
--> -->
</rfc> </rfc>
 End of changes. 124 change blocks. 
1992 lines changed or deleted 1593 lines changed or added

This html diff was produced by rfcdiff 1.48.