<?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 [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-stir-passport-rcd-26" number="9795" submissionType="IETF" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true"> symRefs="true"
updates="" obsoletes="" xml:lang="en" version="3">

  <front>
    <title abbrev="RCD">PASSporT abbrev="RCD">Personal Assertion Token (PASSporT) Extension for Rich Call Data</title>
    <seriesInfo name="RFC" value="9795"/>
    <author initials="C." surname="Wendt" fullname="Chris Wendt">
      <organization>Somos Inc.</organization>
      <address>
        <email>chris-ietf@chriswendt.net</email>
      </address>
    </author>
    <author initials="J." surname="Peterson" fullname="Jon Peterson">
      <organization>Neustar Inc.</organization>
      <address>
        <email>jon.peterson@neustar.biz</email>
      </address>
    </author>
    <date year="2023" month="June" day="05"/> year="2025" month="May"/>
    <area>art</area>
    <workgroup>stir</workgroup>
    <keyword>Identity</keyword>
    <abstract>
      <t>This document extends PASSporT, Personal Assertion Token (PASSporT), a token for conveying cryptographically-signed cryptographically signed call information about personal communications, to include rich meta-data metadata about a call and caller that can be signed and integrity protected, transmitted, and subsequently rendered to the called party. This framework is intended to include and extend caller caller- and call specific call-specific information beyond human-readable display name name, comparable to the "Caller ID" function common on the telephone network and network. It is also enhanced with a an integrity mechanism that is designed to protect the authoring and transport of this information for different authoritative use-cases.</t> use cases.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction"><name>Introduction</name> anchor="introduction">
      <name>Introduction</name>
      <t>PASSporT <xref target="RFC8225"/> is a token format based on JWT JSON Web Token (JWT) <xref target="RFC7519"/> for conveying cryptographically-signed cryptographically signed information about the parties involved in personal communications; it is used to convey a signed assertion of the identity of the participants in real-time communications established via a protocol like SIP <xref target="RFC8224"/>. The STIR Secure Telephone Identity Revisited (STIR) problem statement <xref target="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 procedures to protect additional caller caller- and call related call-related information.  This is additional information beyond the calling party originating identity (e.g. (e.g., telephone number or SIP URI) that is intended 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 the person or entity on one side of a communications session, for example, the traditional "Caller ID" of the telephone network along with related display information that would be rendered to the called party during 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 delivering a 'calling name' from the originating side, though in practice, practice the terminating 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, similarly can carry this information in a 'display-name' display-name in the From header field value (or alternatively the Call-Info header field) from the originating to terminating side, or alternatively in the Call-Info header field. side. In this document, we utilize the STIR framework to more generally extend 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 protocols, 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, Section 12 <xref target="use"/> describes use-cases use cases that enable external third-party authorities to convey rich information associated with a calling number via a 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.

Original:
   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 and therefore a constraint on the RCD data
   that a PASSporT can attest via certificate-level controls.

Option A:
   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.

Option B:
   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 by specifying the use of JWT claims constraints on the RCD data
   that a PASSporT can attest to via certificate-level controls.
-->
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 and therefore a constraint on the RCD that 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", anchor="terminoloygy">
      <name>Terminology</name>
        <t>
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</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 "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
    </section>
    <section anchor="overview-of-the-use-of-the-rich-call-data-passport-extension"><name>Overview anchor="overview-of-the-use-of-the-rich-call-data-passport-extension">
      <name>Overview of the use Use of the Rich Call Data PASSporT extension</name> Extension</name>
      <t>This document defines Rich Call Data (RCD) (RCD), which is a PASSporT extension <xref target="RFC8225"/> that defines an extensible claim for asserting information about the call beyond the telephone number. This includes information such as more detailed information about the calling party or party, calling number being presented number, or the purpose of the call. There are many use-cases use cases that will be described in this document describes around the entities responsible for the signing and integrity of this information, whether it is the entity that originates a call, a service provider acting on behalf of a caller caller, or use-cases where when third-party services may be authoritative over the rich call data RCD on behalf of the caller. In general, PASSporT <xref target="RFC8225"/> has been defined to be a communications protocol independent technology, of the communications protocol, but it's its initial usage as detailed in <xref target="RFC8224"/> is with the SIP protocol <xref target="RFC3261"/>.  There are many SIP specific SIP-specific references and definitions in this document, but future specifications may extend the usage of RCD PASSporTs and claims to other protocol specific protocol-specific 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 set of info information about a caller associated with "display-name" in SIP <xref target="RFC3261"/>, typically a textual description of the caller, or alternate presentation numbers often used in the From Header header field <xref target="RFC3261"/> or P-Asserted-Identity header field <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 extensions to that data. <xref target="I-D.ietf-sipcore-callinfo-rcd"/> target="RFC9796"/> describes 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 communications event itself (versus the identity description in the previous paragraph), <xref target="I-D.ietf-sipcore-callinfo-rcd"/> target="RFC9796"/> also describes a "call-reason" parameter intended for description of the intent or reason for a particular call. A new PASSporT 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 because 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 per-call basis.</t>
    </section>
    <section anchor="rcdintegrity"><name>Overview anchor="rcdintegrity">
      <name>Overview of Rich Call Data Integrity</name>
      <t>When incorporating call data that represents a user, even in traditional calling name services today, often there are policy and restrictions around what data elements are allowed to be used. Whether preventing offensive language or icons or icons, enforcing uniqueness, notifying about potential trademark or copyright violations violations, or enforcing other policy enforcement, policies, there might be the desire to pre-certify or "vet" the specific use of rich call data. RCD.
<!--[rfced] Please clarify the list in this sentence.

Original:
   This document defines a
   mechanism that allows for a direct or indirect party that enforces
   the policies to approve or certify the content, create a
   cryptographic 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 content of the RCD is as
   intended at its creation and approval or certification.

Option A:
 This document defines a mechanism that allows for a party that
 (a) enforces X, (b) creates Y, and (c) applies Z.

Option B:
 This document defines a mechanism that
 (a) allows for a party that enforces X, (b) creates Y, and (c) applies Z.

Perhaps (if Option A is accurate):
   This document defines a mechanism that allows for a direct or
   indirect party that (a) enforces
   the policies to approve or certify the content, (b) creates a
   cryptographic digest that can be used to validate that data, and
   (c) applies a constraint in the certificate to allow the recipient and
   verifier to validate that the specific content of the RCD is as
   intended at its creation and its approval or certification.
-->
This document defines a mechanism that allows for a direct or indirect party that enforces the policies to approve or certify the content, create a cryptographic 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 content of the RCD is as intended at its creation and its approval or certification.</t>
      <t>There are two mechanisms that are defined to accomplish that for two distinct categories of purposes. The first of the mechanisms include the definition 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 value (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 specification <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 specifically 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 rich call data RCD conveyed in the PASSporT claims is pass-by-value passed by value or pass-by-reference; passed by reference; i.e., is the information contained in the PASSporT claims and therefore integrity protected by the PASSporT signature, or is the information contained in an external resource referenced by a URI in the PASSporT. PASSporT? The second category of purpose is whether the signer is authoritative or has responsibility for the accuracy of the RCD based on the policies of the eco-system ecosystem the "rcd" PASSporTs or "rcd" claims are being used.</t>
      <t>The following table provides an overview of the framework for how integrity should be used with RCD. ("Auth" represents "authoritative" in this table.)</t>

<figure><artwork><![CDATA[
+----------+---------------------+--------------------------------+
|   Modes  |  No URI refs        |      Includes URI refs         |
+----------+---------------------+--------------------------------+
|   Auth   | 1:

<table>
  <thead>
    <tr>
      <th>Modes</th>
      <th>No URI refs</th>
      <th>Includes URI refs</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th>Auth</th>
      <td>1: No integrity req | 2: req</td>
      <td>2: RCD Integrity               |
+----------+---------------------+--------------------------------+
| Non-Auth | 3: Integrity</td>
    </tr>
    <tr>
      <th>Non-Auth</th>
      <td>3: JWT Claim Const. | 4: Const.</td>
      <td>4: RCD Integ./JWT Integ. / JWT Claim Const. |
+----------+---------------------+--------------------------------+
]]></artwork></figure> Const.</td>
    </tr>
  </tbody>
</table>

      <t>The first and simplest mode is exclusively for when all RCD content is directly included as part of the claims (i.e. (i.e., no URIs referencing external content are included in the content) and when the signer is authoritative over the content. In this mode, integrity protection is not required required, and the set of claims is simply protected by the signature of the standard PASSporT <xref target="RFC8225"/> and SIP identity header <xref target="RFC8224"/> procedures. The second mode is an extension of the first where the signer is authoritative authoritative, and an "rcd" claim contents include a URI identifying external resources. In this mode, an RCD Integrity or "rcdi" claim MUST <bcp14>MUST</bcp14> be included. This integrity claim is defined later in this document and provides a digest of the "rcd" claim content so that, particularly for the case where there are URI references in the RCD, the content of that RCD can be comprehensively validated that it was received as intended by the signer of the PASSporT.</t>
<!--[rfced] May this phrase be reworded for clarity?
Seems "allowing the ability to enable a mechanism for allowing"
could be simplified.

Original:
   The third and fourth modes cover cases where there is a different
   authoritative entity responsible for the content of the RCD, separate
   from the signer of the PASSporT itself, allowing the ability, 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.

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.

Option A:
   allowing the ability, in particular when [...],
   to enable a mechanism for agreed or vetted content to be included
   in or referenced by the RCD claim contents.

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 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. The primary framework for allowing the separation of authority and the signing of PASSporTs by non-authorized entities is detailed in <xref target="RFC9060"/> target="RFC9060"/>, although other cases may apply. As with the first and second modes, the third and fourth modes differ with the absence or inclusion of referenced external content using URIs.</t>
    </section>
    <section anchor="rcd_define"><name>PASSporT anchor="rcd_define">
      <name>PASSporT Claim "rcd" Definition and Usage</name>
      <section anchor="syntax"><name>PASSporT 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 value pairs. This document defines a default set of key values.</t>
        <section anchor="nam-key"><name>"nam" anchor="nam-key">
          <name>"nam" key</name>
          <t>The "nam" key value is a display name, associated with the originator of personal communications, which may may, for example example, match the display-name component of the From header field value of a SIP request <xref target="RFC3261"/> or alternatively from of the P-Asserted-Identity header field value <xref target="RFC3325"/>, or a similar field in other PASSporT using protocols. This key MUST <bcp14>MUST</bcp14> be included once as part of the "rcd" claim value JSON object. The key syntax of "nam" MUST <bcp14>MUST</bcp14> follow the display-name ABNF given in <xref target="RFC3261"/>. If there is no string associated with a display name, the claim value MUST then <bcp14>MUST</bcp14> be an empty string.</t>
        </section>
        <section anchor="apn-key"><name>"apn" anchor="apn-key">
          <name>"apn" key</name>

<t>The

<!-- [rfced] This sentence appeared to intend to cite 3GPP TS 24.229, but
there was not a corresponding reference. We added an informative reference
as follows; please review and let us know if this is accurate.
Would you like to update this to the most recent version? (We see
version 19.0.2 from March 2025.)

Original:
   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 <xref target="RFC3325"/>), [RFC3325]), or alternatively from the Additional-Identity Additional-
   Identity header field value [3GPP TS 24.229 v16.7.0], or a similar
   field in other PASSporT using protocols.

Current:
   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 of the Additional-
   Identity header field value [TS.3GPP.24.229], or a similar
   field in other PASSporT-using protocols.

Added in Section 18.2:

   [TS.3GPP.24.229]
              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 "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 <xref target="RFC3325"/>), 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 authorized to show to called parties in lieu of their default number, such as cases where a remote call agent uses the main number of a call center instead of their personal telephone number. The "apn" key value is a canonicalized telephone number per <xref target="RFC8224"/> Section 8.3. section="8.3" target="RFC8224" sectionFormat="comma"/>. If present, this key MUST <bcp14>MUST</bcp14> 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 an "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 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.
<!--[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?

Original:
   How the signer determines
   that a user is authorized to present the number in question is a
   policy decision outside the scope of this document, 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.

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 jCard data needs to be conveyed with the call. Only one "apn" key may be present. "apn" MUST <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 present in a PASSporT with a "tel" key value.</t>
        </section>
        <section anchor="icn-key"><name>"icn" 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 communications. 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"/> target="RFC3261"/>, this claim key value is used to protect the Call-Info header field with a purpose parameter value of "icon" as described in Section 20.9 <xref section="20.9" target="RFC3261"/>.  Example as follows:</t>

<figure><artwork><![CDATA[  For example:</t>
          <artwork><![CDATA[
Call-Info: <http://wwww.example.com/alice/photo.jpg>;
  purpose=icon
]]></artwork></figure>
]]></artwork>
          <t>Note that <xref target="I-D.ietf-sipcore-callinfo-rcd"/> target="RFC9796"/> extends the specific usage of "icon" in SIP in the context of the larger rich call data framework with specific guidance on referencing images and image types, sizes sizes, and formats.</t>
          <t>It should be also noted that with jCard, as described in the following for "jcd" and "jcl" key value sections values (Sections <xref target="jcd-key" format="counter"/> and <xref target="jcl-key" format="counter"/>) and in <xref target="I-D.ietf-sipcore-callinfo-rcd"/>, target="RFC9796"/>, there are alternative ways of including photos and logos as HTTPS URL references. The "icn" key should be then considered a base or default image image, and jCard 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 represents for the proper rendering to end users.</t>
        </section>
        <section anchor="jcd-key"><name>"jcd" anchor="jcd-key">
          <name>"jcd" key</name>
          <t>The "jcd" key value is defined to contain a jCard <xref target="RFC7095"/> JSON object. object <xref target="RFC7095"/>. The jCard is defined in this specification as an extensible object format used to contain RCD information about the call initiator. This object is intended to directly match the Call-Info header field value defined in <xref target="I-D.ietf-sipcore-callinfo-rcd"/> target="RFC9796"/> with a type of "jcard" "jcard", where the format of the jCard and properties used should follow the normative usage and formatting rules and procedures in that document. It is an extensible object where the calling party can provide both the standard types of information defined in jCard or can use the built-in extensibility of the jCard specification to add additional information. The "jcd" key is optional. Either a "jcd" or "jcl" MAY <bcp14>MAY</bcp14> appear in the "rcd" claim, but not both.</t>
          <t>The jCard object value for "jcd" MUST <bcp14>MUST</bcp14> be a jCard JSON object that MAY <bcp14>MAY</bcp14> have URI referenced URI-referenced content, but that URI referenced URI-referenced content MUST NOT <bcp14>MUST NOT</bcp14> further reference URIs. Future specifications may extend this capability, but as stated in <xref target="I-D.ietf-sipcore-callinfo-rcd"/> it target="RFC9796"/> constrains the security properties of RCD information and the integrity of the content referenced by URIs.</t>

<t>Note:
<!--[rfced] Please clarify "using Call-Info as protocol".

Original:
   Note: even though we refer to <xref target="I-D.ietf-sipcore-callinfo-rcd"/> [RFC9796] 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 is not required.
-->
          <t>Note: Even though we refer to <xref target="RFC9796"/> 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 is not required.  The identity header carrying a PASSporT with an "rcd" claim including a "jcd" value can be used as the primary and only transport of the RCD information.</t>
        </section>
        <section anchor="jcl-key"><name>"jcl" anchor="jcl-key">
          <name>"jcl" key</name>
          <t>The "jcl" key value is an HTTPS URL that refers to a jCard <xref target="RFC7095"/> JSON object <xref target="RFC7095"/> on a web server. The web server MUST <bcp14>MUST</bcp14> 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 defined in <xref target="I-D.ietf-sipcore-callinfo-rcd"/> target="RFC9796"/> with a type of "jcard". As also defined in <xref target="I-D.ietf-sipcore-callinfo-rcd"/>, target="RFC9796"/>, the format of the jCard and properties used should follow the normative usage and formatting rules and procedures. The "jcl" key is optional. The "jcd" or "jcl" keys MAY <bcp14>MAY</bcp14> only appear once in the "rcd" claim but MUST <bcp14>MUST</bcp14> be mutually exclusive.</t>
          <t>The jCard object referenced by the URI value for "jcl" MUST <bcp14>MUST</bcp14> be a jCard JSON object that MAY <bcp14>MAY</bcp14> have URI referenced URI-referenced content, but that URI referenced URI-referenced content MUST NOT <bcp14>MUST NOT</bcp14> further reference URIs. Future specifications may extend this capability, but as stated in <xref target="I-D.ietf-sipcore-callinfo-rcd"/> it target="RFC9796"/> constrains the security properties of RCD information and the integrity of the content referenced by URIs.</t>
        </section>
      </section>
    </section>
    <section anchor="rcdi_define"><name>"rcdi" 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"/> of this document. (<xref target="rcdintegrity"/>). "rcdi" and "rcd" claims MAY <bcp14>MAY</bcp14> each appear once in a PASSporT, but if "rcdi" is included included, the "rcd" MUST correspondingly <bcp14>MUST</bcp14> be present also. correspondingly. The value of the "rcdi" 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"?

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 "rcd" claim object that require integrity protection with an associated digest over the content referenced by the key string. The individual digest of different elements of the "rcd" claim data and URI referenced URI-referenced external content is kept specifically separate to allow the ability to verify the integrity of only the elements that are ultimately retrieved or downloaded retrieved, downloaded, or rendered to the end-user.</t> 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 additional rule to support URI references to external content that include JSON objects themselves, for the specific case of the use of "jcl", defined in <xref target="jcl_element"/>. JSON pointer syntax is the key value that documents exactly the part of JSON that is used to generate the digest which produce that produces the resulting string that makes up the value for the corresponding key. Detailed procedures are provided below, but an example "rcdi" is provided here:</t>

<figure><artwork><![CDATA[
      <sourcecode type="json"><![CDATA[
"rcdi" : {
  "/jcl": "sha256-7kdCBZqH0nqMSPsmABvsKlHPhZEStgjojhdSJGRr3rk",
  "/jcl/1/2/3": "sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI"
}
]]></artwork></figure>
]]></sourcecode>
      <t>The values of each key/value pair consists of a digest across one of the following objects referenced by the JSON pointer key,</t>

<t><list style="symbols">
  <t>content key:</t>
      <ul spacing="normal">
        <li>the content inline to the referenced object</t>
  <t>the object, </li>
        <li>the content of a resource referenced by an inline URI object</t>
  <t>the object, or</li>
        <li>the content of a resource specified by a URI that is in embedded in content specified by an inline URI object(e.g., jcl)</t>
</list></t> object (e.g., "jcl")</li>
      </ul>
      <t>This is combined with a string that defines the crypto cryptographic algorithm used to generate the digest. RCD implementations MUST <bcp14>MUST</bcp14> support the hash algorithms SHA-256, SHA-384, and SHA-512.  These hash algorithms are identified by "sha256", "sha384", and "sha512", respectively.  SHA-256, SHA-384, and SHA-512 are part of the SHA-2 set of cryptographic hash functions <xref target="RFC6234"/> defined by the US National Institute of Standards and Technology (NIST).  Implementations MAY <bcp14>MAY</bcp14> support additional recommended hash algorithms in <xref target="IANA-COSE-ALG"/>; target="IANA-COSE-ALG"/>, that is, the hash algorithm has algorithms with "Yes" in the "Recommended" column of the IANA registry.  Hash algorithm identifiers MUST <bcp14>MUST</bcp14> use only lowercase letters, and they MUST NOT <bcp14>MUST NOT</bcp14> contain hyphen characters. The character following the algorithm string MUST <bcp14>MUST</bcp14> be a hyphen character, "-", or ASCII 45. The subsequent characters are the base64 encoded <xref target="RFC4648"/> digest of a canonicalized and concatenated string or binary data based on the JSON pointer referenced elements of the "rcd" claim or the URI referenced URI-referenced content contained in the claim. The next section covers the details of the determination of the input string used to determine the digest are defined in digest.</t>
<!--[rfced] Would you like to list the next section.</t> codepoint for this character
in a more typical manner? "ASCII 45" was last used in RFC 1849.

Original:
   MUST be a hyphen character, "-", or ASCII 45.

Perhaps:
   MUST be a hyphen character ("-", %x2D).

Or:
   MUST be a hyphen character, "-" (HYPHEN-MINUS, U+002D).
-->
      <section anchor="creation-of-the-rcd-element-digests"><name>Creation anchor="creation-of-the-rcd-element-digests">
        <name>Creation of the "rcd" element digests</name> Element Digests</name>
        <t>"rcd" claim objects can contain "nam", "apn", "icn", "jcd", or "jcl" keys as part of the "rcd" JSON object claim value. This document defines the use of JSON pointer <xref target="RFC6901"/> as a mechanism to reference specific "rcd" claim elements.</t>

<!--[rfced] How should the first point be changed to a complete sentence? (The
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?

Preceding sentence for context:
   In order to facilitate proper verification of the digests and to
   determine whether the "rcd" elements or content referenced by URIs
   were modified, the input to the digest must be completely
   deterministic at three points in the process:

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.

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 determine whether the "rcd" elements or content referenced by URIs were modified, the input to the digest must be completely deterministic at three points in the process. First, at the certification point where the content is evaluated to conform to the application policy and the JWT Claim Constraints is applied to the certificate containing the digest. Second, when the call is signed at the Authentication Service, there may be a local policy to verify that the provided "rcd" claim corresponds to each digest. Third, when the "rcd" data is verified at the Verification Service, verification service, the verification is performed for each digest by constructing the input digest string 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 corresponding to a JSON pointer string key is as follows.</t>

<t><list style="numbers">
  <t>The
        <ol spacing="normal" type="1"><li>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 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 defined in <xref target="RFC8225"></xref>, Section 9. section="9" target="RFC8225" sectionFormat="comma"/>.  The resulting string is the input for the hash function.</t>
  <t>For function.</li>
          <li>For any URI referenced URI-referenced content, the bytes of the body of the HTTP response is are the input for the hash function.</t>
</list></t> function.</li>
        </ol>
        <t>Note that the digest is computed on the Json JSON representation of the string, which necessarily includes the beginning and ending double-quote characters.</t>
        <section anchor="nam_apn_element"><name>"nam" anchor="nam_apn_element">
          <name>"nam" and "apn" elements</name> Elements</name>
          <t>In the case of "nam" and "apn", the only allowed value is a string. For both of these key values values, an "rcdi" JSON pointer or integrity digest is optional because the direct value is protected by the signature and can be constrained directly with JWTClaimConstraints.</t>
        </section>
        <section anchor="icn_element"><name>"icn" elements</name> anchor="icn_element">
          <name>"icn" Elements</name>
          <t>In the case of "icn", the only allowed value is a URI value that references an image file. If the URI references externally linked content content, there MUST <bcp14>MUST</bcp14> be a JSON pointer and digest entry for the content in that linked resource. When creating a key/value representing "icn", the key is the JSON pointer string "/icn" "/icn", and the digest value string would be is created using the image file byte data referenced in the URI.</t>
        </section>
        <section anchor="jcd_element"><name>"jcd" elements</name> 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 numeric indices into elements of arrays, including when those elements are arrays themselves.</t>
          <t>As an example, for we have the following "rcd" claim:</t>

<figure><artwork><![CDATA[
          <sourcecode type="json"><![CDATA[
"rcd": {
  "jcd": ["vcard",
    [ ["version",{},"text","4.0"],
      ["fn",{},"text","Q Branch"],
      ["org",{},"text","MI6;Q Branch Spy Gadgets"],
      ["photo",{},"uri",
        "https://example.com/photos/quartermaster-256x256.png"],
      ["logo",{},"uri",
        "https://example.com/logos/mi6-256x256.jpg"],
      ["logo",{},"uri",
        "https://example.com/logos/mi6-64x64.jpg"]
    ]
  ],
  "nam": "Q Branch Spy Gadgets"
}
]]></artwork></figure>
]]></sourcecode>
          <t>In order to use a JSON pointer to refer to the URIs, the following example "rcdi" claim includes a digest for the entire "jcd" array string as well as three additional digests for the URIs, where, as defined in <xref target="RFC6901"/> target="RFC6901"/>, zero-based array indices are used to reference the URI strings.</t>

<figure><artwork><![CDATA[
          <sourcecode type="json"><![CDATA[
"rcdi": {
  "/jcd": "sha256-7kdCBZqH0nqMSPsmABvsKlHPhZEStgjojhdSJGRr3rk",
  "/jcd/1/3/3": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4",
  "/jcd/1/4/3": "sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI",
  "/jcd/1/5/3": "sha256-GKNxxqlLRarbyBNh7hc/4lbZAdK6B0kMRf1AMRWPkSo"
  }
}
]]></artwork></figure>
]]></sourcecode>
          <t>The use of a JSON pointer and integrity digest for the "jcd" claim key and value is optional. The "jcd" value is the directly included jCard array and array; it can be protected by the signature and can be constrained directly with JWTClaimConstraints.  However, for data length reasons (as with "icn" above) or more importantly for potential privacy and/or security considerations with a publically publicly accessible certificate, the use of the "rcdi" JSON pointer and integrity digest as the constraint value in JWTClaimConstraints over the jCard data is RECOMMENDED.</t> <bcp14>RECOMMENDED</bcp14>.</t>
          <t>It is important to remember the array indices for JSON Pointer pointer are dependent on the order of the elements in the jCard. The use of digest for the "/jcd" corresponding to the entire jCard array string can be included as a redundant mechanism to avoid any possibility of substitution, insertion attacks, or other potential techniques that may be possible to avoid undermine integrity detection.</t>
          <t>Each URI referenced in the jCard array string MUST <bcp14>MUST</bcp14> have a corresponding JSON pointer string key and digest value.</t>
        </section>
        <section anchor="jcl_element"><name>"jcl" elements</name> anchor="jcl_element">
          <name>"jcl" Elements</name>
<!--[rfced] Please clarify this sentence. In particular, what does
"with the exception and the minor modification" mean?
We suggest making this into two sentences.

Original:
   In the case of the use of a "jcl" URI reference to an external jCard,
   the procedures are similar to "jcd" with the exception and the minor
   modification 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 directly part of the
   overall "rcd" claim JSON object.

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 jCard, the procedures are similar to "jcd" with the exception and the minor modification 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 directly part of the overall "rcd" claim JSON object. The following example illustrates a "jcl" version of the above "jcd" example.</t>

<figure><artwork><![CDATA[
          <sourcecode type="json"><![CDATA[
"rcd": {
  "jcl": "https://example.com/qbranch.json",
  "nam": "Q Branch Spy Gadgets"
},
"rcdi": {
  "/jcl": "sha256-7kdCBZqH0nqMSPsmABvsKlHPhZEStgjojhdSJGRr3rk",
  "/jcl/1/3/3": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4",
  "/jcl/1/4/3": "sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI",
  "/jcl/1/5/3": "sha256-GKNxxqlLRarbyBNh7hc/4lbZAdK6B0kMRf1AMRWPkSo"
}
]]></artwork></figure>
]]></sourcecode>
          <t>The "rcdi" MUST <bcp14>MUST</bcp14> have a "/jcl" key value and digest value to protect the referenced jCard object object, and each URI referenced in the referenced jCard array string MUST <bcp14>MUST</bcp14> have a corresponding JSON pointer string key and digest value.</t>
          <t>The following is the example contents of the resource pointed to by https://example.com/qbranch.json https://example.com/qbranch.json; it is used to calculate the above digest for "/jcl"</t>

<figure><artwork><![CDATA[
          <sourcecode type="json"><![CDATA[
["vcard",
  [ ["version",{},"text","4.0"],
    ["fn",{},"text","Q Branch"],
    ["org",{},"text","MI6;Q Branch Spy Gadgets"],
    ["photo",{},"uri",
      "https://example.com/photos/quartermaster-256x256.png"],
    ["logo",{},"uri",
      "https://example.com/logos/mi6-256x256.jpg"],
    ["logo",{},"uri",
      "https://example.com/logos/mi6-64x64.jpg"]
  ]
]
]]></artwork></figure>
]]></sourcecode>
        </section>
      </section>
      <section anchor="jwt-claim-constraints-for-rcd-claims"><name>JWT anchor="jwt-claim-constraints-for-rcd-claims">
        <name>JWT Claim Constraints for "rcd" claims</name> Claims</name>
        <t>When using JWT Claim Constraints for "rcd" claims claims, the procedure when creating the signing certificate should follow adhere to the following guidelines.</t>
        <t>The "permittedValues" for the "rcd" claim MAY <bcp14>MAY</bcp14> contain a single entry or optionally MAY <bcp14>MAY</bcp14> contain multiple entries with the intent of supporting cases where the certificate holder is authorized to use different sets of rich call data corresponding to different call scenarios.</t>
        <t>Only including "permittedValues" for "rcd", with no "mustInclude", provides the ability for the construction a valid PASSPorT PASSporT that can either have no "rcd" claim within or only the set of constrained "permittedValues" values for an included "rcd" claim.</t>
      </section>
      <section anchor="jwt-claim-constraints-usage-for-rcd-and-rcdi-claims"><name>JWT anchor="jwt-claim-constraints-usage-for-rcd-and-rcdi-claims">
        <name>JWT Claim Constraints Usage for "rcd" and "rcdi" Claims</name>
<!--[rfced] May 'usage' be cut from the title of Section 6.3 for
consistency with the title of Section 6.2?

Original:
6.2.  JWT Claim Constraints for "rcd" claims
6.3.  JWT Claim Constraints usage for "rcd" and "rcdi" claims</name> claims

Perhaps:
6.2.  JWT Claim Constraints for "rcd" Claims
6.3.  JWT Claim Constraints for "rcd" and "rcdi" Claims
-->
<t>The use of JWT Claim Constraints with an "rcdi" claim is for cases where URI referenced URI-referenced content is to be protected by the authoritative certificate issuer. The objective for the use of JWT Claim Constraints for the combination of both "rcd" 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 predetermined set of content. Once both the contents of the "rcd" claim and any referenced content is are certified by the party that is authoritative for the certificate being issued to the signer, the "rcdi" claim is constructed and linked to the STIR certificate associated with the signature in the PASSporT via the JWT Claim Constraints extension as defined in <xref target="RFC8226"/> Section 8 section="8" target="RFC8226" sectionFormat="comma"/> and extended in <xref target="RFC9118"/>. It should be recognized that the "rcdi" set of digests is intended to be unique for only a specific combination of "rcd" content and URI referenced URI-referenced external content, and therefore the set provides a robust integrity mechanism for an authentication service being performed by a non-authoritative party. This would often be associated with the use of delegate certificates <xref target="RFC9060"/> for the signing of calls by the calling party directly directly, as an example, even though the "authorized party" is not necessarily 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.

Original:
   This would often be associated with the use of delegate
   certificates [RFC9060] for the signing of calls by the calling party
   directly as an example, even though the "authorized party" is not
   necessarily the subject of a STIR certificate.

Perhaps:
   For example, this may be used with delegate certificates [RFC9060]
   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 that there should always be where both "rcd" and "rcdi" claims should always be included in the PASSporT, the certificate JWT Claims Constraint extension MUST <bcp14>MUST</bcp14> include both of the following:</t>

<t><list style="symbols">
  <t>a
        <ul spacing="normal">
          <li>a "mustInclude" for the "rcd" claim, which simply constrains the fact that an "rcd" must be included</t>
  <t>a included</li>
          <li>a "mustInclude" for the "rcdi" claim and a "permittedValues" equal to the created "rcdi" claim value string.</t>
</list></t> string.</li>
        </ul>
        <t>Note that optionally the "rcd" claims may be included in the "permittedValues" however "permittedValues"; however, it is recognized that this may be redundant with the "rcdi" permittedValues because the "rcdi" digest will imply the content of the "rcd" claims themselves.</t>
        <t>The "permittedValues" for the "rcdi" claims (or "rcd" claims more generally) may contain multiple entries, entries to support the case where the certificate holder is authorized to use different sets of rich call data.</t> RCD.</t>
      </section>
    </section>
    <section anchor="crn_define"><name>PASSporT anchor="crn_define">
      <name>PASSporT "crn" claim Claim - Call Reason Definition and Usage</name>
<!--[rfced] May we update these section titles to make them parallel
and simplified?

Original:
   5.  PASSporT Claim "rcd" Definition and Usage
   6.  "rcdi" RCD Integrity Claim Definition and Usage
   7.  PASSporT "crn" claim - Call Reason Definition and Usage

Option A:
   5.  PASSporT Claim "rcd" Definition and Usage
   6.  PASSporT Claim "rcdi" Definition and Usage
   7.  PASSporT Claim "crn" Definition and Usage

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="I-D.ietf-sipcore-callinfo-rcd"/> target="RFC9796"/> and corresponding to the "call-reason" parameter for the Call-Info header. This claim is optional.</t>

<figure><artwork><![CDATA[
      <sourcecode type="json"><![CDATA[
Example "crn" claim with "rcd":

"crn" : "For your ears only",
"rcd": { "nam": "James Bond",
         "jcl": "https://example.org/james_bond.json"}
]]></artwork></figure>
]]></sourcecode>
      <section anchor="jwt-constraint-for-crn-claim"><name>JWT anchor="jwt-constraint-for-crn-claim">
        <name>JWT Constraint for "crn" claim</name> Claim</name>
<!--[rfced] There is one instance of "JWT Constraints" (plural) in this
document; should it be "JWT Claim Constraints" to match usage elsewhere
within this document?

Original:
   The integrity of the "crn" claim contents can optionally be protected
   by the authoritative certificate issuer using JWT Constraints in the
   certificate.
-->
        <t>The integrity of the "crn" claim contents can optionally be protected by the 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 indicates that a "crn" claim must always be present and is RECOMMENDED <bcp14>RECOMMENDED</bcp14> to be included by the certificate issuer. If the signer of the "crn" claim 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 RECOMMENDED <bcp14>RECOMMENDED</bcp14> to be included by the certificate issuer.</t>
      </section>
    </section>
    <section anchor="rich-call-data-claims-usage-rules"><name>Rich 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"?

Original:
   ... in which case the PASSporT
   claims MUST contain at least one or both an "rcd" or "crn" claim.

Perhaps:
   In that case,
   the PASSporT MUST contain at least one "rcd" or "crn" claim (or both).
-->
      <t>The "rcd" or "crn" claims MAY <bcp14>MAY</bcp14> appear in any PASSporT claims object as optional elements. The creator of a PASSporT MAY <bcp14>MAY</bcp14> also add a PASSporT extension ("ppt") value, defined in <xref target="RFC8225"/> Section 8.1, section="8.1" target="RFC8225" sectionFormat="comma"/>, of "rcd" to the header of a PASSporT as well, in which case PASSporT. In that case, the PASSporT claims MUST <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>

<figure><artwork><![CDATA[
      <sourcecode type=""><![CDATA[
{ "typ":"passport",
  "ppt":"rcd",
  "alg":"ES256",
  "x5u":"https://www.example.com/cert.cer" }
]]></artwork></figure>
]]></sourcecode>
      <t>The PASSporT claims object contains the "rcd" key with its corresponding value. The value of "rcd" is an array of JSON objects, of which one, the "nam" key and value, is mandatory.</t>
      <t>After the header and claims PASSporT objects have been constructed, their signature is computed normally per the guidance in <xref target="RFC8225"/>.</t>
      <section anchor="rcd_passport_verification"><name>"rcd" anchor="rcd_passport_verification">
        <name>"rcd" PASSporT Verification</name>
        <t>A verifier that successfully verifies a PASSportT PASSporT that contains an "rcd" claim MUST <bcp14>MUST</bcp14> ensure the following about the PASSporT:</t>

<t><list style="symbols">
  <t>it
        <ul spacing="normal">
          <li>It has a valid signature per the verification procedures detailed in <xref target="RFC8225"/></t>
  <t>it target="RFC8225"/>.</li>
          <li>It abides by all rules set forth in the proper construction of the claims defined in <xref target="rcd_define"/> of this document</t>
  <t>it target="rcd_define"/>.</li>
          <li>It abides by JWT Claims Constraint rules defined in <xref target="RFC8226"/> Section 8 section="8" target="RFC8226" sectionFormat="comma"/> or extended in by <xref target="RFC9118"/> if present in the certificate used to compute the signature in the PASSporT</t>
</list></t> PASSporT.</li>
        </ul>
        <t>In addition addition, if the "iss" claim is included in the PASSPorT, PASSporT, verification should follow procedures described in <xref target="thirdsignverify"/>.</t>
        <t>Consistent with the verification rules of PASSporTs more generally <xref target="RFC8225"/>, if any of the above criteria is not met, relying parties MUST NOT <bcp14>MUST NOT</bcp14> use any of the claims in the PASSporT.</t>
      </section>
      <section anchor="rcdi-integrity-verification"><name>"rcdi" anchor="rcdi-integrity-verification">
        <name>"rcdi" Integrity Verification</name>
        <t>When the "rcdi" claim exists, the verifier should verify the digest for each JSON pointer key.  Any digest string that doesn't match a generated digest MUST <bcp14>MUST</bcp14> be considered a failure of the verification of the content referenced by the JSON pointer.</t>
        <t>If there is any issue with completing the integrity verification procedures for referenced external content, including HTTP or HTTPS errors, the referenced content MUST <bcp14>MUST</bcp14> be considered not verified.  This SHOULD NOT however  However, this <bcp14>SHOULD NOT</bcp14> impact the result of base PASSporT verification for claims content that is directly included in the claims of the PASSporT.</t>
        <t>As a potential optimization of verification procedure, procedures, an entity that does not otherwise need to dereference a URI from the "rcd" claim for display to end-user the end user is NOT RECOMMENDED <bcp14>NOT RECOMMENDED</bcp14> to unnecessarily dereference the URI solely to perform integrity verification.</t>
      </section>
      <section anchor="example-rcd-passports"><name>Example anchor="example-rcd-passports">
        <name>Example "rcd" PASSporTs</name>
        <t>An example of a "nam" only "nam"-only PASSporT claims object is shown next (with line breaks for readability only).</t>

<figure><artwork><![CDATA[
        <sourcecode type=""><![CDATA[
{  "orig":{"tn":"12025551000"},
   "dest":{"tn":["12025551001"]},
   "iat":1443208345,
   "rcd":{"nam":"James Bond"} }
]]></artwork></figure>
]]></sourcecode>
        <t>An example of a "nam", "apn", and "icn" using an https URI PASSporT claims object is shown next (with line breaks for readability only). Note, in this example, there is no integrity protection over the "icn" element in the "rcd" claim.</t>

<figure><artwork><![CDATA[
        <sourcecode type=""><![CDATA[
{  "orig":{"tn":"12025551000"},
   "dest":{"tn":["12155551001"]},
   "iat":1443208345,
   "rcd":{
     "apn":"12025559990",
     "icn":"https://example.com/photos/quartermaster-256x256.png",
     "nam":"Her Majesty's Secret Service" } }
]]></artwork></figure>
]]></sourcecode>
        <t>An example of a "nam", "apn", and "icn" using data URI PASSporT claims object is shown next (with line breaks for readability only). Note, in this example, the "icn" data is incorporated directly in the "rcd" claim claim, and therefore separate integrity protection is not required.</t>

<figure><artwork><![CDATA[
        <sourcecode type=""><![CDATA[
{  "orig":{"tn":"12025551000"},
   "dest":{"tn":["12155551001"]},
   "iat":1443208345,
   "rcd":{
     "apn":"12025559990",
     "icn":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAY
       AAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OH
       wAAAABJRU5ErkJggg==",
     "nam":"Her Majesty's Secret Service" } }
]]></artwork></figure>
]]></sourcecode>
        <t>An example of an "rcd" claims object that includes the "jcd" and also contains URI references to content content, which requires require the inclusion of an "rcdi" claim and corresponding digests. Note, in this example, the "rcdi" claim includes integrity protection of the URI referenced URI-referenced content.</t>

<figure><artwork><![CDATA[
        <sourcecode type=""><![CDATA[
{
  "crn": "Rendezvous for Little Nellie",
  "orig": { "tn": "12025551000"},
  "dest": { "tn": ["12155551001"]},
  "iat": 1443208345,
  "rcd": {
    "jcd": ["vcard",
    [ ["version",{},"text","4.0"],
      ["fn",{},"text","Q Branch"],
      ["org",{},"text","MI6;Q Branch Spy Gadgets"],
      ["photo",{},"uri","https://example.com/photos/q-256x256.png"],
      ["logo",{},"uri","https://example.com/logos/mi6-256x256.jpg"],
      ["logo",{},"uri","https://example.com/logos/mi6-64x64.jpg"]
    ] ],
    "nam": "Q Branch Spy Gadgets"
  },
  "rcdi": {
   "/jcd/1/3/3":"sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4",
   "/jcd/1/4/3":"sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI",
   "/jcd/1/5/3":"sha256-GKNxxqlLRarbyBNh7hc/4lbZAdK6B0kMRf1AMRWPkSo"
  }
}
]]></artwork></figure>
]]></sourcecode>
<!--[rfced] Do both of these sentences refer to the example that follows?  Perahps the text can be clarified?

Original:
    In an example PASSporT, where a jCard is linked via HTTPS URL using
   "jcl", a jCard file served at a particular URL.

   An example jCard JSON file hosted at the example web address of
   https://example.com/qbranch.json is shown as follows:

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>

<figure><artwork><![CDATA[
        <sourcecode type="json"><![CDATA[
["vcard",
  [ ["version",{},"text","4.0"],
    ["fn",{},"text","Q Branch"],
    ["org",{},"text","MI6;Q Branch Spy Gadgets"],
    ["photo",{},"uri","https://example.com/photos/q-256x256.png"],
    ["logo",{},"uri","https://example.com/logos/mi6-256x256.jpg"],
    ["logo",{},"uri","https://example.com/logos/mi6-64x64.jpg"]
  ]
]
]]></artwork></figure>
]]></sourcecode>
        <t>For the above referenced jCard, the corresponding PASSporT claims object would be as follows:</t>

<figure><artwork><![CDATA[
        <sourcecode type=""><![CDATA[
{
  "crn": "Rendezvous for Little Nellie",
  "orig": {"tn": "12025551000"},
  "dest": {"tn": ["12155551001"]},
  "iat": 1443208345,
  "rcd": {
    "nam": "Q Branch Spy Gadgets",
    "jcl": "https://example.com/qbranch.json"
  },
  "rcdi": {
   "/jcl":"sha256-qCn4pEH6BJu7zXndLFuAP6DwlTv5fRmJ1AFkqftwnCs",
   "/jcl/1/3/3":"sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4",
   "/jcl/1/4/3":"sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI",
   "/jcl/1/5/3":"sha256-GKNxxqlLRarbyBNh7hc/4lbZAdK6B0kMRf1AMRWPkSo"
  }
}
]]></artwork></figure>
]]></sourcecode>
        <t>An example "rcd" PASSporT that uses "nam" and "icn" keys with "rcdi" for calling name and referenced icon image content:</t>

<figure><artwork><![CDATA[
        <sourcecode type=""><![CDATA[
{
  "crn": "Rendezvous for Little Nellie",
  "orig": {"tn": "12025551000"},
  "dest": {"tn": ["12155551001"]},
  "iat": 1443208345,
  "rcd": {
    "nam": "Q Branch Spy Gadgets",
    "icn": "https://example.com/photos/q-256x256.png"
  },
  "rcdi": {
    "/nam": "sha256-sM275lTgzCte+LHOKHtU4SxG8shlOo6OS4ot8IJQImY",
    "/icn": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4"
  }
}
]]></artwork></figure>
]]></sourcecode>
      </section>
    </section>
    <section anchor="compact-form-of-rcd-passport"><name>Compact form anchor="compact-form-of-rcd-passport">
      <name>Compact Form of "rcd" PASSporT</name>
      <section anchor="compact-form-of-the-rcd-passport-claim"><name>Compact form anchor="compact-form-of-the-rcd-passport-claim">
        <name>Compact Form of the "rcd" PASSporT claim</name> Claim</name>
        <t>The specific usage of the compact form of an "rcd" PASSporT claim, defined in <xref target="RFC8225"/> Section 7, section="7" target="RFC8225" sectionFormat="comma"/>, has some restrictions that will be enumerated below, but it mainly follows standard PASSporT compact form procedures. Compact form only provides the signature from the PASSporT, requiring the re-construction reconstruction of the other PASSporT claims from the SIP header fields as discussed in <xref target="RFC8224"/> Section 4.1.</t> section="4.1" target="RFC8224"/>.</t>
<!--[rfced] Please clarify this sentence. Specifically,
what is "leading to too restrictive a set of constraints"?
Also, please consider starting with "The claims" or similar
to make a clearer break with the preceding sentence (which ends
with the example of the empty string "".).

Original:
   "jcl" and "jcd" MUST NOT be used with compact form due to
   integrity rules and URI reference rules in this document leading to
   too restrictive of a set of constraints.

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 re-construction reconstruction of the "nam" claim, if using the SIP protocol, should use the 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 used; otherwise, the string should be an empty string, e.g., "". "jcl" and "jcd" MUST NOT <bcp14>MUST NOT</bcp14> be used with compact form due to integrity rules and URI reference rules 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 guidance for other protocol usage.</t>
      </section>
      <section anchor="compact-form-of-the-rcdi-passport-claim"><name>Compact form anchor="compact-form-of-the-rcdi-passport-claim">
        <name>Compact Form of the "rcdi" PASSporT claim</name> Claim</name>
        <t>The use of the compact form of a PASSporT using an "rcdi" claim is not supported, so if "rcdi" is required required, compact form MUST NOT <bcp14>MUST NOT</bcp14> be used.</t>
      </section>
      <section anchor="compact-form-of-the-crn-passport-claim"><name>Compact form anchor="compact-form-of-the-crn-passport-claim">
        <name>Compact Form of the "crn" PASSporT claim</name> Claim</name>
        <t>Compact form of a "crn" PASSporT claim shall be re-constructed reconstructed using the "call-reason" parameter of a Call-Info header as defined by <xref target="I-D.ietf-sipcore-callinfo-rcd"/>.</t> target="RFC9796"/>.</t>
      </section>
    </section>
    <section anchor="parties"><name>Third-Party anchor="parties">
      <name>Third-Party Uses</name>
      <t>While rich data about the call can be provided by an originating authentication 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 STIR Authentication Service, generating its own PASSporT, and that PASSporT could be attached to a call by either the originating or terminating side. This third-party 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 call lacks a first-party PASSporT that assures verification services that the calling party number is not spoofed.
<!--[rfced] What is "It" in "It is intended"? The third-party PASSporT?
(The preceding sentence is included for context.)

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 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 calling party, and potentially other helpful information could also be passed over 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 over the 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. cases <xref target="RFC8816"/>. 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 the SIP protocol for this example: 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 verification service implemented at a SIP proxy server receives this request, request and determines that the signature is valid, it might query a third-party service that 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 Identity header field to the request for the PASSporT object provided by the third-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 equivelent string-equivalent to, the display name in the INVITE, then the name would presumably be rendered to the 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 originating 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-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 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 crowdsourced reputation scores might derive from third parties. When those elements are present, they MUST <bcp14>MUST</bcp14> be in a third-party "rcd" PASSporT using the "iss" claim described in the next section.</t>
      <section anchor="thirdsign"><name>Signing anchor="thirdsign">
        <name>Signing as a Third Party</name>
        <t>A third-party PASSporT contains an "iss" element to distinguish its PASSporTs from first-party PASSporTs. Third-party "rcd" PASSporTs are signed with credentials that do not have authority over the identity that appears in the "orig" element of the PASSporT claims. The presence of "iss" signifies that a different category of credential is being used to sign a PASSporT than the <xref target="RFC8226"/> certificates (as defined in <xref target="RFC8226"/>) used to sign STIR calls; it is instead a certificate that identifies the source of the "rcd" data. How those credentials are issued and managed is outside the scope of this document; however, the value of "iss" however MUST <bcp14>MUST</bcp14> reflect the Subject of the certificate used to sign a third-party PASSporT. The explicit mechanism for reflecting the subject Subject field of the certificate is out of scope of this document and left to the certificate governance policies that define how to map the "iss" value in the PASSporT to the subject Subject field in the certificate. Relying parties in STIR have always been left to make their own authorization decisions about whether to trust the signers of PASSporTs, and PASSporTs; in the third-party case, where an entity has explicitly queried 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 Third Party issued PASSporT claims object issued by a third party is as follows.</t>

<figure><artwork><![CDATA[
        <sourcecode type=""><![CDATA[
{  "orig":{"tn":"12025551000"},
   "dest":{"tn":["12025551001"]},
   "iat":1443208345,
   "iss":"Zorin Industries",
   "rcd":{"nam":"James St. John Smythe"} }
]]></artwork></figure>
]]></sourcecode>
      </section>
      <section anchor="thirdsignverify"><name>Verification using Third Party anchor="thirdsignverify">
        <name>Verification Using Third-Party RCD</name>
        <t>The third-party "rcd" PASSporT cases must be considered in the verification service, as an attacker could attempt to cut-and-paste cut and paste such a third-party PASSporT into a SIP request in an effort to get the terminating user agent to render the display name or confidence values it contains to a call that should have no such assurance. Following the rules of <xref target="RFC8225"/> and in particular if there is are multiple identity headers, for example with headers (as in the case of the inclusion of an "rcd" and "shaken" PASSporTs from two different signing providers, providers), a verification service MUST <bcp14>MUST</bcp14> determine that the calling party number shown in the "orig" of the "rcd" PASSporT corresponds to the calling party number of the call it has received, and that the "iat" field of the "rcd" PASSporT is within the date interval that the verification service would ordinarily accept for a PASSporT. It is possible that if there is multiple identity headers are present, only the verified identity information should be considered when presenting call information to an end user.</t>
        <t>Verification services may alter their authorization policies for the credentials accepted to sign PASSporTs when third parties generate PASSporT objects, per <xref target="thirdsign"/>. This may include accepting a valid signature over a PASSporT even if it is signed with a credential that does not attest authority over the identity in the "orig" claim of the PASSporT, provided that the verification service has some other reason to trust the signer. No further guidance on verification service authorization policy is given here.</t>
      </section>
    </section>
    <section anchor="loa"><name>Levels anchor="loa">
      <name>Levels of Assurance</name>

<t>As

<!--[rfced] Please clarify "providers that are indirectly or delegated
authority to sign PASSporTs". What is the intended meaning? Is a word missing?

Original:
   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 directly authorized to sign PASSporTs in the STIR ecosystem or third-party providers that are indirectly or delegated authority to sign PASSporTs. Relying parties could benefit from an additional claim that indicates the identification, in the form of a uniquely identifiable name, of the attesting party to the caller. Even in first party first-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 the number to an enterprise, in which case the CSP might have little insight into the caller's name. In third party third-party cases, a caller's name could be determined from any number of data sources, on a spectrum between public data scraped from web searches to a direct business relationship to the caller. As multiple PASSporTs 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 that carry "rcd" data are RECOMMENDED <bcp14>RECOMMENDED</bcp14> to also carry an indication of the identity of the generator of the PASSporT in the form of the 'iss' claim.</t>
    </section>
    <section anchor="use"><name>Use anchor="use">
      <name>Use of "rcd" PASSporTs in SIP</name>
<!--[rfced] Please note that we have removed "and" from the sentence below.  Please let us know if this incorrect.

Original:
   This section documents SIP-specific usage for "rcd" PASSporTs and in
   the SIP Identity header field value.

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 the SIP Identity header field value. Other using protocols of using PASSporT may define their own usages guidance for the "rcd" PASSporTs.</t>
      <section anchor="authentication-service-behavior-for-sip-protocol"><name>Authentication anchor="authentication-service-behavior-for-sip-protocol">
        <name>Authentication Service Behavior for SIP protocol</name> Protocol</name>
        <t>An authentication service creating a PASSporT containing an "rcd" claim MAY <bcp14>MAY</bcp14> include a PASSporT extension ("ppt" value) of "rcd" or not. "rcd". Third-party authentication services following the behavior in <xref target="thirdsign"/> MUST <bcp14>MUST</bcp14> include a PASSporT extension value of "rcd". If the PASSporT extension does contain an "rcd", then any SIP authentication services MUST <bcp14>MUST</bcp14> add a PASSporT extension "ppt" parameter 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[
        <sourcecode type=""><![CDATA[
Identity: sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9
       dlxkWzoeU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgt
       w0Lu5csIppPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs=;
       info=<https://biloxi.example.org/biloxi.cer>;alg=ES256;
       ppt="rcd"
]]></artwork></figure>
]]></sourcecode>
        <t>This document assumes that by default when using the SIP protocol, an authentication service determines the value of "rcd", specifically only for the "nam" key value, from the display-name component of the From header field value of the request, alternatively request. Alternatively, for some calls this may come from the P-Asserted-ID header. It is however a matter of authentication service policy to decide how it populates the value of the "nam" key, which MAY <bcp14>MAY</bcp14> also match or be determined by other fields in the request, from customer profile data, data or from access to external services. If the authentication service generates an "rcd" claim containing "nam" with a value that is not string equivalent string-equivalent to the From header field display-name value, it MUST <bcp14>MUST</bcp14> use the full form of the PASSporT object in SIP.</t>
        <t>In addition, {I-D.ietf-sipcore-callinfo-rcd}} <xref target="RFC9796"/>  defines a Call-Info header field that MAY <bcp14>MAY</bcp14> be used as a source of RCD information that an authentication services service uses to construct the appropriate PASSporT RCD claim types used.</t>
        <t>Note also that, as a best practice, the accuracy and legitimacy of Rich Call Data information that is included in the claims is RECOMMENDED <bcp14>RECOMMENDED</bcp14> to follow a trust framework that is out of scope of this document. As with telephone numbers for the STIR framework framework, the authentication of Rich Call Data should follow some type of vetting process by an entity that is authoritative over determining the accuracy and legitimacy of that information. This includes the mechanisms for how and from whom that information is received by the authentication service. For example, the general use of Call-Info via SIP as a trusted source of RCD information on the authentication side is NOT RECOMMENDED.</t> <bcp14>NOT RECOMMENDED</bcp14>.</t>
      </section>
      <section anchor="verification-service-behavior-for-sip-protocol"><name>Verification anchor="verification-service-behavior-for-sip-protocol">
        <name>Verification Service Behavior for SIP protocol</name> Protocol</name>
        <t><xref target="RFC8224"/> Section 6.2 section="6.2" target="RFC8224" sectionFormat="comma"/>, Step 5 requires that future specifications defining PASSporT extension ("ppt") values describe any additional verifier behavior specific to the SIP protocol. The general verification proceedures procedures defined 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>
        <t>If the PASSporT is in compact form, then the verification service MUST <bcp14>MUST</bcp14> extract the display-name from the From header field value, if any, and MUST <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 there exists a Call-Info header field as defined in <xref target="I-D.ietf-sipcore-callinfo-rcd"/>, target="RFC9796"/>, the "jcard" JSON object value MUST <bcp14>MUST</bcp14> be used to construct the "jcd" key value when it recomputes the header and claims of the PASSporT object. If the signature validates over the recomputed object, then the verification is considered successful.</t>
<!--[rfced] Is this a list of five elements? If so, may it be rephrased
as follows or otherwise?

Original:
   Similarly, "jcd" or "jcl" jcard information, "icn", "apn", or "crn"
   can be optionally, based on local policy for devices that support it,
   used to populate a Call-Info header field following the format of
   [I-D.ietf-sipcore-callinfo-rcd].

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 "rcd", then the verification service MUST <bcp14>MUST</bcp14> extract the value associated with the "rcd" claim "nam" key in the object. If the PASSporT signature is verified successfully successfully, then the verification service MUST <bcp14>MUST</bcp14> additionally compare the string value of the "rcd" claim "nam" key value with the From header 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 specification (e.g. (e.g., P-Asserted-Identity) as discussed in <xref target="RFC8224"/>. Similarly, "jcd" or "jcl" jcard jCard information, "icn", "apn", or "crn" can be optionally, based on local policy for devices that support it, used to populate a Call-Info header field following the format of <xref target="I-D.ietf-sipcore-callinfo-rcd"/>. target="RFC9796"/>. If future defined PASSporT RCD claims types defined in the future are present, they should follow similar defined proceedures and policies.</t>
        <t>The behavior of a SIP UAS User Agent Server (UAS) upon receiving an INVITE 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 while 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-extensions"><name>Using anchor="using-rcd-rcdi-crn-as-additional-claims-to-other-passport-extensions">
      <name>Using "rcd", "rcdi", and "crn" as additional claims Additional Claims to other Other PASSporT extensions</name> 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 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 communications is supporting the authentication service for the calling identity and 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 authenticates the calling identity.</t>
      <section anchor="procedures-for-applying-rcd-claims-as-claims-only"><name>Procedures anchor="procedures-for-applying-rcd-claims-as-claims-only">
        <name>Procedures for applying Applying RCD claims Claims as claims only</name> Claims Only</name>
        <t>For a given PASSporT using some other extension than "rcd", the Authentication Service MAY <bcp14>MAY</bcp14> additionally include the "rcd" defined in {#rcd_define}, <xref target="rcd_define"/>, "rcdi" defined in {#rcdi_define}, <xref target="rcdi_define"/>, and "crn" defined in {#crn_define} <xref target="crn_define"/> claims. This would result in a set of claims that correspond to the original intended extension with the addition of the "rcd" claim.</t>
        <t>The Verification verification service that receives the PASSporT, if it supports this specification and chooses to, should interpret the "rcd" claim as simply just an additional 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 anchor="example-for-applying-rcd-claims-as-claims-only">
        <name>Example for applying Applying RCD claims Claims as claims only</name> Claims Only</name>
        <t>In the case of <xref target="RFC8588"/> target="RFC8588"/>, which is the PASSporT extension supporting the SHAKEN Signature-based Handling of Asserted information using toKENs (SHAKEN) specification <xref target="ATIS-1000074.v002"/>, a common case is for an Authentication authentication service to co-exist coexist in a CSP network along with the authority over the calling name used for the call. Rather than require two identity headers, the CSP Authentication Service 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[
        <sourcecode type=""><![CDATA[
Protected Header
{
   "alg":"ES256",
   "typ":"passport",
   "ppt":"shaken",
   "x5u":"https://cert.example.org/passport.cer"
}
Payload
{
   "attest":"A",
   "dest":{"tn":["12025551001"]},
   "iat":1443208345,
   "orig":{"tn":"12025551000"},
   "origid":"123e4567-e89b-12d3-a456-426655440000",
   "rcd":{"nam":"James Bond"}
}
]]></artwork></figure>
]]></sourcecode>
        <t>A Verification Service verification service that understands and supports claims defined in the "rcd" and "shaken" PASSporT extensions is able to receive the above PASSporT and interpret both the "shaken" claims as well as the "rcd" defined claims.</t>
        <t>If the Verification Service verification service only understands the "shaken" PASSporT extension claims and doesn't support the "rcd" PASSporT extension or claims, then the "rcd" claim, claim in this example, example is used during PASSporT signature validation but is otherwise ignored and disregarded.</t>
      </section>
    </section>
    <section anchor="extend"><name>Further anchor="extend">
      <name>Further Information Associated with Callers</name>
      <t>Beyond naming information and the information that can be contained in a jCard object <xref target="RFC7095"/> object, target="RFC7095"/>, there may be additional human-readable information about the calling party that should be rendered to the end user in order to help the called party decide whether or not to pick up the phone. This is not limited to information about the caller, but caller; it includes information about the call itself, which may derive from analytics that determine based (based on call patterns or similar data data) if the call is likely to be one the called party wants to receive. Such data could include:</t>

<t><list style="symbols">
  <t>information
      <ul spacing="normal">
        <li>information related to the location of the caller, or</t>
  <t>any or</li>
        <li>any organizations or institutions that the caller is associated with, or even categories of institutions (is (whether this a government agency, or a bank, or what have you), or</t>
  <t>hyperlinks or</li>
        <li>hyperlinks to images, such as logos or pictures of faces, or to similar external profile information, or</t>
  <t>information or</li>
        <li>information processed by an application before rendering it to a user, like social networking data that shows that an unknown caller is a friend-of-a-friend, or reputation scores derived from crowdsourcing, or confidence scores based on broader analytics about the caller and callee.</t>
</list></t> callee.</li>
      </ul>
      <t>All of these data elements would benefit from the secure attestations provided by the STIR and PASSporT frameworks. A new IANA registry has been defined to hold potential values of the "rcd" array; see <xref target="rcdtypes"/>. Specific extensions to the "rcd" PASSporT claim are left for future specification.</t>
      <t>There is are a few ways RCD can be extended in the future, future; jCard is an extensible object and the key/values in the RCD claim object can also be extended. General guidance for future extensibility that were was followed by the authors is that jCard generally typically should refer to data that references the caller as an individual or entity, where whereas other claims, such as "crn" "crn", refer to data regarding the specific call. There may be other considerations discovered in the future, but this logical grouping of data should be followed to the extent possible should be followed for future extensibility.</t>
    </section>
    <section anchor="acknowledgements"><name>Acknowledgements</name>

<t>We would like to thank David Hancock, Robert Sparks, Russ Housley, Eric Burger, Alec Fenichel, Ben Campbell, Jack Rickard, Jordan Simpson for helpful suggestions, review, and comments.</t>

</section>
<section anchor="IANA"><name>IANA anchor="IANA">
      <name>IANA Considerations</name>
      <section anchor="json-web-token-claim"><name>JSON anchor="json-web-token-claim">
        <name>JSON Web Token Claim</name>

<t>This document requests that the
        <t>Per this document, IANA add has added three new claims to the JSON "JSON Web Token Claims Claims" registry as defined in <xref target="RFC7519"/>.</t>

<t>Claim Name: "rcd"</t>

<t>Claim Description: Rich
<dl spacing="compact" newline="false">
        <dt>Claim Name:</dt><dd>"rcd"</dd>
        <dt>Claim Description:</dt><dd>Rich Call Data Information</t>

<t>Change Controller: IESG</t>

<t>Specification Document(s): [RFCThis]</t>

<t>Claim Name: "rcdi"</t>

<t>Claim Description: Rich Information</dd>
        <dt>Change Controller:</dt><dd>IETF</dd>
        <dt>Reference:</dt><dd>RFC 9795</dd>
</dl>
<dl spacing="compact" newline="false">
        <dt>Claim Name:</dt><dd>"rcdi"</dd>
        <dt>Claim Description:</dt><dd>Rich Call Data Integrity Information</t>

<t>Change Controller: IESG</t>

<t>Specification Document(s): [RFCThis]</t>

<t>Claim Name: "crn"</t>

<t>Claim Description: Call Reason</t>

<t>Change Controller: IESG</t>

<t>Specification Document(s): [RFCThis]</t> Information</dd>
        <dt>Change Controller:</dt><dd>IETF</dd>
        <dt>Reference:</dt><dd>RFC 9795</dd>
</dl>
<dl spacing="compact" newline="false">
        <dt>Claim Name:</dt><dd>"crn"</dd>
        <dt>Claim Description:</dt><dd>Call Reason</dd>
        <dt>Change Controller:</dt><dd>IETF</dd>
        <dt>Reference:</dt><dd>RFC 9795</dd>
</dl>
      </section>
      <section anchor="personal-assertion-token-passport-extensions"><name>Personal anchor="personal-assertion-token-passport-extensions">
        <name>Personal Assertion Token (PASSporT) Extensions</name>

<t>This document requests that the
        <t>Per this document, IANA add has added a new entry to the Personal "Personal Assertion Token (PASSporT) Extensions Extensions" registry for the type "rcd" which is specified in [RFCThis].</t> this document.</t>
      </section>
      <section anchor="rcdtypes"><name>PASSporT anchor="rcdtypes">
        <name>PASSporT RCD Claim Types</name>

<t>This document requests that the IANA create
        <t>IANA has created a new registry for PASSporT "PASSporT RCD claim types. This new Claim Types" registry should be added to in the "Personal Assertion Token (PASSporT)" registry group. Registration of new PASSporT RCD claim types shall be under the Specification Required policy.</t> policy <xref target="RFC8126"/>.</t>
        <t>This registry is to be initially populated with five claim name values, "nam", "apn", "icn", "jcd", and "jcl", which are specified in [RFCThis]. This is a two column registry with column1 = this document. The columns are "Name" and column2 = "Reference Document". "Reference". Any new registrations should consist of only of the name and the reference document. There is an obligation for expert review, 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 usage or interpretation of the other existing types in the registry.</t>
      </section>
    </section>
    <section anchor="Security"><name>Security anchor="Security">
      <name>Security Considerations</name>
      <t>The process of signing information contained in a "rcd" PASSporT, whether PASSporT (whether the identities, identifiers, alternate identities or identifiers, images, logos, physical addresses, or otherwise otherwise) should follow some vetting process in which an authoritative entity should follow follows an appropriate consistent policy defined and governed by the eco-system ecosystem using RCD and the STIR framework. This can be of many forms, depending on the setup and constraints of the policy requirements of the eco-system ecosystem, and is therefore out-of-scope out of scope of this document. However, the general chain of trust that signers of "rcd" PASSporT are either directly authoritative or have been delegated authority through certificates using JWT Claim Constraints and integrity mechanisms defined in this and related documents is critical to maintain the integrity of the eco-system ecosystem utilizing this and other STIR related STIR-related specifications.</t>
      <t>Revealing information such as the name, location, and affiliation of a person necessarily entails certain privacy risks. Baseline PASSporT has no particular confidentiality requirement, as the information it signs in many current base communications protocols, for example SIP, protocols (for example, SIP) is information that is carried in the clear anyway. Transport-level security can hide those SIP fields from eavesdroppers, and the same confidentiality mechanisms would protect any PASSporT(s) carried in SIP.</t>
      <t>The dereferencing and download of any RCD URI linked URI-linked resources as part of verification either in-network or on device could provide some level of information about calling patterns, so this should be considered when making these resources available.</t>
      <t>The use of JWTClaimConstraints, a mechanism defined in <xref target="RFC8226"/> and extended in <xref target="RFC9118"/> target="RFC9118"/>, to constrain any of the RCD information in the public certificate by including that information in the certificate, depending on the availability in the deployment of the PKI system, may present a privacy issue. The use of the "rcdi" claim and digests for representing JWT claim contents is RECOMMENDED <bcp14>RECOMMENDED</bcp14> for the prevention of the exposure of that information through the certificates which that are often publically publicly accessible and available.</t>
      <t>Since computation of "rcdi" digests for URIs requires the loading of referenced content, it would be best practice to validate that content at the creation of the "rcdi" or corresponding JWT claim constraint value by checking for content that may cause issues for verification services or that doesn't follow the behavior defined in this document, e.g., unreasonably sized data, the inclusion of recursive URI references, etc. Along the same lines, the verification service should also use precautionary best practices to avoid attacks when accessing URI linked URI-linked content.</t>
      <t>As general guidance, the use of URLs and URIs that reference potentially dangerous or intentionally harmful content should be considered in implimenting implementing this specification.  <xref target="RFC3986"/> Section 7 section="7" target="RFC3986" sectionFormat="comma"/> contains good additional guidance to consider when communicating or dereferencing URLs and URIs.</t>
      <section anchor="the-use-of-jwt-claim-constraints-in-delegate-certificates-to-exclude-unauthorized-claims"><name>The use anchor="the-use-of-jwt-claim-constraints-in-delegate-certificates-to-exclude-unauthorized-claims">
        <name>Use of JWT Claim Constraints in delegate certificates Delegate Certificates to exclude unauthorized claims</name> Exclude Unauthorized Claims</name>
        <t>While this can apply to any PASSporT that is signed with a STIR Delegate Certificates Certificate <xref target="RFC9060"/>, it is important to note that when constraining PASSporTs to include specific claims or contents of claims, it is also important to consider potential attacks by non-authorized signers that may include other potential PASSporT claims that weren't originally vetted by the authorized entity providing the delegate certificate. The use of JWT claims constraints as (as defined in <xref target="RFC9118"/> 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 title='Normative References'>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>

<!-- [I-D.ietf-sipcore-callinfo-rcd] companion document RFC 9796 -->
<reference anchor='I-D.ietf-sipcore-callinfo-rcd' target='https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-callinfo-rcd-06'> anchor="RFC9796" target="https://www.rfc-editor.org/info/rfc9796">
<front>
<title>SIP Call-Info Parameters for Rich Call Data</title>
<author initials='C' surname='Wendt' fullname='Chris Wendt' initials='C.' surname='Wendt'>
         <organization>Somos Inc.</organization> Wendt'>
<organization />
</author>
<author initials='J' surname='Peterson' fullname='Jon Peterson' initials='J.' surname='Peterson'>
         <organization>Neustar Inc.</organization> Peterson'>
<organization />
</author>
<date day='3' month='June' year='2023'/>
      <abstract>
	 <t>   This document describes a SIP Call-Info header field usage defined to
   include Rich Call Data (RCD) associated with the identity of the
   calling party that can be rendered to a called party for providing
   more descriptive information about the caller or more details about
   the reason for the call.  This includes extended information about
   the caller beyond the telephone number such as a calling name, a logo
   or photo representing the caller or a jCard object representing the
   calling party.  The elements defined for this purpose are intended to
   be extensible to accommodate related information about calls that
   helps people decide whether to pick up the phone and with the use of
   icon and newly defined jCard and other elements to be compatible and
   complimentary with the STIR/PASSporT Rich Call Data framework.

	 </t>
      </abstract> year='2025' month='May'/>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-sipcore-callinfo-rcd-06'/> name="RFC" value="9796"/>
<seriesInfo name="DOI" value="10.17487/RFC9796"/>
</reference>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3261.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6234.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6901.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7095.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7519.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8224.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8225.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8226.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8588.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9060.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9118.xml"/>

        <reference anchor='RFC3261' target='https://www.rfc-editor.org/info/rfc3261'> anchor="IANA-COSE-ALG" target="https://www.iana.org/assignments/cose">
          <front>
<title>SIP: Session Initiation Protocol</title>
<author fullname='J. Rosenberg' initials='J.' surname='Rosenberg'><organization/></author>
<author fullname='H. Schulzrinne' initials='H.' surname='Schulzrinne'><organization/></author>
<author fullname='G. Camarillo' initials='G.' surname='Camarillo'><organization/></author>
<author fullname='A. Johnston' initials='A.' surname='Johnston'><organization/></author>
<author fullname='J. Peterson' initials='J.' surname='Peterson'><organization/></author>
<author fullname='R. Sparks' initials='R.' surname='Sparks'><organization/></author>
<author fullname='M. Handley' initials='M.' surname='Handley'><organization/></author>
<author fullname='E. Schooler' initials='E.' surname='Schooler'><organization/></author>
<date month='June' year='2002'/>
<abstract><t>This document describes
            <title>COSE Algorithms</title>
            <author>
              <organization>IANA</organization>
            </author>
          </front>
        </reference>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>

      </references>
      <references>
        <name>Informative References</name>

        <reference anchor="TS.3GPP.24.229"
target="https://www.3gpp.org/ftp/Specs/html-info/24229.htm">
          <front>
            <title>IP multimedia call control protocol based on Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants.  These sessions include Internet telephone calls, multimedia distribution, (SIP) and multimedia conferences.  [STANDARDS-TRACK]</t></abstract> Session Description Protocol (SDP); Stage 3</title>
            <author>
              <organization abbrev="3GPP">3rd Generation Partnership Project</organization>
            </author>
            <date month="September" year="2020"/>
	  </front>
          <seriesInfo name='RFC' value='3261'/>
<seriesInfo name='DOI' value='10.17487/RFC3261'/> name="3GPP TS" value="24.229"/>
	  <refcontent>16.7.0</refcontent>
        </reference>

<reference anchor='RFC3986' target='https://www.rfc-editor.org/info/rfc3986'>
<front>
<title>Uniform Resource Identifier (URI): Generic Syntax</title>
<author fullname='T. Berners-Lee' initials='T.' surname='Berners-Lee'><organization/></author>
<author fullname='R. Fielding' initials='R.' surname='Fielding'><organization/></author>
<author fullname='L. Masinter' initials='L.' surname='Masinter'><organization/></author>
<date month='January' year='2005'/>
<abstract><t>A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource.  This specification defines

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3325.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7340.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8816.xml"/>

<!-- [rfced] Regarding [ATIS-1000074.v002], the generic URI syntax and a process for resolving URI references that might original URL provided
yields "Sorry, the document could not be in relative form, along with guidelines and security considerations for found".
We found the use following URL of URIs on the Internet.  The URI syntax defines a grammar that is a superset more recent version of all valid URIs, allowing an implementation this standard:
https://access.atis.org/higherlogic/ws/public/download/67436
(which appears to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier.  This specification does not define a generative grammar for URIs; that task is performed by the individual specifications be Version 3 of each URI scheme.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='STD' value='66'/>
<seriesInfo name='RFC' value='3986'/>
<seriesInfo name='DOI' value='10.17487/RFC3986'/>
</reference>

<reference anchor='RFC4648' target='https://www.rfc-editor.org/info/rfc4648'>
<front>
<title>The Base16, Base32, and Base64 Data Encodings</title>
<author fullname='S. Josefsson' initials='S.' surname='Josefsson'><organization/></author>
<date month='October' year='2006'/>
<abstract><t>This document describes the commonly used base 64, base 32, this standard and base was published
16 encoding schemes.  It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use August 2022). May we update this reference to that version?

Original:
   [ATIS-1000074.v002]
              ATIS/SIP Forum NNI Task Group, "Signature-based Handling
              of non-alphabet characters in encoded data, use Asserted information using toKENs (SHAKEN)
              <https://access.atis.org/apps/group_public/
              download.php/62391/ATIS-1000074.v002.pdf>", November
              2021.

Perhaps:
   [ATIS-1000074.v003]
              Alliance for Telecommunications Industry Solutions,
              "Signature-based Handling of different encoding alphabets, and canonical encodings.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4648'/>
<seriesInfo name='DOI' value='10.17487/RFC4648'/>
</reference>

<reference anchor='RFC6234' target='https://www.rfc-editor.org/info/rfc6234'>
<front>
<title>US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)</title>
<author fullname='D. Eastlake 3rd' initials='D.' surname='Eastlake 3rd'><organization/></author>
<author fullname='T. Hansen' initials='T.' surname='Hansen'><organization/></author>
<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> Asserted information using
              toKENs (SHAKEN)", August 2022,
              <https://access.atis.org/higherlogic/ws/public/
              download/67436>.
-->

        <reference anchor='RFC6901' target='https://www.rfc-editor.org/info/rfc6901'> anchor="ATIS-1000074.v002">
          <front>
<title>JavaScript Object Notation (JSON) Pointer</title>
<author fullname='P. Bryan' initials='P.' role='editor' surname='Bryan'><organization/></author>
<author fullname='K. Zyp' initials='K.' surname='Zyp'><organization/></author>
<author fullname='M. Nottingham' initials='M.' role='editor' surname='Nottingham'><organization/></author>
<date month='April' year='2013'/>
<abstract><t>JSON Pointer defines a string syntax
            <title>Signature-based Handling of Asserted information using toKENs (SHAKEN)</title>
            <author>
              <organization>Alliance for identifying a specific value within a JavaScript Object Notation (JSON) document.</t></abstract> Telecommunications Industry Solutions</organization>
            </author>
            <date year="2021" month="November"/>
          </front>
<seriesInfo name='RFC' value='6901'/>
<seriesInfo name='DOI' value='10.17487/RFC6901'/>
        </reference>

<!-- Here's XML if the update to [ATIS-1000074.v003] is preferred.

        <reference anchor='RFC7095' target='https://www.rfc-editor.org/info/rfc7095'> anchor="ATIS-1000074.v003" target="https://access.atis.org/higherlogic/ws/public/download/67436">
          <front>
<title>jCard: The JSON Format for vCard</title>
<author fullname='P. Kewisch' initials='P.' surname='Kewisch'><organization/></author>
<date month='January' year='2014'/>
<abstract><t>This specification defines &quot;jCard&quot;, a JSON format for vCard data. The vCard data format is a text format for representing and exchanging
            <title>Signature-based Handling of Asserted information about individuals and other entities, using toKENs (SHAKEN)</title>
            <author>
              <organization>Alliance for example, telephone numbers, email addresses, structured names, and delivery addresses.  JSON is a lightweight, text-based, language- independent data interchange format commonly used in Internet applications.</t></abstract> Telecommunications Industry Solutions</organization>
            </author>
            <date year="2022" month="August"/>
          </front>
<seriesInfo name='RFC' value='7095'/>
<seriesInfo name='DOI' value='10.17487/RFC7095'/>
          <refcontent>ATIS-1000074.v003</refcontent>
        </reference>

<reference anchor='RFC7519' target='https://www.rfc-editor.org/info/rfc7519'>
<front>
<title>JSON Web Token (JWT)</title>
<author fullname='M. Jones' initials='M.' surname='Jones'><organization/></author>
<author fullname='J. Bradley' initials='J.' surname='Bradley'><organization/></author>
<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 claims 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) structure or as
-->

<!-- [rfced] Regarding [W3C-SubresourceIntegrity], the plaintext of a JSON Web Encryption (JWE) structure, enabling original URL
for this reference directed the claims reader to be digitally signed or integrity protected a W3C First Public Working Draft
with a Message Authentication Code (MAC) and/or encrypted.</t></abstract>
</front>
<seriesInfo name='RFC' value='7519'/>
<seriesInfo name='DOI' value='10.17487/RFC7519'/>
</reference>

<reference anchor='RFC8224' target='https://www.rfc-editor.org/info/rfc8224'>
<front>
<title>Authenticated Identity Management in the Session Initiation Protocol (SIP)</title>
<author fullname='J. Peterson' initials='J.' surname='Peterson'><organization/></author>
<author fullname='C. Jennings' initials='C.' surname='Jennings'><organization/></author>
<author fullname='E. Rescorla' initials='E.' surname='Rescorla'><organization/></author>
<author fullname='C. Wendt' initials='C.' surname='Wendt'><organization/></author>
<date month='February' year='2018'/>
<abstract><t>The baseline security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity date of 22 April 2025. However, the end users that originate SIP requests, especially in an interdomain context.  This document defines a mechanism original date provided for securely identifying originators
this reference was 23 June 2016, which matches that of SIP requests.  It does so by defining a SIP header field for conveying a signature used for validating the identity and for conveying a W3C
Recommendation titled "Subresource Integrity"
(https://www.w3.org/TR/2016/REC-SRI-20160623/). We have updated this
reference to that.

However, please let us know if you intended to point to
the credentials of the signer.</t><t>This document obsoletes RFC 4474.</t></abstract>
</front>
<seriesInfo name='RFC' value='8224'/>
<seriesInfo name='DOI' value='10.17487/RFC8224'/>
</reference> First Public Working Draft (https://www.w3.org/TR/2025/WD-sri-2-20250422/)
or otherwise.

Original:
   [W3C-SubresourceIntegrity]
              W3C, "Subresource Integrity <https://www.w3.org/TR/SRI/>",
              23 June 2016.

Current:
   [W3C-SubresourceIntegrity]
              Akhawe, D., Ed., Braun, F., Ed., Marier, F., Ed., and J.
              Weinberger, Ed., "Subresource Integrity", W3C
              Recommendation, 23 June 2016,
              <https://www.w3.org/TR/2016/REC-SRI-20160623/>.
-->

        <reference anchor='RFC8225' target='https://www.rfc-editor.org/info/rfc8225'> anchor="W3C-SubresourceIntegrity" target="https://www.w3.org/TR/2016/REC-SRI-20160623/">
          <front>
<title>PASSporT: Personal Assertion Token</title>
<author fullname='C. Wendt' initials='C.' surname='Wendt'><organization/></author>
            <title>Subresource Integrity</title>
            <author fullname='J. Peterson' initials='J.' surname='Peterson'><organization/></author> fullname="Devdatta Akhawe" role="editor" />
            <author fullname="Frederik Braun" role="editor" />
            <author fullname="Francois Marier" role="editor" />
            <author fullname="Joel Weinberger" role="editor" />
            <date month='February' year='2018'/>
<abstract><t>This document defines a method year="2016" month="June" day="23"/>
          </front>
          <refcontent>W3C Recommendation</refcontent>
        </reference>

<!-- Here's XML for creating and validating a token that cryptographically verifies an originating identity or, more generally, a URI or telephone number representing the originator of personal communications.  The Personal Assertion Token, PASSporT, is cryptographically signed to protect the integrity of the identity of the originator and to verify the assertion W3C First Public Working Draft of the identity information at the destination.  The cryptographic signature is defined with the intention
[W3C-SubresourceIntegrity] if 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 over IP networks and other multi-hop interconnection scenarios where the originating and destination parties may not have a direct trusted relationship.</t></abstract>
</front>
<seriesInfo name='RFC' value='8225'/>
<seriesInfo name='DOI' value='10.17487/RFC8225'/>
</reference> preferred.

        <reference anchor='RFC8226' target='https://www.rfc-editor.org/info/rfc8226'> anchor="W3C-SubresourceIntegrity" target="https://www.w3.org/TR/2025/WD-sri-2-20250422/">
          <front>
<title>Secure Telephone Identity Credentials: Certificates</title>
<author fullname='J. Peterson' initials='J.' surname='Peterson'><organization/></author>
            <title>Subresource Integrity</title>
            <author fullname='S. Turner' initials='S.' surname='Turner'><organization/></author> fullname="Frederik Braun" role="editor" />
            <date month='February' year='2018'/>
<abstract><t>In order to prevent the impersonation of telephone numbers on the Internet, some kind of credential system needs to exist that cryptographically asserts authority over telephone numbers.  This document describes the use of certificates in establishing authority over telephone numbers, as a component of a broader architecture for managing telephone numbers as identities in protocols like SIP.</t></abstract> year="2025" month="April" day="25"/>
          </front>
<seriesInfo name='RFC' value='8226'/>
<seriesInfo name='DOI' value='10.17487/RFC8226'/>
          <refcontent>W3C First Public Working Draft</refcontent>
        </reference>

<reference anchor='RFC8259' target='https://www.rfc-editor.org/info/rfc8259'>
<front>
<title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
<author fullname='T. Bray' initials='T.' role='editor' surname='Bray'><organization/></author>
<date month='December' year='2017'/>
<abstract><t>JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format.  It was derived from the ECMAScript Programming Language Standard.  JSON defines a small set of formatting rules
-->
      </references>
    </references>
    <section anchor="acknowledgements" numbered="false">
      <name>Acknowledgements</name>
      <t>We would like to thank <contact fullname="David Hancock"/>, <contact fullname="Robert Sparks"/>, <contact fullname="Russ Housley"/>, <contact fullname="Eric Burger"/>, <contact fullname="Alec Fenichel"/>, <contact fullname="Ben Campbell"/>, <contact fullname="Jack Rickard"/>, <contact fullname="Jordan Simpson"/> for the portable representation of structured data.</t><t>This document removes inconsistencies with other specifications of JSON, repairs specification errors, helpful suggestions, review, and offers experience-based interoperability guidance.</t></abstract>
</front>
<seriesInfo name='STD' value='90'/>
<seriesInfo name='RFC' value='8259'/>
<seriesInfo name='DOI' value='10.17487/RFC8259'/>
</reference>

<reference anchor='RFC8588' target='https://www.rfc-editor.org/info/rfc8588'>
<front>
<title>Personal Assertion Token (PaSSporT) Extension for Signature-based Handling of Asserted information using toKENs (SHAKEN)</title>
<author fullname='C. Wendt' initials='C.' surname='Wendt'><organization/></author>
<author fullname='M. Barnes' initials='M.' surname='Barnes'><organization/></author>
<date month='May' year='2019'/>
<abstract><t>This document extends comments.</t>
    </section>

</back>

<!--[rfced] Terminology

a) We updated the Personal Assertion Token (PASSporT), which is a token object that conveys cryptographically signed information about following terms to the participants involved in communications.  The extension is defined based form on the &quot;Signature-based Handling of Asserted                                     information using toKENs (SHAKEN)&quot; specification by the ATIS/SIP Forum IP-NNI Task Group.  It provides both (1) a specific set of levels of confidence in the correctness of the originating identity of a call originated in a SIP-based telephone network as well as (2) an identifier that allows the right
based on common usage. Please let us know if you prefer otherwise.

Verification Service Provider (SP) to uniquely identify the origin of the call within its network.</t></abstract>
</front>
<seriesInfo name='RFC' value='8588'/>
<seriesInfo name='DOI' value='10.17487/RFC8588'/>
</reference>

<reference anchor='RFC9060' target='https://www.rfc-editor.org/info/rfc9060'>
<front>
<title>Secure Telephone Identity Revisited (STIR) Certificate Delegation</title>
<author fullname='J. Peterson' initials='J.' surname='Peterson'><organization/></author>
<date month='September' year='2021'/>
<abstract><t>The Secure Telephone Identity Revisited (STIR) certificate profile provides a way to attest authority over telephone numbers and related identifiers for the purpose of preventing telephone number spoofing. This specification details how that authority can be delegated from a parent certificate to a subordinate certificate. This supports a number of use cases, including those where -> verification service providers grant credentials to enterprises or other customers capable of signing calls with STIR.</t></abstract>
</front>
<seriesInfo name='RFC' value='9060'/>
<seriesInfo name='DOI' value='10.17487/RFC9060'/>
</reference>

<reference anchor='RFC9118' target='https://www.rfc-editor.org/info/rfc9118'>
<front>
<title>Enhanced

JSON Web Token (JWT) Pointer -> JSON pointer

'display-name', "display-name" -> display-name
   (because it most often appeared without quotes)

b) JWTClaimConstraints (4 instances) vs.
   JWT Claim Constraints for Secure Telephone Identity Revisited (STIR) Certificates</title>
<author fullname='R. Housley' initials='R.' surname='Housley'><organization/></author>
<date month='August' year='2021'/>
<abstract><t>RFC 8226 specifies the use of certificates for Secure Telephone Identity Credentials; (15 instances)
Do these certificates are often called &quot;Secure Telephone Identity Revisited (STIR) Certificates&quot;. RFC 8226 provides a certificate extension to constrain have the JSON Web Token (JWT) claims that can same meaning? If so, should one be included in the Personal Assertion Token (PASSporT), used
consistently?

c) Note that we added hyphens as defined in RFC 8225.  If the PASSporT signer includes a JWT claim outside the constraint boundaries, then shown on the PASSporT recipient will reject right below.  Please let us know if you have any concerns.

URI referenced content -> URI-referenced content
URI linked content -> URI-linked content
-->

<!-- [rfced] Please review the entire PASSporT. This document updates RFC 8226; it provides all "type" attribute of the capabilities available each sourcecode element
in the original certificate extension as well as an additional way XML file to constrain ensure correctness. If the allowable JWT claims.  The enhanced extension can also provide a current list of claims that are not allowed to be included in the PASSporT.</t></abstract>
</front>
<seriesInfo name='RFC' value='9118'/>
<seriesInfo name='DOI' value='10.17487/RFC9118'/>
</reference>

<reference anchor="IANA-COSE-ALG" >
  <front>
    <title>COSE Algorithms &lt;https://www.iana.org/assignments/cose/cose.xhtml&gt;</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>

<reference anchor='RFC2119' target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words preferred
values for use in RFCs "type"
(https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types)
does not contain an applicable type, then feel free to Indicate Requirement Levels</title>
<author fullname='S. Bradner' initials='S.' surname='Bradner'><organization/></author>
<date month='March' year='1997'/>
<abstract><t>In many standards track documents several words are used let us know.
Also, it is acceptable to signify the requirements in leave the specification.  These words are often capitalized. This document defines these words as they "type" attribute not set.

In addition, review each artwork element. Specifically,
should any artwork element be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, 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'>
<front>
<title>Ambiguity tagged as sourcecode or another
element?
-->

<!-- [rfced] Please review whether any of Uppercase vs Lowercase the notes in RFC 2119 Key Words</title>
<author fullname='B. Leiba' initials='B.' surname='Leiba'><organization/></author>
<date month='May' year='2017'/>
<abstract><t>RFC 2119 specifies common key words that may this document
should be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the <aside> element. It is defined special meanings.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>

    </references>

    <references title='Informative References'>

<reference anchor='RFC3325' target='https://www.rfc-editor.org/info/rfc3325'>
<front>
<title>Private Extensions to the Session Initiation Protocol (SIP) as "a container for Asserted Identity within Trusted Networks</title>
<author fullname='C. Jennings' initials='C.' surname='Jennings'><organization/></author>
<author fullname='J. Peterson' initials='J.' surname='Peterson'><organization/></author>
<author fullname='M. Watson' initials='M.' surname='Watson'><organization/></author>
<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'>
<front>
<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'><organization/></author>
<author fullname='H. Tschofenig' initials='H.' surname='Tschofenig'><organization/></author>
<date month='September' year='2014'/>
<abstract><t>Over the past decade, Voice over IP (VoIP) systems based on SIP have replaced many traditional telephony deployments.  Interworking VoIP systems with the traditional telephone network has reduced the overall level of calling party number and Caller ID assurances by granting attackers new and inexpensive tools to impersonate or obscure calling party numbers when orchestrating bulk commercial calling schemes, hacking voicemail boxes,
content that is semantically less important or even circumventing multi-factor authentication systems trusted by banks.  Despite previous attempts tangential to provide a secure assurance of the origin of SIP communications, we still lack effective standards for identifying the calling party in a VoIP session.  This document examines
content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside).
-->
<!-- [rfced] Please review the reasons why providing identity for telephone numbers on "Inclusive Language" portion of the Internet has proven so difficult online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and shows how let us know if any changes are needed.  Updates of this nature typically
result in the last decade may provide us with new strategies for attaching a secure identity to SIP sessions.  It also gives high-level requirements more precise language, which is helpful for a solution readers.

Note that our script did not flag any words in particular, but 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'>
<front>
<title>Secure Telephone Identity Revisited (STIR) Out-of-Band Architecture and Use Cases</title>
<author fullname='E. Rescorla' initials='E.' surname='Rescorla'><organization/></author>
<author fullname='J. Peterson' initials='J.' surname='Peterson'><organization/></author>
<date month='February' year='2021'/>
<abstract><t>The Personal Assertion Token (PASSporT) format defines should
still be reviewed as a token that can best practice.

In addition, please consider whether "traditional" should be carried by signaling protocols, including SIP, to cryptographically attest updated for clarity in the identity of callers. However, instances listed below.  While the NIST website
<https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1>
indicates that this term is potentially biased, it is also ambiguous.
"Tradition" is a subjective term, as it is not all telephone calls use Internet signaling protocols, and some calls use them the same for only part of their signaling path, while some cannot reliably deliver SIP header fields end-to-end. This document describes use cases that require everyone.

   ... the delivery of PASSporT objects outside traditional "Caller ID" of the telephone network

   Traditional telephone network signaling path, and defines architectures and semantics to provide this functionality.</t></abstract>
</front>
<seriesInfo name='RFC' value='8816'/>
<seriesInfo name='DOI' value='10.17487/RFC8816'/>
</reference>

<reference anchor="ATIS-1000074.v002" >
  <front>
    <title>Signature-based Handling protocols ...

   The first data is a more
   traditional set 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>

  </back>

<!-- ##markdown-source:
H4sIAHrdfWQAA+19a3PbVpbgd/0KLPMh9jRJPS3byqRrZVmO5PjVkpx0OpXq
AkmQhAUCDABKZtye377nee+5ACg7iXtqdmtTM26SAu7j3HPP+zEYDLbqtM6S
o+jN8eXlsiivotP3dZJXaZFH06KMLtLxPDqJsyx6GtfxVjwalcnNUXRx8nRr
UozzeAGvTsp4Wg/SpJ4OqjotB8u4qmCoelCOJ4O9w61xXCezolwfRVU92dpK
l+VRVJerqt7b2Xm8s7cVl0l8FMVlvXWdrG+LcnIUXV6dX5hv52/8l/NJksOa
11tbVR3nk3/GWZHDItZJtbVMj6Kf62LcjyqYvkymFXxaL/DDL1tb8aqeF+XR
1mArSvPqKDoZRj8m+aTeingbJ/MyrfSnopzBvMWiqKLzfDzcipJFnGZH0Rgf
or3+b/p4i48P86TecuM+H0ZvkjopqyLXoZ8DNP1vNParBAAQl+Ho74p8uJTn
/nfOTwxH6W9bW1t5US7iOr1Jjrai6HzwdMjwTpfjokwGYzihNJ8WCHJ84OLZ
yf7e4a5+fPzoUD4eHB48ko+He/sH+vHxjj77cOfxA/34YPexfHy0t3fgPz7w
Hw/dxwfu2QePdIrHO4c7+nF3l349P351PDh5fXk6OH7x3VEEv0SRoCD+Gh1n
gCppPV9U0X/O63pZHW1v397eDtM4j4cAuW1ArnSWLwAJqu1xUSX0z/D9vF5k
f91CGBg44d733XIf7h/oah492qWVH1+dXw52d+C/hwfDm52dvSO7oEuYKK5X
AN9RXCWT6AzwDcA8i4ppdFxVSVnDj25KOONVhX+ti+9PX1XRvcuzY/hw3+8j
Ho+TqhrCsxVvZbmstmdlsVr+c7kaZel4e1Lc5lkRT4bL+XIbDujx7nZricPl
ZPpXWqZidET/wYhxnv5GKzminW3DxYmeFeVqEb16dR5dxdV19B1OR29M4Foe
RXs7e7uD3V345cf9k8HlCu53VazKcXKew62Fk1iHIPEPRO6J8KRu92lzVxfb
lxfn259eKcwbrGf3cLBzONjbhxs1GETxqKrLeAz362oO1xOIzgrPPkqQTE0q
R7f6UQyAv06YbI2L/CZZ42GMy/WyLmZlvJyneEvWA0QfODf8EhxePCpWdbSk
yxdnMMRiscrhHfwjEJK6gKfH2WqSRCUSxUVSxwNYcywvxjwioAh9SMqonsc1
fM6jURLJpPjX1IFtWRZ1MgYkgtHLOK8WaU1f8KlqNaqSX1ew1WwdlbDVpIT3
YRH1POEJJtESaOZ6GBFgpiVQGqCQ1xF8wSngjYldNA7KQNP16VKjapmM02k6
DsAxStYFPDBfLeJ8ABR6Eo+yJJqk1TKL10TXEESwBPpdFtY74aHPn/ai6Sof
00gISfgf+D98pE6yZDkHmh0B1aQFE1CqKM6qIkryeZyPYeW3QAMAph5Yi2QM
f0qrBcMVcSERqMLkAkqagZENDx9HJsgiO8JbW88JOn6XiCyTdDoF6AJSyZs1
ERC4zUhYq6QaMiou0skkS7a2vkLML4vJira3teVY54cPQh8/fqQNeYSE2SKm
ITDn8x/lUSSw8OhnImwbV3GziANpgpu6KbIbemwTDn8TpQS3VcUw4zlhmYqc
RNJweIJUEqXCavU7zTVOlzHQXpwHsCIb1CljgpkoSoBxAT2r5jDqTQo3hM6n
GBdZlKXXCTJ0B6yDjx8RhRPi+fgcoNMCJAWgBnTRGVJAugFSk2ScxXgPqmS8
ohPGZQU4CUtl9K4iAFEFW8CfcOyvcc1pnQJcqnGxTOTitCgKDgkgwtfwpBCH
3AmnjMPFTVLixaEl+5s3WsMKpzAJop5/KXESFeEjYmhVFeM0RvahuwacB0ZT
WVyOJ5MU4YkH2bixZZLFDeYzjHg/iHj+xY4brQQEV0kUBOhxOkuB0+Ev7szv
JcPZ0N7W1WIESwBcxdN7e3F+311ES26A1llqhdy6UuKoJAvBOEExZ8Gwup0n
sKiSngcWuaxxFpIQkXoVC7oWAYbJ2QltC690tQLqHPM5KkoQ9tKtwKEVq5Em
IWlmHImbWAw3H0+tTxc0eR8vllnSZxpWxg7CluTJTB0kDoTUGdM0PTrFWrt0
AuhtscomTTg2qX40YfyPM7yyKJKU0RLQJkf8Bo5BdxzwEbgPELUCxsfhCwf2
xAEdcWpe3BLwcbDmWeHvnrXdzosFHrkgEFDGKwOL9saRtMSMakIBqmgeA3El
gFSrJVJmhEaSAcnlLUVfK3ri8X0NF6xY8LUzeIqnhodRrGZzonkoJKRjPSDa
pH8Sl1xMATxRlkzrEBAxY4mbJbwbgvYASiCX1SqreYlZAY/hRYM7W0WjorjG
EwBo42UvERYoGiDJH+J9aeBQlS5SIGRwTigejOOyXLdZE2wKQCFoMmBQCP15
hmudA0+GlU3TBNDlJs5WSTekEHsa4OjTYjNaKbK6bK0jIzIPzmEVwfBD4Hi8
QKWW/egWqGSdZulvCb3YIIUw6QIUk2iW5EQq1yp7CPnzjEZgBgQS5YgqIT7t
qJAFSF7UwD5ASBJKs6qFABB9MCgz/JSwKFT2BjEj4LdKe1U0IJnGHkFP4I08
BchgiSJaVVcEUDlVQSd8jLhkQdfMoX8fadNtgvcJpLZVSX/tkUhJtwzxphfd
Aw37vmHzzAAA6nN80NE9+lOB5LeulPp0HyEukFdCMisI1SC+MMcxYiogtKc3
Ci06feUp/ehS4LO7hxLYuExHSeVlJR4uyUkqdJcBcKecDPhGqZCVMrcTKaTk
fRkRx/NIkQXdEfOVZMGiBxpvzx8swAfmHWcJ3S5Go+laJYVgGQw90WUEdqG5
I2Svz+AGASL3w4tgYCBUdAlATcobvhZeftUZTp4iUlRjAFGZFhXS4ZKehX8X
wA/gFPIiH7RE0VLFl1olW6St+BmHFMmiTKZ462IiVsClYHqVu/EpOno6ICOe
4NHHoHgAt0WQjvFqTpEJJoMsAdpACFYC5g5R9L0iUlJkxWwdffiq1m/r2foj
3rokEkNNFfVevr286vX5f6NXr+nzxenf3p5fnD7Fz6Afv3jhPugTl2ev3754
6j/5N09ev3x5+uopvwy/Ro2fXh7/1GPlqff6zdX561fHL3pM1+x5xWUicgqe
TQmnVZPs6w6SROgnJ2+i3QMQPv8XSJ97uySn85dHuw9BZMVjy3myIgdM468A
Z0Cs5RKwj8h3hpLbEg5Rrn0FKJJHeEwEy9fA8W7S5FZxQ6TODkRsy5JNEkeC
JyBh40WmI0I1qm6p1KothBw6VkiaQfROF0QVhX6jtNipkxAdM9JmU4j8HOmN
uAcw6TjNNuo+TSm2SSFGCQsecB9zPGQh6MtVuSw8qPEl0kDw4tAlzNdNenab
0o5CHGniVbGS/RLvQvIGMy8LAZ+yE721oSmgQzftOxGN1TY38prXpDweD4o2
gSYQpDwgBSl3g7Mas3iI5H0eZ1ORdFlmhSX5jSoh8iRSBquULoU0CZUgWlTI
u8KpPO8iLiLiQD/q1JnncO6jJMkFAVWfaAnmTplMQUBeopQM8Ae2PWe61GfR
oDYK36qKZwlfcodRVgNF+BKXIVEGGLubgh5CWyqqqU0swSed8QRoL1oRxnRx
JqIJ8oKbyMIrnK6QAbsBZHMIayMr8coBkki/FWo8A11I4qGhiOGXJNsOVzNk
Ok1co8Fju5T+8JLdcQFSlkBuQfIDvhOJ1R+uAav307QEDkMYQoSILrhVpFT0
Q8nFmtSSsrXOhkgGszmLAh8VkOL1ks0naIYBeK5QJKfFL62JQ+UqIw8nSjFE
6iRaouoD6VUwH0ngZ1a+MrPjaG8GaiEeqMdCHtlHXO+LupCOO0Qde2kQdFUy
LkjzZz8Kw0/AhcfoDWJ8bQDP8bR0j+9O4jLER9JFhPxXLO7FfDZDWOSd3gWy
wqjEQ6rGUs5PuBfPBiDaIIfC4nDNbqO9d6D/gAjnH1f6TNazYXSaEnbDmkeA
57Ip/DNgGpxyQmhHeCVCLNoMYIRSLCSowOYiJzIPUzg1URhuxrEznaCkRzau
THRzFoo7cMhdt6YV7IauRV0lQAvvAbWsVlV4xexgpMMmN2mxotOLSSO53/+M
8yDDqT8UkInxAbTZVkXeo8EWqO16Ow1ZPdsbob+T8YXfZWYvZr8VqjbMK49B
vb81AiQBtTcu815fubCM0GcFFwTImNRZkElZFo/rBhrp3CFPRksDja5WJj0b
EDOXNdwB3FxtFF97zKNkHCNSMvtM8psU8R3ZCms8bpX4Z1Qu6TBReYtDmWTz
/STaihQbbdNIp3OlbNOSrfd9tDsJe0ZsxR2O4iqtWhJgQ3Lz3pUPX8GmnKgA
YvaPIGwaLFf114j3ZSI0DNEBlYc+YSNhvCG5Vmn23L4uJjEgPxO82nG8ZZGl
4zXtGMaGgxwzmovgc6skJAJpb8FT45tZVtw6Vo7kcxj9KHIN4jseKXnUpkiO
0DAEgFwRzyuJOjK1wtMY44NwvxCuSQUStTN40aaSRVySFWZcLNcgG81Rnymy
2JE84ZK8DR4xYW4s2he9M0r0nqesKSzxxpFSRDJm7yape+G9F8oXykFN87IT
qpueDIJQJXdtApOO6QqCbMOfxQzHajUtmm8MbUSUaNA5QOAjmOlSjWkAbiEg
ek2SVGDtmKQzVPusBUCdAzdxlqJHzrMGOnmYKEtZ4vQaptiOjObI1sQMFWIU
EAFOy5SEZBgCzXzACsr2LA1iGlAE0psrvplCxWIirrw3ta4zIAAjHCSEHLPU
I6hMQoqegoj4MekbTu6Mx+jdQh8G/5nEd3gNJA9A2HFt5BtcovCsQNaRlZuJ
1BfHCKb8WKxgXhkg8sUjsbmg7QMjEYDcBhXNz4K1GCc7D5kMkPEYDdBi83AC
K1uK0aZP9I0oNZNQNiuSK6BPa1zgzZyijSV8G7g40F1CYRYAWn/OevflSgS7
SPNqmZZqrJ54LxnC6Mf9kw0e50BoBh65yXmtziURodpHsqrUjBYv41GaEfzZ
/o3enxMCw4nDdaA6RnpQDeIQubDzr5q/YdSDLqFzOL8RZGqzVSrY4S6JHEjz
fnkf3mK5qhOnWVK4gl5Ix6FV9yT8I53/HomA8u0+wsVfPFYrxKKUlowEGEpT
+Guqt9NdxtHarYH4HRET2YVT5MbjFbJruItPAlHOn0ffYDsjLq/EAa8KDyOk
WrNERUWVDDIUslBFFCXYiRq4Zrm09s46GdvfadIN1UPVVnfZfqnSZNIQi8gf
hwFRg9F6wLcJPTXyg7sk30TpMIErlqow5IUPEZ42TxCa/jqiC/Rs3IsOUUhc
+9Sc1qlxJ+1orK9bd9kMV0EdpGyhnaEkw4CzpfAdVZRmnBoH9tWAhjg2KQ/A
egbVuqoTKzB6xRo5vJchWYZhOxLJLqw7TwvkbSTJkp1brC1kMSsaRj3vE8El
o43YH1E1V18fITAJl7CBYXSvdwww6Fk5rhdAxRs2aQXD+1tb/2X/2/rLwP1n
Pg4+9at9YOtfURS9LHBfEXx8VdApYzRdJP/9i//nXA15zb9H//pi60B40Iy7
R7gSD0OQs+HXPYpJNAwi/O9LreNVkQ9oJf+K9o+aFH0Ivx6YdQy32w98kXWE
J73lqRd7BdDHCF8WBfs9hcyTlw9REE3VZJrGhTo6XonoSa5AOs6WHUFuxD0k
VaAv4WlXjhDgZXBkQkeNy8SPplyM/3Zf3MmsYmy+/GpklNe8JxK312+Tu9Sr
c6iBkWihYRdiMvGEmWDVQSk9J1UVH0NNUazptFvi+GiAcnq9GDysgdGHeAR0
UQ/Jm9q9Os5n6vxDG2FEcm9o4XA+QRf9xRTa+MNaNL1qwhbGDO+U0MZUZyHH
zsgfsbPrB4KstUxh6EPZYTuHHXgaqhKrgKFjXyqK9I1tIvM8Ae3ZgV8N8VBo
k5poU+cV6wcCDU0KQg5dDhYuUMYqkznrpzCNKi1iSEjhjIg/jZP0hm/NBqlI
NuQYJF9dsrgTCKYFuoMJ+qDWEOqHpnn8N2UIdYesCf51+R3a+lS/w37SvVIx
YvVZp1NvqojLZCYzNiK605MkS2YacCAOD1kpn5OP26wLdRdb1ZjUYZ0tnpUJ
+29A+UbAe/HTExcyW1mpRMWB8Erw9VuWoMqAOBJy52B7AhxV0NzqHTWRfcEf
vfgA0xrv7W+wEOcMSju8DxggTRY8CWRhEwUfOpqVUN1eD6Nj450wlN6TkErC
XrpRibHFDxGPKgQSWxlUI0ADhgdfi5RzaDOSfDJcOcxg9sZ39KlXaXENb8n7
QNarfzIB+Aivmnf5LR7hw1fVGoTO9x83OTZjMjo+v3z9KvoxGUVXFFrpfZI0
Vr9hRGOoiNg9tW5QGqcYveOYUTF/qJ0SPZUwJNnxrpO1DLCMAfKbrTrwKV5l
tTIZ9x7BC3bdy+NFD3/mW+++yuhyrX0kY7/T7KhOv4Lu6MZgZd4pYpCJO4Lv
9ZiHsf4Tom+wZU8bNoUXkevQhL00fR5hRJGjKV2ukI7RW94RF1DDT7lQGoc/
jJMuskbOBmHa5ExwpOOkKc9YxsJLMFjBZALHYrzEl/jMaGzWANqwPH7y6lk0
S8XWGjgPz6eegoP0JKbwdphLiARO8JIl0uw1klhUqEFqWCxRkaDBFNPiZW4x
Tb8aTMu92+ZOt9e/EwfRLP0ncO8e+Rg9d4xdzKEsnaIUyzI1mvPdPrn7HWFx
Dom9Y+hOJP55/7s3b6Kry2jvYLi39zi62T0cPhzu/PJHMfq8NtJElSximHlc
aRCLi+CWLTvzjI3/Izh7ofE3NsdUEq1kYj05jDzK0mQlp5GWjqzxDH0XnxGC
vkwWIEJLmOiM+YXY1cgZrMHDGnsQjTEiA9kPKOLxxE/nsKkrZqQbl5F0F4h3
Ge+tGbG8bEjiGr/2aLhPl1LQXuK6vhD14KtnAnrcffNbsJHTlAMQynpGFnPS
vUOUlplCDzeIX8fIrjuvt0hJiCLD6EwImszrImTVQL4Bk2RcelWvXh7RJRVl
LFanyyQZpyxsSGg+TYfB+C4AxodIAIImN4hybA+txU/EEsyduxKziqHR5NXj
aDYYQQfDEECHLaK8kaUI/XpruZt32cXuPhThRxyEYQ87ruzJoNzu7rIKn13b
EirWgzXbO0CXiozuJIlXab0SnxejUq7xIWS4lGAAtFzmIFNXYpp1VszAwTmM
XmNwG4LHo60EA8kKh/IXvTNsyCIHZe1Ni03frhhpGdHqwvG8T58tuzGn3uFA
rgVcGFNFxUZyYviwUGatDdApv0zHAb/Ur9388uzq6s0lCMIvvLgccYgBO0ec
ibTLq7ZMx8A2OUTf2fY+n6mqgo1BI36BDSsiYheZQKPCk+9FAleW6KxydI5B
k0U3ImwlsUw8zd78SWSqEWrD15bpoF+T27DJy9oQECJzq1XYhys49O7hhnut
GE0l5Hs7w8eNOK1TkTYwxJqoQHXUNJC61Rxx+iJnL94ORVAZAuS3gaWMk22g
D3UxfLec/fUbzFeVhX6Li2qa4l4V6sv8dNiGzTdqRGz5PUtok7WdvXc3CSSJ
md5r75DwKi1B1g2NzqWY1L48sNoRBrAbgZGBgmowSeE3+ZkJICoy57XBNoo7
yQtnCKHphBA1z6oOrOZ8eSlSV2+v4nKiUQW5aMmfAKM67znWwFPU23hdcTiZ
ZgjQMfLAWTEryJfccZnFQOCpgN8wid3o9045L6d9zRiAOAXTWT5OP4J5Ga8S
3A70pVbeeSgRWQhOTVDgSFiOBbBnyIxb0MWdslra3F8oLoMcv/50rV9B7UMw
HUpKnHQkeSMYhEih50op6dw8pdSvnlIaD7qP+mFYcCLfzmO0mLYULYkaq1qx
WaGjN24GJYsKLymWJrORpmbv+cYQZYmnLzQgWQZrZLQ5u7hXXTZQMoZC4B/+
FBEQ4qeRQRoM54VA2VkQyifm0mXCMjvtui3zuIoBJgyURyPaX64U8Uz2YSo5
aC4iDhSQ0DxtgO4XGcaIIs9T5KWQvcCC7kL27MEYmPEWC/YhoxyLb49WaVYP
Ur8KdgIGUAkxBVnyZLIhFVKuuENfPHvh7y7eMG6KGC+PfzKx/Q0VgCN60euA
OxbxX7bC0JIMLR5u4gUmvR4tixTOR6lygeXa2T55Rnqy+4FI8y5clpEXWMiO
Fz37dAAyKdFLZ+nFKTGPoZbYys/AcBADXaiQMDtK3mWXjeKwRLIGl1XsrK0U
Gt1faO0V0yRy4COWEsWmeiveakSJzwim5DWG0TmEZHgz7ZKnFD1Psn3gfAHW
yWq8pxKxiVn3VlhBTQ3/aVgVKCtQ1QEUZN+QIT50bXFI+uZ3myKwVVo9Z1RU
ZxS1IqtAQ63lLt2lkVSfNA/P84ss5BdZW7L2PFhCF6cYbk1pp3cyDg62vE1G
FLmoFgL/nfFfKcjL85enIAVPUiG2eHo0GAlUyFcwso3vwPY7DApVc5ywdkC0
YiIq6NurZ4NHalR48JgjfGA3gEjXHA5alOyDccl0/26WQU4CiQT+/MH6/738
xdHdrIPuepIcanVIBwnphPiSMaZNgYk2KVFdrDDgn7JOxfndRZLb7iKkpAGh
zv4/of43Eeqv1Jcc+pjZG7TZk5R6V9KVIIDzR/ucsolPt2InWdsn1tROzOo1
gufDhyDw+mPLSDXU+UmVsfY4xAkSuhtIGxvHJ2UpTXUIu3iP2oQanprAxcqs
9YVuPF8dpy3XHWDpcHiF+SKiJcstsVbNYhqOJvc2HFFokvi+6C/w3HbDcYah
fvxC1aCQBCoN0NLw8Q5Dq92A8MDuEBBeUBC6r1EFjYiSDipAWh97VJi9AuBB
mqUUIhea4F3wdy3YBU43rn7Lv0qmZ0xpsPGgzj8fhFNrmCrGT2OA5bp9+5hJ
W2C6GGcsYbDgyMgygU0mN+xZ19JT/K1ZewK+DshK7JJ8BT1s1pvXQg1adFBq
NRGx7EHYsiwoG7cVXIuVyTzPw1zj0sr0yGTIm8GFJJpBHohZTUAz8ktYjMFh
InmLKslu0PjhyIeLio29LV+s68QeGvHA8NM/BeYoFQR7E0eiGEU9CAONC+O1
YlI3SfAShwNLKnJtVcuVmG8JJ2fEZKfbkqoT8R/glknVCpt8s4ivkbMvjYPc
B4oYaoPLHAI5lrgFoyqysZW0PDRtAHIK18mdr89TNvcgqowNU9yWPHYUfdiK
ot42QvUo6lXzeO/B4eDh9eTkyT9+PdvJf315+aZaHD+5qb7Pzt7M/3F6Wc/e
Fe/mk8vn312U++V1r6/vb+9u723vm1HevTiYHjycPnu092J1Oy5fl5fr8fXx
weWPZXaaTY8vzq5/PLz+qdh9PjnvbX0Ml7flqCvdcCJVIXFjs07FFMCFL8Xj
ssDg/NzhjTeAKcq1aU+AMTBNP9ra+g8T75JhyRK5lOZtHhCetJSNVrMpZDfX
wfDOfMbrchNswK+v/xMlC2ClEojjgrSCNzrmk7wCOLD7WxL2gWJMsRjRhVKm
EuSMTcUhpYU7gC5KwcC77sWQhRbEyoV6FCpmrko68OF5XM39gFV0eXY8APTp
04f9Rwec8I9fHuzuse5Vtd+iqEeOtJPNCxpikQL4BANpnQL4BiPBN7xxyLrQ
6QwD3zkxXz3jiqSnXXRjkPxBa9NKbJXQ1L39A0rjZLqlou9l9CoWsnoOYmBa
Y14B1jkRyw0L81cuzTq69+r88uo+rPa8CVcQfhSsllgn6M1gu1oTZiyh2tqQ
Hz9+owjW7zgcignv/ZRUPacLXPjxgdMU2WrhlHccGeafwSUtEb5n4VjutMrK
a43EQzF5rSTan2HkWVn1Vdxde7FdzY3z9ZIsxPMYixElIvT47zZunBxdOr+g
uNc0miMB4gw4ufL48uT8PDp4IFGkrkqgmZWjA9BqBus+PGDNNRE9GguA4uE7
OabpP6fMchBX4QLlJDfJ4jD/Ns3RCkAyTRBjHxAtK+UYySgQ40qnbXWoQ62M
B5MPxRF0TtRSH3VsLTVpvgQ+JMtWouDrPRluaXO+ZK4czQHihSArRnSi+WWB
eCdb0ySVra22mFoFQWUUPNRnb2mf3Qt91nf7TTdmV6CBlbaNFLUpHs2IKcHh
WKEqbiQjFkbvdHKP3ZYeJzqCMN5ywka1aTxGgZQ9tuRE4LyfcQA2m81j0z4C
cFacv7lJbYxuKU+zmBBl7ZvT1uxsPtcFlo6TyF24t5wFJPXmgLKNIwqTKZOE
4eKigSWhDmv9lBUo7prsZBMJ+RVr/PYSfIJnEtfOCYE6si7N2JdsKi1dn87M
sFRsUl4Itwlggla+BiKzuUtSd/s+sJ4dHZWr8cg7whwGJHmynktO/XWJsFLu
Q6qcyWqtuiHDOLEujNFW+bFyqp0u7woDVM3q+D0tCuHSxWT4Hywa2TWGCIby
ZVIirEXvN1Nq4TYqd6XAYpSRB4ROqPSr95qd3n5FeTOlsUX3XAzelWISCspe
rDZkhBbYRUd0NaEMTrbQjrmcLm71912xCQfPJ6m3K4lt1egeHKJDJIfXejsv
MgksCQyuXKIxkMjoXUvIJa6glV4AS0OR6RnFwdGotAIMQseACK0jx5pOQRFl
N5Q+jjpNjRQpHrORkaTIEYDzupK9GrXEmWiC+06j6kRitQpp/8+SzvGLL3D2
WEZvaVAurAXRSM83kLRgs/u62Xy90TBITHpd++S0UTFx1jO0i2skf/J5c/rw
A0MMWaTGLFHPryuKAQjia1ymC25RozfzBOlhXKY+LYjXMQJZKnd1jCS/clKs
Rlky+HVFsYBeCrIB0CT2UsSQI/kfvoK//BN+c5oz8RemXqJqh+8y5NgoLPUF
TDygmm6etUqG+KBsjd5Ke+FFKcpWAqq1UruaEgzf0jv2WMndlEbEhVtzDQEg
Ek8mKXEtk6oDbIC4gGECGIPjQ5QMxOD7HdBi4eIuGHlDt3e6aO0ik+WtUctN
w4rebpSQ0/zaCG/MQbwkG0CXKhExUOHZ0mTsOP2W1yODOtoRUSASk1AyGnkF
3KExBZb4nQtt3ECmo942gVRZsKxKglD4EVeIlasnTLS8O15DnweP95c5mLnh
Ik8A1NwJvgvEnA9fwfc7TpDlQm+cMXZMOr+WK0Jv7BwNzrmG9Qn847KMBclA
YxjQ16phncqLWovYwwHnIE6WVBF8knK6FLJyI87zGH3jRRSmjjFcYQUQetJY
17DMTuWLoSoOmPAgL0102Yp6Yil6Rx9/7t2QA6xPReR/xu9Ac2Ajvf6Hj/0e
uvd6/d7BcKf3S1/qz//cm4Z//Vv0pIzz8dw+UpSz4JmX54ff6HPR5XIdfRdP
Zkld2XcoxIjfWpVpT/8Aa9UC+Ta6jAOStn9dAecFXhVX8C9q/e/h/4fLfGZH
xoilzx6Ywpu2F+mhG+3d8kuMdnjw/vCAx6JX8F8alcjzUdTrhE/LnmZ1B6Sl
ARqqFqIyL4r9/QZ+NOyL1p1t8wedSAe0oVTfIl8Fl3zhKrGyOmCsFaqvTL2y
SkkNSZlIeFunpfq3pCykXQRPpTeIbO+ijJrIUaGtvCC8Gh2mUW8ZnfxJy+hk
e3d7P7CMXhTvZj/evj18/7Y+P/j10d5frs/erM8Wu8+/Hy0e/uXwcH/08ua3
9WJ+nR0Eoxz8YfuqHeVBMMp33796//7X7MVFXI7WT17NH87H2wfZ6B/Hk+8P
n+xcv7yY7h6/vPjxzfVl0YNBPnZaajX0vc15WozdVfh957UXZBtUpUZ5ZZeD
2v3RiwE2b1q86HT8hvP/W+QDjNrnMHkq6oV8KEvyGRUax9pWVXQvluxBFiLi
EcjV911+W7pAM11MbSamtog4Bn3cxKylblNFDXEGawyjBplr+C42MOGCe9Tm
hGuGeo21b20Sxkf56WOKXZ1jLTgk8M+7QOIdfCbUHY7KFIvlQFa0NuvmReNI
JIsmadxdFyzyRtdJyoOWnhSpmola04spogAthnFIYNBEwm3GwqbmZyiYxStV
FF3JO5eyj4LIZJVPcFuBdSe+KdIJ6SPLorIxdGhFJHsvVR1Nc63OHdd1PL7m
4tZaPMtV3EI7MJbiqtShxH7pQk7ezWeOMxHvLMpEp6gCN/QiC6pwmyRPUoxF
3IDQJrXYiJpBrD+Z2QIxLNsshtWWnvCrwZIl8N/puhL87ExJ3lOmiV/wApMQ
FwaWvMeOBzaOgr2cbOXy0Yx2o8KHxFlmfYIB7wzX1WB9OaOC56oq8jXYlq0I
ziAQt431tN1nm7PIyZgBPw1XsNnZzmvDDHpH7az1U1ttWAtTK3q4LRqkWbZC
isDVcXndIhe6HCIkhCqXi7xzp7RJbskuCenXEUk9Qwwb632GPNRv8fUv4fH8
83w9+yJ8PftzfL2LpwursFRAUN970ZsXvpl9YjAvCAIj+8VmYtR67cvTpRCD
tdKzILKt7u98sTwul9VaR59CSR8WH2dYokE8o4z/hgsxSBtXwKpXn6FcfVK1
+v2K1Ua16k8pVZuUoN+vUP3BkUJl6petXxp4D8yq2y/gqh1IrJlkabFx4vNe
CTkUa+7OuKKSKYkXxuPQjgD1SEuF69AuqxFkvSVaX7FWxw9kb+t5OccQcnQU
m+KwGN2WiGUIRY6lq/ZqH1ygMXYpD2JIoi9d7eIWxPvMElKYVWu3NC+ySVdK
K/J8H99VJXL9moXfGpKaf4O7qmmLBwAJpVF6U0k3dKSEBW0nBzkBvVhSWgt+
dvVx+O6GVdC8i4OCoqlCjQ8ad5mI4gYggoUzmKOQUC0Eu8aOaUCBUUjaCxdz
6lTKWascaoYe3oHLHDns0VPjKFOP3EZi7h5DQ/2aMY/NlOoN3uZUbWUt9Sws
rWPxJq2qlQacMxvBJ/Qw7lytPzGMcnGmd7JTb4CBLNGdg7uhLOnReTkEMHes
YyDS3GxWgM3Tsi4uMRxT8VvnOp8YlOBiXK/xUZfj0+xEY/FL5c3uExDgetib
oretelcOhOZE2F1H5+KkVQZR3yqbDjkcvMS3JwZneZOaGdnhu8pgbC63iW1U
uk/ftIJrW5CkkKirT3B3SdEgFRNDa4Bi/6apmGbLcmRqzmokt2GiB6lxBFU5
dFvQ3CKpnKcWd/t0VKsLlpHilKbGV1mMuL9bu7at0JI49FFrZwtp6uEcvhSN
1u6YY3tjsiGf61mPug9TdXIuWxXgVhWUamq28Si432CliNtol6AqjSYuis3b
5ifRWRn+Q2/2NNPHeuBo3pX4YqkeSgNPgdQ+MzXQKocMpWPfcUaZsaPkEySn
UbXPlOtq3LzOyqwG0UlE1nhb447z0sMRRjjGIb/rEhfUxSFV+xrJCtNYA8Nd
YQYNA9HNfGqeNCBWHcwu+RVjwDUaQ7Td4E3rQAocskaYaWzLtVdpwrw9v5TE
kNIK7UufurG8Ccg3WuB1NgYNPJryiMYSY9MbhrX10bWJe8O582n5z+PZvaZk
GnaNuy/ZVN2SX9+Gfju7zZcX9cKKZ9ToQI57wLXGLriNwIasFXjeJq38keJm
3FvBzLW5splI0TZGw4ahhX0Nfl/mWadtclOzCT3vZuJbs62Ds683FE8t4WDB
7XMYgWbwH46iHpK8NSjGoMZjnxbgYb2+M904W8xzWFcVPYHFG4fXRrMOdrB+
h2/8cwRvsGWnaZlQqdZTPXdWvF6+Cq20KLsjJzKNTY0RTfH5nfKoVQFtHFmr
eri4040Y2ar3mEttikIZhi8kahtnaGzolGQ7CejZSGLNvmVRGyLf0PZInFcK
D9k3iah7LuYSobiJtLHyuy5vQlWVQXfI8RLkEAIjQDxqedwSwq3AK3cUZZZN
+h0NyF6LrkrwzKB9lYGmOK1hHOIr/FNbRorWaDgiTJyp1gVmb3rjG+dkeoBU
jWx4PP1mXXK1r5noGRdAynHRyEALqQrm3qaBMY+V0ve7+tXd6y2Xde++oluH
GP0gKPO12/fCqxAtycENZxZvMFVRYoJK/CS4GLp7TssTxamOMrgOtdaNJCHH
CSEh4IbRcb72NUE5oNJmedtZNvUpImO7q26MTAyTtajCQjiOh1lqfO7aNqJx
413JLlyjsz+6BwRkTpz41MF4mHu5RjsgbizLswX0ul4ve0c9LJGPfJ3Nyjju
EdtH8GuczeDr6SXlVOAP7x+s4Acl4s0yPoj/Q/inF3UZlzfgrZxuZYQdtN/S
/tMggZECRTUYO2ntnot9kdVYo7ElPrzvWTegjiiqri6o80JTW4AFJmHAbVlj
9My0FjelHIrpBueLkUkMOhl7qKue0XlprrS0OqyJEqTMbuRCS5nGlZ0J7xhb
dhpF0IKgXS7+qmf5Txu2C7LQsekFg4S+WpHneLrCueVPpmdlrZYsPZlG0Wu6
lICKK1c6xdUPdnVfdJmAd1H0HyhIz8llyhYzDw7deRBobHx6XX0EASI6aDwi
NXdEsXeSCo+KOLCBem6izak3lLXdaeZ0iwBQLrKKke1M5PbE3XoZL+WTloei
3GR4QM+eqbHWZC+/qy8J+VtdGQxxGfaAQ3UldJt335AiGhxNaJwODsrkeX/4
QBWScUFMeQmHTzh7L7HKUjA4A62wdZ4bza0NCvRxI1Q+0LoZYQ01hh+rWg8y
MiZ9ZWu1FSCmu4QiVErMEE4nD6Dnbx+oUz6B3t4/cQ209NvkfUpNq/1OfdVE
k1Lc7BzUzE0cRsTNwtB1yWZNqvzrWoSZ2KXkOd+XBogG1bSmcKVM0f2uLJLN
fmS7OAwwsOV2EZYk+PABS1qITwdQ2G267dOwtnjbzOVN+xS1DY9zVZOkLItS
AL2p8EMIBUQOzTqg+PMU0xC1EbK3ACyWsXNsYng6GZFRXPFWSLsZMoYzGoWJ
0F19H2zaVdXUDRC2x1zTU2NBUL5baFw91dfsAiM1FEhMA1tEEtovxZbcplVC
JSk5W8tbojlYubPDH4U8aenIwiWp464a/aFZSrLGNDsFjktReEWGuUIoI7F9
cQNu8NU7NWGIpoUMgMeLTxw5QjydjKsbhA0nGVH62T3CUpPmIAgYT9Tvg2Pd
b2rMH0AQwjKSvaMPvToHeWh3b2fvwYMHuzs7O72PpPT2gBzW+vefzQO7vV/k
iTSGB3YPDvb3dh7tHzzgH0mZ/sCqtNWkP7Ykqs69u7Q3MjRSGJpk/+fsvSbo
f1HYRGh66zvR2Vlea1OCu7NyhAsfC2LuOwrOfAnw7z74HeBnqwVB0g3++PHj
HbVn0IKP/phXXIfgEz7D6knxO1js+usKxYISZBdJwAIh+k8eOnlP/zsPXGbX
SMCgP6yhfp0+K++8cMU4PqfnzP9U5EAYHFH2wjYc+zecIdxPf3jy+uJ25/vv
ZsUx/Pfq8u389O0MP77Ff56dHP+kJjP4evJqtB5l+Iez0+z0bz/87Xx3783B
9vaj7dv9R9+dH//96fmT7093np69n2XvXj05Pn79+OrvL3Z+Onh9pqPc4ttP
nl+8fXBaXj+fzWbffvtlUTCsyBYWvrF5TL4SKdkcnGrRLiSibJP1NTlnTcoy
TTSanmjOp7a6orji7sbYztD2boLVkaHjRAzk1iEiorqM9ogjTJgHAf+3G+w4
jHfqRVrXAL5XSZalCevVjLJoRa3pjRbWCtK6J7rwltE2CvHWhNb9X5HKcSdZ
/cysjS+SrPF7czQiGerumMQo+qinonGJYcLAH40rDBMG/mhcYZgw8MXyBc5z
W67G+zi1rYGrSivhAejY9+UKmZtJFSB9mHLCqAAhpTEH3bPhpWFAqUwWF703
L6rapz/rU1jSELTkUlq9fjLc7zPMbP8To/p+9w37Avfrz92udtCeet9Z6W/G
jmqnMcsMNshALvfwDlPpH6LknyTkf4qO30Vj+krqPy+OeiNJyjwB+PUkP1ie
nh0+eb56+Nvf88mLZ6vjN4dPb7OrmwfTi8Xz3eNn179O69v8pPJkJPsiJC37
IiQt++Ik7Tgsv2UMsyT8UHKnyabWKueV962mPQmdM73hG+UPqAEB58CKnPH/
CHKSkHx3YHFAiTqRFE5WppJDrV7uPXyQXc1+O6mTv7w4e/39Wf324PL9d4+q
efa6OHx9eVDUj86f/+188ZMuZFtW8gdQtBMtvopOCjYZkVnDeSe8Kfar9iNe
HwqpFPtN2j0Lxo332x1SJI7nEy67h32yylfFgqxbdZlK+SppM5BhHn6UUMIK
KXGm/By2G8o0raXqaNwZLNKWpg13n3NfUB9y663YvrGZExhYHVCDIkZOdBj1
G72ehOC70bDPg60NTHU9Jmk1XlVVCCvbxehguIsy/tXmafm2C+TTqYgtOJvW
pO6r7ddXNjAtzbToBevHrf5cXGdB0sO0cVVfrPm+X6XvaSaVj+ksrSFa5gm7
mfSNcbDzoUYLtH4kyUm9oWT9SJcJraWKdsGg33KADxPOGzHdhV0V4zDxi39v
OWYzAIzGxhSFR94bMYw0Q6rrO4v7lslNWqUS2MWOW2qREmvBQQ18CDqUYusL
mo1FRj473Y/0jVxpPEqrjm/hSve3G4dMWwfNd394J/VIu8mHRFy2aEazGVpH
ZDcaWiTsCzEE9PagjK7zjAdjN0//jkWTu7655uaTcedzgJkxkyd7G4PaEZsC
pmjMVplwE6M1Wn86RosCO6jK0uANRaC+RYb/4StxMX1EjxBqGhTgxsVpw54Y
PldZKntS6UbbT647LrfP4f9oXcQi66UzqNGoy5huGgegYmzHmGv3NlIqYLJf
V4mWridf3YADaWWWYXRJ/edcNHAynWrZRBi0rjgBluJiN9W4El8U3QsMrgFF
yRNyNvkBZTL8QikNZsPO2T8hUVCwXkmpIPpugIR6gFamox64Ey3VZnflQ0/q
mqOzNzYrkQxN6sEHq+c5YwNiEdkoOlSa9eaUikkd+3CnWAKzTQOpGzgPkWG2
L/rhsPpZc4kcilVV5BALfa8MWR9t3AiC9v0Y6eIui2KKvq3zVqcVXZPt7Ji3
QEspDM53hHSAgtYDnuU7QSNEmERIq0GSKsQN1ULRNL8prinmoAP5LHF0iJtI
0j0FrXPTNE4jdo3l0MkvRL0uJvG63xjdnrnOxNEYC5JC8EakSaMzm4Pu15Vp
D+dCfIAPlVLPEMGhzlP7IuOHc+Jl2u9unmTL6Spol2JvLtKGmAQScZTEHMRf
TuNxMwBGKzw3sk2wZWXNjcL9FCIGYf9idYdn9A/2uPLmeQo9KG8Cn7B/C6Fh
ererJ2dCrYA1Osr7LRVL7PpsLzxak6FpqZSUzidcA3CSEN4Po1NPhUiWqZi9
MRITw4ip8I7mlcPFHhTTwQiXxELdo10MwHAvMSAXcZ7zwbLRuQMnObscpUTc
LcdYfbq5IluhAmqtU0eLdDYHQaYoro3toUNoFOh5w/WRNGg9f/XD+dWp9F5t
CX8Yggy0aFObV+llz52ZsmY0E90BpYrWFccBrXFAc7tolC8BrOY52dL7tXYN
kT7uFe9Nus0y9jQ7YjaCWyqOIupjHA5DkZjZJmLCVROWVatjaaV9WQ0JRZfr
MHq7pLptuMBWzCClULpycXKdOCugObc0C2/wJ73lFHaJ4ejdfW5d7Wluw9u6
Q3JSVoBwl7TJzM/V0EVRszDULXWIgscFiWQyu1Ry8FOPWRe320SwrvVQJErC
tSzQQMp6BEqKcGspHKLobxyMVyPBvY6q8tKRIq0W8SiTvItW3XxesYKheycS
C7f2DYIxjMmJHnwLE19I21zccVZUvuSDY5QmZIYaeb7xy6xCEcrN0rwbodin
3ZUtm5kk8DKamugmrIHBLuRq4LUIzEhWFDBKb/BSwFyNcEoJVkM119suf0q1
2hjtgfvpuwiIJIocj5UXd+C/s8y6mCac3GVy3bkGoS2WJarPG+81kJHcg6bz
4sa519KZALpW0nT8LuY6Dg14VBok90W3ShSuUBGIs4TypIeqGchIoJ66UliG
QDESSOVKZArolCiTjAWceboEyNS3FG0q049XVQ0iV1kpA05LM6AioRx9WWn9
A21TEZVFUbc0VUKLuC0JUct0kvBYmMFXyGnChZHSa4zEK24nXEcBbZrLlZS9
q1CbquSgsAXiTdIhlLjUiVaZO9NGOmgh3UC5hkFMfEgm5rHVmKZdkfpScg/p
mEnZi1jZ+/CVi2+k8NpOXSMIn6WJNcaFG/EiNqzSinUGH/FIsOjSDCop69u5
Qa1+M3MF/cdAHVn+qjQMjAR5rqIhKS5rL7y53masgFDKgYuFZMux20AzjcX3
YdbzGUuBTNw2pXBSiLGkmdgE/jqZFeWaC+rrghE3TTNcTD5DMhcHShIvzIbV
BrmkwZucv4nU7RvJ6VMtJQ6ialnK1iL1Yo/kUiCBmZaS1aSPNyKohTV1JeD8
aLyIIFsCZfpMefEb+pvpx1uZZERC9TKZZlpp5dKnqNYbwoMFbl34yaeVvMdq
2WndSAuWaVyZCpmJaWDHfLw7qgjRuTHO/U6mroC4fXmGOJiT5YtKYDtMYYMM
AgBfAxmOj4Cg4kqTNRWL9nq7ErMuGiHBqSAJ3w7NegIKpIvGRi5CVcnlK8mN
2laT+61XQjFd3XVYTol5VCrBIuG18c197b/bZETMIMU/7sI50VqvJ2Y01thq
zmry6RDOWGLmxFVWzzXAlleJOTWdvEa0T+x1U4lU6sG39tv0N3TYDlazBFQu
yObAtKDU9p+O8PrM6EtErKPeP2D0HCSVCRa2AtzobQzNvATR+HkxB9RZrAEq
HVGawESCPA1mQxYSaCwy7ETC5dl0ewc/Y5XX1993cc2CS11KWV+y47ncHGVE
kCJS12jZJ2UI9GVASJiywkI0LL92MjeqU8tanWooKQd5TKeUJYztYeq7JDUj
KTW1Ae5NMEVCPHYtgVKbKuQsgywEs5dCy63wutGChjQF/Sa2G4hLMrAeMbmF
JobE+lVcPnSj/6f0r3LxI95w5MvadcWs9VxTmusk7zV5P0h+NlNaZBAnuKFZ
q1PlJv5g22/cZSTkwJWQu2/wRIZtBjaOaLQgTfcRMXxizL1MwOHyhbykMWda
2ZZmEw0GLW/izA/TCQQpQVFOsIVKKkUyl7WYDT3vY6Oor6JIBO5zjjyUQV0N
H9fAwD0fmBu7GpOT0dXU1JZW2f4tKXoomi3QwR86rcFI0ElXE/YUsibHUU1/
BC+rEHCMqOBRUUzC1k7o+j01c9/6lMZlkn5co9ZF7NIdZDK2VDbTwEgKtUmo
WLcDzoOFNSvWxlZODNMb2Lh/p2wbIrw0kQmF2b43qdyNas51ziqQZGp3sHwM
QHUtR21n+c5hO46PCqzPUoQJ4if5nl4AiLg/z7FSOuAjWRF/pLQRMdq1nUzi
RyEFQy6w1wld80JfTyUo4tDAEYEmCU7JuBiwkYGbWzhTcdfwmHguE2BmiRSD
mZija03WFtnUnpKDlFgz6YxzW1maj1dlF5fp7puGMeT7ug/vceRSPWgNlydj
JBKs9Wq6GSFbKAM5R8gwOiUEzgM4E89mlf6kWCxWuXNCi88seiOgiu6dXL65
j2OyQTpWIovlO4Gz8X1gFRoXj/YMV1KHdFl+nPgkUhj2ztzOC2sHxJ+bT5Oo
mZTLMq2SrgRtWJfMS9w24xgjrHfFawnAIJYCNfs4jBBAxOFj3kBmCmHJsVou
QyYG1srQzJhLISW4dQtnFOEqyfLouIyXOhS3rY5LtFEyeKS7xAbBNzzVY8MY
/DWQW9ZZu4r2FWOyu/UAbeDgDABnvCIMEwwx3BV7CJDvDffjluMAou0Jbmy9
lcxRixmQChRwiD6WSJSBeIypgpMkYPQ7JT65vdTx3LYTwuvcyP/iCH96kIyo
k0ZuoaPG8l34StFVHiO4mPj5axDSv/YF79Dv3o6yYn0OZNMPXwHr1GowYtsx
LUDhkUEjvMrXyDOmFa+jkeOl014pmemvibyynO/CdKzORzxRNFuvT9Lknkk3
VsDmqG5He/QkgcNOC64EYz1HW1tYYGBDeS/T46NpsTLRILaApK9MsrEkAQPh
vj+QgvpdhIar7gWpvqdi+kh3FaYTg6weFLrqXExYGYDcFx1Pkdzgi/JpWUgi
jUhxEJSb1kpr2Fg4g2HhI06EinTjTdBgzAZEiLjT3MzV3HZK6h6z07fYDB3V
V4+i6ubByVWx8+D7X5eXi/qs3p+MT9PX27snP15d/qPOv9tPf/jLbr5YlS/+
/sP22aJev7p8+KIuZ481zWiSvb/+8bcieftw8vD1D4/ObpOrq6fF6If9tL5a
zN7cnjx7F58uXq5Pz/cnDy/Xr/Z216+eFnunF9uvb2a1S1baebF6MK7Ol8s3
v76e7a7+nk9+Oxt993BxcXiRPX6Sv52fraY/XIyWD3Zf5vu3O7Pp2+rbb/Rt
lJy//U+NKB2lWfE+HdoyQ/LTOCn/+k2czb6lshbudTiybwnCrcoVgRkLZK2F
mqdGdI9jTAq+9ZVhlUr4oL/NNfYCR2ezokU/7FFd5JmvQ+qrV0jlCufNCMIz
MDCryI3FdpM7WP7svbDe9yOzkqTLFfhc/bNxsbBRmgOQRBMMFRucP3VFqFjR
UhtmjP5BDcLqhonvgodWtQmb/0DAWxZLqqncBJVCQjmfq2vDOfFo0wokipEG
YEjwp6s/LVun/agzBU+RMkY4tAGJLAkkYy7sYtpeK2lwztIN21MlqlVVw9AB
3lNw/zWJnEJxjE81Fp/qhtMNsEGLnNS+9ypx11WWBSy2w2cGCD0Mqkj0o09W
MfM111rBdiYyFY9L45HIz+Lt7dRK2OrDUnRwE1GmmHtXO0prtMZLDOcs00Bx
xaFFPVgvxVuA4b1UR5CwBydjgxksD0V4bLLmfPoqNolde5aiE21MEk2j2lNr
Ax21Nnz52YYkJWU2YlEpp8hQyDmsI91pdCd5lUXRVuSDEhLS3ey4LcRtbyms
AUKEAaHIFQnqWiQfuiHsR7eOpVaVWVLSXRdBbdm7Gb6izzmoiqUhyDZ1zgze
KFIQHIg1gHmxaA0iZR7JWmXLwLXRjMOwgxxSKU+ikbYe2zGNjaSISo8Qq4pt
xG9pb9KcF2lgu9DCsG1c/gyBsCuy/XC4F13WyTJ6YLNtAT7TzoBputZBRtWG
wlS+JgyJU0Yxd6VQnJDnhHAtDGxWzSKPArld88IVoGnU8OmuhvRxyxvjNNyD
MxpY01AZFKU3au5ttsHWHqlhJyuuqJYGm0dcYMcmBa9bQhhqEZXAAEoN3n0o
tAmK2Wz9hZMotVxJGKepTHqDAKDFdNhSa9hD7NoCCddhdtSWQ0gCSmtuPo4l
ifitduGsbiYDtMrhBwb3OVssZy5sZiK/s7amZH2/o6zMoOkqb0zjCXx9paDe
9zstT8ZP/+lNm4KIbAglwyiJB8546QafODdeNypIuW0xL/siXxvxy3N+kTU+
qUv9bixsdVUMyuSq7OPRKIivcfBx6wqjANXmHtQz+4wFxgbV+JKVSRvHO4qr
N8Ruv5mNcjUf4ZISWvBUxEqgkRL2V2l0hZVVw4bQshAkGRoc5rpCRVqp7SZZ
V/beRzanqJ6XFDgVq9elDuLa26uX3JySY6rdRtGIYrkBtygKJH9RKu/flVQ1
jC45/A5vOt8p15mdbqZli76HO1c58XUe2ezmi7n2I+4H2IQfVS9KTOi8ljJO
4SrpRVf1YjOlCe0TvD72I34qVwTRWJip0qq2JFqJKNqOcWrIWxK5qCNZHsiR
5uzwkQLRjsVyIXPAobfHl9EqDHAFSEogqMs8UomuwtSmQiOFuUybOHytuagz
grip4miMeZksODDKaIOOd1q/B1mOFwXOxSbj8CmtOO/8yBRZ2IznbfrU8PTI
D90IzKMaa1zWSuPsHaUQXW9JtQGMb9p72+Oxs2g2Iu7xQDeH/gT3SSyarjdr
X7Kt+oLycdXyb9DKGhmPjnpXW1uh7G4rqAVxi8GF47BGyovwki5qG1TZn8y+
Tpan5dwkCligFxUvLvRwWIAE5VYpT99QeOnw62uu2rrjLqOOSzqSG6g7x5XF
9GZPGrU7m3DbOxdd2QY3dyj1Ng2G8p3UKielg/XVwpanbp6MzTZy1lln3+80
9DWro2KcUtM/YbChf9cexmHIb2abKkwmLVZIvpNG0pIfWAShJjxYaXkTFvyL
MbEInzKkMK6c5JRna673EIsLtBHTaVywXmohIHqJZZPpnGxFVhhQs7LfrUWv
r0xpUL2arQdS/wRFedDFDR4ydepN5GTqqRnVGeRWTZLHqtX/idfriTdi0TOf
4+UB4SQUV/6zLdYIp+iKLoika7lL1bB+cvbPyw2pusQDkoDnRcGGGZf+nLKL
MWnll1AaHXdCeEfxZB3+XJvIhr2wbljSxtapKjzr7/BQeMnCeoKfi3yNZpVM
ZR48wiKtrh9AIKV68DfIx+XZ8fenrxpA+vDh+Or8coDxazsPD4Y3Ozt7qKc4
CkzzSq+W4+67S4rKgFQlxht006qsGGcFTO8RoR0eEXACEogsQRtGF4YyCWmm
KKV2OFQtLuIN941oDOURul5GApJmJKBryVMpHglehLTIpyDfXclbGrYEZptW
gQDVaZtxWaYdgj776bIx/7X1xvUVOCPwbHFllWZN7c5C3FqJW5bCP4XFt6nY
tvVv6ABUgXvr49abeJ0V8USnJW8yvH/c+1Mxkp8KvSRiNKG/7ScHDw4fDpJH
j0eD3b3J/iCG74ODvcPDBw8ODhDdN4dWctXLRnkNqrvSbfPioiuuPDsjkCNN
XdiR3BWKZ5gmSTnSaVdd83SPqPSQzyzOLV1z6O1G9rTFd0Jv8hhhBk5d79wp
+YHsTrtx1l8ec6O0XLDKVI2wO/+Oq2JrFP6gQ1CrmJ72xgW+HhgHW6YNHB7N
bShP1lpyAh4qSomYB62xTGagBXLtgOiZRE6dGxHyuGFQOKG4CEzA53LaH7e2
niRr5JGAVFyZoVF/Yd7QC7R/C8fo1bEiitYbI6r/cOcxRosaM0yZaEC1YVTz
1SLOB1w6MwvnaSebmw5sts/YhvQ2mxWGGcRuKG1opV4zDUFnDzxpuOn4GhQ/
lnjRGaCWc/YqZaBXSijg5gVjFBEdnq+UuOlRlx7PPJKjHny2TwyAWtdoP5VQ
f41bdTq8ZoujSFrhPpzmS34VG25aUcoRVxRGk0CetOHiWovIJZYSB9JiksUS
2hS1ybL7ooggfxZoW2jm/SFcipL6XmE58XIW5xLBRyvHbBPp+93I3pdWSSE6
k5GDQiAlPybliOVgmHupiFyxJFCw4XkGeumaBogBlPk1fbzFKSkkaF2s7utS
56Dil1hxr2LjNUag9DV6OqJibPgy4E1NwjqsAJVizu2kAD0+D+cDVWdpoEzy
XBae4hxyaZYoESiVG3ENWMZ/Lh3BqgZif58zywhWmco3rtKtXqFbDTTMgUxe
5xhdYyAN2Jdi/epiOogH/Jn2085QY2wVr5HPZqPiN2GEurzgMHdUFmIAVhxv
3iKWjPEjRnMeY1kJQqaKPc0+4+22HeToFOFGiFgzE5hceziPo8XOzwcKxzGn
Xh6/Ooatz0BwLDm9hJJelCEhkSkyU71APTuBEkE9N76BNSXseSE7Fln51Ktj
uKl2s+qoV0WWEsq3QVGsy/vEmooWO5rCBihRh2R3pt22mwKZ6WiUvq8wKW3k
c477Nr2p8enrZL2t6Qb8vncUa7sSUpO5QINONoy+E+9UUMJHdqDTcRFlLq2F
e7DJxl4wl8RMeIiX7HsfCHdwnec90tsCugbFKg2/A7TAfnpIVEhe18Qi1pqV
0evFZ401nIYZsksHc30rST24smxQxhQ/hPoMTd2E8FzY8ZYSucFAl2hWFqul
9LriHQoHfE9VmFzEftuLtxHmJEUcj5EUADuY8c3a2vpRswWIqNA0QC9BTwRw
RWdwisUYqOdFMQJBG1A5hmsDX1dVFZ0VqyrDiJPTEoDwZFXOkDYdZ8k4epbk
wO2SrB89gXt0AsLRiFodPY+B+YIyek3lKZ8DD4ezuQSVppKmAVoOpFrNZtwe
qOpTYarktq+1p7inE+6G7u1JCOQPX+GvH7lfWtjh7kTLQdlYJjHjGoZEo7KC
VSYJEQhvY8QHuoatPP3o6LX68MHuY27+QZfoFRCgI778+tNT8q6SEf+oGWlg
RD54HI5nhqHTeV0WiOFH0fnp5XdbW5eBOv1U9nevun8U/QxLwF3/0l5A+pkr
0Ipe/7a14HXrXIppQ/inZ0Szm1o52VmDT/Mx3lMyfD86NZbjz8YWrmKRUDtx
QZTfN5fHINXByfvAPMKZWITqMHK5rYlJ0bpTGJRX5E0hkxwzpM/cEbcblU0F
C9sUPSRydPC8KZw3mXjZsfcZgOkxDcSEBxrMCZs4wcYIJlcPbeVy6kLMuFBT
ibhWBBxuxa4/t9SEwbqM4hMTJWtK7RBpTh9PBlQq7EKg3rp3ZHyVqoBYuVlS
GTxPb56kU0disi6Ni2y1yP0CpYog/rgbfRv18Pr0hDTij3v444WrHKg3oceO
HXM6Qi/liKTEH5ULQtVaRBtXjpVd8Dqqj63ygggczihLZ1JficxM6Jxw1Nv7
H0BjInWYTLT0jDYDUsulw0WpQTi569SlpxY7lIJ+QDbZAAVVOHFK70UmnMVL
24+ZaoqW3nYR6DZqV+dqBYJqLmKSD4YY0qV6ZlpMSf8iOa0aGYauRUltDCtg
Bbp3KCb2fWL13KURUH9al7NP+ZHixbCP0BbtQ6rukJrTB4V4XZH8IdUcRcvx
FoqOoLdmsJvLlonzRoybmEnDMVjzcbGJptSk+K2VlyIWsornhUWTbsVuEMQM
RdcwqE8bwYq7fIolCdZcsaMvMQckb0mj0qReLeVW+Z6Zgg6yMLG6LmzTTLMg
7/SSjh5ShmtTlOIZBweHwXTjOYbl48OSTSfFbiSDvqE/IFWRzLZm6pqGGZam
Q19nxpnESDSqSLhOr60+omrxa7RVbxuhuagzE1Kfe4JHAm8S0lF9gZQzEdgy
1Whla4+7BqH2NxbFZXC+pXTqOk8YtAdX9AJAHGfN66Yyv1K8vrNuSFnDKSj0
qSMJsbhKg27p6I1Ps4oAhxsAfL7BWM0yrVDRfAJaMXWVcYeFVCsvbLK16tJI
sagarEewvi4viNZkXKArR9gMJIbynKgzV8OLa4rl2mzty/M3/ajhqncpTqkN
zsXeqzAJqJpwlco4Jyv7gFKqvEcar9ecXfxYEQQDLcRFS0p7ArhXTeCyL5lE
yU3l/LDG7g0qaekr8iQE3V9BwLMr5QDtK+Ixyq04sgNx7jZHTwBnoHPJAayy
K80WgNxx7hhCGg+l1VpMblaaD9SnhKQxl6AasZ65crZIGhk4ndWEvN2TLXtU
NJJ9hxuzpBfxteieVWLXewOIhybWYVDqFq4r3VZzWdGd5iucbGjL6HxOHd0Y
g5bEpmVgM4ZXyydy/qGtcjJS77LL9Ol4z7zQQZtlv2xI0OT4ZJkV66Aqz/fn
Uu6rT0q569zsbiZV3+Cw2pVPnws66UjvHCkGY7LUkRY2Wmo34tZVhoeXbvAl
L02AzFNUrvFgAwJKfxtgqIzcyPEnDFvOo6S4P7IHELUy+HCZ5uNE2mM6+qUu
e7M5uAiuknEl9l2uLQ3Pt/v8UPqE8/4FmQGII6Ecp62M1N5LQR2hCz7tsS3R
RnEEINaGohwiCEg0nidjug1TNkL6HoOUkhPjidIB8/66K8gWZSgvikhS24Cx
Tb5ULf29yjnlnWvdUYo4Z8kwtTZlL0okklQyO2z3BCPVYxDPyUHtyCEyi6Bn
ZsPZLWSCjHC4WcAz2DW5Xsp1eCSc4ntTpBMpeiJ1DQRvYFZDB7WTE+XPzxoG
vb5Iy4S7by9euFrlVcMEF4jeE9TZS2zIIBJ27iJN5nG5QHuPnmAn8cMinsCs
0oVcvo6IsYjJ1P7jR7az7ENfK2VWFBPrnHImSiFplG9OUDF8kysrh6wk2DWr
3SHR7eww7/PSg0tN4XQca7PKTZEBtjdpjbxaBVcOGqAE9Wap5FZ9CJKDnuqs
J3ZWpug7hzvUPpZzcRbIzWNOosoLvboCENmJ9Wiys0TihLwlVAJGSk8WXdyO
TkUYG8zn4O8N7IqncNPzIh8Y0Kj06+66LkJKxbshmoENzuSMN12Dhajzc103
zc80k6grzNHV6Nt1jsMmBvjWp15MbhsFhacieVImofF1aiX3IJYhR+zOZYns
7q7tCBttcBrcJ0DawWAAQuL4euv/ABKLMmaTAQEA info about a caller associated with "display-name"
   in SIP ...

   ... even in traditional calling name services today ...

   While in the traditional telephone network, ...
-->

</rfc>