draft-wendt-stir-vesper — VESPER core specification — library

draft-wendt-stir-vesper (Wendt, Sliwa) is the normative specification for VESPER. Its full title is “VESPER — Verifiable STI Presentation and Evidence for RTU,” where RTU is right-to-use. I am the primary author. The conceptual context — what VESPER is, why the certificate profile is structured the way it is, the relationship to STIR/SHAKEN — lives on the VESPER topic page. This page covers what’s specific to this draft.

The draft describes itself as a profile for the use of delegate certificates in STIR. It does not define new PASSporT claims or new protocol machinery. It constrains how existing pieces — RFC 8226 certificates, RFC 9060 delegation, RFC 9118 claim constraints, ACME issuance, certificate transparency — are combined so that a verifier can learn something the base framework does not tell it.

What the profile requires

The certificate carries the binding. A VESPER delegate certificate MUST carry a TNAuthList naming the telephone numbers or number ranges it covers, a SubjectAltName dNSName giving the domain of the entity that holds the right-to-use, and an embedded Signed Certificate Timestamp proving the certificate was logged before use. Validity is short-lived. Those three elements are the profile: telephone-number authority, domain identity, and public logging, bound in one artifact that a relying party can check without a side channel.

Claim constraints are mandatory once you go beyond the baseline. A certificate authorizing any claim beyond iat, orig and dest MUST carry the Enhanced JWT Claim Constraints extension (RFC 9118). Unauthorized STIR claims MUST be listed in mustExclude, permittedValues MUST bound the ones that are permitted, and the baseline claims MUST NOT appear in mustExclude. The effect is that a delegate certificate issued for rich call data cannot be turned into a general-purpose signing credential — the certificate itself states the ceiling.

Publication is the domain operator’s obligation. The entity holding the right-to-use MUST publish its certificate at a stable HTTPS location under the domain named in the SubjectAltName, and the TLS certificate serving that location MUST match. That is what makes the domain claim checkable rather than asserted: two independently administered chains — telephone number authority and domain control — have to agree.

Issuance is bound and logged. Certificates MUST be issued as bound certificates, and the issuing CA MUST submit each one to a transparency log. Issuance runs over ACME extended with TNAuthList Authority Tokens (RFC 9448) and, where claim constraints apply, JWTClaimConstraints Authority Tokens.

Signing and verification are constrained, not advisory. An Authentication Service MUST construct the PASSporT, MUST sign it, MUST convey it with an x5u reference, and MUST NOT include any claim the certificate’s constraints do not authorize. A Verification Service MUST apply the checks and MUST reject a PASSporT that fails them.

The RTU Token carries the same proof outside SIP. It is a JWT signed by the certificate’s private key, and it exists because the thing it replaces — a letter of authorization — is not cryptographically verifiable and cannot be revoked. It MUST include the defined claims and MUST NOT include any claim the certificate’s constraints do not authorize.

Scope: telephone numbers, not SIP URIs

The profile is defined for telephone numbers. A SIP URI already carries a domain by construction, so the binding VESPER performs is unnecessary there. Telephone numbers are the case where authority over the identifier and control of the domain are administered by different parties under different processes, and nothing in the base STIR framework connects them.

Authority itself operates at two levels. A certificate scoped by Service Provider Code attests provider-level authority; a certificate scoped by telephone number attests authority over specific numbers. The distinction determines what a verifier can conclude from a valid signature.

Connected identity

The profile integrates with connected identity as specified in RFC 9970, which supplies the bidirectional authentication the one-directional STIR/SHAKEN model does not — the called party can assert its identity back to the caller under the same certificate-profile guarantees.

Design choices worth knowing

The profile is smaller than earlier VESPER drafts, and the removals are the design. There is no vper PASSporT claim: the trust signal lives in the certificate, so a PASSporT signed by a VESPER delegate certificate is an ordinary RFC 8225 PASSporT and needs no VESPER-aware parser on the wire. There is no Claim Agent — no intermediate entity asserting claims for someone else — because the responsible entity signs directly and further sub-delegation is handled by delegate-certificate mechanics that already exist. There are no VESPER-specific privacy modes; privacy comes from short-lived certificates and from keeping the trust artifact thin.

What that buys is deployability. Every mechanism the profile depends on is already specified and, in most cases, already implemented somewhere. The work VESPER does is in the constraints, not in new machinery.

Status

draft-wendt-stir-vesper-10 (5 August 2026), individual draft. Current revision and state on the IETF datatracker.