]> Somos Inc.

US chris@appliedbits.com

Somos Inc.

US robjsliwa@gmail.com

AREA WG Working Group 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 framework by introducing support for vetted delegate certificates using authority tokens and certificate transparency logs and monitoring to enhance reliability and trust for the delegation of telephone number specific certificates and the associated claims authorized to be made by the use of those certificates for signed PASSporTs. The use cases motivating these enhancements are outlined in . This document describes how to expand the VESPER framework to use an out-of-band delivery mechanism corresponding to the model described in . The VESPER framework defines how delegate certificates are issued based on authority tokens that attest to the vetting and authorization of the entity to use a telephone number and assert other related claim information. This specification extends this to enable authorized delegate certificate holders, who sign calls via a STIR Authentication Service, to deliver PASSporTs containing authorized, verifiable claims over a non-SIP-based path. These PASSporTs can be retrieved and validated by a STIR Verification Service, similar to SIP-based STIR as defined in , thereby maintaining continuity of trust across heterogeneous networks. OOB delivery is critical in extending the utility of STIR to networks where SIP identity headers cannot be delivered end-to-end. It provides a verifiable alternative path for transmitting PASSporTs and proving the originating telephone number's association to the signing identity. The Vesper OOB delivery model assumes a one-way publish-and-retrieve interface based on a defined 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 based on with the corresponding Vesper requirement to utilize and verify STI certificate transparency receipts with delegate certificates used in Vesper OOB. It also optionally supports the STIR concept of Connected Identity adopted in VESPER framework as well, where not only the originator of a call or message can authenticate their telephone number, but the destination party can also prove their telephone number back to the originator to have a full end-to-end bi-directional trust relationship. This is based on Connected Identity defined in and 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 Entity STIR Passport Entity Representation . PASSporT: Personal Assertion Token as defined in . Delegate Certificate: A certificate issued to an enterprise or user entity asserting right-to-use for a telephone number, based on an authority token, defined in . Authority Token: A signed assertion that authorizes the issuance of a delegate certificate and represents the vetting of a subject's control over a telephone number and any associated claims defined in . CPS URI: Call Placement Service (CPS) URI extension in X.509 certs . CPS Discovery: Defines the use of STI certificate transparency log monitoring and CPS URI extension in certificates for announcing CPS locations for certificates .

Vesper OOB Architectural Overview The VESPER OOB architecture consists of three main functional components that work together to enable 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 both simulataneous and parallel in-band and out-of-band delivery of telephone number authentication information, ensuring interoperability across a variety of telephony related network environments. 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. The POST endpoint MUST require authentication Access JWT. The GET endpoint MAY be unauthenticated. 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 a STIR eco-system trusted root.

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' Timestamp indicating the time the call is guaranteed to complete 'jti' Unique token ID. SHOULD be used for replay prevention and audit. 'action' Operation intent: "publish", "retrieve", or "respond". 'aud' The CPS hostname (e.g., "cps.example.net"). MUST match the target server. 'iss' The SPC or TN representing the signer. MUST match TNAuthList in cert. 'sub' Same value as iss. Identifies the subscriber authorized to act. 'orig' Object with TN/URI of the originating party. 'dest' Object with TN/URI of the destination party. 'passports' OPTIONAL. For 'publish', SHA-256 JCS digest of the canonicalized passports. 'rsp_passport' OPTIONAL. For 'respond', SHA-256 JCS digest of the rsp_passport.

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 hash MUST match the canonicalized JSON in the request body using JSON Canonicalization Scheme (JCS) .

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: supports a "re-publish" action, because the VESPER-OOB discovery mechanism is different and re-publishing PASSporTs is not required for VESPER-OOB, CPSs that support this specification are not dependent on support the initiation of this action or otherwise communicate to other CPSs supporting this specification including the inclusion of "token" fields, but the intent is to be compatible with implementations that support both specifications

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 .

Request Body The request body is a JSON object with the following field: passports: REQUIRED. An array of PASSporT strings signed by the calling party. 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 .

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.

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 via: WebSocket: wss://cps.example.net/stream/respond/{UUID} Server-Sent Events (SSE): GET /passports/response/stream/{UUID} (with Accept: text/event-stream header) These interfaces allow immediate delivery of Connected Identity responses when available.

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 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 the delegate certificates through the CPS URI extension defined in . Verifiers are expected to obtain the CPS URI for a specific telephone number via transparency-enabled discovery mechanisms described in . The CPS URI identifies the base URL for the Call Placement Service responsible for publishing and serving PASSporTs for calls associated with that telephone number. The CPS URI MUST resolve to a reachable and operational CPS that supports the VESPER OOB interface defined in this document. It is assumed that the CPS implements the endpoints defined in the HTTPS interface specification, including '/health', '/passports/{DEST}/{ORIG}', and appropriate authorization mechanisms. The CPS will provide a response_uuid in its response to the publish operation, which is used by the calling and called parties in subsequent API calls for Connected Identity. /////////// Delegate certificates MUST reference a CPS via the CPS URI extension and MUST be resolvable through the Discovery service specified for Vesper OOB. The Discovery service MUST return multiple CPS instances for each delegate certificate to provide redundancy. Operators SHOULD advertise regional or edge CPS instances to improve latency and availability for verifiers and retrievers. Verifiers and retrievers MUST implement endpoint failover across the set of CPS instances provided by Discovery and SHOULD select among them using local policy (e.g., lowest latency or geographically closest instances). Deployments that also support CPS-to-CPS replication MAY perform inter-CPS propagation by invoking the publish API using "action": "republish" semantics. In this mode, a CPS acts as a client to peer CPS servers to broaden availability of published PASSporTs. The wire format and validation requirements are otherwise identical to "action": "publish", except the policy MUST authorize the republish CPS to perform this operation. ///////////

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: Retrieve the CPS URI from an appropriate CPS discovery service as discussed and defined in to locate the specific '/passports/{DEST}/{ORIG}' endpoint. PASSporT Retrieval: Submit a 'GET' request to the CPS endpoint using a properly formed JWT in the Authorization header. 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 provided certificate referenced in the 'x5c' Header. Verify that the delegate certificate: Is valid and chains to a trusted authority. Contains valid SCTs proving inclusion in a certificate transparency log. Was issued under a valid, verifiable authority token (directly or via reference). Check that the 'iat' claim is within an acceptable range relative to the call time. Optionally, verify the transparency receipt (if present) that correlates the certificate and signing event. 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.

Privacy Considerations The VESPER OOB framework facilitates the transmission and verification of signed identity assertions that may include personally identifiable information (PII), such as telephone numbers and organizational names. This section outlines key privacy considerations to ensure implementations protect individual privacy and comply with applicable regulations.

Minimization of Identity Claims PASSporTs exchanged via VESPER OOB SHOULD contain only the minimum necessary identity claims to establish the intended trust relationship. The inclusion of unnecessary claims in the PASSporT payload or certificate extensions may reveal sensitive information about users or organizations. Implementations SHOULD avoid including additional metadata beyond what is required for call verification.

Use of Connected Identity The Connected Identity feature allows both parties in a communication to share independently signed identity assertions. While this can enhance trust, it also introduces a risk of correlation between calling and called parties. Implementers SHOULD consider allowing users to opt out of responding with Connected Identity or restrict participation to enterprise contexts where such correlation is expected. The response_uuid MUST only be disclosed to the authenticated parties authorized to retrieve the original publish. Servers SHOULD keep the response_uuid lifetime short and MUST NOT expose it via unauthenticated endpoints or logs.

Compliance with Regional Privacy Regulations Operators deploying VESPER OOB MUST assess their processing of PASSporTs and related metadata for compliance with applicable data protection laws (e.g., GDPR, CCPA). This includes evaluating: Whether telephone numbers are treated as personal data Lawful basis for processing and retention User transparency and rights of access, rectification, and erasure Audit mechanisms and data subject request workflows SHOULD be implemented when operating in regulated jurisdictions.

Transparency and Logging While logging of CPS activity is important for fraud detection and accountability, implementations MUST avoid logging full PASSporT payloads or tokens unless strictly necessary. Where logs include sensitive fields, they SHOULD be protected with access controls and subject to audit. The use of transaction-specific UUIDs instead of callback URLs minimizes the privacy exposure associated with publishing service endpoints. Only parties with the appropriate authorization token (Access JWT) can retrieve or respond to a PASSporT exchange, which helps ensure that identity data is not leaked to unauthorized entities. Connected Identity responses are associated only with the UUID provided to the intended recipient, reducing correlation risk across sessions.

Security Considerations

Trust Anchors and Certificate Transparency All JWTs and PASSporTs MUST be signed using delegate certificates anchored in a trusted STI-CA root and SHOULD be accompanied by Signed Certificate Timestamps (SCTs) to prove log inclusion. Verifiers SHOULD validate SCT presence and match against a known CT log set.

Cross-Origin and CORS CPS servers that expose web-facing endpoints MAY implement CORS headers to restrict origin access to approved domains or application scopes.

Logging and Audit CPS operators SHOULD log authentication attempts, JWT usage (by jti), PASSporT publication, and response_url usage for auditing and potential fraud investigation. Logs SHOULD be retained securely and in accordance with privacy regulations.

UUID-Based Transaction Integrity The specification relies on cryptographically random UUIDs as transaction identifiers for Connected Identity responses. These UUIDs MUST be generated by the CPS using secure random generation techniques and MUST be unguessable to prevent targeted scraping or brute-force enumeration of published PASSporTs or responses.

Replay and Reuse Mitigation The use of the 'jti' (JWT ID) field in Access JWTs supports replay protection and auditability. CPS implementations SHOULD maintain short-term caches of recent JTIs and reject duplicate requests. JWTs MUST have short time-to-live values (e.g., 5 minutes) to reduce exposure from replay attacks.

CPS Operator Responsibilities CPS operators MUST enforce authorization controls and rate limiting across all endpoints. They are responsible for securing logs, ensuring endpoint availability, monitoring for anomalies, and maintaining certificate trust anchors. Any retained identity data MUST be stored securely and retained 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. 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 formalizes a profile and a framework for the use of delegate certificates and authority tokens to strengthen the association between telephone number assignments and the entities that have the authoritative right to use them. It defines a model in which the TNAuthList Authority Token serves as a trusted representation of telephone number assignment and right-to-use (RTU), anchored by a Notary Agent that logs these associations through verifiable transparency mechanisms. The framework also extends the use of authority tokens to support other PASSporT claims like Rich Call Data (RCD) by defining a role for JWTClaimConstraints Authority Tokens. These tokens are issued by authoritative or recognized and vetted claim agents within the ecosystem to assert information associated with the entity assigned a telephone number. The Notary Agent plays a critical role in recording these claims and their provenance, enhancing transparency and accountability. Delegate certificates encapsulate and incorporate both the telephone number and associated information validated via authority tokens to the certification authority issuing them, binding them to the authenticated telephone number of the calling party. These certificates are published to a certificate transparency log, enabling relying parties to independently verify the integrity and legitimacy of number use and related claims. The VESPER (Verifiable STI PERsona) approach utilizes STIR protocols and the ACME authority token to formalizing a verifiable, auditable, and privacy-conscious foundation for associating telephone numbers with vetted entities and validated assertion of associated metadata. Somos, Inc. This document discusses a set of use cases and requirements for an extension to Secure Telephone Identity Revisited (STIR) called Verifiable STI PERsona (VESPER). VESPER fundamentally enhances STIR by establishing an authoritative and cryptographically verifiable Right-to-Use (RTU) relationship between telephone numbers and their assigned entities, business organizations or individuals, through digital signatures that bind an entity to a set of asserted claims, delegate certificates that govern the assertion of those claims to a responsible party, and Authority Tokens that prove the validation of those claims by authoritative parties. This cryptographic binding ensures explicit non-repudiation, removing ambiguity around who is accountable for calls or messages originating from specific telephone numbers, significantly deterring spoofing and fraud. 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. Somos Inc. Somos Inc. This document defines a Discovery Service for STIR Out-of-Band (OOB) Call Placement Services (CPS). The Discovery Service enables Authentication Services (AS) and Verification Services (VS) to quickly determine which CPS is responsible for a given telephone number (TN) or Service Provider Code (SPC), allowing retrieval of PASSporTs even when SIP Identity headers are removed by non-IP or hybrid network segments. The Discovery Service leverages a CPS URI certificate extension, which allows STIR Certificates or Delegate Certificates to embed an HTTPS URI for the CPS serving the TNs or SPCs covered by the certificate. 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.