VESPER Out-of-Band OOB
draft-wendt-stir-vesper-oob-03
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Chris Wendt , Robert Śliwa | ||
| Last updated | 2026-07-06 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wendt-stir-vesper-oob-03
Secure Telephone Identity Revisited C. Wendt
Internet-Draft R. Śliwa
Intended status: Standards Track Somos Inc.
Expires: 7 January 2027 6 July 2026
VESPER Out-of-Band OOB
draft-wendt-stir-vesper-oob-03
Abstract
This document describes a mechanism for delivering authenticated
telephone call identity information using the VESPER framework for
use where in-band signaling does not carry the identity end to end,
or where there is no in-band path between the parties at all. By
supporting an out-of-band (OOB) transport model, this approach
enables entities to publish and retrieve signed PASSporT assertions
independent of end-to-end delivery within an in-band signaling path
such as a SIP-based VoIP network. These PASSporTs are signed with
VESPER delegate certificates, which identify the entity holding the
right-to-use for a telephone number and bind it to that entity's
domain identity. This document also introduces support for Connected
Identity to the STIR OOB model, enabling the called party to respond
with a signed PASSporT asserting its identity, thereby binding the
identities of both parties to the transaction and enhancing end-to-
end accountability. The OOB mechanism provides a delivery path for
PASSporTs where in-band delivery within a signaling path such as SIP
is unavailable or is not the path used, enabling verifiers to confirm
the association between the originating telephone number and the
identity asserting authority as part of the broader VESPER trust
framework.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://github.com/appliedbits/draft-wendt-stir-vesper-oob. Status
information for this document may be found at
https://datatracker.ietf.org/doc/draft-wendt-stir-vesper-oob/.
Discussion of this document takes place on the Secure Telephone
Identity Revisited Working Group mailing list (mailto:stir@ietf.org),
which is archived at https://mailarchive.ietf.org/arch/browse/stir/.
Subscribe at https://www.ietf.org/mailman/listinfo/stir/.
Source for this draft and an issue tracker can be found at
https://github.com/appliedbits/draft-wendt-stir-vesper-oob.
Wendt & Śliwa Expires 7 January 2027 [Page 1]
Internet-Draft VESPER OOB July 2026
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 7 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. VESPER OOB Architectural Overview . . . . . . . . . . . . . . 5
4. VESPER OOB Mechanism . . . . . . . . . . . . . . . . . . . . 6
4.1. Operations . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Required Properties . . . . . . . . . . . . . . . . . . . 7
4.3. Mechanism Flow . . . . . . . . . . . . . . . . . . . . . 8
5. Authentication Service Procedures for VESPER OOB . . . . . . 10
5.1. Delegate Certificate Requirements . . . . . . . . . . . . 10
5.2. PASSporT Construction Requirements . . . . . . . . . . . 10
6. PPS URI and OOB PPS Discovery . . . . . . . . . . . . . . . . 11
7. Verification Service Procedures for VESPER OOB . . . . . . . 12
7.1. Retrieval and Validation Process . . . . . . . . . . . . 12
7.2. PASSporT Validation . . . . . . . . . . . . . . . . . . . 13
7.3. Connected Identity Validation . . . . . . . . . . . . . . 13
Wendt & Śliwa Expires 7 January 2027 [Page 2]
Internet-Draft VESPER OOB July 2026
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
The STIR framework enables the signing and verification of telephone
communications using PASSporT [RFC8225] objects carried in SIP
[RFC3261] in Identity Header Fields defined in [RFC8224]. However,
there are scenarios where SIP-based in-band transmission is not
feasible or the Identity Header Field may not be supported, such as
legacy TDM interconnects or where intermediary network elements strip
SIP Identity headers. STIR Out-of-Band (OOB) [RFC8816] addresses
this generally for STIR by defining an OOB delivery model. [RFC9888]
applies that model to interconnected service providers, using
provider-operated placement services discovered through service-
provider advertisements, whereas this document applies the model to
entities identified by VESPER delegate certificates, with placement
services discovered through certificate transparency.
The VESPER framework [I-D.wendt-stir-vesper] composes existing STIR
mechanisms into a trust framework in which an entity is identified by
a domain identifier bound to its telephone number right-to-use,
carried in a telephone-number-scoped delegate certificate. This
document relies on that framework for the definition, issuance, and
verification of VESPER delegate certificates and does not restate
them here; it defines how PASSporTs signed with those certificates
are delivered out of band.
This document describes how the VESPER framework is applied to an
out-of-band delivery mechanism corresponding to the model described
in [RFC8816]. It enables authorized delegate certificate holders to
deliver PASSporTs over an out-of-band path for retrieval and
validation by a STIR Verification Service, maintaining continuity of
trust across heterogeneous networks.
The VESPER OOB delivery model is based on a publish-and-retrieve
interface using an open discovery model for PASSporT Placement
Services (PPS). This document describes the publish-and-retrieve
mechanism and its required properties, building on the concepts in
[RFC8816], rather than prescribing a specific interface. It utilizes
the following:
Wendt & Śliwa Expires 7 January 2027 [Page 3]
Internet-Draft VESPER OOB July 2026
* A mechanism for announcing the associated OOB PASSporT Placement
Services (PPSs) using the PPS URI attribute of the TN Attributes
extension defined in [I-D.wendt-stir-cert-tn-attr-ext].
* A discovery mechanism for OOB endpoints using STI certificate
transparency log monitoring, where PPS URIs carried in delegate
certificates become publicly discoverable when those certificates
are logged.
It also optionally supports Connected Identity [RFC9970], enabling
both parties to authenticate their telephone numbers and establish
end-to-end identity assurance, as also adopted by VESPER
[I-D.wendt-stir-vesper].
2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
VESPER: Verifiable STI Presentation and Evidence for RTU
[I-D.wendt-stir-vesper].
PASSporT: Personal Assertion Token as defined in [RFC8225].
Delegate Certificate: A certificate issued to an entity asserting
right-to-use for a telephone number, based on an authority token, as
defined in [RFC9060] and profiled in [I-D.wendt-stir-vesper].
Authority Token: A signed assertion that authorizes the issuance of a
delegate certificate and represents the authorization of a subject's
right-to-use a telephone number and any associated claims, defined in
[RFC9447].
Wendt & Śliwa Expires 7 January 2027 [Page 4]
Internet-Draft VESPER OOB July 2026
PASSporT Placement Service (PPS): The service that stores signed
PASSporTs published by an originating party and serves them to an
authorized retrieving party, and that supports the optional Connected
Identity response exchange. Earlier STIR out-of-band work, notably
[RFC8816], refers to this role as a Call Placement Service (CPS).
This document uses PASSporT Placement Service for two reasons.
First, the CPS acronym collides with Certification Practice Statement
(CPS) as used in [RFC8226] and certificate policy practice generally,
which is a recurring source of ambiguity in a document that deals
with both certificates and this service. Second, the service places
and serves PASSporTs and is not limited to telephone calls; the same
mechanism is intended to apply to applications beyond telephone
calls, for which a PASSporT-centric name is more accurate.
PPS URI: A URI [RFC3986] identifying a PASSporT Placement Service
(PPS), carried in the pps-uris attribute (type 1) of the TN
Attributes extension [I-D.wendt-stir-cert-tn-attr-ext]. The PPS URI
identifies the PASSporT Placement Service (PPS) for the telephone
numbers covered by the certificate.
PPS Discovery: The process of identifying the PPS endpoint
responsible for a given telephone number by monitoring STI-CT logs
for delegate certificates carrying a PPS URI attribute as defined in
[I-D.wendt-stir-cert-tn-attr-ext].
3. VESPER OOB Architectural Overview
The VESPER OOB architecture enables the out-of-band signing,
publishing, discovery, and verification of PASSporTs using a trust
framework based on delegate certificates and transparency mechanisms.
The out-of-band path is a general mechanism for delivering PASSporTs
from an originating party to a destination party, independent of any
particular signaling protocol. It may operate alongside an in-band
signaling path, such as a SIP call in which the PASSporT would
otherwise travel in an Identity header field, or it may be the sole
channel between the two parties, as in messaging, non-SIP signaling,
or other applications where there is no in-band path to carry the
PASSporT. Figure 1 illustrates the flow of identity data between the
authentication service, the out-of-band PASSporT Placement Service
(PPS), and the verification service, with the in-band signaling path
shown as an optional parallel path.
Wendt & Śliwa Expires 7 January 2027 [Page 5]
Internet-Draft VESPER OOB July 2026
+--------------------+ Originate communication over an
| Authentication | in-band signaling path, if any
| Service | (e.g. SIP INVITE with RFC8224
| (Originating Party)| Identity Header Field)
+---------+----------+-------------------+
| |
| 1. Publish PASSporT with |
| Delegate Certificate |
v .~~~~~~~~~~.
+---------+----------+ .-'' '-.
| PPS | ,.' In-band '.
| | / signaling path |
+---------+----------+ | (e.g. SIP), if any /
^ '.___..~~~~~~..______.'
| |
| 2. Retrieve PASSporT |
| |
+---------+----------+ |
| Verification | |
| Service |<------------------+
| (Destination Party)| Receive communication over the
+--------------------+ in-band signaling path, if any
Figure 1 - Architecture showing out-of-band PASSporT delivery
alongside an optional in-band signaling path
4. VESPER OOB Mechanism
This section describes how PASSporTs are delivered out of band
through a PASSporT Placement Service (PPS), and how Connected
Identity allows the called party to return a signed response.
Following the approach of [RFC8816], this document describes the
mechanism and the properties an implementation must preserve, rather
than prescribing a specific API. A PPS interface that provides these
operations and preserves these properties is conformant; implementers
may adopt an existing publish-and-retrieve interface or define their
own.
4.1. Operations
The mechanism is built from three operations against a PPS:
* Publish: the originating party places one or more signed PASSporTs
for a given originating and destination pair into the PPS, so they
can be retrieved by the destination party. A publish operation
MAY also request a Connected Identity exchange, in which case the
PPS returns a transaction handle that identifies the exchange.
Wendt & Śliwa Expires 7 January 2027 [Page 6]
Internet-Draft VESPER OOB July 2026
* Retrieve: the destination party obtains the PASSporTs published
for a given originating and destination pair, and, where a
Connected Identity exchange was requested, learns the transaction
handle.
* Respond: where Connected Identity is in use, the destination party
places a signed response PASSporT against the transaction handle,
which the originating party then retrieves.
Each operation is authorized by the requesting party signing its
request with its VESPER delegate certificate, so that the PPS and the
counterparty can confirm the requester is authorized for the
telephone number involved. The integrity of the published PASSporTs
is bound to that authorization so that stored content cannot be
substituted. The mechanism used to convey and authorize these
operations is not defined here; an implementation may use any
mechanism that authenticates the requesting party and protects the
integrity of the request.
4.2. Required Properties
An implementation of the VESPER OOB mechanism preserves the following
properties, however the PPS interface is realized. Some of these
properties are guaranteed cryptographically by the signed request and
the signed PASSporT, while others are enforced by the PPS as a
relied-upon party; the Security Considerations section discusses this
distinction and its consequences.
* Authorization: publish, retrieve, and respond requests are
authorized by the requesting party using its VESPER delegate
certificate. The PPS and the counterparty can verify that the
requester is authorized for the originating or destination
identifier it is acting for, consistent with the certificate's
TNAuthList.
* Scoping: retrieval is scoped to a specific originating and
destination pair, so that a party can obtain only the PASSporTs
intended for an exchange it is part of.
* Integrity: the authorization of a publish or respond request is
bound to the PASSporT content it carries, so that the stored
PASSporTs cannot be altered or substituted without detection.
* Replay resistance: requests are protected against replay, for
example through a unique request identifier and a freshness
window, and are scoped to a single transaction rather than reused.
Wendt & Śliwa Expires 7 January 2027 [Page 7]
Internet-Draft VESPER OOB July 2026
* Confidentiality of the exchange: in a Connected Identity exchange,
the transaction handle and the response are disclosed only to the
parties of the original transaction. In particular, the response
is made available only to the party that performed the original
publish.
* Transport security: all PPS interactions occur over a server-
authenticated secure transport.
4.3. Mechanism Flow
The following sequence illustrates the mechanism. Steps 1 and 2 are
the basic publish-and-retrieve flow for delivering a PASSporT from
the originating party (A) to the destination party (B). Steps 3 and
4 are the optional Connected Identity exchange, in which B returns a
signed response PASSporT for A to retrieve.
Wendt & Śliwa Expires 7 January 2027 [Page 8]
Internet-Draft VESPER OOB July 2026
A (Originating) PPS B (Destination)
| | |
| 1. Publish PASSporT(s) | |
| for (orig=A,dest=B), | |
| authorized by A's | |
| delegate certificate | |
| ----------------------> | |
| (handle, if Connected | |
| Identity requested) | |
| <---------------------- | |
| | 2. Retrieve PASSporT(s)
| | for (orig=A,dest=B),
| | authorized by B's
| | delegate certificate
| | <-------------------- |
| | PASSporT(s) (+ handle
| | if Connected Identity)
| | --------------------> |
| | |
| | 3. Respond with rsp |
| | PASSporT against |
| | handle, authorized
| | by B's delegate cert
| | <-------------------- |
| 4. Retrieve rsp | |
| PASSporT for handle, | |
| authorized by A's | |
| delegate certificate | |
| ----------------------> | |
| <---------------------- | |
| rsp PASSporT | |
| | |
Figure 2 - VESPER OOB publish/retrieve (steps 1-2) and optional
Connected Identity exchange (steps 3-4)
In the basic flow, A publishes the PASSporTs it would otherwise have
carried in the SIP Identity header field, and B retrieves and
verifies them as part of terminating the call. In the Connected
Identity flow, the transaction handle returned at publish ties B's
response to the original transaction. B can respond only after
retrieving the original PASSporTs, so that it has had the opportunity
to verify A before asserting its own identity, and only A, as the
original publisher, can retrieve B's response. The verification of
the retrieved PASSporTs, in both directions, is described in the
verification procedures below.
Wendt & Śliwa Expires 7 January 2027 [Page 9]
Internet-Draft VESPER OOB July 2026
5. Authentication Service Procedures for VESPER OOB
Authentication Services that sign PASSporTs for out-of-band delivery
follow the core VESPER specification [I-D.wendt-stir-vesper],
together with the additional procedures in this section that are
specific to the out-of-band case.
The role of the Authentication Service is to author the PASSporT: to
construct and sign it using the VESPER delegate certificate and the
VESPER PASSporT usage profile, asserting the originating identity.
This authored PASSporT is the same artifact regardless of how it is
delivered. In the in-band case it travels with the communication,
for example in a SIP Identity header field; in the out-of-band case
it is the PASSporT placed in the PASSporT Placement Service (PPS) for
the destination party to retrieve. Out-of-band delivery may be the
sole path between the two parties, as in messaging or other
applications where there is no in-band path that can carry the
PASSporT, or it may run alongside an in-band copy of the same
PASSporT. In all of these cases the authoring of the PASSporT is
unchanged; what is specific to out-of-band operation is that the
authored PASSporT is published to a PPS rather than, or in addition
to, being carried in band. The subsections below state the
certificate properties this relies on and the delivery step that is
specific to out-of-band operation.
5.1. Delegate Certificate Requirements
Certificates used to sign PASSporTs in VESPER OOB are VESPER delegate
certificates as defined and profiled in [I-D.wendt-stir-vesper]; this
document adds no requirements on the certificate beyond those of
VESPER other than the one specific to out-of-band discovery below.
For out-of-band operation, the signing certificate MUST carry one or
more PPS URIs in the pps-uris attribute of the TN Attributes
extension [I-D.wendt-stir-cert-tn-attr-ext], enabling discovery of
the associated OOB PASSporT Placement Service (PPS) as described in
the PPS URI and OOB PPS Discovery section.
5.2. PASSporT Construction Requirements
PASSporTs delivered over VESPER OOB are constructed and signed as
defined in the VESPER PASSporT usage profile [I-D.wendt-stir-vesper].
VESPER OOB adds no requirements on the content of the PASSporT
itself; the orig, dest, and iat claims and the x5c and x5u headers
are populated as that profile specifies.
Wendt & Śliwa Expires 7 January 2027 [Page 10]
Internet-Draft VESPER OOB July 2026
The one requirement specific to OOB is delivery: rather than, or in
addition to, carrying the PASSporT in a SIP Identity header field,
the Authentication Service publishes the signed PASSporT to the PPS
identified by the PPS URI in the signing certificate, using the
publish operation of the VESPER OOB mechanism.
6. PPS URI and OOB PPS Discovery
PPS URIs are associated with VESPER delegate certificates through the
pps-uris attribute (type 1) of the TN Attributes extension defined in
[I-D.wendt-stir-cert-tn-attr-ext]. This attribute carries one or
more HTTPS URIs identifying the PPS endpoints responsible for
publishing and serving PASSporTs for the telephone numbers covered by
the certificate's TNAuthList.
When a VESPER delegate certificate carrying a PPS URI attribute is
submitted to a Secure Telephone Identity Certificate Transparency
(STI-CT) log [I-D.ietf-stir-certificate-transparency], the PPS URI
becomes publicly visible and verifiable. Parties that wish to
discover the PPS for a given telephone number do so by monitoring
STI-CT logs for delegate certificates that carry a PPS URI attribute,
extracting the telephone numbers and PPS URI from each certificate,
and associating the covered telephone numbers with the indicated PPS
endpoint. This approach provides a transparent, cryptographically
verifiable discovery mechanism that does not require bilateral
provisioning or static configuration between service providers.
The discovery process follows these steps:
1. A VESPER delegate certificate carrying a TNAuthList and a PPS URI
attribute is issued and submitted to a STI-CT log, generating an
SCT.
2. A monitoring party observes the log, verifies the certificate
chain to a trusted STI root, validates the SCT, and extracts the
telephone-number-to-PPS mappings.
3. Authentication Services and Verification Services consult these
mappings to identify the appropriate PPS endpoint for a given
call.
4. PASSporTs are published or retrieved using the discovered PPS URI
as part of the OOB authentication process.
Wendt & Śliwa Expires 7 January 2027 [Page 11]
Internet-Draft VESPER OOB July 2026
Implementations MAY maintain local caches of telephone-number-to-PPS
mappings, respecting certificate validity periods when using
extracted data. PPS operators SHOULD publish delegate certificates
in multiple STI-CT logs to ensure broad visibility. The PPS URI MUST
resolve to a reachable and operational PPS that supports the VESPER
OOB mechanism defined in this document.
The mechanism permits a certificate to carry more than one PPS URI,
so that an operator can advertise multiple PPS instances, including
regional or edge instances. Where multiple instances are advertised,
an implementation can select among them or fail over between them
using local policy such as lowest latency or geographic proximity.
The degree of redundancy that is appropriate is a matter of
deployment experience and local policy, and is not specified here.
7. Verification Service Procedures for VESPER OOB
Verification Services that retrieve and validate PASSporTs via the
VESPER OOB model MUST implement the following procedures in addition
to those defined fundamentally in [RFC8224] and specific to VESPER
defined in [I-D.wendt-stir-vesper].
7.1. Retrieval and Validation Process
* PPS URI Resolution: Determine the PPS URI for the given telephone
number by consulting telephone-number-to-PPS mappings derived from
monitoring STI-CT logs for delegate certificates carrying a PPS
URI attribute, as described in the PPS URI and OOB PPS Discovery
section of this document.
* PASSporT Retrieval: Perform the retrieve operation of the VESPER
OOB mechanism against the resolved PPS, scoped to the originating
and destination pair and authorized by the verifier's VESPER
delegate certificate, as described in the VESPER OOB Mechanism
section.
* Multiple PASSporT Handling: If the retrieved response contains
multiple PASSporTs, the verifier MUST validate each PASSporT
independently. All PASSporTs MUST share the same orig, dest, and
iat values and MUST be signed by the same delegate certificate.
If any PASSporT fails validation, the verifier SHOULD reject the
entire set and SHOULD log the failure for diagnostic purposes.
The verifier MAY apply local policy to determine which PASSporT
types are actionable.
Wendt & Śliwa Expires 7 January 2027 [Page 12]
Internet-Draft VESPER OOB July 2026
7.2. PASSporT Validation
Once retrieved, the verifier validates the PASSporT and its signing
certificate exactly as specified by the VESPER framework
[I-D.wendt-stir-vesper], which applies the procedures of [RFC8224]
and the VESPER certificate and binding checks. VESPER OOB places no
additional requirements on this validation and does not modify it;
the only difference from the in-band case is that the PASSporT was
obtained by retrieval from the PPS rather than from a SIP Identity
header field. The verifier applies the full VESPER verification to
each retrieved PASSporT before relying on it, so that end-to-end
trust in the originating identity is established even across
heterogeneous network paths or in the absence of SIP Identity header
delivery.
7.3. Connected Identity Validation
When a Connected Identity response PASSporT (rsp) is retrieved by the
Verification Service (VS), it MUST be validated in accordance with
[RFC9970] and the VESPER framework [I-D.wendt-stir-vesper]. The rsp
PASSporT and its signing certificate are validated using the full
VESPER verification, as for any VESPER PASSporT; the requirements
below are those specific to the Connected Identity response in the
out-of-band context.
The rsp PASSporT MUST be signed using a VESPER delegate certificate
valid for the dest telephone number of the original call. The
distinction from originating-direction verification is that the
responder is asserting control over the dest number, so the signing
certificate's TNAuthList MUST authorize that number.
The VS MUST confirm that the orig and dest claims in the rsp PASSporT
match those of the original transaction, and that the iat claim is
within an acceptable freshness interval as defined by local policy.
If these validations succeed, the verifier can confirm that the
called party has cryptographically asserted its identity using a
VESPER-authorized certificate, completing the Connected Identity
flow. Any failure MUST cause the rsp PASSporT to be rejected.
8. Security Considerations
PASSporTs in VESPER OOB are signed using VESPER delegate
certificates, which a verifier validates using the full VESPER
verification [I-D.wendt-stir-vesper]. This dependence on the signed
PASSporT and its VESPER delegate certificate, rather than on the
delivery path, is what allows a verifier to establish the originating
identity independently of how the PASSporT was delivered out of band.
Wendt & Śliwa Expires 7 January 2027 [Page 13]
Internet-Draft VESPER OOB July 2026
The publish, retrieve, and respond operations are authorized as
described in the VESPER OOB Mechanism section, with each request
signed by the requesting party's VESPER delegate certificate, scoped
to a single transaction, and protected against replay through a
unique request identifier and a short freshness window. Because the
integrity of a published PASSporT is bound to that authorization,
stored content cannot be substituted without detection.
A PPS is not assumed to be an openly writable, anonymously accessible
endpoint. PPS operators are expected to administer their own
admission controls governing which parties may reach the service at
all, for example through operator-managed credentials, peering
arrangements, or network-level access policy. The design of that
admission layer is a matter for the operator and is out of scope for
this document. Within an admitted context, the requirement that each
operation be signed by the requesting party's VESPER delegate
certificate is what authorizes the specific action on a specific
telephone number. This is an appropriate use of the delegate
certificate: the certificate is the cryptographic representation of
the subject's right-to-use for the telephone numbers in its
TNAuthList, so a request signed by it, and scoped to those numbers,
expresses exactly the authorization needed to publish or retrieve
PASSporTs for them. A party cannot use this mechanism to publish for
a telephone number it does not hold a valid certificate for.
The authentication of the requester and the integrity of each
PASSporT are cryptographic and do not depend on the PPS behaving
honestly: a verifier validates each retrieved PASSporT and its
signing certificate independently, so a misbehaving or compromised
PPS cannot cause acceptance of a forged or altered identity
assertion. Other properties, such as scoping retrieval to the
intended originating and destination pair and keeping a Connected
Identity exchange confidential to its two parties, are enforced by
the PPS as a relied-upon party rather than guaranteed
cryptographically by the signed request alone. A compromised PPS
could therefore affect the availability of PASSporTs, or the
confidentiality and scoping of an exchange, even though it cannot
forge the identities asserted within. The degree of additional
assurance an operator places on PPS behavior is a matter of
deployment and local policy.
In a Connected Identity exchange, the transaction handle and the
response are sensitive. The Confidentiality property required in the
VESPER OOB Mechanism section limits their disclosure to the parties
of the original transaction, with the response made available only to
the party that performed the original publish. A further concern is
that the existence or pending state of a transaction handle can
itself be sensitive: to avoid confirming a handle to an unauthorized
Wendt & Śliwa Expires 7 January 2027 [Page 14]
Internet-Draft VESPER OOB July 2026
requester, a PPS should not distinguish, in its observable behavior,
between a handle that does not exist and one the requester is not
authorized to access.
A PPS handles identity data and is exposed to request-volume abuse,
so operators should apply rate limiting and should retain identity
data only as long as operationally necessary.
9. IANA Considerations
This document has no IANA actions.
10. References
10.1. Normative References
[I-D.ietf-stir-certificate-transparency]
Wendt, C., Śliwa, R., Fenichel, A., and V. A. Gaikwad,
"STI Certificate Transparency", Work in Progress,
Internet-Draft, draft-ietf-stir-certificate-transparency-
02, 18 May 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-stir-certificate-transparency-02>.
[I-D.wendt-stir-cert-tn-attr-ext]
Wendt, C. and R. Śliwa, "TN Attribute Certificate
Extension for STI Certificates", Work in Progress,
Internet-Draft, draft-wendt-stir-cert-tn-attr-ext-00, 6
July 2026, <https://datatracker.ietf.org/doc/html/draft-
wendt-stir-cert-tn-attr-ext-00>.
[I-D.wendt-stir-vesper]
Wendt, C. and R. Śliwa, "VESPER - Verifiable STI
Presentation and Evidence for RTU", Work in Progress,
Internet-Draft, draft-wendt-stir-vesper-07, 31 March 2026,
<https://datatracker.ietf.org/doc/html/draft-wendt-stir-
vesper-07>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, July 2002,
<https://www.rfc-editor.org/rfc/rfc3261>.
Wendt & Śliwa Expires 7 January 2027 [Page 15]
Internet-Draft VESPER OOB July 2026
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/rfc/rfc3986>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
"Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 8224,
DOI 10.17487/RFC8224, February 2018,
<https://www.rfc-editor.org/rfc/rfc8224>.
[RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
<https://www.rfc-editor.org/rfc/rfc8225>.
[RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity
Credentials: Certificates", RFC 8226,
DOI 10.17487/RFC8226, February 2018,
<https://www.rfc-editor.org/rfc/rfc8226>.
[RFC8816] Rescorla, E. and J. Peterson, "Secure Telephone Identity
Revisited (STIR) Out-of-Band Architecture and Use Cases",
RFC 8816, DOI 10.17487/RFC8816, February 2021,
<https://www.rfc-editor.org/rfc/rfc8816>.
[RFC9060] Peterson, J., "Secure Telephone Identity Revisited (STIR)
Certificate Delegation", RFC 9060, DOI 10.17487/RFC9060,
September 2021, <https://www.rfc-editor.org/rfc/rfc9060>.
[RFC9447] Peterson, J., Barnes, M., Hancock, D., and C. Wendt,
"Automated Certificate Management Environment (ACME)
Challenges Using an Authority Token", RFC 9447,
DOI 10.17487/RFC9447, September 2023,
<https://www.rfc-editor.org/rfc/rfc9447>.
[RFC9970] Peterson, J. and C. Wendt, "Connected Identity for Secure
Telephone Identity Revisited (STIR)", RFC 9970,
DOI 10.17487/RFC9970, June 2026,
<https://www.rfc-editor.org/rfc/rfc9970>.
10.2. Informative References
Wendt & Śliwa Expires 7 January 2027 [Page 16]
Internet-Draft VESPER OOB July 2026
[RFC9888] Peterson, J., "Out-of-Band Secure Telephone Identity
Revisited (STIR) for Service Providers", RFC 9888,
DOI 10.17487/RFC9888, June 2026,
<https://www.rfc-editor.org/rfc/rfc9888>.
Acknowledgments
The authors thank the contributors of the STIR working group, whose
out-of-band work informed the mechanism described in this document
for PASSporT delivery signed with VESPER delegate certificates.
Authors' Addresses
Chris Wendt
Somos Inc.
United States of America
Email: chris@appliedbits.com
Rob Śliwa
Somos Inc.
United States of America
Email: robjsliwa@gmail.com
Wendt & Śliwa Expires 7 January 2027 [Page 17]