<?xml version="1.0" encoding="US-ASCII"?>
<!--
vim:et:ts=2:sw=2:spell:spelllang=en:tw=80
-->
<!-- This template is for creating an Internet Draft using xml2rfc,
    which is available here: http://xml.resource.org. --> version='1.0' encoding='UTF-8'?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC7340 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7340.xml">
<!ENTITY RFC8224 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8224.xml">
<!ENTITY RFC8225 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8225.xml">
<!ENTITY RFC8226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8226.xml">
<!ENTITY RFC8816 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8816.xml">
<!ENTITY RFC8816 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8816.xml"> nbsp    "&#160;">
  <!ENTITY RFC9060 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9060.xml"> zwsp   "&#8203;">
  <!ENTITY RFC7258 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7258.xml"> nbhy   "&#8209;">
  <!ENTITY RFC8588 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8588.xml">
<!ENTITY RFC9325 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9325.xml">
<!ENTITY RFC9110 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9110.xml"> wj     "&#8288;">
]>
<!--?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?-->
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
    please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
    (Here they are set differently than their defaults in xml2rfc v1.32) -->
<!--?rfc strict="yes" ?-->
<!-- give errors regarding ID-nits and DTD validation -->

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

  <front>
    <title abbrev="Service Provider OOB">Out-of-Band Secure Telephone Identity Revisited (STIR) for Service Providers</title>

<!-- control [rfced] We had the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- following questions/comments about the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead
     document title:

a) Please note that the title of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
    (using these PIs document has been updated as follows is recommended by the RFC Editor) -->
<?rfc compact="no" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list
follows:

Abbreviations have been expanded per Section 3.6 of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-stir-servprovider-oob-08"
     ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
    ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902, RFC 7322 ("RFC
Style Guide"). Please review.

Original:
Out-of-Band STIR for Service Providers

Current:
Out-of-Band Secure Telephone Identity Revisited (STIR) for Service
Providers

b) Should "Framework" or pre5378Trust200902
    you can add the attributes updates="NNNN" and obsoletes="NNNN"
    they will automatically something be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - added after (STIR) (once
expanded, it is only necessary if doesn't seem like a noun anymore...).  See also our
change to the
         full title is longer than 39 characters -->

    <title abbrev="Service Provider OOB">Out-of-Band STIR first sentence of the Introduction.

Perhaps:
Out-of-Band Secure Telephone Identity Revisited (STIR) Framework for
Service Providers</title> Providers
-->

    <seriesInfo name="RFC" value="9888"/>
    <author initials="J." surname="Peterson" fullname="Jon Peterson">
      <organization abbrev="TransUnion">TransUnion</organization>
      <address>
        <email>jon.peterson@transunion.com</email>
      </address>
    </author>
    <date year="2025" />

    <!--    <area>
    ART
    </area>--> month="October"/>
    <area>ART</area>
    <workgroup>stir</workgroup>

    <keyword>SIP</keyword>

    <abstract>
      <t>
The Secure Telephone Identity Revisited (STIR) framework defines means of carrying its Personal Assertion Tokens (PASSporTs) either in-band, within the headers of a Session Initiation Protocol (SIP) request, or out-of-band, through a service that stores PASSporTs for retrieval by relying parties. This specification defines a way that the out-of-band conveyance of PASSporTs can be used to support large service providers, providers for cases in which in-band STIR conveyance is not universally available.
      </t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>
   <xref target="RFC8224">Secure
   The Secure Telephone Identity Revisited (STIR)</xref> (STIR) <xref target="RFC8224" format="default"></xref> framework provides a cryptographic assurance of the identity of calling parties in order to prevent impersonation,
   which is a key enabler of unwanted robocalls, swatting, vishing, voicemail hacking, and similar attacks (see <xref target="RFC7340"/>). target="RFC7340" format="default"/>). The STIR out-of-band <xref target="RFC8816">out-of-band</xref> target="RFC8816" format="default"></xref> framework enables the delivery of PASSporT <xref target="RFC8225">PASSporT</xref> target="RFC8225" format="default"></xref> objects through a Call Placement Service (CPS), rather than carrying them within a signaling protocol such as SIP. Out-of-band conveyance is valuable when end-to-end SIP delivery of calls is partly or entirely unavailable due to network border policies, calls routinely transiting a gateway to the Public Switched Telephone Network (PSTN), or similar circumstances.
    </t><t>
      </t>
      <t>
   While out-of-band STIR can be implemented as an open Internet service, it then requires complex security and privacy measures to enable the CPS function without allowing the CPS to collect data about the parties placing calls. This specification describes CPS implementations that act specifically on behalf of service providers who will be processing the calls that STIR secures, and thus secures and, thus, who will necessarily know the parties communicating, so an alternative security architecture becomes possible. These functions may be crucial to the adoption of STIR in some environments, like legacy non-IP telephone networks, where in-band transmission of PASSporTs may not be feasible.
    </t><t>
      </t>
      <t>
   Environments that might support this flavor of STIR out-of-band include carriers, large enterprises, call centers, or any Internet service that aggregates on behalf of a large number of telephone endpoints. That last case may include PSTN gateway or  interexchange or international transit providers.
      </t>
    </section>
    <section title="Terminology">

<t>The numbered="true" toc="default">
      <name>Terminology</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<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="arch" title="Service numbered="true" toc="default">
      <name>Service Provider Deployment Architecture for Out-of-Band STIR"> STIR</name>
      <t>
	The architecture in this specification assumes that every participating service provider is associated with one or more designated CPS instances. A service provider's CPS serves as a place where callers, or callers or, in some cases gateways, cases, gateways can deposit a PASSporT when attempting to place a call to a subscriber of the destination service provider; if the caller's domain supports in-band STIR, this can be done at the same time as an in-band STIR call is placed. The terminating service provider could operate the CPS themselves, or a third party could operate the CPS on the destination's behalf. This model does not assume a monolithic CPS that acts on behalf of all service providers,  nor does it prohibit multiple service providers from sharing a CPS provider. Moreover, a particular CPS can be a logically distributed entity compromised of several geographically distant entities that flood PASSporTs among themselves to support an anycast-like service.
	  	</t><t>
      </t>
      <t>
	The process of locating a destination CPS and submitting a PASSporT naturally requires Internet connectivity to the CPS. If the CPS is deployed in the terminating service provider network, any such network connectivity could instead be leveraged by a caller to initiate a SIP session, during which in-band STIR could be used normally. The Therefore, the applicability of this architecture is therefore to those cases where, for whatever reason, SIP requests cannot reliably convey PASSporTs end-to-end, but an HTTP transaction can reliably be sent to the CPS from an out-of-band authentication service (OOB-AS). It is hoped that as IP connectivity between telephone providers increases, there will be less need for an out-of-band mechanism, but it can serve as a fallback mechanism in cases where service providers cannot predict whether end-to-end delivery of SIP calls will occur.
      </t>
    </section>
    <section anchor="adv" title="Advertising numbered="true" toc="default">
      <name>Advertising a CPS"> CPS</name>
      <t>
	If more than one CPS exists for a given deployment, there will need to be some means of discovering CPSs, either administratively or programmatically. Many service providers have bilateral agreements to peer with one another, and another; in those environments, identifying their respective CPS's CPSs could be a simple matter of provisioning. A consortium of service providers could agree to choose from a list of available CPS providers, say. But in more pluralist environments, some mechanism is needed to discover the CPS associated with the target of a call.
	    </t><t>
      </t>
      <t>
    In order to allow the CPS chosen by a service provider to be discovered securely, this specification defines a CPS advertisement. Effectively, a CPS advertisement is a document
	 which
	 that contains the URL of a CPS, CPS as well as any information needed to determine which PASSporTs should be submitted to that CPS (e.g., Service Provider Codes (SPCs) or telephone number ranges). An advertisement may be signed with a STIR <xref target="RFC8226"/> credential, target="RFC8226" format="default"/> credential or another credential that is trusted by the participants in a given STIR environment. The advantage to signing with STIR certificates is that they contain a "TNAuthList" value indicating the telephone network resources that a service provider controls. This information can be matched with a TNAuthList value in the CPS advertisement to determine whether the signer has the authority to advertise a particular CPS as the proper destination for PASSporTs.
	  	</t><t>
      </t>
      <t>
      The format of a service provider CPS advertisement consists of a simple JSON object containing one or more pairs of TNAuthList values pointing to the URIs of CPSs, e.g. { for example:</t>
      <t>{ "0-1234":"https://cps.example.com" }. The }</t>
      <t>The format of this is a hyphen-separated concatenation of each <xref target="RFC8226"/> target="RFC8226" format="default"/> TNAuthList TNEntry value ("0" for SPC, "1" for telephone number range, "2" for individual telephone number) with the corresponding TNAuthList value. Note for in case "1", telephone number ranges are expressed by a starting telephone number followed by a count, and the count itself is here also by itself; they are hyphen-separated from the TN (e.g., "1-15714341000-99"). An advertisement can contain multiple such ranges by adding more pairs. CPS URIs MUST <bcp14>MUST</bcp14> be HTTPS URIs <xref target="RFC9110"/> (Section 4.2.2). (<xref target="RFC9110" sectionFormat="comma" section="4.2.2"/>). These CPS URIs SHOULD <bcp14>SHOULD</bcp14> be
	publicly reachable, reachable as service providers cannot usually anticipate all of the potential callers that might want to connect with them, but them; however, in more constrained environments, they MAY <bcp14>MAY</bcp14> be only reachable over a closed network.
		</t><t>
      </t>
      <t>
	Advertising an SPC may be inappropriate in environments where an originating domain has no ready means to determine whether a given called telephone number falls within the scope of an SPC (such as a national routing database that maps telephone numbers to SPCs). In such environments, TN-based advertisements could enable discovery instead. Also, note that PASSporTs can be used to sign communication where the "orig" and/or "dest" are not telephone numbers as such, but instead URI-based identifiers; typically, these PASSporTs typically would not be signed by an a certificate as described in <xref target="RFC8226"/> certificate, target="RFC8226" format="default"/> and any future specification would be required to identify URI-based prefixes for CPS advertisements.
		</t><t>
      </t>
      <t>
	CPS advertisements could be made available through existing or new databases, potentially aggregated across multiple service providers and distributed to call originators as necessary. They could be discovered during the call routing process, including through a DNS lookup. They could be shared through a distributed database among the participants in a multilateral peering arrangement.
		</t><t>
      </t>
      <t>
	An alternative to CPS advertisements that may be usable in some environments is adding a field to STIR <xref target="RFC8226"/> certificates as described in <xref target="RFC8226" format="default"/> identifying the CPS URI issued to individual service providers. As these certificates are themselves
	signed by a CA Certificate Authority (CA) and contain their own TNAuthList, the URI would be bound securely to the proper telephone network identifiers. As STIR assumes a community of relying parties who trust these credentials, this method perhaps best mirrors the trust model required to allow a CPS to authorize PASSporT submission and retrieval.
      </t>
    </section>
    <section anchor="store" title="Submitting numbered="true" toc="default">
      <name>Submitting a PASSporT"> PASSporT</name>
      <t>
    Submitting a PASSporT to a CPS as specified in the STIR <xref target="RFC8816">out-of-band target="RFC8816" format="default">out-of-band framework</xref> requires security measures that are intended to prevent the CPS from learning the identity of the caller (or callee) to the degree possible. In However, in this service provider case, however, the CPS is operated by the service provider of the callee (or an entity operating on their behalf), and behalf) and, as such such, the information that appears in the PASSporT is redundant with call signaling that the terminating party will receive anyway (see <xref target="Security"/> target="Security" format="default"/> for potential data minimization concerns). Therefore, the service provider out-of-band framework does not attempt to conceal the identity of the originating or terminating party from the CPS.
	  	</t><t>
      </t>
      <t>
    An out-of-band authentication service (OOB-AS) forms a secure connection with the target CPS. This may happen at the time a call is being placed, placed or it may be a persistent connection if there is a significant volume of traffic sent over this interface. The OOB-AS SHOULD <bcp14>SHOULD</bcp14> authenticate itself to the CPS via mutual TLS (see <xref target="RFC9325"/>) target="RFC9325" format="default"/>) using its STIR credential <xref target="RFC8226"/>, target="RFC8226" format="default"/>, the same one it would use to sign calls; this helps mitigate the risk of flooding that more open more-open OOB implementations may face. Furthermore, the use of mutual TLS prevents attackers from replaying captured PASSporTs to the CPS. A CPS makes its own policy decision as to whether it will accept calls from a particular OOB-AS, and at what volumes.
	</t><t>
      </t>
      <t>
	A CPS can use this mechanism to authorize service providers who already hold STIR credentials to submit PASSporTs to a CPS, but alternative mechanisms would be required for any entities that do not hold a STIR credential, including gateway or transit providers who want to submit PASSporTs. See <xref target="gatewaying"/> below target="gatewaying" format="default"/> for more on their behavior.
	    </t><t>
      </t>
      <t>
	Service provider out-of-band PASSporTs do not need to be encrypted for storage at the CPS, although the use of transport-layer security TLS to prevent eavesdropping on the connection between the CPS and OOB-ASs is REQUIRED. <bcp14>REQUIRED</bcp14>. PASSporTs will typically be submitted to the CPS at the time they are created by an AS; if the PASSporT is also being used for in-band transit within a SIP request, the PASSporT can be submitted to the CPS before or after the SIP request is sent, at the discretion of the originating domain. An OOB-AS MUST <bcp14>MUST</bcp14> implement a REST Representational State Transfer (REST) interface to submit PASSporTs to the CPS as described in <xref target="RFC8816"/> Section 9. target="RFC8816" sectionFormat="comma" section="9"/>. PASSporTs persist at the CPS for as long as is required for them to be retrieved (see the next section), but <xref target="retrieval"/>) but, in any event event, for no longer than the freshness interval of the PASSporT itself (a maximum of sixty seconds).
      </t>
    </section>
    <section anchor="retrieval" title="PASSporT Retrieval"> numbered="true" toc="default">
      <name>PASSporT Retrieval</name>

      <t>
	The STIR out-of-band framework <xref target="RFC8816">out-of-band framework</xref> target="RFC8816" format="default"></xref> proposes two means by which called parties can acquire PASSporTs out-of-band: through a retrieval interface, interface or a subscription interface. In the service provider context, where many calls to or from the same number may pass through a CPS simultaneously, an out-of-band capable out-of-band-capable verification service (OOB-VS) may therefore operate in one of two modes: it can either pull PASSporTs from the CPS after calls arrive or receive push notifications from the CPS for incoming calls.
	</t><t>
      </t>
      <t>
	CPS implementations MUST <bcp14>MUST</bcp14> support pulling of the PASSpoRTs PASSporTs via the REST flow described in <xref target="RFC8816"/> Section 9. target="RFC8816" sectionFormat="comma" section="9"/>. In the pull model, a terminating service provider polls the CPS via its OOB-VS after having received a call for which the call signaling does not itself carry a PASSporT. Exactly how a CPS determines which PASSporTs an OOB-VS is eligible to receive over this interface is a matter of local policy. If a CPS serves only one service provider, then all PASSporTs submitted to the CPS are made available to the OOB-VS of that provider; indeed, the CPS and OOB-VS may be colocated or effectively operated as a consolidated system. In a multi-provider environment, the STIR credential of the terminating domain can be used by the CPS to determine the range of TNAuthLists for which an OOB-VS is entitled to receive PASSporTs; this may be through a mechanism like mutual TLS, TLS or through using the use of the STIR credential to sign a token that is submitted to the CPS by the retrieving OOB-VS. Note that a multi-provider CPS will need to inspect the "dest" element of a PASSporT to determine which OOB-VS should receive the PASSporT.
	</t><t>
      </t>
      <t>
    In a push model, an OOB-VS could could, for example example, subscribe to a range of telephone numbers or SPCs, which will be directed to that OOB-VS by the CPS (provided the OOB-VS is authorized to receive them by the CPS). PASSporT might be sent to the OOB-VS either before or after unsigned call signaling has been received by the terminating domain. In either model, the terminating side may need to delay rendering a call verification indicator when alerting, in order to await the potential arrival of a PASSporT at the OOB-VS. The exact timing of this, and its interaction with the substitution attack described in <xref target="RFC8816"/> Section 7.4, target="RFC8816" sectionFormat="comma" section="7.4"/>, is left for future work.
      </t>
    </section>
    <section anchor="gatewaying" title="Gateways"> numbered="true" toc="default">
      <name>Gateways</name>
      <t>
	In some deployment architectures, gateways might perform a function that interfaces with a CPS for the retrieval or storage of PASSporTs, especially in cases when in-band STIR service providers need to exchange secure calls with providers that can only be reached by STIR out-of-band. For example, a closed network of in-band STIR providers may send SIP INVITEs to a gateway in front of a traditional PSTN tandem that services a set of legacy service providers. In that environment, a gateway might extract a PASSporT from an in-band SIP INVITE and store it in a CPS that was established to handle requests for one or more legacy providers, who who, in turn turn, consume those PASSporTs through an OOB-VS to assist in robocall mitigation and similar functions.
    </t><t>
      </t>
      <t>
	The simplest way to implement a gateway performing this sort of function for a service provider CPS system is to issue credentials to the gateway that allow it to act on behalf of the legacy service providers it supports: this would allow it to both add PASSporTs to the CPS acting on behalf of the legacy providers and also to create PASSporTs for in-band STIR conveyance from the legacy-providers to terminating service providers in the closed STIR network. For example, a service provider could issue a delegate certificate <xref target="RFC9060"/> target="RFC9060" format="default"/> for this purpose.
      </t>
    </section>
    <section anchor="Acknowledgments" title="Acknowledgments">
      <t>We would like to thank Alex Fenichel for contributing to this specification.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>

<t>This memo includes document has no request to IANA.</t> IANA actions.</t>

    </section>
    <section anchor="privacy" title="Privacy Considerations"> numbered="true" toc="default">
      <name>Privacy Considerations</name>
      <t>
The analysis of out-of-band STIR in the Privacy Considerations "Privacy Considerations" section of <xref target="RFC8816"/> target="RFC8816" format="default"/> differs considerably from this document. Per <xref target="intro"/>, target="intro" format="default"/>, this specification was motivated in part by choosing a different privacy architecture than <xref target="RFC8816"/>, target="RFC8816" format="default"/>, one in which the CPS is operated by a service provider who is a party to the call itself, and thus itself and, thus, would independently have access to the call metadata captured in a PASSporT.
    </t><t>
      </t>
      <t>
That said, in cases where a third-party service operates the verification service function on behalf of a carrier, that third party third-party service would indeed be privy to this metadata. That said, it It is a fairly common situation for third party third-party services to receive this sort of metadata to perform tasks related to billing, security, number translation, and so on, and on; existing data governance agreements could be readily applied to the out-of-band STIR use case.
    </t><t>
      </t>
      <t>
Finally, note that PASSporTs are extensible tokens, and it is conceivable that they might contain data that is not otherwise carried in SIP signaling or that would ordinarily be considered a component of call metadata. Any such extensions might have specific interactions with the privacy of both in-band and out-of-band STIR which that their specifications would need to elaborate.
      </t>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>

<!--[rfced] We had a few questions about the following sentence:

Original:
Moreover, any additional information included in a PASSporT which is
not strictly redundant with the contents of a SIP request increases
data collection concerns; while baseline [RFC8225] PASSporTs only
contain information otherwise in the SIP request.

a) Please help us clarify the subject of "which".  Is it "information"
or is it "PASSporT"?

b) Could the "while" be removed?  This seems to be further
information, not contrasting information?

c) Please clarify "only contain information otherwise in the SIP
request". Does this mean only redundant information?

Perhaps:
Moreover, in a PASSporT, any additional information that is not
strictly redundant with the contents of a SIP request increases data
collection concerns; baseline [RFC8225] PASSporTs only contain
information redundant with the SIP request.

-->

      <t>
	  The Security Considerations security considerations of <xref target="RFC8816"/> target="RFC8816" format="default"/> apply to this documen, document, including concerns about potential denial-of-service vectors and traffic analysis. However, that specification's model focused a great deal on the privacy implications of uploading PASSporTs to a third-party web service. This draft document mitigates those concerns by making the CPS one of the parties to call setup (or an entity contractually acting on their behalf). That said, any architecture in which PASSporTs are shared with a federated or centralized CPS raises potential concerns about data collection <xref target="RFC7258"/>. target="RFC7258" format="default"/>. Moreover, any additional information included in a PASSporT which that is not strictly redundant with the contents of a SIP request increases data collection concerns; while baseline <xref target="RFC8225"/> target="RFC8225" format="default"/> PASSporTs only contain information otherwise in the SIP request. Existing and future extensions (e.g. <xref target="RFC8588"/> (e.g., the "origid" field) field described in <xref target="RFC8588" format="default"/>) might leak further information.
	  </t><t>
      </t>
      <t>
	  Unlike <xref target="RFC8816"/>, target="RFC8816" format="default"/>, this document proposes the use of STIR certificates to authenticate transactions with a CPS as well as signatures for CPS advertisements. This presumes an environment where STIR certificates are issued by trust anchors which that are already trusted by the CPS, potentially to gateways and similar services. Common STIR deployments use Service Provider Codes (SPCs) instead of telephone number ranges to identify service providers today; determining whether a given SPC entitles a service provider to access PASSporTs for a given telephone number is not trivial, but is a necessary component of this CPS architecture. Otherwise, if anyone with a STIR certificate were able to publish or access PASSporTs for any telephone number, this could lead to an undesirable environment where effectively anyone with a STIR certificate could acquire PASSporTs for calls in progress to any service provider.
      </t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <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"/>
        <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.8816.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9325.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <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.9060.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7258.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8588.xml"/>
      </references>
    </references>

    <section anchor="Acknowledgments" numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>Thank you to <contact fullname="Alex Fenichel"/> for contributing to this specification.</t>
    </section>

<!-- References split into informative [rfced] Please review the "Inclusive Language" portion of the
     online Style Guide
     <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
     and normative -->

    <!-- There let us know if any changes are 2 ways to insert reference entries from needed.  Updates of this
     nature typically result in more precise language, which is
     helpful for readers.

Note that our script did not flag any words in particular, but this
should still be reviewed as a best practice.

In addition, please consider whether "tradition" should be updated for
clarity.  While the citation libraries:
    1. define an ENTITY at 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 the top, and use "ampersand character"RFC2629; here (as shown)
    2. simply use same for everyone.

Original:
..may send SIP INVITEs to a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
       (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

    Both are cited textually gateway in front of a traditional PSTN...
-->

<!-- [rfced] We had the same manner: by using xref elements.
    If you following questions/comments about
     abbreviation use throughout the PI option, xml2rfc will, by default, try to find included files document:

a) FYI - We have added expansions for abbreviations upon first use per
Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the same
    directory as document carefully to ensure correctness.

b) FYI - We will update to use the including file. You can also define abbreviation only after the XML_LIBRARY environment variable first
use for the following abbreviations in accordance with a value containing a set
https://www.rfc-editor.org/styleguide/part2/#exp_abbrev:

OOB-AS
SPC

-->

<!--[rfced] Please review the use of directories to search.  These can be either in citation tags throughout the local
    filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Normative References">
&RFC2119;
&RFC8174;
&RFC8224;
&RFC8225;
&RFC8226;
&RFC8816;
&RFC9325;
&RFC9110;
	</references>
    <references title="Informative References">
&RFC7340;
&RFC9060;
&RFC7258;
&RFC8588;

    </references>
     document: some are read as part of the sentence while others are
     not syntactically relevant.

Please see https://www.rfc-editor.org/styleguide/part2/#citation_usage
for further information/guidance.-->

<!--[rfced] We see the following similar terminology used throughout
     the document.  Please let us know if/how we may make these
     consistent.

STIR credential vs. STIR certificate vs. STIR [RFC8816] certificate

out-of-band STIR vs. STIR out-of-band vs. STIR out-of-band framework [RFC8816]

-->

  </back>
</rfc>