]> Somos Inc.

US chris@appliedbits.com

Somos Inc.

US robjsliwa@gmail.com

Applications and Real-Time Secure Telephone Identity Revisited stir certificates delegate certificates oob This document describes a mechanism for delivering authenticated telephone call identity information using the VESPER framework in environments where SIP signaling is unavailable or unsuitable. 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 SIP-based VoIP networks. These PASSporTs are signed with delegate certificates that were authorized for issuance by corresponding authority tokens, which represent the trust and validation of telephone number control and related claim information. Transparency features ensure that these authorizations are publicly auditable and cryptographically provable, supporting a higher standard of trust. 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 serves as an alternative delivery path for PASSporTs in cases where end-to-end in-band SIP delivery is not possible, enabling verifiers to confirm the association between the originating telephone number and the identity asserting authority as part of the broader VESPER trust framework. The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Secure Telephone Identity Revisited Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The STIR framework enables the signing and verification of telephone calls using PASSporT objects carried in SIP in Identity Header Fields defined in . 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) addresses this generally for STIR by defining an OOB delivery model. The VESPER framework extends the STIR architecture by introducing delegate certificates issued under authority tokens and recorded in certificate transparency logs, strengthening the association between telephone number assignments and the entities authorized to use them in signed PASSporTs. This document defines how the VESPER framework extends to an out-of-band delivery mechanism corresponding to the model described in . It enables authorized delegate certificate holders to deliver PASSporTs over a non-SIP-based 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 Call Placement Services (CPS). This document extends the concepts in to specifically define an HTTPS-based interface for publishing and retrieving VESPER PASSporTs. It utilizes the following: A mechanism for announcing the associated OOB Call Placement Services (CPSs) using the CPS URI extension defined in . A discovery mechanism for OOB endpoints using STI certificate transparency log monitoring, where CPS URIs embedded in delegate certificates become publicly discoverable when those certificates are logged. It also optionally supports Connected Identity , enabling both parties to authenticate their telephone numbers and establish end-to-end identity assurance, as also adopted by VESPER .

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 when, and only when, they appear in all capitals, as shown here. VESPER: Verifiable STI Presentation and Evidence for RTU . PASSporT: Personal Assertion Token as defined in . Delegate Certificate: A certificate issued to an entity asserting right-to-use for a telephone number, based on an authority token, as defined in and profiled in . 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 . CPS URI: Call Placement Service (CPS) URI extension in X.509 certs . CPS Discovery: The process of identifying the CPS endpoint responsible for a given TN or SPC by monitoring STI-CT logs for delegate certificates containing the CPS URI extension defined in .

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. These components interact across SIP and HTTPS protocols to support parallel in-band and out-of-band delivery of telephone number authentication information. Figure 1 illustrates the flow of identity data between the authentication service, the out-of-band Call Placement Service (CPS), and the verification service.

Figure 1 - Architecture showing both in-band and out-of-band PASSporT delivery

HTTPS Interface Specification The interface design is conceptually aligned with the interface model described in Section 7. It supports two categories of HTTPS methods: General Operations: These required endpoints enable basic VESPER-OOB publish and retrieval functions: GET /health - check service availability POST /passports/{DEST}/{ORIG} - publish one or more signed PASSporTs, optionally with a 'response_uuid' for Connected Identity GET /passports/{DEST}/{ORIG} - retrieve published PASSporTs and optionally discover an associated 'response_uuid' Connected Identity Extensions: These optional endpoints are used if a response_uuid was included in the publish operation and the recipient supports Connected Identity: POST /respond/{UUID} - the called party submits a 'rsp' PASSporT GET /passports/response/{UUID} - the caller polls for the response GET /passports/response/stream/{UUID} - Server-Sent Events (SSE) push interface (optional) wss://.../stream/respond/{UUID} - WebSocket push delivery (optional) All endpoints MUST be served over HTTPS. All endpoints that expose PASSporTs, Connected Identity UUIDs, or response PASSporTs MUST require authentication via Access JWT as defined in . The GET /health endpoint does not require authentication. CPS operators SHOULD additionally enforce rate-limits and access-control policies. Server certificates SHOULD be validated using standard PKIX procedures. HTTP Strict Transport Security (HSTS) MAY be used by CPS operators to enforce HTTPS usage.

Common Access JWT All CPS interfaces that require authorization MUST support Access JWTs signed using the ES256 algorithm and validated against trusted VESPER delegate certificates. These tokens establish caller or responder identity and intent.

Access JWT Header

'alg': MUST be "ES256" as required by STIR PASSporT and VESPER. 'x5c': An array of base64-encoded certificates representing the end-entity delegate certificate and any intermediate certificates with an optionally included root certificate. These MUST be validated against the trust anchors defined in the certificate policy defined in .

Access JWT Claims The Access JWT payload MUST contain the following claims: Claim Description 'iat' Issued-at timestamp (Unix time). MUST be recent (< 5 min skew). 'exp' Expiration timestamp for the token. 'jti' Unique token ID for replay prevention and audit. 'action' Operation intent: "publish", "retrieve", or "respond". 'aud' CPS hostname. MUST match the target server. 'iss' SPC or TN of the signer. MUST match TNAuthList in cert. 'sub' SPC or TN of the subscriber on whose behalf the action is taken. 'orig' Object with TN/URI of the originating party. 'dest' Object with TN/URI of the destination party. 'passports' OPTIONAL. See below for digest definition. 'rsp_passport' OPTIONAL. See below for digest definition. The 'passports' claim, when present for a "publish" action, MUST contain the base64url-encoded SHA-256 hash of the JCS canonicalization of the complete JSON request body object (i.e., the object containing the passports array). The 'rsp_passport' claim, when present for a "respond" action, MUST contain the base64url-encoded SHA-256 hash of the JCS canonicalization of the complete JSON request body object (i.e., the object containing the rsp_passport field). Hash values MUST use base64url encoding without padding as defined in RFC 4648 Section 5. Note: The TNAuthList in a VESPER delegate certificate may contain TN entries, SPC entries, or both. In the common case where an entity signs for its own telephone numbers, iss and sub will be the same value and correspond to a TN or SPC in the TNAuthList, as the signing entity and the telephone number holder are the same party. In platform or delegated deployments, iss may identify an SPC-authorized signing entity while sub identifies the subscriber's TN, both of which are covered by the certificate's TNAuthList.

Examples Publish Token (Calling Party):

Retrieve Token (Verifying Called Party):

Respond Token (Called Party responding with Connected Identity):

Validation Rules The CPS MUST validate the Access JWT as follows: Signature: Must be signed with ES256 using a VESPER delegate certificate that chains to a trusted STI root. Certificate: The certificate in 'x5c' MUST match the 'iss'/'sub' TN and contain valid TNAuthList entries. Time Validity: 'iat' MUST be recent (within an allowed freshness window, e.g., 5 minutes). Audience: 'aud' MUST match the target CPS domain. Claims Match: The 'orig' and 'dest' claims MUST match the HTTP path parameters. Digest Integrity: If the 'passports' or 'rsp_passport' claim is present, its value MUST equal the base64url-encoded SHA-256 hash computed over the JCS canonicalization of the complete JSON request body. Both parties MUST canonicalize the full request body object before hashing. The encoding of the hash value MUST use base64url without padding as defined in RFC 4648 Section 5.

Additional Security CPS SHOULD reject expired, reused, or improperly scoped JWTs. JWT replay prevention SHOULD be enforced using the jti field and short TTLs. The CPS MUST cache recent jti values and MUST reject re-use within the configured window. Tokens MUST be scoped per transaction; long-lived JWTs MUST NOT be used.

API Method Definitions

Method: 'GET /health'

Request Definition

Response Definition 200 OK - Service operational 503 Service Unavailable - Service not operational Body (optional):

Publish Method: POST /passports/{DEST}/{ORIG} This method allows the calling party to publish one or more signed PASSporTs associated with a specific ORIG and DEST pair. The CPS MAY optionally return a response_uuid for Connected Identity. PASSporTs and Connected Identity response PASSporTs SHOULD be retained only for a short period of time unless longer retention is explicitly required by policy. Note: defines a "re-publish" action for forwarding PASSporTs between CPSs. Because VESPER OOB uses a transparent discovery model based on STI-CT log monitoring rather than bilateral CPS-to-CPS communication, re-publishing is not required. CPS implementations conforming to this specification are not required to support the re-publish action or the associated "token" fields defined in . However, this specification is designed to be compatible with deployments that support both VESPER OOB and .

Request Definition

Request Headers

]]>

The server SHOULD support an Idempotency-Key request header . When present, repeated requests with the same key MUST return the original result without creating duplicate records.

Request Parameters DEST: Canonicalized and percent-encoded destination telephone number or URI. ORIG: Canonicalized and percent-encoded originating telephone number or URI. Canonicalization of TNs follows and percent encoding of URIs follows . Note: The path ordering places {DEST} before {ORIG} to align with the lookup pattern used by the called party, which typically knows its own number (DEST) and resolves PASSporTs based on the calling party (ORIG). The CPS MUST validate that the orig and dest claims in the Access JWT match the {ORIG} and {DEST} path parameters respectively; a mismatch MUST result in a 403 Forbidden response.

Request Body The request body is a JSON object with the following field: passports: REQUIRED. An array of one or more PASSporT strings signed by the calling party. Multiple PASSporTs MAY be included when the authentication service issues PASSporTs with different ppt types (e.g., a base shaken PASSporT alongside a div or rcd PASSporT) for the same call. All PASSporTs in the array MUST share the same orig, dest, and iat values and MUST be signed by the same delegate certificate. Authorization JWT Requirements: The Access JWT for this method MUST include: "action": "publish" All other validation requirements are defined in Common Access JWT.

Example Request

Content-Type: application/json { "passports": [ "eyJhbGciOiJFUzI1NiIsIn..." ] } ]]>

Response Definition Success Codes

Failure Codes

Responses MUST use status codes defined in and SHOULD be informative when possible. If the server supports Connected Identity, the response body MAY include a response_uuid that the called party can use in follow-up Connected Identity methods. This UUID is generated by the CPS and serves as a transaction-specific identifier for subsequent API calls.

Example Response

Response Body Fields status: HTTP status code indicating result of publish request (e.g., 201 for success). message: A human-readable message describing the outcome of the request. response_uuid: (Optional) A UUID generated by the CPS for Connected Identity. Returned only if the CPS supports Connected Identity response workflows.

Example Success and Error Responses Success Response (201 Created):

Error Response (400 Bad Request):

Error Response (401 Unauthorized):

Retrieve Method: GET /passports/{DEST}/{ORIG} This method allows the called party to retrieve PASSporTs published by the originating party for a given ORIG/DEST combination.

Request Definition

Request Headers

]]>

Request Parameters DEST: Percent-encoded and canonicalized destination telephone number or URI, representing the final called party after any retargeting. ORIG: Percent-encoded and canonicalized calling party TN or URI, typically from the SIP From or P-Asserted-Identity header. Canonicalization of TNs follows and percent encoding of URIs follows . Note: The path ordering places {DEST} before {ORIG} to align with the lookup pattern used by the called party, which typically knows its own number (DEST) and resolves PASSporTs based on the calling party (ORIG). The CPS MUST validate that the orig and dest claims in the Access JWT match the {ORIG} and {DEST} path parameters respectively; a mismatch MUST result in a 403 Forbidden response.

Authorization JWT Requirements The JWT used to authorize this request MUST include: "action": "retrieve" All other JWT validation requirements are defined in and MUST also be enforced by the CPS.

Prerequisite Check Before accepting a Connected Identity response, the CPS SHOULD verify that the PASSporT associated with the given response_uuid was previously retrieved by a party whose iss claim matches the dest TN of the original transaction. This ensures that the responding party has had the opportunity to validate the originating PASSporT before asserting its own identity. If the CPS enforces this check and no prior retrieval has occurred, it SHOULD return 409 Conflict with a descriptive error indicating that retrieval must precede response submission.

Response Definition Success:

Failure:

Status codes MUST follow . On 5xx failures, retrying another CPS endpoint MAY be allowed. Response Body (on success):

passports: An array of one or more PASSporT strings published by the originating party, in compact JWS serialization format as per . response_uuid: OPTIONAL. If present, provides the Connected Identity transaction UUID to which the called party can submit an identity response PASSporT using the appropriate API method. This value is provided only if included in the corresponding publish operation.

Example Request

]]>

Example Response

Example Success and Error Responses Success Response (200 OK):

Error Response (404 Not Found):

Error Response (403 Forbidden):

Response Body Fields passports: Array of PASSporT strings published by the originating party, encoded in compact JWS serialization. response_uuid: (Optional) UUID that identifies a Connected Identity response transaction. Provided only if the CPS returned it during publish.

Respond Method: POST /respond/{UUID} This method allows the called party to submit a response PASSporT (rsp_passport) asserting their identity in a Connected Identity exchange. The UUID corresponds to the response_uuid originally returned by the CPS during the publish operation.

Request Definition

Request Headers

]]>

Request Parameters UUID: A unique response transaction identifier returned by the CPS in the publish response as response_uuid. This identifies the call session context for Connected Identity.

Request Body

rsp_passport: REQUIRED. The PASSporT signed by the called party delegate certificate for Connected Identity.

Authorization JWT Requirements The JWT used to authorize this request MUST include: "action": "respond" All other JWT validation requirements are defined in and MUST be enforced by the CPS.

Response Definition Success:

Failure:

Status codes MUST follow . Connected Identity response PASSporTs SHOULD be retained only for a short period unless longer retention is explicitly required by policy.

Example Request

{ "rsp_passport": "eyJhbGciOiJFUzI1NiIsIn..." } ]]>

Example Response

Example Success and Error Responses Success Response (201 Created):

Error Response (409 Conflict):

Error Response (404 Not Found):

Retrieving Connected Identity Responses Once a response is submitted using the response_uuid, the originating party may retrieve it in two ways using a polling interface (GET method) or via an optional push interface using WSS as detailed in the following methods.

Retrieve Response Method: GET /passports/response/{UUID} This method allows the originating (calling) party to retrieve a Connected Identity response PASSporT, if one has been submitted by the called party. The UUID in this path is the same value (response_uuid) previously provided by the CPS in the response to the POST /passports/{DEST}/{ORIG} method.

Request Definition

]]>

Response Definition Success: 200 OK - Connected Identity response PASSporT retrieved successfully Failure: 404 Not Found - No response is available yet

Response Body

Response Body Fields rsp: An object containing the Connected Identity response. passport: A PASSporT string signed by the called party using its delegate certificate.

Example Success and Error Responses Success Response (200 OK):

Error Response (404 Not Found):

Retrieve Response Push Methods (Optional) The CPS MAY support real-time delivery of Connected Identity responses via push interfaces as an alternative to polling.

Server-Sent Events (SSE)

]]>

The SSE endpoint uses the same Access JWT authentication as the polling GET endpoint. The JWT MUST include "action": "retrieve" and the iss claim MUST match the originating party of the transaction. The CPS MUST validate the JWT before initiating the event stream.

WebSocket

Because the WebSocket upgrade request does not support the Authorization header in all client implementations, the Access JWT MUST be conveyed using one of the following mechanisms, listed in order of preference: The Sec-WebSocket-Protocol subprotocol negotiation, using the format access_token.<JWT>. A query parameter ?token=<JWT> on the connection URI. When this method is used, CPS operators MUST ensure the token is not logged in access logs. An initial text frame sent immediately after connection establishment, containing the Access JWT. The CPS MUST NOT transmit any response data until the JWT has been received and validated. The CPS MUST close the WebSocket connection with status code 1008 (Policy Violation) if the JWT is missing, invalid, or unauthorized. Both push interfaces MUST enforce the same authorization constraints as the polling GET endpoint: only the authenticated originating party of the transaction (as identified by iss) is permitted to receive the response.

Example VESPER OOB Request/Response Flow This example illustrates a full transaction using the Connected Identity UUID-based pattern.

Calling Party Publishes a PASSporT

]]>

Body:

Response:

Called Party Retrieves PASSporT and Extracts response_uuid

]]>

Response:

Called Party Submits a Connected Identity rsp PASSporT

]]>

Body:

Response:

Calling Party Polls for the rsp PASSporT

]]>

Response:

This flow demonstrates the full cycle from publish to response using the Connected Identity UUID-based model. Optionally, the final step may use SSE or WSS push interfaces instead of polling. The VESPER OOB interface specification offers a modular architecture for telephony identity authentication. It supports both simple publish/retrieve workflows and bidirectional identity binding through Connected Identity.

Authentication Service Procedures for VESPER OOB When participating in VESPER OOB, Authentication Services that sign PASSporTs MUST adhere to all requirements of the core VESPER specification and additional procedures specified herein to ensure the integrity of out-of-band transactions and compatibility with verifier expectations.

Delegate Certificate Requirements Delegate certificates used to sign PASSporTs in VESPER OOB MUST be issued under authority tokens that represent an explicit right-to-use a telephone number. These certificates MUST include: One or more Signed Certificate Timestamps (SCTs) from certificate transparency logs as defined in . A CPS URI in the Call Placement Service (CPS) X.509 extension, enabling discovery of the associated OOB Call Placement Service (CPS) as defined in .

PASSporT Construction Requirements PASSporTs signed in a VESPER OOB deployment MUST meet the following conditions: The PASSporT MUST be signed with a delegate certificate whose authority token authorizes the use of the specific originating telephone number. The 'orig' claim MUST contain the telephone number or URI as authorized by the delegate certificate. The 'dest' claim MUST reflect the final destination of the call after any retargeting. The 'iat' claim MUST represent a timestamp within an acceptable freshness window (e.g., 5 minutes). The JWT 'x5c' header MUST contain the certificate chain including the delegate certificate and its SCT(s). The JWT 'x5u' header MUST contain the HTTPS URL of the delegate certificate at its location in the domain-controlled repository, and the domain in that URL MUST match the dNSName SubjectAltName of the signing certificate. The Authentication Service MUST also publish the signed PASSporT to the CPS endpoint identified by the CPS URI in the delegate certificate.

CPS URI and OOB CPS Discovery CPS URIs are associated with VESPER delegate certificates through the CPS URI extension defined in . This extension embeds an HTTPS URI identifying the CPS endpoint responsible for publishing and serving PASSporTs for the telephone numbers and SPCs covered by the certificate's TNAuthList. When a VESPER delegate certificate containing a CPS URI extension is submitted to a STI-CT log, the CPS URI becomes publicly visible and verifiable. Parties that wish to discover the CPS for a given telephone number do so by monitoring STI-CT logs for delegate certificates that include a CPS URI extension, extracting the TNAuthList and CPS URI from each certificate, and associating the covered TNs or SPCs with the indicated CPS 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: A VESPER delegate certificate containing a TNAuthList and CPS URI extension is issued and submitted to a STI-CT log, generating an SCT. A monitoring party observes the log, verifies the certificate chain to a trusted STI root, validates the SCT, and extracts the TN-to-CPS and SPC-to-CPS mappings. Authentication Services and Verification Services consult these mappings to identify the appropriate CPS endpoint for a given call. PASSporTs are published or retrieved using the discovered CPS URI as part of the OOB authentication process. Implementations MAY maintain local caches of TN-to-CPS mappings, respecting certificate validity periods when using extracted data. CPS operators SHOULD publish delegate certificates in multiple STI-CT logs to ensure broad visibility. The CPS URI MUST resolve to a reachable and operational CPS that supports the VESPER OOB interface defined in this document. To support resilience, operators SHOULD advertise multiple CPS instances, including regional or edge instances to improve latency and availability. Implementations SHOULD implement endpoint failover across available CPS instances, selecting among them using local policy such as lowest latency or geographic proximity.

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 and specific to VESPER defined in .

Retrieval and Validation Process CPS URI Resolution: Determine the CPS URI for the given TN or SPC by consulting TN-to-CPS mappings derived from monitoring STI-CT logs for delegate certificates containing the CPS URI extension, as described in the CPS URI and OOB CPS Discovery section of this document. PASSporT Retrieval: Submit a 'GET' request to the CPS endpoint using a properly formed JWT in the Authorization header. 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. Authentication JWT Validation: Ensure the JWT is: Signed by a valid STI certificate that chains to a trusted root. Contains matching 'iss' and 'sub' values as authorized in the certificate's TNAuthList. Has an 'action' claim set to "retrieve". Contains 'orig' and 'dest' claims matching the intended retrieval parameters.

PASSporT Validation Once retrieved, the verifier MUST: Validate the PASSporT signature using the certificate chain in the 'x5c' header. Confirm that the domain in the 'x5u' URL matches the dNSName SubjectAltName of the signing certificate. Verify that the delegate certificate: Is valid and chains to a trusted authority. Contains valid SCTs proving inclusion in a certificate transparency log as defined in . Was issued under a valid, verifiable authority token. Check that the 'iat' claim is within an acceptable range relative to the call time. These validation steps ensure end-to-end trust in the originating identity of the call, even across heterogeneous network paths or in the absence of SIP Identity header delivery.

Connected Identity Validation When a Connected Identity response PASSporT (rsp) is retrieved by the Verification Service (VS), it MUST be validated in accordance with the procedures defined in and the VESPER framework . Specifically: The rsp PASSporT MUST be signed using a valid VESPER delegate certificate associated with the dest telephone number of the original call. The certificate used to sign the rsp PASSporT MUST: Be issued under a valid authority token authorizing use of the dest number. Contain TNAuthList values that include the dest identifier. Include valid Signed Certificate Timestamps (SCTs) from a Certificate Transparency log. The VS MUST validate the PASSporT signature and the delegate certificate's trust chain, including SCT verification and certificate expiration status. The VS MUST confirm that the orig and dest claims in the rsp PASSporT match those of the original call. That is: The orig claim in the rsp PASSporT MUST match the orig claim of the original PASSporT. The dest claim in the rsp PASSporT MUST match the dest claim of the original PASSporT. The key distinction from typical STIR verification is that the entity signing the rsp PASSporT is asserting control over the dest number, and the delegate certificate used in the signature MUST be valid for that number. The iat claim in the rsp PASSporT MUST be 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 in these validations MUST cause the rsp PASSporT to be rejected.

Security Considerations All PASSporTs and Access JWTs MUST be signed using delegate certificates issued under the certificate policy defined in and containing valid SCTs as defined in . Verifiers MUST validate the certificate trust chain and SHOULD verify SCT inclusion against known CT log sets. Access JWTs MUST use the ES256 algorithm, MUST be scoped per transaction with short validity intervals (e.g., 5 minutes), and MUST include a jti claim for replay prevention. CPS implementations MUST cache recent jti values and reject reuse within the validity window. The response_uuid MUST only be disclosed to authenticated parties authorized to retrieve the original publish and MUST NOT be exposed via unauthenticated endpoints or logs. CPS implementations MUST restrict access to the response_uuid and its associated response endpoint to the authenticated parties of the original transaction. Specifically, the CPS MUST verify that a party requesting the Connected Identity response PASSporT (via GET /passports/response/{UUID} or push interfaces) is the same entity that performed the original publish, as identified by the iss claim in their Access JWT. The CPS MUST NOT disclose whether a response_uuid exists or has a pending response to any other party. CPS implementations SHOULD return 404 (rather than 403) for unauthorized UUID lookups to prevent UUID existence confirmation. CPS operators MUST enforce rate limiting across all endpoints and MUST retain identity data only as long as operationally necessary.

IANA Considerations This document has no IANA actions.

This document describes 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, and multimedia conferences. [STANDARDS-TRACK] A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] This specification defines a Uniform Resource Name namespace for UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDentifier). A UUID is 128 bits long, and can guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System and later in the Open Software Foundation\'s (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms. This specification is derived from the DCE specification with the kind permission of the OSF (now known as The Open Group). Information from earlier versions of the DCE specification have been incorporated into this document. [STANDARDS-TRACK] This document specifies additional HyperText Transfer Protocol (HTTP) status codes for a variety of common situations. [STANDARDS-TRACK] The baseline security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP requests. It does so by defining a SIP header field for conveying a signature used for validating the identity and for conveying a reference to the credentials of the signer. This document obsoletes RFC 4474. This document defines a method 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 of the identity information at the destination. The cryptographic signature is defined with the intention that it can confidently verify the originating persona even when the signature is sent to the destination party over an insecure channel. PASSporT is particularly useful for many personal-communications applications over IP networks and other multi-hop interconnection scenarios where the originating and destination parties may not have a direct trusted relationship. 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. Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. The Personal Assertion Token (PASSporT) format defines a token that can be carried by signaling protocols, including SIP, to cryptographically attest the identity of callers. However, not all telephone calls use Internet signaling protocols, and some calls use them 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 the delivery of PASSporT objects outside of the signaling path, and defines architectures and semantics to provide this functionality. 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 service providers grant credentials to enterprises or other customers capable of signing calls with STIR. Some proposed extensions to the Automated Certificate Management Environment (ACME) rely on proving eligibility for certificates through consulting an external authority that issues a token according to a particular policy. This document specifies a generic Authority Token Challenge for ACME that supports subtype claims for different identifiers or namespaces that can be defined separately for specific applications. Somos, Inc. Somos, Inc. TransNexus Twilio This document describes a framework for the use of the Certificate Transparency (CT) protocol for publicly logging the existence of Secure Telephone Identity (STI) certificates as they are issued or observed. This allows any interested party that is part of the STI eco-system to audit STI certification authority (CA) activity and audit both the issuance of suspect certificates and the certificate logs themselves. The intent is for the establishment of a level of trust in the STI eco-system that depends on the verification of telephone numbers requiring and refusing to honor STI certificates that do not appear in a established log. This effectively establishes the precedent that STI CAs must add all issued certificates to the logs and thus establishes unique association of STI certificates to an authorized provider or assignee of a telephone number resource. The primary role of CT in the STI ecosystem is for verifiable trust in the avoidance of issuance of unauthorized duplicate telephone number level delegate certificates or provider level certificates. This provides a robust auditable mechanism for the detection of unauthorized creation of certificate credentials for illegitimate spoofing of telephone numbers or service provider codes (SPC). The framework borrows the log structure and API model from RFC6962 to enable public auditing and verifiability of certificate issuance. While the foundational mechanisms for log operation, Merkle Tree construction, and Signed Certificate Timestamps (SCTs) are aligned with RFC6962, this document contextualizes their application in the STIR eco-system, focusing on verifiable control over telephone number or service provider code resources. Somos, Inc. Somos, Inc. This document defines VESPER (Verifiable STI Presentation and Evidence for RTU), a framework that extends the STIR architecture to cryptographically bind telephone number authority, domain identity, and originating provider authorization in a single delegate certificate. The delegate certificate is issued under the certificate policy defined under a STIR compliant eco-system and carries the assigned telephone numbers and authorized originating providers in a TNAuthList extension, the responsible entity's domain in a SubjectAltName, and an embedded Signed Certificate Timestamp (SCT) proving the certificate was recorded in a public transparency log prior to use. VESPER enables relying parties to verify that a telephone number was assigned to the entity whose domain is presented, and that calls from those numbers are originated by an authorized originating provider. The framework defines a certificate profile and issuance process grounded in existing STIR and ACME authority token mechanisms, a domain-hosted certificate repository with domain-controlled certificate discovery enabling cross-channel trust signals, a PASSporT usage profile for SIP signaling, and certificate transparency to support ecosystem auditability and detection of mis- issuance. Somos Inc. Somos Inc. This document specifies a non-critical X.509 v3 certificate extension that conveys the HTTPS URI of a Call Placement Service (CPS) associated with the telephone numbers authorized in a STIR Delegate Certificate. The extension enables originators and verifiers of STIR PASSporTs to discover, with a single certificate lookup, where Out- of-Band (OOB) PASSporTs can be retrieved. The mechanism removes bilateral CPS provisioning, allows ecosystem-scale discovery backed by STI Certificate Transparency (STI-CT), and is fully backward compatible with existing STIR certificates and OOB APIs. TransUnion Somos The Session Initiation Protocol (SIP) Identity header field conveys cryptographic identity information about the originators of SIP requests. The Secure Telephone Identity Revisited (STIR) framework, however, provides no means for determining the identity of the called party in a traditional telephone-calling scenario. This document updates prior guidance on the "connected identity" problem to reflect the changes to SIP Identity that accompanied STIR, and considers a revised problem space for connected identity as a means of detecting calls that have been retargeted to a party impersonating the intended destination, as well as the spoofing of mid-dialog or dialog- terminating events by intermediaries or third parties. The HTTP Idempotency-Key request header field can be used to make non-idempotent HTTP methods such as POST or PATCH fault-tolerant. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. ATIS

Acknowledgments The authors thank the contributors of the STIR working group and authors of ATIS-1000105, many of the API mechanisms have been aligned and extended in this document to support the VESPER OOB Framework for PASSporT delivery signed with delegate certificates.