VESPER Out-of-Band OOB

4.1. 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.¶

{
  "alg": "ES256",
  "x5c": [
    "MIIB3TCCAYOgAwIBAgIUUjF7Jq9kYfU12nJkBA==",
    "IUUjF7Jq9kYfU12nJkBAMIIB3TCCAYOgAwIBAg=="
  ]
}

{
  "iat": 1693590000,
  "exp": 1608048425,
  "jti": "550e8400-e29b-41d4-a716-446655440000",
  "action": "publish",
  "aud": "cps.example.net",
  "iss": "12013776051",
  "sub": "12013776051",
  "orig": { "tn": "12013776051" },
  "dest": { "tn": ["19032469103"] },
  "passports": "sha256-XyZabc123..."
}

{
  "iat": 1693590100,
  "jti": "550e8400-e29b-41d4-a716-426655440002",
  "action": "retrieve",
  "aud": "cps.example.net",
  "iss": "19032469103",
  "sub": "19032469103",
  "orig": { "tn": "12013776051" },
  "dest": { "tn": ["19032469103"] }
}

{
  "iat": 1693590050,
  "jti": "550e8400-e29b-41d4-a716-426655440001",
  "action": "respond",
  "aud": "cps.example.net",
  "iss": "19032469103",
  "sub": "19032469103",
  "orig": { "tn": "12013776051" },
  "dest": { "tn": ["19032469103"] },
  "rsp_passport": "sha256-AbCdEf123..."
}

4.2. API Method Definitions

Method: GET
Path: /health
Authentication: None required

{
  "status": 200,
  "message": "OK"
}

Method: POST
Path: /passports/{DEST}/{ORIG}
Authentication: Access JWT with "action": "publish"

Content-Type: application/json
Authorization: Bearer <Access JWT>

POST /passports/19032469103/12013776051 HTTP/1.1
Host: cps.example.com
Authorization: Bearer <Access JWT>
Content-Type: application/json

{
  "passports": [
    "eyJhbGciOiJFUzI1NiIsIn..."
  ]
}

201 - Created if the PASSporTs were successfully published.

400 - Bad Request if required fields are missing or malformed
401 - Unauthorized if authentication fails
403 - Forbidden if certificate constraints are not met
429 - Too Many Requests if rate-limited
5xx errors (e.g., 503 Service Unavailable)

HTTP/1.1 201 Created
Content-Type: application/json

{
  "status": 201,
  "message": "Created",
  "response_uuid": "123e4567-e89b-12d3-a456-426614174000"
}

HTTP/1.1 201 Created
Content-Type: application/json

{
  "status": 201,
  "message": "Created",
  "response_uuid": "123e4567-e89b-12d3-a456-426614174000"
}

HTTP/1.1 400 Bad Request
Content-Type: application/json

{
  "status": 400,
  "error": "Missing required field: passports"
}

HTTP/1.1 401 Unauthorized
Content-Type: application/json

{
  "status": 401,
  "error": "Access JWT is invalid or expired"
}

Method: GET
Path: /passports/{DEST}/{ORIG}
Authentication: Access JWT with "action": "retrieve"

Authorization: Bearer <Access JWT>

200 OK - PASSporT(s) retrieved successfully

401 Unauthorized - JWT missing or invalid
403 Forbidden - Certificate constraints violated
404 Not Found - No PASSporTs available
429 Too Many Requests - Rate limits exceeded
503 Service Unavailable - CPS temporarily unavailable

{
  "passports": [
    "eyJhbGciOiJFUzI1NiIsIn..." // Base64-encoded PASSporT string(s)
  ],
  "response_uuid": "123e4567-e89b-12d3-a456-426614174000"
}

GET /passports/19032469103/12013776051 HTTP/1.1
Host: cps.example.com
Authorization: Bearer <Access JWT>

HTTP/1.1 200 OK
Content-Type: application/json

{
  "passports": [
    "eyJhbGciOiJFUzI1NiIsIn..."
  ],
  "response_uuid": "123e4567-e89b-12d3-a456-426614174000"
}

HTTP/1.1 200 OK
Content-Type: application/json

{
  "passports": [
    "eyJhbGciOiJFUzI1NiIsIn..."
  ],
  "response_uuid": "123e4567-e89b-12d3-a456-426614174000"
}

HTTP/1.1 404 Not Found
Content-Type: application/json

{
  "status": 404,
  "error": "No PASSporTs available for the requested origin and
    destination"
}

HTTP/1.1 403 Forbidden
Content-Type: application/json

{
  "status": 403,
  "error": "Caller is not authorized to retrieve PASSporTs for this
    identity"
}

Method: POST
Path: /respond/{UUID}
Authentication: Access JWT with "action": "respond"

Content-Type: application/json
Authorization: Bearer <Access JWT>

{
  "rsp_passport": "eyJhbGciOiJFUzI1NiIsIn..."
}

201 Created - The Connected Identity response was accepted.

401 Unauthorized - JWT missing or invalid.
403 Forbidden - Certificate constraints violated.
404 Not Found - UUID not found or expired.
409 Conflict - A response has already been submitted.
429 Too Many Requests - Rate limits exceeded.
503 Service Unavailable - CPS temporarily unavailable.

POST /respond/123e4567-e89b-12d3-a456-426614174000 HTTP/1.1
Host: cps.example.net
Content-Type: application/json
Authorization: Bearer <Access JWT>

{
  "rsp_passport": "eyJhbGciOiJFUzI1NiIsIn..."
}

HTTP/1.1 201 Created
Content-Type: application/json

{
  "status": 201,
  "message": "Connected Identity Stored"
}

HTTP/1.1 201 Created
Content-Type: application/json

{
  "status": 201,
  "message": "Connected Identity Stored"
}

HTTP/1.1 409 Conflict
Content-Type: application/json

{
  "status": 409,
  "error": "A response for this UUID has already been submitted"
}

HTTP/1.1 404 Not Found
Content-Type: application/json

{
  "status": 404,
  "error": "UUID not found or expired"
}

Method: GET
Path: /passports/response/{UUID}
Headers: Authorization: Bearer <JWT>

{
  "rsp": {
    "passport": "eyJhbGciOiJFUzI1NiIsIn..."
  }
}

HTTP/1.1 200 OK
Content-Type: application/json

{
  "rsp": {
    "passport": "eyJhbGciOiJFUzI1NiIsIn..."
  }
}

HTTP/1.1 404 Not Found
Content-Type: application/json

{
  "status": 404,
  "error": "No Connected Identity response has been submitted for
      this UUID"
}

5.1. Calling Party Publishes a PASSporT

POST /passports/19035551234/12015550100 HTTP/1.1
Host: cps.example.net
Content-Type: application/json
Authorization: Bearer <jwt-from-calling-party>

Body:¶

{
  "passports": [
    "eyJhbGciOiJFUzI1NiIsIn..." // Signed PASSporT by calling party
  ]
}

Response:¶

HTTP/1.1 201 Created
Content-Type: application/json

{
  "status": 201,
  "message": "Created",
  "response_uuid": "123e4567-e89b-12d3-a456-426614174000"
}

5.2. Called Party Retrieves PASSporT and Extracts response_uuid

GET /passports/19035551234/12015550100 HTTP/1.1
Host: cps.example.net
Authorization: Bearer <jwt-from-called-party>

Response:¶

{
  "passports": [
    "eyJhbGciOiJFUzI1NiIsIn..."
  ],
  "response_uuid": "123e4567-e89b-12d3-a456-426614174000"
}

5.3. Called Party Submits a Connected Identity rsp PASSporT

POST /respond/123e4567-e89b-12d3-a456-426614174000 HTTP/1.1
Host: cps.example.net
Content-Type: application/json
Authorization: Bearer <jwt-from-called-party>

Body:¶

{
  "rsp_passport": "eyJhbGciOiJFUzI1NiIsIn..."
}

Response:¶

HTTP/1.1 201 Created
Content-Type: application/json

{"status":201,"message":"Connected Identity Stored"}

5.4. Calling Party Polls for the rsp PASSporT

GET /passports/response/123e4567-e89b-12d3-a456-426614174000 HTTP/1.1
Host: cps.example.net
Authorization: Bearer <jwt-from-calling-party>

Response:¶

{
  "rsp": {
    "passport": "eyJhbGciOiJFUzI1NiIsIn..."
  }
}

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.¶

6.1. 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 [I-D.wendt-stir-certificate-transparency]. - 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 [I-D.sliwa-stir-cert-cps-ext].¶

6.2. 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.¶

8.1. Retrieval and Validation Process

• CPS URI Resolution: Retrieve the CPS URI from an appropriate CPS discovery service as discussed and defined in [I-D.sliwa-stir-oob-transparent-discovery] 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.¶

8.2. 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.¶

8.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 the procedures defined in [I-D.ietf-stir-rfc4916-update] and the VESPER framework [I-D.wendt-stir-vesper].¶

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.¶

9.1. 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.¶

9.2. 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.¶

9.3. 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.¶

9.4. 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.¶

10.1. 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.¶

10.2. 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.¶

10.3. 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.¶

10.4. 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.¶

10.5. 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.¶

10.6. 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.¶

12.1. Normative References

[I-D.ietf-httpapi-idempotency-key-header]

Jena, J. and S. Dalal, "The Idempotency-Key HTTP Header Field", Work in Progress, Internet-Draft, draft-ietf-httpapi-idempotency-key-header-07, 15 October 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-idempotency-key-header-07>.

[I-D.ietf-stir-rfc4916-update]

Peterson, J. and C. Wendt, "Connected Identity for STIR", Work in Progress, Internet-Draft, draft-ietf-stir-rfc4916-update-07, 7 July 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-stir-rfc4916-update-07>.

[I-D.sliwa-stir-cert-cps-ext]

Śliwa, R. and C. Wendt, "Call Placement Service (CPS) URI Certificate Extension for STI Certificates", Work in Progress, Internet-Draft, draft-sliwa-stir-cert-cps-ext-00, 5 September 2025, <https://datatracker.ietf.org/doc/html/draft-sliwa-stir-cert-cps-ext-00>.

[I-D.sliwa-stir-oob-transparent-discovery]

Śliwa, R. and C. Wendt, "Transparent Discovery of STIR Out-of-Band Call Placement Services", Work in Progress, Internet-Draft, draft-sliwa-stir-oob-transparent-discovery-00, 5 September 2025, <https://datatracker.ietf.org/doc/html/draft-sliwa-stir-oob-transparent-discovery-00>.

[I-D.wendt-stir-certificate-transparency]

Wendt, C., Śliwa, R., Fenichel, A., and V. A. Gaikwad, "STI Certificate Transparency", Work in Progress, Internet-Draft, draft-wendt-stir-certificate-transparency-06, 11 June 2025, <https://datatracker.ietf.org/doc/html/draft-wendt-stir-certificate-transparency-06>.

[I-D.wendt-stir-vesper]

Wendt, C. and R. Śliwa, "VESPER - Framework for VErifiable STI Personas", Work in Progress, Internet-Draft, draft-wendt-stir-vesper-05, 5 September 2025, <https://datatracker.ietf.org/doc/html/draft-wendt-stir-vesper-05>.

[I-D.wendt-stir-vesper-use-cases]

Wendt, C., "Verifiable STI Persona (VESPER) Use Cases and Requirements", Work in Progress, Internet-Draft, draft-wendt-stir-vesper-use-cases-02, 11 August 2025, <https://datatracker.ietf.org/doc/html/draft-wendt-stir-vesper-use-cases-02>.

[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, June 2002, <https://www.rfc-editor.org/rfc/rfc3261>.

[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>.

[RFC4122]

Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, <https://www.rfc-editor.org/rfc/rfc4122>.

[RFC6585]

Nottingham, M. and R. Fielding, "Additional HTTP Status Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012, <https://www.rfc-editor.org/rfc/rfc6585>.

[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>.

[RFC8785]

Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, <https://www.rfc-editor.org/rfc/rfc8785>.

[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>.

12.2. Informative References

[ATIS-1000105]

ATIS, "ATIS-1000105 - Signature-based Handling of Asserted information using Tokens (SHAKEN): Out-of-Band PASSporT Transmission Between Service Providers that Interconnect using TDM", n.d., <https://access.atis.org/higherlogic/ws/public/download/79509/ATIS-1000105.pdf>.